C-More alternatives?

[Scot]

Is there a HMI compatible with Do-More that updates a little faster than the C-More panels? My C-Mores take 4 to 5 seconds to update. But I've noticed the Do-More designer has no problem updating several times per second. So, I don't think it's network congestion. I think the C-Mores are just really slow.

[RBPLC]

Redlion HMI's have drivers for built-in memory. They're well regarded and have a ton of features. C-More's aren't generally that slow. They're are a myriad of things that could be affecting your panel performance.

[Garyhlucas]

Been using C-Mores for more than 10 years and haven?t seen that happen except when there were network issues.

[Controls Guy]

All HMI programming software is crap IMO (actually ADCs is probably among the best), so I pick based on screen resolution, brightness and saturation, and quick startup time on power up.    I'm currently using Idec's which use Kyocera TFTs.    Really really nice screens and they boot almost instantaneously.

[Scot]

Do the Idec's have a Do-More communication protocol or does every tag have to be read using modbus?

[Controls Guy]

No, I don't believe they have a native one.

I use Modbus intentionally to black box the PLC and HMI from one another, plus keep all the comms in the sandbox, so that's not a criteria for me.

[Controls Guy]

They do also have a native K-Sequence driver, but I don't use it, cause you know, the black box thing previously mentioned.

[Scot]

I'm pretty sure the C-More problem is non-contiguous memory locations being read through ECom cards on multiple PLCs.
I have one screen page that's pretty simple and only shows a few timers and counters from a 1-rack Do-More connected to the built-in ethernet port. That page updates about once per second.
Any other screen, even reading only from a single ECom, takes 4 to 5 seconds.

[franji1]

I'm pretty sure the C-More problem is non-contiguous memory locations being read through ECom cards on multiple PLCs.
I have one screen page that's pretty simple and only shows a few timers and counters from a 1-rack Do-More connected to the built-in ethernet port. That page updates about once per second.
Any other screen, even reading only from a single ECom, takes 4 to 5 seconds.

You got something going on on your network.  4 to 5 seconds is getting to where the retries could actually be making the matter much worse (compounding the problem).

On the physical ECOM network, do you have multiple devices polling the PLC, or it's polling other devices, or other PLCs are doing a bunch of broadcasts (logging DmLogger events with DST61 set to (level) 2).  You may need to Wireshark on the ECOM wire to see what is going on given that the c-more can only update once every 4 or 5 seconds.

It's not the C-more.

[Scot]

Each PLC has it's own local/isolated network for expansion racks connected to its built-in ethernet port - if it has expansion racks. Two of the PLC's do not. There are 7 PLCs. 5 connected to a Plant LAN through their ECom card and 2 connected directly to the built-in ethernet port. There are 6, 15" EA9 C-More panels on the same Plant LAN (one is headless). Plus 2 PCs for programming. One of those PCs monitors a PID trend constantly because it's monitor is much larger than a C-More and the Designer software updates much faster.

They are all using Peerlink. One is sending logger packets once every 15 minutes (DST61=1).

I'll try wireshark after a reboot.

[BobO]

PLC scan time might also be relevant.

[franji1]

Each PLC has it's own local/isolated network for expansion racks connected to its built-in ethernet port - if it has expansion racks.

Very good.

There are 7 PLCs. 5 connected to a Plant LAN through their ECom card and 2 connected directly to the built-in ethernet port. There are 6, 15" EA9 C-More panels on the same Plant LAN (one is headless). Plus 2 PCs for programming. One of those PCs monitors a PID trend constantly because it's monitor is much larger than a C-More and the Designer software updates much faster.

PID update polling should only be affecting the one PC it is monitoring (is this the one w/4 second update time)?  Not that it would bog it down THAT much, regardless (unless your PLC scan time is > 50ms)

They are all using Peerlink.

That should only be affecting the onboard Ethernet ports, 10Hz broadcast rate is pretty slow - no retries.  Unless you've configured your ECOM modules to do PEERLINK???

One is sending logger packets once every 15 minutes (DST61=1).

As long as there's no PLCs w/DST61 = 2 (BRX MQTT log events are extremely frequent)

I'll try wireshark after a reboot.

We've had rogue digital video cameras doing UDP broadcasts on our local subnet bring throughput to its knees.  You might be amazed what you see...

[Scot]

The EComs are doing the peerlink communications on 5 of the PLCs. Only the 2 without expansion racks are using the Peerlink instruction in the Main code block.

Wireshark shows 85 to 95 packets/sec of traffic on the Plant LAN for the PLC IP addresses. About the same for all traffic with a few short spikes up to 120 packets/sec. But it's not seeing any traffic from the C-More IP addresses. Wireshark is only seeing the broadcast packets with a destination IP of 255.255.255.255. So those packets are probably Peerlink local broadcasts, which seems about right.

It will take me some time to decipher Wireshark and its filters.

The slowest PLC scan time I have is 9.4 ms. One other is at 9.1 ms. The rest are 1 ms to 5 ms.

[Scot]

I found the problem.
I have 636 alarms (events).
If I delete them all, the screen will update about once per second.
However, I can't delete the alarms. So I have 2 options:
1. Find a way to make the alarms more efficient
2. Live with slow screens.

[Controls Guy]

Threaten them.