InTouch 10.1 (Standalone): Button Response

[SoftwareJanitor]

We seem to have bad button response across applications here when trying to write a single bit to a (Rockwell) PLC (to reset an alarm, for example). It can take several clicks of the button, even in a rapid-fire fashion, to get it to work. And it's not a case of the PLC writing over this same tag at the same time. It's typically a rung contact being read by the PLC, and Wonderware just needs to write the bit to the tag! The buttons are typically defined as discrete/direct.
I've also tried a small script which writes the value, loops 10,000 times, then clears the value, but the performance appears to be unchanged.

Anybody else experience this with Wonderware?

 

[NetNathan]

I usually use Touch Pushbuttons>Action script
On Left Click/Key Down: tag=1
On Left Click/Key Up: tag =0

You could also use a Condition script on the tag, and use "While True" to time how long it stays high.

 

[Bit_Bucket_07]

We seem to have bad button response across applications here when trying to write a single bit to a (Rockwell) PLC (to reset an alarm, for example). It can take several clicks of the button, even in a rapid-fire fashion, to get it to work. And it's not a case of the PLC writing over this same tag at the same time. It's typically a rung contact being read by the PLC, and Wonderware just needs to write the bit to the tag! The buttons are typically defined as discrete/direct.
I've also tried a small script which writes the value, loops 10,000 times, then clears the value, but the performance appears to be unchanged.

Anybody else experience this with Wonderware?

You are merely exacerbating the problem with multiple pushbutton clicks or writes from a script. That causes redundant messages to be sent on a network that is already slow.

We would need to know which Rockwell PLC, which network, which IO Server etc., in order to offer any useful advice.

 

[Bit_Bucket_07]

I usually use Touch Pushbuttons>Action script
On Left Click/Key Down: tag=1
On Left Click/Key Up: tag =0

You could also use a Condition script on the tag, and use "While True" to time how long it stays high.

Just curious. Why do you use scripting to emulate the native "Direct" momentary pushbutton function? Sounds like an unnecessary reinvention of the wheel.

 

[mellis]

My preference for HMI pushbuttons is for the button to set the bit and the PLC to reset the bit.

For instance, if I have valve open and close pushbuttons each button will set it's own command bit. The PLC will execute the logic to open or close the valve and immediately after it will reset the open and close command bits. This approach eliminates any concern about how long the pushbutton stays "on".

 

[Bit_Bucket_07]

My preference for HMI pushbuttons is for the button to set the bit and the PLC to reset the bit.

For instance, if I have valve open and close pushbuttons each button will set it's own command bit. The PLC will execute the logic to open or close the valve and immediately after it will reset the open and close command bits. This approach eliminates any concern about how long the pushbutton stays "on".

That also prevents "stuck" pushbutton bits that can occur with an overloaded network. With older HMIs, we used to have to use bit sets and subsequently reset those bits in the PLC logic, because no momentary pushbutton function was available.

 

[Bit_Bucket_07]

A few questions for the OP:

Do you have multiple HMIs attempting to communicate directly with your PLC(s), or are you implementing a client/server model for your IO Server(s)?

Is your Rockwell PLC an SLC? If so, have you looked at the status of the System bits that control messaging?

Assuming Ethernet comms, which IO Server are you using?

 

[NetNathan]

Just curious. Why do you use scripting to emulate the native "Direct" momentary pushbutton function? Sounds like an unnecessary reinvention of the wheel.

Using the scripting I use causes a slight delay between 0 and 1 on the tag, longer at 1. Sort of making sure the plc sees the 1 longer than the "Direct" momentary command.
I had an issue with a Honeywell HC900 plc occasionally missing the signal when it was "Direct".
It is on a busy network supplying 20 Intouch applications and a "Master" to monitor/control all 20. About 1500 PLC tags per application and 30,000 (20x1500) tags for the "Master". All talking Modbus TCP, so a lot of traffic.

 

[SoftwareJanitor]

NetNathan:

Yeah - the "Direct" feature doesn't seem to be reliable. I've seen it on more than one Wonderware app here. You click the button, wait ... nothing, click it again, wait .... nothing, then you click it 4 or 5 times rapidly, and it works! Now I'm seeing it happen on this app *I'm* working on, and I'm tired of it (although Operators don't seem to complain ... must be used to it ...).

=========
Bit_Bucket_07:

The script isn't doing multiple writes. It's only writing the bit *once*, then delaying before writing the bit the 2nd time to clear it. My initial thought was the bit would be held during the delay, but that's wrong. So all this is doing is delaying the clear - which is probably useless.

The PLC is a ControlLogix L73, Ethernet, RSLinx + FSGateway. There are two Wonderware HMIs running identical applications both talking to this single PLC (and they also talk to a handful of other PLCs, but I'm not sure if this makes it a "busy" network)

====
mellis:

Clearing the bit in the PLC sounds like a good idea, but if the bit isn't getting there, they'll be no bit to clear, so that's not really getting to the heart of the problem. The problem is - what's *not* happening when the button is pressed? Is is that the data is being sent but not making it to the receiver, or is it just not being sent?

 

[Bit_Bucket_07]

NetNathan:

Yeah - the "Direct" feature doesn't seem to be reliable. I've seen it on more than one Wonderware app here. You click the button, wait ... nothing, click it again, wait .... nothing, then you click it 4 or 5 times rapidly, and it works! Now I'm seeing it happen on this app *I'm* working on, and I'm tired of it (although Operators don't seem to complain ... must be used to it ...).

=========
Bit_Bucket_07:

The script isn't doing multiple writes. It's only writing the bit *once*, then delaying before writing the bit the 2nd time to clear it. My initial thought was the bit would be held during the delay, but that's wrong. So all this is doing is delaying the clear - which is probably useless.

The PLC is a ControlLogix L73, Ethernet, RSLinx + FSGateway. There are two Wonderware HMIs running identical applications both talking to this single PLC (and they also talk to a handful of other PLCs, but I'm not sure if this makes it a "busy" network)

====
mellis:

Clearing the bit in the PLC sounds like a good idea, but if the bit isn't getting there, they'll be no bit to clear, so that's not really getting to the heart of the problem. The problem is - what's *not* happening when the button is pressed? Is is that the data is being sent but not making it to the receiver, or is it just not being sent?

If you clear the bit in the PLC, then you can simply "Set" the bit with the pushbutton animation, rather than using the "Direct" selection. The bit will remain set until the PLC resets it. It would probably be worthwhile to try allowing only one of the 2 HMIs to communicate with the PLC, while the second HMI acts as a client. Is there anything other than the HMIs and a programming terminal connected to the PLC's Ethernet port? Is there any messaging between PLCs? I've never had an issue with momentary pushbuttons in InTouch, unless there was some sort of network problem.

 

[Bit_Bucket_07]

Using the scripting I use causes a slight delay between 0 and 1 on the tag, longer at 1. Sort of making sure the plc sees the 1 longer than the "Direct" momentary command.

Just for clarity, the "Direct" selection sets the bit on mouse key or keyboard key down, and resets the bit on mouse key or keyboard key up. That's the exact same thing that you're doing with your script.

 

[SoftwareJanitor]

Bit_Bucket_07:

I used NetNathan's suggestion of "While true on left key-down" and entered 500 ms for the hold time. That seemed like the best solution to me (and kind of looks like a Wonderware admission that you might have problems with these buttons ... maybe due to network issues ... but who knows?)

As far as clearing the bit in the PLC, if you just set it in Wonderware (and clear it in the PLC), does the bit get set repeatedly, or just once? I would think the latter (just once), which - if true - means it won't work any better than setting and clearing it in Wonderware with a left-click button. That's why I just went with the "while true"/500 ms hold time option. If that doesn't work, I'll change it to 1 sec, which *should* do it ... but we'll see ...

As far as only *one* HMI communicating with the PLC, this is just a read-only bit in the PLC. And the button is only being clicked on *one* HMI (the two HMIs are side-by-side). I suppose I could shut down one of the HMIs to see if the performance improves. How would I make the 2nd HMI a client? The two HMIs are redundant and symmetrical. Are you saying the 2nd HMI would talk *through* the 1st HMI, which would communicate exclusively with the PLC?

This PLC communicates with the redundant HMI pair, but the HMIs also communicate with at least a handful of other PLCs on this same network. The programming terminal (laptop) is normally offline, connecting over the network only for downloads and debugging. I do not believe there is any PLC messaging on this network. Each PLC is a self-contained application.

We *did* recently have some network issues with BlackBox fiber converters, but that appears to be cleared up. Admittedly, we're not very good about debugging network issues. It's definitely a weakness here for Automation *and* IT. Even worse, the network topography is not documented because a single IT person ruled over it for years here and was never required to maintain any such documentation. On the plus side, we've started replacing/upgrading our 10-15+year old switches with new managed switches, but there's still more to do.

 

[Bit_Bucket_07]

How would I make the 2nd HMI a client? The two HMIs are redundant and symmetrical. Are you saying the 2nd HMI would talk *through* the 1st HMI, which would communicate exclusively with the PLC?

Yes. PLC Ethernet ports can be overloaded with multiple HMIs redundantly polling the same data, especially if they are also supporting other network traffic. Simply go into the Access Name configuration and specify the IP Address (or node name) of the IO Server node, rather than having InTouch look for the IO Server locally on both machines. You don't even need IO Server software installed on a client HMI.

Oh, and yes. A bit is only set once when using the "Set" function, rather than the "Direct" function in a pushbutton animation. Repeatedly writing the bit merely overloads an IO Server that is already lagging.

 

[NetNathan]

I usually run a 0.1 sec timer in the PLC and log the Accumulated value in Intouch, to monitor the "speed" of the network.

 

[SoftwareJanitor]

Bit_Bucket_07:

But doesn't that configuration change also come at the cost of losing the HMI redundancy?

What happens if the 1st HMI machine fails? The Operators would have to update the 2nd machine to start reading data on its own, right?

Net_Nathan:

That's interesting information, but it still doesn't tell me what happened to the lost bit. Was it never sent, or was it never received? How does one debug these interfaces down to bare metal?