Detect change in integer

plvlce said:

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.

Click to expand...

I like this idea, however have never used indirect addressing. I found some videos online but they were all for RSLogix 5000 instead of 500

The cleanest solution would be to upgrade the HMI to a Red Lion and add users to its security system where it can log all the changes. No changes to the PLC would be required.

I did this on a system in a plant where they had me go so far as to add alarms to the alarm queue so any time an operator made a change their full real name appeared in the alarm history.

Amazingly, they suddenly quit making mistakes. But just by using the built in security logger and not displaying it gives you a means to track every changed value accurately.

It's so simple, however, you need to do your own logic to want you want to do when it detects a difference for example Generate an alarm, or store the index of the value changed, you could move the Value in n10:0 to some other file then index it indirectly. see the simple indirect addressing here it just assumes N7:0 to n7:30 are the variables to check against N9:0-30
EDIT: Assuming your using an old , cannot remember it's been many years but perhaps you can embed N10:0 into an alarm so it displays the position of the changed variable.

parky said:

It's so simple, however, you need to do your own logic to want you want to do when it detects a difference for example Generate an alarm, or store the index of the value changed, you could move the Value in n10:0 to some other file then index it indirectly. see the simple indirect addressing here it just assumes N7:0 to n7:30 are the variables to check against N9:0-30
EDIT: Assuming your using an old , cannot remember it's been many years but perhaps you can embed N10:0 into an alarm so it displays the position of the changed variable.

Click to expand...

Indirect addressing works well in a SLC/Micrologix, but be very careful how you manipulate the index. One that ends up out of range can cause a major fault.

Parky's example would examine one register on each subsequent PLC scan, which might be fine for what you are doing. If you need to check them all within the same PLC scan, you can loop with a JMP and LBL pair with a compare before the JMP. Here's a snippet from one I use where there are two different HMIs and PLCs connected by radio modems where the setpoints for a pump station can be edited from either end.

This example keeps a local copy of each of the "incoming" setpoints and only updates the "outgoing" copy if the incoming doesn't match its copy. The HMI works only with the outgoing setpoints file. In my example, I zero the index and then the first step in the loop increments it so I am using elements 1 through 19 of the associated three files.

You situation would require a bit more code inside the loop and perhaps another file or two to record the old value and maybe the date/time it was changed.

Possible enhancement to @parky's that unlatches the mismatch alarm when everything matches again.

The GRT N10:0 might be safer as LIM 31 N10:0 -1; that would break my code, but it could be fixed.

Yes I agree with brian, perhaps put a less than 0 just in case, however, we have assumed here that the variables are consecutive & all the same type, it is probable that some might be floats, in that case, then this would have to be done by comparing the float file as well, the other possibility is that they are not consecutive, & any in-betweeners i.e. an actual variable that can change would set an alarm, althogh any decent programmer would put them in a single file or area for that type.

One thing I always do is have the HMI write to a NewValue tag and the PLC decide if it will accept the new value or reject if it is out of range or some other condition isn't right to accept the cange. That could be NotInManualMode, MotorNotRunning (or MotorIsRunning), SupervisorKeySwitchNotOn, etc.


If everything is OK with the new value then the PLC changes the value of the Setpoint tag.


I also do this with BOOL enables. I don't ever have the HMI directly write to a used tag.


This also prevents Bubba, who has a PanelView in his locker he can program to write any value to any tag or toggle any bit. To override this logic Bubba would have to write the new value to the Write AND Used tags the same scan.


EDIT: Doesn't show in the pic but the next rung changes the Write tag value to the Used tag value if it was not accepted. NEQ N10:3 N11:3 MOV N10:3 N11:3