Ah yes, the old works-in-autostep-but-not-when-out thing…
Usually you hit this problem when working with communications, either serial or Ethernet, but I can see how the same problem is snagging your charts here.
The problem is that the controller is too fast for itself.
When it’s in autostep mode, the controller slows down that chart enough that it has time to handle everything the way you expect.
When it’s out of autostep, the controller is switching the charts so fast that it does not have time to do the commands that the chart itself is trying to do.
It takes many 10’s of milliseconds for the chart commands you are using to complete. The reason for this (I believe, we can check with the firmware guys to be sure, but this is the rough outline I was given when it happen to me) is that there is some overhead in the ‘stack’ inside the controller that has to be taken care of AFTER you issue the command.
I see that you had a loop to try and detect this, not entirely sure why this method did not work, I suspect it was because the loop itself was in one of the ‘run too fast’ charts.
Bottom line, you need to throw a few delays in there after calling or continuing your charts.
If it were me, I would make the delay a variable and that way you can tune it a little to make sure you have the shortest delay needed to ensure it works reliably every time.
I suspect that you are going to end up with something like 50 to 100 ms.
You have to allow enough time for the stack to be dealt with when the host task runs.
Remember, the more user charts you have, the less often the host task will run.
Also, keep in mind that if you do all this in debug mode from PAC Control, this will have an effect on the delay needed as well.
I often used a spare digital out to flash an LED so that I knew where things were up to on these sorts of timing issues.
Of course, if it’s not super critical, you could just throw in a ~150 ms delay and it would ‘just work’ and you could get on with the next task on your list…