Chart continues when in auto-step but not in step-off


#1

I’ve got a chart that starts another chart then suspends itself. I could have used call chart, but I sometimes need the calling chart to stay suspended. The called chart then attempts to continue the calling chart when its commands are done and stops.

Sometimes this works for a few cycles, sometimes the called chart is stopped and the calling chart is still suspended, apparently never continued. I’ve put a loop in the called chart to check if the calling chart is running and if not, continue it again. That didn’t solve the problem.

The wrinkle is that if I put the calling chart chart in auto-step mode, the starting, stopping, and continuing of both charts works perfectly.

What am I missing?


#2

Jblinks,

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…

Ben.


#3

Thanks Ben.

That worked great. I had already tried letting the charts give up their time slice by putting a delay of 1 msec in. That didn’t work, but kicking it up to 50 msec did the trick.

Thanks again.


#4

Hi All,

Just to add a bit to something Ben mentioned:

… used a spare digital out to flash an LED so that I knew where things were up to on these sorts of timing issues.

There’s also the handy [B]AddMessageToQueue[/B] command. (For you programmers out there, this could act like a debugging PRINT or printf.)

The command will spit out info on what’s happening where/when. Just be careful since you can fill up your 1000-message queue fast if you call that in a loop. Usage may look like this:


//4 = Info
//8 = Warning
//16 = Error
 
//The queue holds a total of 1000 errors and messages. 
AddMessageToQueue( 4, "About the call chart XYZ" );


Just don’t forget to rip them out when you’re done troubleshooting!
-OptoMary


#5

Just for my own memory on the subject, due to the changes in architecture from OptoControl to Pac Control, isn’t there an issue with starting and stopping charts on a regular basis? If memory serves me, the time to start or stop a chart in Pac is much greater than in OptoControl and less deterministic as well. I think this is due to the CPU OS which requires the CPU to look at a whole host of items (I can’t quite remember the exact process) before actually starting or stopping a chart which can, depending on the size of the strategy and number of charts, delay the action for up to 100ms. This is why I approach a strategy where I use as few charts as I can, and I only start them once and let them loop, unless their operation is very infrequent. It seems to me that it is just fine to let a chart loop on a 1 ms delay if you want it available to run upon a condition or event. On the other hand, that can also be done as well in your main chart if your strategy is built the way I do mine where I provide a flow through path on a main logic tree. In this design, you can put whatever conditional branch you want in the tree to branch for a specific operation as long as the execution of that operation required is not more frequent than the loop time of your main logic. In most all the cases I come across, the main loop time is going to be less than 100 ms. and if the strategy is not large, it can be less than 10ms.
What I cannot remember is whether the suspend or continue or pause chart commands have the same limitations.


#6

A couple more comments appeared related to this topic on LinkedIn, in particular, we had a reply:

To my understanding, the chart control commands Call, Suspend, Continue do not have the limitations of the Start & Stop commands.
Using Subroutines is also recomended.

To which Barrett then replied:

I would like to see a confirmation from Opto on that point. I agree on subroutines, they are very powerful but it has been awhile since I have made any myself. I have used the Modbus RTU sub and the most powerful thing about them is that you can use the same sub simulatneoulsy multiple times in a strategy to greatly increase processing and capability. I had a strategy where I used the RTU modbus in two seperate chartes running in parallel to talk to 9 vfd drives through 5 rack mounted serial ports.

I especially like Barrett’s point about how you can use the same code, if it’s in a subroutine, simultaneously in multiple charts at once.

In general, if you’re concerned about start-up time for charts, the methods mention above – where the chart is started but looping, waiting for a “go” flag – work well. I’ve asked my favorite expert about the other chart commands. Stay tuned…

-OptoMary


#7

Hi All,

Here’s what I learned from our in-house expert: “Part of the delay is because we use a [OS] message to start a chart; we use a [OS] message to continue a chart, so there can be some delay there, too. The continue doesn’t have to allocate a [chunk of memory], though, so it should be a bit faster.” (That’s in theory, we haven’t done benchmarks, however.)

So, again, if you’re concerned about speed, you can use a loop in the chart that’s waiting on a flag set in another chart to give the “go” signal.

-OptoMary


#8

Mary,

I think I orginally spoke to Bryce on this and his explanation did not include that fact that the OS uses internal messaging, however, it was considerably more complicated than just a message delay. I would use Call Chart and Pause and Continue if was sure that the overhead or delay time was not considerable (more than 1-2 ms.). Even though even 50ms might not be a problem, the problem with that is why create possible headaches that may be hard to realize the cause? I am spoiled with the speed of the Pac controllers. I keep comming across other programmers who jump through hoops becuase they think the controller isn’t fast enough when in reality, they have created huge program delays by poor practices and compond that by trying to fix it…
Another point I would like to make is that I think many users use additional charts to try to make their program more logical or sort of a means of documentation without documentation. I constantly find that the documentation is at least as important for my own benefit than for anyone else. The older you get the harder it becomes to remeber what wild scheme you last cooked up, and of course it may be completely legitimate, however, not everybody thinks the same way and may consider your genious scheme to total rubble, noot mention what they’re saying under their breath as they try and reverse engineer it.


#9

There is one thing that I want to add to this discussion. Along with the “Start Chart” command taking ±100mS, there is a longer and indeterminate time period for “freeing up” the timeslice from a chart that ends. In the old case of having chart A start chart B and end, then have chart B call chart C and end then have chart C call Chart A and end when you have more than 32 charts to run, you can run out of time slices in which to run charts even though you do not have more than 32 charts running. It happens because chart B can finnish running and start chart C, but the timeslice from chart A is still not free’d up. thus you hit a point where the chart being started has no timeslice to run in so it doesnt run, and the whole loop of charts stopps.


#10

Hi Adern,

Re:

…the chart being started has no timeslice…

Thanks for pointing this out. Sounds like this would be a good place for a little error checking (where you could check the status coming back from Start Chart, make sure it succeeded, and if not, try again a few ms later for some reasonable number of attempts).

Also, rather than having A start B which starts C etc., a more maintainable setup might be to have one master chart that does all the starting. That way, if you no longer need Chart B in you strategy, for example, you don’t have to fix the chain by changing A to no longer start B and something else to start C. You just change the one master/supervisory chart. Make sense?

One last thing I should mention since we’re talking about pushing the number of timeslices: our lovely new-ish “Start Alternate Host Task” will also take up a time slice.

Thanks,
-OptoMary


#11

Also, for those of you watching the status of your charts closely, you’ll find that starting in firmware version R9.1d, the [B]Get Chart Status[/B] command will return more info:

Bit 17: Starting (0 = chart is not in the process of starting; 1 = chart is in the process of
starting or is currently running)

Updated documentation coming soon. Be sure to subscribe to OptoNews so you don’t miss any important updates!


#12

Just to quickly throw my 2cents into this one…

Another way to handle this starting of charts is to make sure you always have less than 32 or 16 charts and to have them run all the time…
No really, if you have less than the maximum amount, you could just leave them looping all the time.

Another way is to have them looping straight after Block 0, looking at a ‘Is Variable’ flag ‘True’ with something like a 10ms delay in that loop.
Your master chart then toggles the flag for each chart when its needed.
This way your chart is giving up lots of time slices and only runs when you ask, and it does so within ~10ms. (or what ever you put your delay to be).

Ben.