understanding AB functions?

I'm sure this has been addressed before, but...

I need to know (more accurately, the plc needs to know) when power drops off of a touchscreen, or if the cable comes unplugged from the plc. The HMI is a Red Lion G306 tied into the serial port on the AB 5/03.

I know that I can flag bits in the HMI when the plc loses power. I can flag bits when comms are active or inactive, but this is a first for me...I've checked the S bits in RS500, but this doesn't quite seem to be what I need.

Is ten seconds OK ?

Comms Active S:1/7

This bit is set (1) by the controller when the controller receives valid data from its RS-232 channel. If the controller does not receive valid data for 10 seconds through this channel, the bit is cleared (0).

You can also define a Channel 0 diagnostic file, and watch Word 2 (like N12:2) for the number of Messsages Received. If it stops changing, the HMI must have stopped communicating.

well, the S:1/7 would work IF the HMI updated constantly. In this application, it's used in leui of selector switches (Manual), and in the auto mode, once the machine starts, the only comms is when there is an error with the auto function, or during shutdown and/or manual.

To offer insight, the auto cycle was started through the HMI, and for testing, the power to the HMI was disconnected. The Auto bit was set in RS500 (even though they are not set to toggle in the HMI) and the machine continued to start....typically not a problem, except that the only control is through the HMI.

stasis said:

To offer insight, the auto cycle was started through the HMI, and for testing, the power to the HMI was disconnected. The Auto bit was set in RS500 (even though they are not set to toggle in the HMI) and the machine continued to start....typically not a problem, except that the only control is through the HMI.

Click to expand...

Not to try and get too far off subject, but that would be a programming issue more than anything.

If you are using a Momentary HMI Pushbutton to start a cycle, just as if you were using a physical pushbutton, you should check for the absense of that pushbutton's input at the end of the machine cycle to ensure that repeat cycles do not happen.

The machine will not fully complete its cycle and be able to start a new cycle unless the cycle start input has turned off after it turned on initially.

Tharon said:

Not to try and get too far off subject, but that would be a programming issue more than anything.

Click to expand...

thanks, I think....I know this is what SHOULD be expected.

However, the bit was set,the data file showed a 1 for the bit, and the touchscreen was without power. The (HMI) tag is non-retentive, and is set to 'pushbutton'.

However, the bit was set,the data file showed a 1 for the bit, and the touchscreen was without power. The (HMI) tag is non-retentive, and is set to 'pushbutton'.

Click to expand...

Then the machine, after checking to see if the data file is "1" to start the machine, should check for it to be "0" at the end of the cycle.

This way, if anything like this ever happens in real production the machine would fault and not perform unsafe (to the person, product, or machine) actions.

This would solve the problem of it sticking on "1" if the HMI is disconnected by not allowing the machine to operate until the communication problem is fixed.

not just at the end of the cycle, but whenever there is a loss of power to the HMI. Not just that, but if comms cable gets unplugged, fuse blows, etc. Most of these situations can be remedied through hard wiring, but the power loss or cable comming unplugged?


the bit was set even when the power to the HMI is removed.This is what I'm trying to correct. Writing code to see if the data is true/false isn't the problem, as this is simple enough. But in the case of the above mentioned situation?

stasis said:

not just at the end of the cycle, but whenever there is a loss of power to the HMI. Not just that, but if comms cable gets unplugged, fuse blows, etc. Most of these situations can be remedied through hard wiring, but the power loss or cable comming unplugged?


the bit was set even when the power to the HMI is removed.This is what I'm trying to correct. Writing code to see if the data is true/false isn't the problem, as this is simple enough. But in the case of the above mentioned situation?

Click to expand...

Easiest thing to do and forget about cables becoming unplugged and such.
Set up a heartbeat between HMI and PLC.
If the things stops "beating" say every half second, shut down your process, machine whatever that may be that you are controlling.

As long as the G3 needs data from the PLC, it will be polling. As long as you have a tag with an alarm or trigger, we would be polling for those specific tags, regardless of what page you were on. So the S:1/7 should do the trick.

Regards,
Dan

Why ain't it like this?

Stuck Button Syndrome is something that can happen with any HMI for a lot of different reasons. I always thought that some HMI firmware changes could at least help with the problem:


1. When the HMI powers up, it should be able to write the states of all of control objects, as selected by the user. This could be a checkbox in a tag data table...

2. Any time the value of a control object is written to the PLC by the HMI, The HMI should read the value back to ensure that the write message was successful. If not, try again to write the value to the PLC, and maybe provide a timeout limit. There should be a list of tags that are awaiting this verification, and once an item is verified, it gets dropped off the list.

Those two things seem pretty straightforward, and I have always wondered why things are not done that way in all HMI platforms. The PanelView write to controller on power up is pretty useless because it writes every tag in the database, which is rarely a good thing to do.

I almost always try to use the same power source for PLC and HMI, but this is not always feasible. If only the HMI loses power then you still need to have logic in the PLC to contend with those stuck buttons, but for intermittent communications that so often go unnoticed (especially with ethernet), rule number 2 above should handle that, right?

Paul