PLC stuck in Idle status periodically

Once or twice a day our Allen Bradley PLCs stop communicating and show “Idle” status on our development servers and we’re not sure why. We’re using version 8.1.1 at the moment.

On this project we have two tag servers, and one client server to deal with our high tag count. Initially in the project we were using one server, and it was getting overloaded constantly as we were adding tags, and the PLCs would commonly go into Idle status. Once we split out our servers however, the memory and CPU on the servers never get too high, and communications seem to be working decently well, but we still see devices dropping into “Idle” state and not coming back until the connection is refreshed through the gateway.

I’ve tried increasing and decreasing the Max Concurrent Requests, as well as the timeout parameters to no avail.

We’re actively developing on these PLCs, and sometimes during tag imports some PLCs go Idle, then back to Connected within a second or two, but sometimes they just get stuck in Idle.

Has anyone else had this problem?

Yes.

Though it was thought to be fixed in 8.1.1. One sufferer recently noted a possible correlation to online creation of program-scope tags. It is definitely correlated with runtime development on the affected PLCs. Also a possible correlation with v32 firmware.

When it occurs, it generally is fixable by restarting the Ignition device (go to edit the device config and just hit save).

We have not been able to reproduce this in house yet.

I am going to get with a QA person soon to explain the issue and then put out a call here on the forum for anybody who is experiencing this relatively frequently and can provide us with both their gateway backup and their PLC program or tag export so we can hopefully reproduce it. I suspect there needs to be a certain amount of real world comms load on the PLC while doing online edits to trigger it.

1 Like

FWIW I haven’t had this experience and I’ve performed a substantial amount of online PLC changes on v32 (L83, 80% memory used) over the past 12 months. Phase imports, Program imports, Rung imports, UDT/AOI imports, creation of global and program tags you name it I have probably done it. Various flavors of v8.0.x

Our PLCs have quite a few tags, and each import is generally pretty large, so that wouldn’t surprise me that it’s related to communications load.

@pturmel - That’s what we’ve been doing to reset them. Whenever someone on the team says that their screens are dead/ unresponsive one of the Ignition admins goes on, opens the device configuration, and saves without making changes. Although sometimes I bump up the timeout, or play with the concurrent requests to see if it makes a difference although at this point it hasn’t. We are running V32 software in the PLCs.

Edit: @Kevin.Herron this happens a couple times a day for us, so if you’d like to watch our system and watch us do a tag import or something we could probably schedule some testing time.

Bumping this thread. It is happening on our system(Ignition version 8.1.3 PLC version 32.012) now as well. Are there any updates on fixing this issue?

Sure, it was fixed as of 8.1.4.

3 Likes