Controller running too fast?

[Arlin]

When reading the latest Opto Newsletter I was struck by a comment that Ben Orchard made in the Tech Tip. The tip revolved around how sometimes issues are non-existent when running through things with Autostep turned on but are problems when Autostep is off. Ben's quote was "sometimes the controller is too fast for itself".

I have seen this issue a number of times in a variety of scenarios. Usually I try to get around it by simplifying programming or finding an alternative means. I'm wondering though, is this a consistent issue with the controllers? I've seen situations where the controller seemingly skips lines of script code (especially when it's a fairly lengthy chunk of script) if I don't throw in delays to slow it down. However, it seems to happen somewhat randomly which makes it incredibly hard to replicate (and make tech support believe me :p). Has anyone else experienced this or am I way off in left field on this one?

[mstjohn]

Hi Arlin,

The "skipping" code thing, I'll bet you a nickel, is another timing-related situation like the one described in that [tech tip. The [URL="http://www.opto22.com/community/showthread.php?t=197&p=559&viewfull=1#post559"]AddMessageToQueue suggestion](http://www.opto22.com/site/optonews/2012/optonews_01042012.aspx#ttip) I posted later in that discussion might work in your situation to help figure out the path through your code that happens at full-speed vs. autostep (or something with delays).

Of course, adding those messages to the queue also takes a little time (something of a Schrödinger's cat situation where the observation part affects the experiment itself).

In any case, I hope you'll continue to share whatever you learn and observe, and that no cats will be harmed in the course of your experiments.

-OptoMary

[Beno]

Gudday Arlin,

Wow, yeah, I can see how that got stretched a little!
My point was the controller is too fast for the device its talking to, not so much itself.
In the 24 (25 years this October) years I have been using Opto 22 gear, I have never heard or seen what you are describing.
As Mary said, every time I see something that smells like that, its turned out to be my code.... And a whole book could be written on the bugs that I have caused over the years!

Im currently in Australia consulting on a project that has around 180 serial devices, we have seen some really 'interesting' timing issues with them.... and that's not including the topic of working in autostep on, but not when its off!!!
My point is that when talking to external devices, timing can become a grey area and you need to keep your wits about you.

Cheers,

Ben.

[Arlin]

Hi Ben/Mary,

I see where you're coming from on the whole "controller too fast" when communicating with external devices. I didn't mean to misconstrue your comments, rather it jogged my memory on this particular issue I described earlier and I was curious if anyone had seen anything like it.

If my memory serves correctly regarding the last time I saw the issue I described, there was a single if/then statement controlling whether the contents of the code would be executed. The statement was true however the code was failing to execute. Now I do agree, sometimes even if a guy were to watch variables, things refresh or occur much quicker than our eyes can see so I will try Mary's AddtoMessageQueue idea next time I run into this one to actually log it to see what I'm really missing.

[Barrett]

This reminds me of a script I wrote where I was getting serial data from a Badger mag flow meter and the serial port data on the Badger was transmit only once a second. Of course since it was transmit only, I had to come up with some means of determining if the data was good each time before accepting it. The real story hear is that I also could not control the stream of data either. When I first started the script up where I was listening to the serial port and looking for a string, I realized the reason it wasn't working is that the string I was looking for was being recived and processed one character at a time instead of getting the whole string in the buffer. I had to put a timer in there to wait for the whole string (but less than the whole streaming second) instead of getting the string each time the logic loop executed. Now keep in mind, this logic was in series with all the other logic on the R2, and yet at 9600 baud, it was picking off each individual charachter of the string and trying to process the string with only one charachter.
This should give you an idea of how fast these CPU's are.

[Travis]

I have had issues in the past where it seemed as if the controller was "skipping" portions of my code when not in auto step. This is reliably remedied by adding a brief delay (>500ms) between lines of code. I have have never been able to get to root cause of the "skipping"issue, and I am sure it is caused by an inadvertant error on my part, but the delay makes it go away.

[Barrett]

All,
It's not that the controller is too fast (we all want fast controllers) it's that you're not taking into account how fast the controller is....