[Logix] Keeping track of BOOL values when sending vis MSG

[defcon.klaxon]

EDIT: Sorry for the typo in the title, it should say "via MSG"

Hi guys,

I've come up against something that is likely simple to take care of, but I'm having a hard time wrapping my head around the necessary logic.

Basically, I have a remote PLC (CompactLogix) controlling well sites. All the control logic is done at the remote sites, and a "master" PLC polls each site; the master PLC is responsible for interacting with the HMI (InTouch). I have it set up so that I use four MSG instructions for each site; the master PLC sends an array of DINTs, then an array of REALs; then receives an array of DINTs, then REALs.

The problem I'm encountering is with the idea of Alarm Reset. All the alarms at the remote site latch, so they have to be manually cleared via local control panel pushbutton, or an HMI button. The problem I'm encountering is, let's say I set the alarm reset bit high with a button in InTouch:

1. Alarm_Reset bit is now high at the "master" PLC.
2. Alarm_Reset bit is sent to remote site.
3. Alarm_Reset resets the alarm, then remote site resets Alarm_Reset bit.
4. Alarm_Reset needs to be reset at "master" PLC.

The problem is with step 4; I can only allow Alarm_Reset to go back low at the master PLC after the actual reset occurs; otherwise, I'd be over-riding the master PLC every time it polled the site because I'm sending all the data with every poll cycle.

Such a simple task proves devilishly difficult to gracefully implement; I think the solution is going to involve some sort of rising/falling edge detection and/or one shots but this feels like it's getting pretty complicated, and as I'm learning more and more about programming PLCs it seems like there's usually a graceful way of doing things that you don't know until you have the experience, hence me asking how you guys would tackle this problem. I'm going to keep working on trying to find a solution but I'd love to hear your opinions. Thanks a bunch!

 

[willxfmr]

If it were me, I would use the remote alarm reset bit to trigger a one time message back to the "master" showing the alarm bit is now reset. Shouldn't be more than a rung or two in the remote and master.

Will.

 

[harryting]

Some thoughts:

- Have you considered having the HMI interact with the remote PLC directly? Unless there's some master function that absolutely need the master plc to do.

- Consider having the alarm reset from HMI as a momentary. You can do this with HMI or have another bit set high with TOF or similar logic. That way, you do not have to worry about sending the alarm reset back.

btw. what you encountered here is a typical issue with RTU type communication, that's why some protocol enforce directional consistency. ie. Digital Out vs Digital In. Whenever you deal with remote communication, always force direction. You can start by labeling a bit correctly.

I don't see how you can do this without some type of momentary function, otherwise you are going to be going in circles.

 

[AGill]

Do you have access to the remote Alarm_Reset at the "master"? When you see either this bit change status (high to low) OR when you see the remote alarm clears, you can then clear the master Alarm_Reset.

 

[defcon.klaxon]

Some thoughts:

- Have you considered having the HMI interact with the remote PLC directly? Unless there's some master function that absolutely need the master plc to do.

That's a great question and kind of a complicated answer; I'll do my best to give you the long and short of it. Basically, the system was designed before I even worked at the firm I'm at now. It was designed with a "classical" sense, in that the whole idea was that the remote sites would be polled by a data concentrator in a "serial MODBUS" fashion. But then somewhere along the time, AB Logix was spec-ed and they decided to do everything on Ethernet/IP, but having never worked with it before, they didn't realize how darn easy it is for remote sites to directly interact with the HMI since, you know, Ethernet/IP. It didn't take me long to realize that the way the project was designed was not how AB Logix wants to do things these days. So yeah, if I were to design this system from the ground up knowing what I do, I'd do away with the data concentrator, it's really redundant in this situation. But I'm kind of stuck with it, unfortunately.

- Consider having the alarm reset from HMI as a momentary. You can do this with HMI or have another bit set high with TOF or similar logic. That way, you do not have to worry about sending the alarm reset back.

So here's why I have shied away from momentary, please let me know if my assumptions are incorrect. If the button in the HMI is momentary, then it sets the Alarm_Reset bit high for as long as I have it depressed. Will the radio polling cycle be fast enough to grab that bit's changed value and send it? I don't know. It could be that if the polling is taking long enough, it would go from low to high then back low before the reset was actually sent. Now using a TOF would give me that high value for, say, five seconds. But what if something goes wrong and the remote site doesn't get the reset bit? I suppose the operator would simply try again and if something was broken, we'd get a call. Maybe the data concentrator has logic that says if you've reset the alarms and they don't report back reset, then give an alarm.

btw. what you encountered here is a typical issue with RTU type communication, that's why some protocol enforce directional consistency. ie. Digital Out vs Digital In. Whenever you deal with remote communication, always force direction. You can start by labeling a bit correctly.

This is exactly why this board is so valuable and you guys are so helpful; being new in the PLC world, every time I come up against a logic oddity I think "I can't possibly be the only person working on this problem" and lo and behold, every time you guys come through with very helpful info. I really can't say thanks enough! Between troubleshooting and good programming practices, I've learned a ridiculous amount just by reading and posting here.

I don't see how you can do this without some type of momentary function, otherwise you are going to be going in circles.

Exactly, whenever I thought up a solution I'd realize it was a circular feedback thing; create a second tag to indicate the reset happened, but then how is *that* tag reset, just once? It is quite a tricky issue. I think the TOF set for a couple seconds is the way to do this. If it was the PLC to HMI directly, it would be quite a bit easier; I in fact played with that very problem earlier and thought I had this all figured out, but I realized that was more simplistic than my actual network.

 

[defcon.klaxon]

Do you have access to the remote Alarm_Reset at the "master"?

I do have access to the master yes, I'm writing that code too.

When you see either this bit change status (high to low) OR when you see the remote alarm clears, you can then clear the master Alarm_Reset.

I was thinking something along these lines; if I package up the Alarm_Reset big into a Msg, I can compare that packaged value with a different tag name (whatever its array address is) to the master PLC Alarm_Reset bit; if Alarm_Reset goes high at the HMI, then it could remain high until the packaged bit also goes high; then the Alarm_Reset bit could be reset, and that in turn would reset the bit at the remote site. Gonna try that, see how it works. I could wind up in another feedback loop though, we'll see.

 

[defcon.klaxon]

If it were me, I would use the remote alarm reset bit to trigger a one time message back to the "master" showing the alarm bit is now reset. Shouldn't be more than a rung or two in the remote and master.

Will.

That's an interesting thought, the MSG could be sent from the remote site, to the data concentrator; I had been thinking of MSG instructions at the data concentrator only. Definitely a possibility, thanks!

 

[harryting]

Well, here's my thought. All alarm reset are momentary. Think of a physical push button on a panel. For HMI, sometime time lag is an issue so I would have the HMI SET (or latch) a bit then pass that info off to another bit in the PLC.

HMI Set Reset High -> PLC Set Reset High for 5 sec AND Unlatch HMI Reset

 

[MichaelG]

change your code to try the following

1. Alarm_Reset bit is now high at the "master" PLC.
2. Alarm_Reset bit ON is sent to remote site.
3. Alarm_Reset (oneshot) resets the alarm, then remote site Sets Alarm_Reset_ECHO bit.
4. Alarm_Reset_ECHO bit is sent to "master" site.
5. "master" PLC resets Alarm_Reset
6. Alarm_Reset bit OFF is sent to remote site. (this resets the oneshot)

Notes:
It is not recommended for the HMI to set Alarm_Reset directly
This is because the Alarm_Reset should only be set once the Alarm_Reset_ECHO is off
Test test test - to make sure that it will work in all cases of communication failure and recovery

 

[RET]

change your code to try the following

1. Alarm_Reset bit is now high at the "master" PLC.
2. Alarm_Reset bit ON is sent to remote site.
3. Alarm_Reset (oneshot) resets the alarm, then remote site Sets Alarm_Reset_ECHO bit.
4. Alarm_Reset_ECHO bit is sent to "master" site.
5. "master" PLC resets Alarm_Reset
6. Alarm_Reset bit OFF is sent to remote site. (this resets the oneshot)

Notes:
It is not recommended for the HMI to set Alarm_Reset directly
This is because the Alarm_Reset should only be set once the Alarm_Reset_ECHO is off
Test test test - to make sure that it will work in all cases of communication failure and recovery

I think the "done" bit of the MSG instruction is pretty reliable. You could probably just use that to know that the message made its way through, and then unlatch the master reset bit. Of course multiple message and reset bits, one for each remote site.

The remote sites then can latch in their own reset when a reset bit is received from the master, and then can unlatch it itself at the end of a complete scan, or after the alarm reset routine.

 

[MichaelG]

I think the "done" bit of the MSG instruction is pretty reliable. You could probably just use that to know that the message made its way through, and then unlatch the master reset bit. Of course multiple message and reset bits, one for each remote site.

The remote sites then can latch in their own reset when a reset bit is received from the master, and then can unlatch it itself at the end of a complete scan, or after the alarm reset routine.

The Done bit is ok but the above method works over any communications link

 

[defcon.klaxon]

I think the "done" bit of the MSG instruction is pretty reliable. You could probably just use that to know that the message made its way through, and then unlatch the master reset bit. Of course multiple message and reset bits, one for each remote site.

The remote sites then can latch in their own reset when a reset bit is received from the master, and then can unlatch it itself at the end of a complete scan, or after the alarm reset routine.

That's a really great idea; presumably, if the MSG gets through, I would assume all the data got there. I already have MSG error checking, so I think I can hang my hat on that instead of having to necessarily send an ECHO bit back.

 

[defcon.klaxon]

change your code to try the following

1. Alarm_Reset bit is now high at the "master" PLC.
2. Alarm_Reset bit ON is sent to remote site.
3. Alarm_Reset (oneshot) resets the alarm, then remote site Sets Alarm_Reset_ECHO bit.
4. Alarm_Reset_ECHO bit is sent to "master" site.
5. "master" PLC resets Alarm_Reset
6. Alarm_Reset bit OFF is sent to remote site. (this resets the oneshot)

Notes:
It is not recommended for the HMI to set Alarm_Reset directly
This is because the Alarm_Reset should only be set once the Alarm_Reset_ECHO is off
Test test test - to make sure that it will work in all cases of communication failure and recovery

Thanks for the help with this; I may use the .DN bit on the MSG for now, but I'll definitely keep this method in my back pocket for this, and future projects. Thanks again!