Studio 5000 Program Scan. Why Do My Lights Flicker?

[@DaDaDaddeo]

This video is great at explaining the I/O control on the CLX. Unpredictable output reaction like that should always be a concern all automation programmers. The same test can be proven accurately by adding a new task with a delayed time period such as the default 10ms. Place a counter (or Add +1 instruction) in the new task to determine how many times the output bit is caught being on "when it's not supposed to". This will illustrate how the task logic is independently running just like the embedded I/O. If there is a concern about even the slightest output chatter, the counter never lies. The best rule of thumb is to know the control system, eliminate warnings the same way you would heed all warnings from a C++ compiler, and run simulations.

[@TimWilborne]

Great tips!

[@DaDaDaddeo]

I forgot mention to add an ONS if you want to count only the single detection of the bit being on. It may not matter much regardless unless you slow the scan rate like Tim does later in the video.

[@DaDaDaddeo]

This video should be an eye opener and this topic should be a must for all programmers. All conditions, not just I/Os can be misread in separate tasks when sharing global tags that can change state in multiple locations. Even good practices such as using OTL and OTU instructions and not using AFIs will not matter. I am definitely in the camp of batching global tags (including I/O) that are shared with other tasks and that conditions to handle these tags are kept within the same synchronous logic.

[@TimWilborne]

Very true

[@seeigecannon]

I wish Studio 5000 (or any PLC IDE really) had a trace button like Labview. It is so useful to watch one instruction happen at a time (even if it would have some problems translating to full speed again). I was once racking my brain for a long time trying to basically figure out why an ADD instruction was giving me 3 for 1+1, turned out I was writing to that variable elsewhere from the first time I tried implementing that feature.

[@TimWilborne]

I should do a video sometime on how I debug programs. The big problem I see people do is exactly what you are asking for. They start at the top left and try to trace the logic to the bottom. The key is to start at the result and work your way back using the cross reference.

[@TheDrewbe3]

Interesting. I was not aware that a physical output would update immediately upon going high. For some reason I was thinking it waited until finishing the ladder scan.

[@TimWilborne]

It isn't that they are updated immediately, it is that they are updated asynchronously based on the RPI of the particular IO module.

[@jgomez7535]

Great explanation of AFI. Allways writing zero, dependant of scan time, RPI and used to temporarily troubleshoot

[@TimWilborne]

Glad it was helpful!

[@darthenx2585]

Bummer I missed this live. I would have asked to see how you would of prevented it?

[@TimWilborne]

Prevented the watchdog fault...? Let me do some thinking :)

[@darthenx2585]

@@TimWilborne no prevented the light from turing off, but still leave the AFI or alternate option, in case you needed to block a rung on purpose.

[@TimWilborne]

Ah, good point. There are a few ways, I'll follow up next week.

[@TimWilborne]

Here you go. kzbin.infoqLXBDobuA2U?feature=share

[@electrician240]

Thanks for all your videos! I started watching your video's thanks to eric!

[@TimWilborne]

Glad you like them!

[@randycort3142]

Tim, this was a very cool and interesting video.

[@TimWilborne]

Glad you enjoyed it

[@darrelljourdan9926]

Very interesting

[@TimWilborne]

Glad you think so!