Strang tag behaivor when Pop up closes

Ignition
1

I have an strange issue that I sure is user error but want to ask y’all about. What I am trying to do is take the row of selected data from a table and save into a UDT of my PLC. That part is working. The part I am having trouble with is I am also trying to use that button (Momentary) to copy that data from one UDT to another in the PLC. When that happens though, the tag that the button is controlling stays forever instead of just while it is being pressed. I suspect that it has something to do with the popup closing but haven’t found a way around it yet. Any suggestions?

[code]table = event.source.parent.getComponent(“Table”)
data = table.data

BarCodeID = data.getValueAt(table.selectedRow,“BarCodeID”)
PartNum = data.getValueAt(table.selectedRow,“PartNum”)
Description = data.getValueAt(table.selectedRow,“Description”)
GrindModule = data.getValueAt(table.selectedRow,“GrindModule”)
PartClampEnable = data.getValueAt(table.selectedRow,“PartClampEnable”)
SwingArmEnable = data.getValueAt(table.selectedRow,“SwingArmEnable”)

system.tag.write(“CurrentPart/BarCodeID”,BarCodeID)
system.tag.write(“CurrentPart/PartNum”,PartNum)
system.tag.write(“CurrentPart/Description”,Description)
system.tag.write(“CurrentPart/GrindModule”,GrindModule)
system.tag.write(“CurrentPart/PartClampEnable”,PartClampEnable)
system.tag.write(“CurrentPart/SwingArmEnable”,SwingArmEnable)

system.nav.closeParentWindow(event)[/code]

2

Yeah, closing the window usually kills off the mouse release event for that button. Try putting your data copying script in the mouse release event instead (but you’ll have to check for the correct mouse button yourself).

In general, you should avoid connecting a momentary button to a PLC unless you have code in the PLC to kill off the button with a timeout. Necessary anyways to handle client/driver/server disconnects/crashes. Consider a handshake using “set from Ignition/reset in PLC” wherever buttons only need to operate on a leading edge.

3

If a momentary button shouldn’t be used with a PLC then what’s better? And how would you suggest doing the hand shake?

4

The handshake is simple: A command bit is set from Ignition. The command bit is acted on in the PLC, then reset by the PLC. To allow Ignition to verify a successful write, the reset is typically after a delay somewhat longer than the tag scan interval. Any button press that triggers a single PLC action should be implemented this way.

Any use of a momentary button to implement ramp-up, ramp-down, or similar functions should have a time limit in the PLC to account for broken communications.

The issue is that ordinary OPC drivers use request/response messaging over TCP/IP to access data in the PLC. With such protocols, a momentary button must be emulated by a tag write on press, then another tag write on release. If the program responsible for the release event fails or is terminated, or comms are lost, the button gets ‘stuck’ on. As long as the protocol is entirely external request/response, the virtual pushbutton is vulnerable. The PLC application must have custom logic to detect and deal with this problem.

The various PLC brands all implement their I/O interfaces with a dedicated protocol built around a retransmit model, usually over UDP. These I/O protocols expect the data to be retransmitted continually, with a reset (and fault indicator) in the PLC if the transmissions stop. The PLC firmware provides the error checking needed for real momentary buttons to work correctly, whether remote or local.

What is safe to do with a real pushbutton connected to I/O is not necessarily safe to do with a virtual pushbutton. Implementing your own logic to replace the native I/O fault detection is one way to do this. Note that this is true for any HMI platform that uses request/response protocols.