Optimization of EIP Comms

I’m working a project with 9 remote sites, each with a MicroLogix 1400. The sites communicate back to the Ignition server via a multipoint radio network with a theoretical bandwidth of 768 kbps. It seems even this low bandwidth should allow decent comms, but we can’t seem to avoid lengthy timeouts and lose entire stations from the network, sometimes for hours. Radio signal strength is good to each station and consistent.

I’m using the native Ignition 1400 driver with about 40 tags per station as SQLTags (now have disabled all but about 3 essential tags and am using leased tags in all cases) and then also polling these tags using transaction groups on about 2 minute intervals, with some triggering up to higher rates (5-10 seconds) when certain equipment in the station runs to build history in a database.

I guess I’m looking to optimize the network comms to avoid some of these drops and get consistent data coming in to Ignition. I realize that I can do some other things like have a “central” MLX1400 @ the Ignition site and use it to poll the others, partition the radio network further by adding additional base stations, or even put store & forward PC’s in a wheel & spoke configuration for each site, but I want to try to keep the network topology as is. Any advice?

what kind of radios? can you ping the plc’s while they are reporting bad comms in ignition? are the radios reporting any kind of faults?

Not sure on the make/model of the radios - this is a project where I’m working from about 700 miles away from the facility and our scope is software only. I was able to find out that the radios are only rated for 109 kbps - much less than expected. This only further emphasizes the need for some traffic optimization.

I’ll check on pings and radio faults, but no apparent indications of a failure on that end.

if you have series b 1400’s, maybe setting up the 1400 to use modbus tcp may be more friendly than eip on a radio network.

This is worth trying if your devices support it.

Our drivers have absolutely no traffic tuning options, other than the fact that slower scan classes/less tags has the side effect of less frequent communications and less data exchanged when it happens.