Detect change in integer

I was wondering if anyone has any ideas on how to detect change in an integer in a SLC 5/04.

We have a machine that runs 3 different parts. Each part has roughly 40 integers associated with it for timer and counter values mostly. Values are part dependent and can be modified on a Panelview.

We are having issues with values being changed and I am trying to come up with a way to detect if they have changed from the known good value. The only thing that I can think of is to use a bunch EQU instructions.

What usually happens is the machine will start running poorly because someone messed with timers and it is a booger to get set right again. We are trying to get some accountability and would like to know when it is changed so we can react sooner.

NEQ N7:0 N7:1 BST OTE B3:0/1 NXB MOV N7:0 N7:1 BND

B3:0/1 will be true every time N7:0 changes.

dmroeder said:

NEQ N7:0 N7:1 BST OTE B3:0/1 NXB MOV N7:0 N7:1 BND

B3:0/1 will be true every time N7:0 changes.

Click to expand...

Specifically, B3:0/1 will turn true for one scan every time N7:0 changes.

You could use an OTL so that the bit is latched on when you come back looking later, or you could use that one-scan bit to e.g. record a timestamp. Depends how creative you want to get.

Yes, as previous posts, to elaborate you load the variable_A & compare it with another variable_B, if different then it has changed so equal or set a bit or what ever you wish to do and then copy or move Variable_A to Variable_B,

Cant the interaction with values be password protected?

Just read the post fully, it appears that rather than update the variable_B this should only be updated if Engineering changes it, like the last post password protect the HMI fields.

If they are in an array, you could generate a single CRC for the conglomerate of INTs, then compare that to pre-calculated CRCs for known configurations. This will have less data than the EQUs, but the code will be somewhat opaque. And if the integers are spread around (.PREs), it will be messy.

Sounds like what you might need is a recipe system.

If you have known good values, why are operators changing them? Why do they have access to change them?

dmroeder said:

NEQ N7:0 N7:1 BST OTE B3:0/1 NXB MOV N7:0 N7:1 BND

B3:0/1 will be true every time N7:0 changes.

Click to expand...

This would work, but there is a lot of variables that could change, so lots of logic to put in. Is there a way to compare an entire integer file with another? That would make it a lot quicker to implement.

chud said:

Cant the interaction with values be password protected?

Click to expand...

ndzied1 said:

Sounds like what you might need is a recipe system.

If you have known good values, why are operators changing them? Why do they have access to change them?

Click to expand...

The values are password protected in the HMI, and there are on occasion reasons to change some of the speed and timing values. Typically when there is mechanical wear the machine can be made to run by adjusting until we shut down for repairs.

The password is known to the maintenance team, and they have the best intentions when making changes. The biggest issue is we don't have a good process in place to record changes. If someone changes one value on their shift it may cause issue in another area, and another shift may change something else to "fix" the machine. I could change the password, but it would make me very unpopular and I don't work for maintenance but often need their help with other projects.

eight_bools said:

Is there a way to compare an entire integer file with another? That would make it a lot quicker to implement.

Click to expand...

Use indirect addressing with a pointer to iterate through. eg NEQ N7:[N10:0] N9:[N10:0] Increment the pointer each cycle; just make sure to reset it before it goes past the size of your files being compared.

Then use an FFL or equivalent to store the current value of the pointer and a timestamp whenever the rung evaluates true.

It does sound like you need a logging system, depending on the HMI perhaps log date/time & paasword even what variable is changed perhaps to a csv file, this could then be exported or even viewed on the HMI.
Also do this in a loop providing the variables are contiguous you only need to check one variable per scan it would be close enough for example
L Pointer // have a pointer to indirectly point to the variable
> 30 // assume we are checking 30 of them
MOV 0, pointer_1 if it's greater than 30 then set it back to 0 (or if the pointer
MOV 0, pointer_2 //pointer to the stored values to check against
needs to start at any particular register for example N7:20 then the max pointer would be 50 & MOV 20 to reset the pointer.)
CMP Recipe_Reg[pointer_1] <> Recipe_Chk[Pointer_2]
do what you need to do i.e. create a log file
Increment pointer_1 & 2
so in essence each scan would itterate through the variables checking them against the stored variables increment the pointers, if the pointer values reach the last variable address then reset the pointers back to the start.
This means assume 30 itterations & a scan time of 20ms to loop through all 30 would only take 600ms.
easily done in any PLC.

DOH: Been beaten to it

Is there array sum or FAL insruction on PLC5?


Summing array and comparing to old sum would give one shot bit for full array.
However if two or more variables is changed same time bacause communications sum_array can have same sum than before and change isn't recorded.

If only one variable is changed at time, then sum should work.

Lare said:

Is there array sum or FAL insruction on PLC5?

Click to expand...

Per this thread FAL is available in 5 but not in 500 (which is what OP is using).

plvlce said:

Per this thread FAL is available in 5 but not in 500 (which is what OP is using).

Click to expand...

FBC instruction maybe then if it can be used to integer addresses.



https://bryceautomation.com/index.php/2021/08/20/controllogix-file-bit-compare/