Search the Community
Showing results for '"original token"'.
-
What appears to be happening is that both the original token leaving the Original segment and the new token, leaving the Found segment, are both associated with the same Entity and therefore the Transfer Steps are trying to transfer the same entity. This is shown in the Trace when it says which entity it is trying to transfer. Therefore, when the second Transfer step attempts the transfer, it says that it cannot transfer because the entity is already in the middle of being transferred. It is difficult to determine why the process logic is having both tokens transfer the same entity, but the first thing I would suggest that you check is whether or not the Search step is finding the correct entity during it's search. Or if you are using the Entity Type property of the Transfer Step to transfer a specific entity, you might look to make sure you are transferring the correct entity.
-
Hi Everyone I seem to be having a problem with a search step with a transfer step following depending on whether a match is found. I'm sure this is due top my lack of understanding of tokens - apologies, I'm pretty new to Simio! As I understand it, the Search step creates a new token when the match criteria is found but retains the original token which continues through the process. I think the original token is causing the problem. I guess my question is; is there a way to suppress the original token (or destroy it) once the new token is play? I believe the original is trying to initiate an unwanted transfer step which is clashing with the wanted step, resulting in a runtime error. I've attached the error message which may help. Any help, advice or direction to texts explaining tokens would be very much appreciated. .......Dave
-
Thank you - fixed. Have re-jigged the logic so that nothing crucial happens with the original token.
-
I have seen this error before with transporter/entity transfers... You may have conflicting logic here.... i.e. an event occurs that triggers a token into a delay or wait step based on a condition before transfer can complete, yet during this duration another event occurs that wants the transfer to occur for a second time or the entity to be directed somewhere else...the original token is not released and destroyed first... simple solution... I used dummy nodes to shift the transporter\entities around based on a precedence constraint structure whilst clocking the time of the transporter\entity at each node. This worked like a bomb. Also, if you don't need the original token, destroy it or don't attach any processes on the line after it.
-
By default found branch (token) is executed first and then the original. This is unless you have a delay in found branch. If so, (and the delay is at least math.epsilon) original token is executed before the delay and than found token executes. If you can send a screenshot of your process it will be easier to give precise help.