PAC Display - Reading tags Directly from I/O Units

PAC Project
1

Hi,

I am wondering if anyone can assist me with a problem I have recently encountered when configuring my run-time environment to Read tags from the I/O Unit.

The problem I am experiencing is where some of my display images will not react to I/O states, be it a light turning red or a flashing alarm image. After some scratching I disabled the option in configurator > runtime > I/O Unit Tags for the specific I/O unit and this appeared to resolve the issue with all tags reacting correctly.

However, another problem has now surfaced where the display will become non-responsive, majority of the time all the tags will not respond however on some occasion there will still be a couple that are updating. The result being that I have to close run-time and open it again and then all work.

There is no fixed pattern to this occurrence as it could work for days with no problems. I am currently running Run-time B9.6h Build 0111

If someone can give some possible causes or remedies it would be appreciated.

Thanks
Rob

2

Rob this is only my anecdotal experience, so YMMV:

I was seeing this on my non-pro Windows 7 and non-pro Windows 10 PCs until I upgraded. As well, I think my desired refresh rates were exacerbating the issue, as I had not yet comprehended the appropriate level of polling the OptoServer could handle (I was expecting to refresh needle gauge values at least 4 times a second, in addition to attempting to log data at 10Hz).

Hope that helps, I can expand upon the above if you think it’d be worth it

3

Thanks for the input Jimmy,

I would appreciate a little more insight if you have the time,

I can confirm I am running Windows 10 Pro and am only running 1 x Plant Overview Screen with approximately 120 tags doing various things, All operating in the Group 0 [50ms] refresh rate. In the background I am trending 6 floats every 100ms for historic purposes.

As you can see, quite a simple scenario. 4 x scales doing a basic recipe weighing function.

4

Okay, I’ll try to apply what I know given what you just added then:

From what I’ve seen, again emphasis on opinion, you’re asking way too much of the OptoServer between the Display and the I/O units. 20Hz is way too fast to be updating a GUI, even if you’re crunching numbers in the background. @philip, @Beno am I on the right track for him?

In general, what I am finding is that, for my purposes (and maybe yours too), I have plenty of overhead and loop time in my actual Opto hardware to do my calculations, and the GUI needs to be kept as simply a window into those calculations if need be.

In my case, I think I was asking “too much” of PAC Display in two ways:

1.) Expecting to not overload the OptoServer with 4Hz needle gauges. In practice, even though the appearance is less smooth, 1Hz is perfectly fine for most human-readable data to update given the scope of the hardware AND software we have here

2.) Similarly, I was doing all my logging FROM Display, and was reasonably satisfied with it at 1Hz and ~3 dozen data points, BUT, even at 1Hz, you’ll notice the timestamps are NOT exactly the same time slice apart. When I attempted to log at 10Hz for a particular project, everything fell apart, and its not the software OR hardware’s fault. I wasn’t asking the right portion of the tool to do the right job.

This actually takes me up to present and exactly today for myself by coincidence: I am currently working through understanding and debugging my implementation of the example code for FTP-based logging. I am at least up to the point where I can write a nice, consistent set of 10Hz data to a table on my R2, and the time slices are exact to within a reasonable tolerance (+/-5ms worst case, from memory)

Anyway, the more detail you gave, the more I am feeling similarities in that you’re trying ask Display to do things that it’s not intended to do, just like I was. Hope this helps, and I’m DEFINITELY open to correction by the gurus!

5

Hi Robin,
In my applications I consider 1 second a “fast” refresh rate. But it depends on what else is going on in that particular window. Try using slower refresh rates for points that don’t update often.
Other things you may want to consider:
Is the IO on the same network as the HMI?
Is this a dedicated network or are there other users and devices on it (streaming etc…)?
If the IO is on an R1 or R2 controller are you using the loop back address for the IO rather than the controllers IP? Loop back saves traffic on the network.
Is your chart logic scanning the IO points in loops?
If so then what time delay(s) are you using in your charts to slow down the scanning of those points (i.e. 100ms)?
If you have more than one HMI and or groovs scanning the controller that also increases traffic.
I have not had much luck when I try to display in hz. I use Groups that are set up from 500ms to 10 seconds with levels in between and customize the display accordingly. When I need to log data fast and reliably I do it internally to the SD card in the controller and then ftp the file to a host as @JimmyTime mentioned.

6

Hi Norm,

Thankyou for your input

I will definitely take your guys advise and change the configuration of the display operation accordingly.

To answer your questions:

  1. The I/O is on the same network as the HMI
  2. The system resides on a dedicated network, 1 x PC, 1 x switch. No Internet access
  3. I/O is 1 x R1 Controller mounted on a 16 way rack utilizing 5 x ODC5-i, 3 x IDC5-i and 1 x SCM485-422 module. Loop back address is used
  1. There is 5 x charts that run in a loop monitoring mainly communications.
    All the other charts are started as required and stop when they have completed their required tasked.
    When the system is in full operation there are between 9-13 charts running. Loop time is very good. As you can see this is not a big installation at all.
  2. The 5 charts that loop have a delay of between 100ms and 250ms set.
  3. Only one HMI running on PC. Win10Pro, Corei5, 16GB Ram

Thanks again

7

Slowing the refresh rate may certainly help. However, if you have the time, please contact product support and have them take a look at your project, as PAC Display should not just freeze and stop reading tags. That could be expensive/dangerous if an operator has bad/stale information.

These bugs need squashed.

8

Thanks Philip,

I will contact them

9

Hi @Norm_Freeman1, would you be able to expand a little on that concept for me? I’m not sure if my applications could benefit from it until I understand it a bit more, but I’m not fully grasping what you mean yet.

@RobinRR I’d have to agree that contacting support and sending them the project will be very helpful. While I have managed to see my (exact same) issue go away by doing the two things I mentioned (proper Windows version + realistic GUI expectations), it still was odd that we were seeing the lock-up at all, so Opto at least has my case for this issue, but adding yours to it will help!

10

@Philip is correct about these bugs needing squashed, however the developers don’t always get to experience what we do in “the real world”. So my suggestions have to do with adapting to the current state of affairs. I have opened many tickets only to be told that “we cant re-create the problem”.
As far as the R1/R2 comment about using the loop back address here is what I was thinking. R1/R2 controllers have the IO processor internal to the enclosure. If for example your controller is on ip address 192.168.1.22 then using the loop back address of 127.0.0.1 when you set up the IO saves the controller from having to use the Ethernet port and network to get the tag data. This reduces traffic on the Ethernet port. In the past myself and others have noticed that sometimes when processors get too many requests from too many devices they go “silent” and stop responding. This would make Pac Display appear to hang. So I now think in terms of making communications as efficient as possible, Using the loop back on IO is one way to do that. Slower refresh rates is another. You could also potentially overrun the Ethernet port if you do not have time delays in your charts that are reading points from the io when it is on an external ip like 192.168.1.22, so use the loop back instead, it keeps the traffic off the network.

11

Oh, I’m starting to finally get it, I have been wondering why you essentially have two places where, for me, I have been using the same IP address: once for the control engine at the “top” of the tree, and again down at the IO unit level.

So if I have, for instance, an R1, the IO unit that represents what is physically attached to the R1 brain can be set to loopback, which will prevent the brain from using the ethernet port to get the data from the IO unit within itself? Analogy time: If I want a sandwich, I can go down the stairs and take a right into the kitchen, instead of going down the stairs, opening the front door, stepping outside, making sure my house number is the right one, then going back in and taking a turn into the kitchen…

12

Wow, your the master of analogies! That’s a great one. Yes, when you configure the IO units if the IO unit is on the controller then click the checkbox under addressing for Local(Loopback)

loopback
Loopback.JPG520Ă—548 40.6 KB

1 Like
13

haha, now I have a profound desire to make a sandwich.

Correct,

I am using the loopback
have opened a ticket with support
will set refresh rates and do roll out by end of the month

Something that does appear to have been resolved is a problem I had on the same rack with the SCM485-422 module. Port 2 which I use to transmit to a remote display, the module would all off a sudden stop transmitting with RX light simply remaining on. Port 1 reading 4 x devices would operate without a stutter. Updated the firmware in the module and the problem with Port 2 has to date, not reoccurred.