Latency in Re-branded Red Lion HMI

I've brought this up before, but did not come to a conclusion about what to do.

I have a large number of tags used on a re-branded Red Lion HMI project. For those with experience with this, I'm trying to figure out if it would be worth my time to change how I'm reading and writing my tags in order to cut down on my latency.

This was my first HMI project using Red Lion. When I saw how easy it was to "Add a Block" under my device and then attach a tag to the address, I decided that was the best way to do all of my tag addresses. I added blocks from the SLC 5/05 to read and write, as well as the 6 Eurotherm Mini 8 loop controllers. I wasn't sure how to determine the best update rate for each tag, so I left them at the default of Auto... continuous update of read tags, and write only when the value is changed. You can get a feel for how everything from my attached picture.

When it was done, I was disappointed to find how much latency there was. There are switches to turn on pumps that you have to hold for at least 10 seconds before the pump turns on. This is not detrimental to operating the machine, but it's embarrassing to me. At first I asked Red Lion for input. The tech support person was helpful, but when he asked to look at my file, he saw that it was a re-branded version of Crimson, and he directed me to Eurotherm tech support... which was a waste of time.

I'm planning an addition to the HMI, and with a little extra time right now, I'm thinking about attacking the latency issue. My first thought is that I have to get rid of the block reads and just assign each tag individually to the device/address where it goes. With the large number of tags, this will probably take a couple of hours to do.

For those with more experience with Red Lion, do you have thoughts or suggestions about this latency issue?

The rebranded software is called GUIcon: https://www.eurotherm.com/download/guicon-version-2-0-software-package-gold-build-683-003/

...I see it's in the discontinued products section. Ugh.

What is your communication method between the HMI and the PLC?
Can you do a screen shot of the communications section and its settings.

What speed is the communication link?

For a work around on the pushbutton problem, in RedLion there is a value called 'Hold Time' for a momentary pushbutton that will do the same thing as an operator holding the button for a while.

I have 9 devices, using 3 different drivers, all communicating over Ethernet Port 1. (Ethernet port 2 is connected to the office network.) There are no communication speed settings on an Ethernet port that I'm aware of.

I have screen shots of the comm settings for Ethernet port 1, and basic settings for each of the devices on the three drivers. The

Eurotherm Mini 8- Screen shot of first 3 devices (other two devices are same). Only difference is "Comms Delay" of a half-second.

DF1 Master- Most communication is done with block reads. But there are many addresses that are read but not used, even after conservatively selecting block sizes that tried to match addresses I needed. Without a lot of experience, I was guessing that the block reads were more efficient than individual reads assigned in each tag, so that made up for the additional volume. The individual tags are read "internally" from the block reads, so in theory the update rate should be irrelevant to the latency... and all tags' update rates are set to "Automatic". This is where I'm now guessing I was wrong, and I'm contemplating changing each tag from "Internal", read from block read, to directly read from the tag set-up. I just don't know if I'm looking at this theory of operation correctly.

Eurotherm 350x- Nothing out of the ordinary.

I did this project about 5 years ago. As I was looking at the DF1 block reads this morning, I really do have a lot of addresses read and not used. It's just so easy to assign a tag to the block address by dragging it to the address. And when you're done, you can visually see more information about how your tags are connected by doing it this way. But I'm guessing the used addresses need to be packed together better to make this technique work... like when working with DeviceNet. I think if I don't change the tags around, I'll always have this unanswered question in my mind.

If anyone has comments from what I've attached, feel free to add them. I keep thinking there might be a detail I'm overlooking, especially since this was my first experience with the software.

Since you are using gateway blocks, I believe that all the data will be read as fast as possible. I think you might gain some efficiency by converting those to just tags that reference the appropriate device and address. The Crimson comms driver (at least for A/B stuff for sure) is smart enough to pack addresses together to reduce overhead as long as you keep Spanning Reads enabled. But tags that are not on a display or set for alarming will not be read, so that is where I think you can improve things. I have never tried to set up a button hold time for longer than 5,000ms. I typically use 500ms. Not sure you want a 10,000ms bandaid on your buttons...

I had this problem with a PTV and a SLC 505. I set it up to do block reads between a S7-400 and the 505. It was taking several seconds to update just 1 word on the SLC side. Luckily the SLC shared a DeviceNet network with a L32 CompactLogix so I mapped the data from the SLC to the L32 then did the block transfer from there.

I think the answer is that you are moving 'sh*t load of data', is there any stuff that doesn't have to be read so often. Otherwise could you use the 'Block Control'/Request to try disabling things one by one to see if there is one thing causing the problems. Silly question but what are all your Ethernet cables connected to. Do you have a comms rather than a data volume problem.

I would just use direct tags to the SLC and only use gateway blocks to other devices that utilize a different protocol.
Never worked with a 505 with Red Lion tho.

OkiePC said:

But tags that are not on a display or set for alarming will not be read, so that is where I think you can improve things.

Click to expand...

Yeah, Paul, that's what I wondered about. I didn't know if all HMI tags were read at regular intervals, regardless of whether or not they were loaded on the current view. However, it did seem like it would be more efficient if the tags were only read if being displayed. The gateway tags are certainly locked in to regular intervals, regardless of being displayed.

This HMI replaced an old PC running Wonderware on Windows 2000. The Wonderware HMI didn't have the latency issue, which dinged my ego a bit... especially after I recommended this HMI as a replacement. We started talking replacement when they started getting a blue screen on the PC.

kotr: Yeah, I've often thought about how great it would be to pack information tightly before doing a block read. Thanks goodness this extruder uses DeviceNet for all the remote I/O and VFD controls. Those things don't have to compete with the HMI on the Ethernet Network.

BryanG: If I'm remembering correctly, I have 4 Industrial Ethernet switches on the machine. I've thought about the possibility that I've got a bottleneck on the switch connected to the HMI. Seems to me there should be some software I could put on my laptop that would help me sort that question out. I haven't looked into it yet.

Padees: Yeah, I'm pretty sure that's what I'm going to do. Knowledge is good, but *experience* is golden. Looks like this will be a Live Learning Lab for me. I don't mind putting the time in as much as I fear making a little mistake that shuts down my customer.

....one thing I forgot about. I do have some gateway blocks for the SLC doing protocol conversion from the temperature and pressure controllers. Those need to be left as is.

I would keep those. With RS500, I usually do symbols for tags, then I don't have to remember what all the B's and N's are...

I have found that the comms delay setting really does not.like being bigger than 10ms. I've ,Done 500ms and had delays.
Since it's rebranded I would really want redlion to help.more than that. Is the file extension the same? if not Maybe try renaming it and seeing if it will open in crimson to send to.tech support. Lol

I crossed my fingers and changed the extension. Since I recently started playing around with Crimson, it became clear that GUIcon is more like 3.x version of Crimson, not 2.0, which I originally assumed. It's on an XP VM, and I've got Crimson 3.1 on a Windows 7 VM. So I copied a file and tried importing as a .cd3, which didn't work. Then I tried opening it as a .cd31, and that didn't work either. ....darn.

This used to work on old Beijer HMI software, haven't tried it with Crimson, Obviously don't do this with the original file, just a copy. Open the copy with Notepad, but I think better Notepad++ and read through the stuff that looks like garbage, you should be able to see some header information. Maker, software versions etc.

Create a new project in Crimson 3.0, open it with Notepad++, copy the new header and paste it in to the old file, rename the file to .cd3 and see if it will open.

I used to be able to convert files from Beijer (Cimrex) to Mitsubishi, to ABB and back again.