AGV.currentCP sometimes giving NULL value

[clairekruppGhafari]

[ FlexSim 23.1.1 ]

I am using the following code to find out which CP the AGV has arrived at:

99% of the time this works fine, but every once in a while, it gives a NULL answer and then the parking and other logic using "curcp" doesn't work.

I think it is connected to the Time Tables. The AGV for the token above had just about reached its destination when the end of shift happened. When the down time finished the token immediately went through to the next activity, without having an AGV arrival event.

I have also had some occasions when it seems that the AGV "forgets" the currentCP if you have other activities in between the end of travel and the currentCP command.

Is this related to the Release Notes for version 23.1.2/23.0.8?

If not, I can send you my model.

Thanks,

[jason_lightfoot_adsk]

Please post the model Claire - a small test model doesn't elicit the behavior you describe.

BreakdownAndShiftMidAGVtravel.fsm

[philboboADSK]

Change your code from currentCP to recentCP.

https://docs.flexsim.com/en/23.1/Reference/CodingInFlexSim/FlexScriptAPIReference/AGV/AGV.html#Prope...

[clairekruppGhafari]

I'm doing that now....

[clairekruppGhafari]

Thanks, I'll try it....

[clairekruppGhafari]

It's sent. The problem has to do with Event sequence after a Down Time happens. Details in the email.

[clairekruppGhafari]

Well it kind of works - it gives a valid CP, which gets rid of the exception error, but it's only a transit CP so the parking logic does not execute. The AGV will just stay there until called for the next task and could possibly block the next arriving load.

[philboboADSK · Accepted solution]

After looking into this model deeper, we found that this is an AGV module issue. Here's what's happening:

When the AGV is stopped, it decelerates to a stop. Its current arrival event's time is then truncated to the time when its deceleration will end in order for it to stop at that point.

Normally, this is in the middle of a path, but in this particular situation, that time is after the time when the AGV would arrive at its destination.

When the AGV comes back up, it creates a new task to continue traveling to its destination.

In this case, the AGV has already reached its destination during the stopping deceleration, so it immediately ends its travel task without going through the process of traveling to it (which is why currentCP wasn't set).

I was able to replicate the issue in a small sample model, so I'll add that to the dev list to look into.

Rather than hardcoding the CP in your band-aid, you could use the destinationCP rather than finding it by name.

if (curcp == NULL)
  curcp = AGV(token.agv).destinationCP;

This would be a more robust workaround for other times when this might happen rather than just fixing this one particular situation at one particular CP.

[clairekruppGhafari]

I put the following band-aid fix in until the root cause error can be fixed:

[carter-walch]

Hi @Claire Krupp, was Phil BoBo's answer helpful? If so, please click the "Accept" button at the bottom of their answer. Or if you still have questions, add a comment and we'll continue the conversation.

If we haven't heard back from you within 3 business days we'll auto-accept an answer, but you can always unaccept and comment back to reopen your question.

[clairekruppGhafari]

Thanks @Phil BoBo