I’m a bit stuck with this one. I have a FactoryPMI system which has to send a number of control outputs to a PLC. Clicking on an item of plant opens a popup which contains all the controls for that item, plus an Execute button.
I’ve implemented the controls using timer buttons. Pressing a control sets a SQLTags point high for 5 seconds. The Execute button is also a timer button, which sets a point high for 2 seconds.
What I want to happen is another SQLTags point (tied to a PLC output) is set high when both the control and Execute buttons are pressed, then is reset low when either the control or Execute points go low. (This guards against inadvertent operation of the control.)
SQLTags DB type tag that is an expression - a simple AND of both conditions.
{tag1} && {tag2}
I typically don’t recommend timed based systems on the input like this since you don’t have guarantees, particularly when one is based on others, but it should work. Make sure your scan classes are sufficiently fast.
It’s usually better to set the bit high, then have the PLC reset it after a certain amount of time. That way you know what will happen even during a comms loss.
Sorry for the delay in replying - I’ve been on site all week with no web access.
We don’t have control over the PLC in this job, so any control resetting will have to be done independently of the PLC. I would normally have recommended resetting in the PLC, but your comment about comms loss got me thinking - if your system only sets a point high, what would happen if you set an output point during a comms failure? What might happen is that the output is sent when comms are re-established, and you suddenly get plant starting up when you don’t expect it.
Thanks for the advice about tying a SQLTags point with an expression to an output point (in KEPWare in this case). With this arrangement, how often will the output be sent to the PLC? Every time it is scanned or every time it changes? I want controls to be responsive so I imagine I want to scan the output points at sub-second speeds. What kind of loading will this put on the client and server?
The reason we are going for the timer buttons is to replicate the system we are replacing. Currently they press a control button, then have several seconds to press a Confirm button to action the selected control. If anyone can think of a better way of implementing this, I’d love to hear it!
SQLTags won't write a value that was attempted during a communication failure. I was commenting on the practice of writing a value (comms necessarily up at this point), then scheduling another timed write for later (when comms could be down). I think this works as well as it could given that the reset is done out of the PLC. It should be a pretty unlikely event.
As I understand it, a SQLTags "bi-directional" binding will write on a value change (I would guess that rapid value changes being written to the PLC would be constrained by the scan class rate). You don't need to worry about write traffic on a value that isn't changing.
I misunderstood how you described the timer control worked. Your system is indeed "more safe" - deliberately more pesky to the user to activate the output.
My response was regarding setting the output with the HMI, then possibly not being able to un-set it due to a failure. Perhaps your process stops itself after the output raises.