One Shots on AB L35 Processor

Hey folks.

I have a machine that has a L35E processor running the system. Unsure of I/O usage but also have a top server accessing the tag database and manipulating some bits as this machine interfaces with another. I also have messages sent via ethernet from another processor.

I have had a strange occurrence and need some input & advice.

Seems that SOMETIMES a one-shot instruction doesn't get executed! I have an instruction (ONS) to unlatch a latch bit. I verified the latch wasn't used more than once as well as verify the latch wasn't being set at the same time as the unlatch.

When I use the ONS instruction, SOMETIMES the unlatch worked and sometimes it didn't. I changed the logics to use a timer that creates a 200millsecond pulse instead of the one shot. The timer pulse worked every time. I verified by changing back to the ONS and it failed. Back to the timer and it worked and has continued to work. I also have ONS's that trigger ONS's. It that acceptable logics?



Can somebody shed light????



n.

You can use latch and unlatch instruction more than once. ave you used the ONS bit only once? Can you post the program?

Of course makes sure that the bit used by the ONS instruction is not used in more than one place.

Is the ONS actually on the same rung as the latch instruction, or is there a chance there is a "scan race" condition that the timer overcomes by allowing a bit to remain true for several PLC scans ?

Can you post the program ?

Also make sure the Bit Address (TAG) is not used somewhere else with a Cross Reference. It has to be unique. As Ken requested, posting the PLC Program File will allow us to help you out the most with this. (Zip it First - Forum Rule)

Stu....

Also make sure that the ONS and the OTU insturctions are in the same task. If they aren't in the same task then they won't be processed in the same scan.

Memory writes from other devices (HMIs, other PLCs, etc) are asynchronous to the scan. The write could very well happen half way through a rung. If that can be a problem then buffer the bit, eg, write its status to another tag at the beginning of the scan and use the second tag in the program.

JiNCs said:

Hey folks.

I have a machine that has a L35E processor running the system. Unsure of I/O usage but also have a top server accessing the tag database and manipulating some bits as this machine interfaces with another. I also have messages sent via ethernet from another processor.

I have had a strange occurrence and need some input & advice.

Seems that SOMETIMES a one-shot instruction doesn't get executed! I have an instruction (ONS) to unlatch a latch bit. I verified the latch wasn't used more than once as well as verify the latch wasn't being set at the same time as the unlatch.

When I use the ONS instruction, SOMETIMES the unlatch worked and sometimes it didn't. I changed the logics to use a timer that creates a 200millsecond pulse instead of the one shot. The timer pulse worked every time. I verified by changing back to the ONS and it failed. Back to the timer and it worked and has continued to work. I also have ONS's that trigger ONS's. It that acceptable logics?



Can somebody shed light????



n.

Click to expand...

When you are one-shotting one-shots, perhaps you should rethink your logic structure.

I make a habit of describing all one-shot bit storage addresses as "1Shot". Say no more. These bits are not to be used or referenced ever again, and I will have more than 16 of them in most more complicated programs. So, when I read the logic, I know what they do to all the conditions after them...it says 1Shot right over the ONS.

If I see them listed in usage, I know they are of no external value, just a reserved bit, local to the program if possible.

Now, OTE outputs after them all have their descriptions prefixed with "1Shot" followed by a description of function, like "1Shot PLC Clock Just Passed Midnight"

So, when I am using that bit or seeing it used in ladder logic, I know right off the bat that it is only going to blink for one scan of that individual program.

So, if you are relying on the OTE of a 1Shot in another program, it's certainly possible you have a multi-tasking/scheduling thing creating havoc. Seeing the code would help as Ken Roach suggested.

If I am firing OTL instructions from one program, with a 1Shot instruction, there is often a cleaner method to build the rung with a sealed/broken OTE instruction. The advantage to this is readability.

I use 1Shot to latch instructions infrequently for making toggle states/modes, to capture events that interface programs together and so forth. Things I need to survive a power cycle, and I don't worry about keeping the multiple destructive instructions together in the logic necessarily.

I have seen C programmers go apesnot with latching instructions when they learn to program ladder logic, to me, those crazy to follow and debug programs and the PLC world's best example of spaghetti code.