PAC Display Operator Input Very Sluggish

We are working on a project to convert our stand alone automated scales to ones that perform the same function using PAC Project. Several of the issues that we have are the responsiveness of the scale itself, which is manageable, and relatively long delay for inputting data using the custom keyboard. We are using Mary’s keyboard since this is a touchscreen and it is very difficult to see the built in keyboard in an industrial setting.

In PAC Display the keypad readouts are set to 100ms, but we are unable to configure the speed that the keys send their data to the controller. We are using a S1-W with good signal strength on both the controller and the tablet. When we first moved from 9.4 to 9.5 there was a huge delay, but we were able to work with support to correct that. This left us with the delay you see in the video below. On our conventional scale the data is input as fast as the operator can push the buttons but on the Opto Display scale, he is waiting on the values to return back from the controller and for the “async operations”.

The operators will should be able to process 300-400 of these cylinders per shift and the time wasted on data input is not allowing them to meet these goals. We would like to continue to use Opto Display since we run all of our plants using it instead of shifting to something like Ignition or Wonderware just to allow us to input data faster.

Does anyone have a recommendation on how to speed up the data input process?

Conventional Scale Keypad

OPTO Scale Keypad




Can you have the keyboard chart run locally on soft pac on the tablet and then transfer this data peer to peer when the user is done entering the data?

When I click PAC display buttons to set values here on my local network or on PAC sim, it responds pretty quick. Possibly the delay may be on your network.

The downside that I found with the custom keyboard is that the operator will have to slow down to hit the same key twice.

Several possible bottlenecks here. But before we dive into those… perhaps this might be a good place for groov?

Do you have our mobile aPAC/iPAC app? It’d be interesting to see how those do in this network vs. PAC Display…

The custom keyboad inherently creates a decent part of the lag, but I’m thinking there is also a bottleneck because of the wireless. The S1W is only a Wireless G / 54mbps connection and with your wireless to wireless setup you are going to experience latency. I’m curious, if you run this on a PC that is networked with the S1 via hard wire how fast is it?

Most times that I’ve run into similar issues, the problem has been within the strategy itself – something in the programming causing the controller to not get to or not step through the programming that handles the operator input as fast as you need it to.

That said, nearly all my applications involve a hard-wired controller so I cannot comment on the latency and how it potentially relates to the wireless controller. In instances where I do need to go wireless, I hardwire the touchscreen and/or controller to a wireless radio that’s capable of a faster connection over a wireless N connection (100+mbps). Typically you can get into that sort of a setup for the same price or less than that of a wireless controller. Hardwired is so much quicker and more stable.

I was able to resolve the “waiting for async operations” by opening the home window instead of closing the keyboards. There are about 4 keyboard windows opened in the background, so they never have to reopen or close.

I initially had trouble with the chart, but was able to get the chart time down to well under 10ms.

I’m not convinced that it is a networking issue. It seems like PAC Display has an internal refresh rate for outputs to the controller. On the touchscreen I can see when Windows senses a touch when it makes a water drop effect. Using a steady rythem, Display will take my inputs as long as it is not the same key more than once. If I try to type as fast as Windows is sensing the touches, PAC Display will miss some of the inputs. We are not as concerned with the returned values from the controller to Display, just that it will accurately and quickly send the values from Display to the controller.

We are allowed set PAC Display to refresh values from the controller as low as 1ms, how quickly are PAC Display outputs set?

I think philip’s answer is what you are looking for. Write a small strategy that handles the custom keyboard and have it running in the background with SoftPAC. After the operator finishes typing the value and hits enter, set it up so it will send the complete value to the PAC-S1-W. As the operator is typing the value, it should show it a lot faster.

Also, the more screens you keep open, the more time slice it takes for the Strategy to update the values from Display. Even though you are not viewing the screen, it is still trying to scan and update the values on each screen that is still open. The scan time can get pretty high with multiple screens open. It might show even higher with a wireless connection.

Understood. I thought the concern was the delayed response of the send to the controller and read back that was the issue. PAC Display must not buffer the output comm to the controller, because if it did your fast tap commands would still get processed. Keep us posted as I’d be interested to here what solves it.

Also, what kind of tablet and mount are you using? Can you share some of the details? I’ve wanted to experiment with something similar to your setup but I’ve been deterred by the tablet’s power connection coming out the side of the tablet. Did you find something coming out the back?

If Display would buffer the key presses that would solve the problem, or at least make it an option in case a user wants to prevent an accidental double click.

After solving the window “async operations” problem, the MMI is much less frustrating for the operators. They are starting to get used to “pacing” their key strokes, however it would be much better for the input to be faster.

This application is in a hazardous location with a deluge system, so it is hard to find a tablet pc that can meet these requirements. We are using a ruggedized 11.6" tablet rated for Class 1 Division 2, and with the extended battery it will last a little over a shift. The mount is a universal tablet vesa mount and the monitor balance arm is from amazon. Since the tablet is so light we had to counter balance the tablet with some lead.

JWHare,
I do see your frustrations here. I too will be using a custom keyboard in the near future. I quickly built a sample program and I used SoftPAC to run the strategy. I tried everything to get rid of the “double click” or “repeat” delay when trying to select a certain number twice in a row (I am using a Dell P2314T touch LCD screen). This has to be directly related to how PACDisplay runtime will not allow another touch command until a timer is expired (probably 100-250msec). It’s funny because if you choose to have their built in keyboard displayed you can touch that as fast as you can and it will display the number correctly. Also, for each number key I set a “hot key” and it is very fast as far as speed to know what number you pressed and displaying what you typed. I know in other HMI programs I have used there is a setting for repeat delay. Maybe in the future they can offer that setting.

If anyone wants the sample code to test it on a different style touch screen, just let me know. You can test it for yourself.