How best to optimize for real time jog buttons?

General Discussion
,
1

[This is for 8.1.15, Perspective]

In my quest to make the perfect skeuomorphic HMI with working jog buttons, I had thought that the Perspective session was losing mouse events. But in after some experimentation I am coming to the conclusion that the issue is not with Perspective, but with the OPC UA link between Ignition and the PLC.

My system design for a jog button object (built in its own view) is basically:

  • The View the button is built in has an isPressed View Parameter
  • Mouse Down event writes True to isPressed
  • Mouse Up event writes False to isPressed
  • An instance of the button is created from an embedded view on the main view
  • On the button instance, the isPressed view parameter is bound to a PLC bool tag (and I have checked overlay opt-out and bidirectional options)
  • The PLC tag is in its own Tag Group called UserControls set with
    o Mode: Direct
    o Rate: 100 ms
    o Data Mode: Subscribed
    o Read After Write: False
    o Optimistic Writes: True
    Screen Shot 2022-05-12 at 12.29.17 PM

What I am noticing is if I press the button and hold for longer than the Tag Group’s Rate, then the system works as expected. The tag in the PLC is set on button press and cleared on button release.

But if I press and release faster than the Tag Group’s Rate, then while the isPressed View Parameter get set to false, the tag value in the PLC never gets reset back to false. This was really noticeable when the rate was set to 1 second.

In my original design the button view parameter was set as bidirectional (two ended arrows on view parameter definition.) Because the PLC tag was never reset the button continued to appear to be pressed. When I made that parameter write only, isPressed (and my button animation) worked as fast as I could click the button.

So it seems that the false value is not being propagated to the PLC. I vaguely remember seeing some old thread about OPC UA writes potentially being re-ordered in the GW causing issues like I am seeing, but I can’t find that topic again.

Is there anything else I can do to optimize the system to better behave under rapid mouse clicks? I can keep lowering the Tag Group’s Rate, but that is simply the equivalent of sticking my fingers in my ears and going “can’t hear you, can’t hear you”.

I could rebuild the jog button interface in the PLC to have a “click on” and an a “click off” input and have my Perspective button set each bit separately, and have the PLC clear them. But I want to avoid doing that for now.

I’m also guessing that as the issue seems to be in the OPC UA section of Ignition, that swapping to a Vision based system would not solve my problem.

2

Sort of related - lot of talk about jog buttons about mid way down and the issues with them/how to handle them

3

And noted via Brian’s link, there are a couple solutions for Vision, including using my Ethernet/IP module’s very custom momentary button. All solutions require PLC code to monitor the health of the comms. I’m not aware of any fundamental solution for Perspective (yet?).

The technique I use in my custom button for Vision is theoretically possible in a Perspective custom module, but I haven’t written one of those yet. (:

4

If you change the Tag Group to Data Mode = Polled does it change anything?

5

I should mention that I am aware of your module. But using it would be total over kill for what I am trying to achieve.

I’ll also state emphatically that what I am trying to achieve is for simulation purposes of local operator panels only and will never be connected to a physical machine.

And the I totally agree with the horror of that link using HMI momentary buttons to directly control physical equipment. And I regularly have internal conversations about failure modes of HMIs and how they fit in with customer requirements. I’ve also dealt with PLC programming for a very long time including various safety PLCs etc. So I have a fairly good understanding of where HMIs should be used and where I’ll say “hell no” to a customer.

/end rant :wink:

6

My module was not the only solution presented for Vision.

The fundamental problem is the use of separate messages to set a PLC bit when the button is pushed versus reset when released. There is no way to guarantee the second message happens, no matter how good the UI is.

All reliable solutions use a stream of messages from the UI to indicate pressed and continued pressed, and cessation to indicate no longer pressed. (Typically with one end-of-pressed transition message to speed recognition of cessation.)

My module does two things to ease implementation:

  • Implements the UI part in a java component w/ gateway RPC, and
  • Puts the last hop to the PLC on class 1 UDP repeating packet streams.
1 Like
7

I just changed it to polled, keeping the same 100ms rate, and the same problem occurred.

8

Ok, just ruling out one particular race condition that you’ve opted yourself into by using Optimistic Writes and writing to a bit from both Ignition and the PLC.

9

At the moment only the HMI is writing the bit.

10

I agree that in the naive case that you can't guarantee anything over the network, but it seems in this case the second message is being actively suppressed. I'm just trying to understand if this is an Ignition issue or a limitation of OPC UA

11

Just to add another data point. As a test I created a momentary button that used two separate signals to the PLC - one to Set the button and one to Reset the button (and doing horrible things of resetting the signals in the PLC)

When clicking and releasing fast enough I still managed to latch up that button the PLC. So the setting of the Reset signal still managed to get lost somehow.

So to me it seems that rather than queuing OPC UA write requests, once one write request in Ignition is triggered, it is ignoring future write requests for a finite amount of time. But that can’t be true can it? Doing so would be crazy talk :crazy_face:

12

Try using system.opc.write**() direct to the OPC item paths instead of tag writes. Eliminate the tag system as a source of uncertainty.

1 Like
13

I’ll try that in a minute, but I just discovered a new (and weird) data point.

With my fancy Set/Reset momentary button I started counting the the number of commands received in the PLC. In the case where I managed to latch up this system I had counted that a single Set command and a single Reset command had been received by the PLC (so Ignition is generating both writes).

But the only way I can think of to explain this is that the commands were processed in the PLC out of order - and I have no idea how that could be.

14

I just tried this and the integrity of the system went up significantly. I wasn't able to cause a latch up no matter how fast I clicked the button. And the clock count in the PLC matched my HMI click count.

Now I just need to figure out extracting the server and path from the tag that was bound to the control (because I do not want to be manually configuring that stuff)