problem with an ONS structure in Rslogix

Hi,

I'm having some problems with an ons structure in studio logix 5000.




I latch the process_all_off and sometimes I end up in this state. Not all is unlatched. But there is nothing that keeps them latched. I can manual toggle the bits. Now its only the generator that is on, on the picture. But the SLMS were also on. Was able to turn them of with toggle bit.

The unlatch van process_all_off doens't happen. So the ons is not reusable.

There is only one XIC for process all off, one OTU and several OTL in my program. What can cause this trouble? Because I need to be 100% this code works.

best regards,
Wesley

Delete the OTU Process_all_Off instruction. Or get rid of the ONS instruction.

Thanks for the response.

If I get rid of the OTU in that rung, what is the best place to put the OTU? Because its is a command that needs to happen when the process_all_off is latched. Why is it bad to have the otu in that rung? Just curious, there is something happening I don't understand.

If I remove the ONS, than the instruction will keep onrunning until an OTU happens. There is an otu in the rung. So the instruction just will happen once?

If you remove the ONS instruction alone, the rung will be true for one scan after Process_all_off becomes true.
The ONS instruction has a built in memory of the false to true transition and the OTU you put on the end of the rung is apparently messing with it. Another way of doing this is to replace the OTU with a OTE of a temporary bit. Then add a rung below that uses that temporary bit to unlatch the trigger.
Assuming you only want the memory bits to unlatch on the false to true, I prefer the additional rung with the temporary trigger unlatch.

For readability and ease of debugging, try to minimize the use of latches; you'll thank yourself later.

Ingis said:

If I remove the ONS, than the instruction will keep onrunning until an OTU happens. There is an otu in the rung. So the instruction just will happen once?

Click to expand...

In short, yes.

jstolaruk said:

If you remove the ONS instruction alone, the rung will be true for one scan after Process_all_off becomes true.
The ONS instruction has a built in memory of the false to true transition and the OTU you put on the end of the rung is apparently messing with it. Another way of doing this is to replace the OTU with a OTE of a temporary bit. Then add a rung below that uses that temporary bit to unlatch the trigger.
Assuming you only want the memory bits to unlatch on the false to true, I prefer the additional rung with the temporary trigger unlatch.

For readability and ease of debugging, try to minimize the use of latches; you'll thank yourself later.

Click to expand...

thank you very much for you insights.
You are talking about not using latches, but If you want, like in my example, to have a rung done one several occasions, how would you handle that?

I now need to do the process off on 15 occasions. Easiest was to latch and than the corresponding run happend.

best regards,
Wesley

The trouble with excessive use of latches is that its hard to know which rung of logic triggered the latch. In your example, I would make (and different programmers would do it in different ways) Process_All_Off a DINT tag and each rung that wants to perform that function would set a different bit. Then, in the displayed rung, I would test for non-zero, reset all of my latches and then clear Process_All_Off. At least then I would know which rung cleared these memory bits by knowing which bit in the DINT got set. But again, there a lot of different ways to skin a cat.

The problem could be the location in the logic of one of the Latches for Process_all_off.

If the condition that latched it on existed for more than one scan, then the logic in the rung would execute, unlatch Process_all_off, then before it cycles back to that rung, latch it again. Because it only scans the ons when the program cycles back to that rung, it never sees the transition from ON to OFF, so, as far as the ONS is concerned, Process_all_off was never unlatched, so it will not pass a true again until it sees another transition (which, if the OTU in that rung is the only one, will never happen again).

deleting the ONS will ensure that if Process_all_off is true, that rung will execute, even on consecutive scans that it is relatched, and will shutdown the generators etc.

here is the problem with multiple latch / unlatch instructions.

let's say you have 15 latch bits B3/132 in 15 different locations.
multiple unlatches as well.

all is well for 6 months or a year, 3 years.
3 years later, something goes sideways and you or a mechanic tries to debug the program. after a couple of hours of digging and searching, you want to strangle the guy who wrote the program. WHY, you forget what you did and why.

I had that very issue 10 years ago.
18 latch bits of b3/xxx and 14 unlatch b3/xxx.
No I didn't write the program, an oem did and that person left the company.
production went to 60 percent and after 3 days of looking at the program with a co worker, we decided to rewrite the program.
it took 2 weeks to do it, and my co worker reviewed my program and we made changes. 2 days later, we were up and running, with any issues easily corrected.

Yes, I had latch bits in the program (only 1 per bit) and 1 unlatch.
the unlatch bits were grouped at the end of the cycle for reset.

james