Figure Out Which Input Shut Off First

[JoeB7774]

Hello. I mostly use basic logic operators so this might be a little over my head but I'm trying to figure out a way to tell me which input shuts off first from a list of inputs. Lets say I have five inputs (1,2,3,4,5). I have a program where, if one shuts off, they all shut off (which I've got working fine). I need to figure out which was the one that shut off first (and triggered the rest to shut off). I need to output that value onto a screen (maybe a message or a number of the motor) or to an LED light (I could have a light beside each motor button). Any ideas on how to do this?

 

[I_Automation]

I add traps. I do this for troubleshooting why something is turning off, or on, in running machines frequently.



If input 1 is OFF and the rest are ON then latch or set a tag Input_1_First


Do this 5 times, once for each input. Have the latched tag display the correct object on the HMI


Add a way to reset the latched bits - either by operator button or automatically reset when the system starts again.

 

[plvlce]

Fairly straightforward.

When all inputs turn on, set an integer variable to 0
When input 1 turns off, set the value to 1 IF the value is still 0
When input 2 turns off, set the value to 2 IF the value is still 0
(continue pattern for other inputs)

Whichever input turns off first gives its value to the integer. Since the integer is no longer 0, the other inputs turning off does not change the value further, leaving you with a value that corresponds to the input that first turned off.

 

[parky]

It depends on how fast the other inputs shut off, for example due to the scan time of the PLC & inputs are normally updated before the scan of the program so for example if the scan time is 50ms and if more than one input would shut off within 50ms of the others then normal programming will not work, but if the delay between the first input shuts off is greater than say 2 x the scan time you could probably detect it.
The other way is to use input interrupts so when an input goes false then this interrupts the program, you could put a number in a variable corresponding to the input that went false, however, not sure if input interrupts run on both rising edge & falling edge & disable the interrupt so it is not repeated, then re-enable the interrupt on a start.
It will depend on lots of things for example do these inputs all stay on during normal running ?.

See here :
https://www.geeksforgeeks.org/interrupts/
If this could be done within the scan i.e. it is unlikely that more than one input would go false within say 2 scan cycles then it is pretty simple
Just do the following
However, you may need a start up timer or some other method to disable these rungs here it is assumed that the start of the process will reset the latch & zero the input number var.

 

[drbitboy]

A little De Morgan, plus two handfuls of the the always useful, canonical Start/Stop Circuit pattern, gave me this approach.

B1-B5 are the bits that are

• EITHER to be turned on by buttons B1_START-B5_START,
• OR to be turned off by buttons B1_STOP-B5_START,.

Bits B1_LED-B5_LED indicate which B Stop button was most recently pressed while its corresponding B bit was on.

In this first image,

• three of the five "B" items are 1, and
• all of the LEDs are 0

​

In this second image,

• the B3 Stop button has been pressed and released since the first image,
  • which assigns a value of 1 to only the B3 LED bit, and
  • that LED causes values of 0 to be assigned to all B items:

​

In this third image,

• the B2 Start has been pressed and released since the second image,
  • which causes a value of 0 to be assigned to all LED bits, including the B3 bit which was the only one that had a value of 1, and
  • also assigns a value of 1 to the B2 bit:

​

 

[JoeB7774]

Thank you all so much for the information. As I said I am very new to this so I will make sure to read through your posts and get started. Thanks again. It is very much appreciated.

 

[cardosocea]

Fairly straightforward.

When all inputs turn on, set an integer variable to 0
When input 1 turns off, set the value to 1 IF the value is still 0
When input 2 turns off, set the value to 2 IF the value is still 0
(continue pattern for other inputs)

I would take this further and instead have an array with say 10 positions and a pointer.

If all positions are healthy, pointer gets set to 0 (points at the first element).

If input 1 changes, copy 1 into the pointed variable and increment pointer by 1.
if input 2 changes, copy 2 into the pointed variable and increment pointer by 1.

This could potentially provide a better picture of the sequence of events.

Assuming the PLC platform in question maps inputs into an INT and all required inputs are on the same card, I would simply have the value of that INT copied into an array should it be different (some masking may be required) from the previous value. Then it would be a matter of some logic or condition to reset this (most likely tied to an alarm reset).

 

[plvlce]

Assuming the PLC platform in question maps inputs into an INT and all required inputs are on the same card, I would simply have the value of that INT copied into an array should it be different (some masking may be required) from the previous value. Then it would be a matter of some logic or condition to reset this (most likely tied to an alarm reset).

I had thought of this, but OP did not provide any info on PLC to know if it would work (ie if inputs are mapped to a word), so I provided an answer that was agnostic as to whether that was the case.

I would take this further and instead have an array with say 10 positions and a pointer.

If all positions are healthy, pointer gets set to 0 (points at the first element).

If input 1 changes, copy 1 into the pointed variable and increment pointer by 1.
if input 2 changes, copy 2 into the pointed variable and increment pointer by 1.

This could potentially provide a better picture of the sequence of events.

Per OP's post, the sequence of events is that once any of the inputs goes off, that is triggers logic that results in the others going off. All he needs is to know which is the one triggering the shutoff.

There's not enough information about the situation to say for certain, but it doesn't sound like further details about the shutoff sequence are going to be helpful.

Where I might use an array is so that multiple shutoff events can be tracked to easily see if one input is consistently the cause.

 

[joseph_e2]

Here's something I did in a ControlLogix that has a series string of conditions to allow a mill to run. It was sometimes hard to identify what caused it to stop, since the mill stopping caused other things to happen very quickly, or the stop event would be too momentary to catch.

The screenshots are the order in which they're processed in the PLC (0, 1, 2), but I'll explain a little out of order.

Screenshot 1 shows the rung that has the series string of conditions that all enable LT_MillRun. In order for LT_MillRun to turn ON, all of the input conditions must be in their OK state. If any of those conditions change to not OK, LT_MillRun will turn off, so we have to check the status of the input conditions BEFORE LT_MillRun can turn off. For readability, I separated the traps into several rungs that are right ABOVE the rung that controls LT_MillRun (see screenshot 0 for an example). Right after LT_MillRun's rung, I have a MOV instruction to transfer the trap bits to a holding register and another MOV to reset the traps when the Mill is restarted, leaving the storage location unchagned. That way, if the operators have to reset and restart quickly, they can look back and see what went wrong after things calm down some. Those bits are on the HMI.

Incidentally, in the tag comments, you can see notes from when the code was translated first to PLC2, then to PLC5, then to ControlLogix over the years.

 

[JoeB7774]

Thanks again for all the ideas. I'm really new to ladder logic and am much more familiar with function block. I would like to try this in both languages to make sure I'm building the ladder correctly. Which FBD should I be looking for in Unity for the latching/bit parts? I see a "SET_BIT" which I think looks like it will do the trick but thought I should check.

 

[JeremyM]

Could try this:
https://github.com/JeremyMedders/LogixLibraries/blob/main/src/Process/Op_Interlock_AOI.L5X

Includes first-out indication for up to 32 monitored inputs.

 

[drbitboy]

Thanks again for all the ideas. I'm really new to ladder logic and am much more familiar with function block. I would like to try this in both languages to make sure I'm building the ladder correctly. Which FBD should I be looking for in Unity for the latching/bit parts? I see a "SET_BIT" which I think looks like it will do the trick but thought I should check.

It seems like SET_BIT may be out of date, but who knows.

What you need is a latching circuit, like @joseph_e2's example, or mine; cf. the Start/Stop Circuit pattern here; my example was basically nothing but that pattern repeated over and over (it's very useful).

Here are two examples of how to make the equivalent circuit in FBD:

https://youtu.be/PV4psdgbVk4?t=454
https://www.youtube.com/watch?v=J0nCeEC-sCE​

 

[parky]

Set/Reset bits has been about since the introduction of PLC's, as is the seal in circuit, some people prefer the seal in as effectively the set/reset is on the same ladder, there is also a SR or RS this is a function which is the same but both the SET & Rest is on the same ladder, It sometimes makes sense for clarity to have both on the same rung as doing many set/resets throughout the program can make it difficult for others & probably the original coder to either understand or debug a program. In saying that, it can make sense to seperate them & use the scan of the PLC as perhaps it may be essential to reset after scanning other logic but reset the bit after 3 or 4 rungs.
It does seem that in america at least the seal in seems to be preferred perhaps it's a cultural thing, in Europe the opposite is true, I do agree that seal in seems to be easier to understand providing you understand how different types of logic works. TBH it's a matter of choice or perhaps to some it makes sense.
The one problem with seal in circuits is many platforms do not allow the use of multiple out coils (or give you warnings) so you have to use seperate coils
for the latch, not normally a problem but can make the logic larger as you have to interlock the following check rungs so it does not also trigger another message or bit.

 

[drbitboy]

This is in Siemens LOGO!Soft; it should be similar to most FBD dialects.

Each ≥1/&/Q (OR/AND/Output) triplet is a Start/Stop Circuit pattern for each output or for each LED, with the outputs' combined state (≥1• i.e. NOR) and LEDs' combined state (≥1• i.e. NOR) driving each other's Stop logic (&). The only non-standard part is each Output's feeding back into the Start logic for each LED, so each Stop button can only turn its output off, and its LED on, if its output is already on.

This shows but four LED/Output pairs because the NORs have but four input pins; it would be expanded with more NORs combined with an AND to handle more LED/Output pairs. If Unity does not have ORs or NORs with more than two input pins, or if it cannot negate input and output pins, then it could get ugly, but the basic approach is the same.

​

 

[drbitboy]

This is in Siemens LOGO!Soft...

P.S. If using latching relays (Set block and Reset block pair, or a single Reset/Set block, see below), then

• use the one that is Reset dominant to replace the ≥1/& pairs, and
• the NORs combining Outputs' or LEDs' states will change to ORs

​