Error when writing to BRX

[JeffS]

So I noticed that when the BRX gets somewhat loaded (15ms scan time), that if I do a switch to Program mode update that I get "The PLC is not currently in PROGRAM mode." error like the attached screenshot.  Seems when it commands the switch to program mode that the Watchdog timeout triggers and the PLC reboots which causes this error.  Is this something that anyone else has seen?

[MarkTTU]

I saw that once about a year ago when I was working with a project with a lot of loops and long scan time. I couldn't tell you if me changing the program to get the scan time down fixed it or a firmware update fixed it, but I haven't seen it again.

[JeffS]

I can program it fine if I manually switch it to program mode then write the program.  And it isn't consistent, as sometimes it works just fine.

[MarkTTU]

I'd check firmware and software and make sure you're on the latest versions of everything. If that doesn't fix it take a look at any comms you have going on and see if slowing those down helps any. The program I saw that with was running up over 20ms when I saw it. I've since managed to get my scan down to 5-6ms, but during that same time there was also a firmware update so I really don't know for sure what the fix was.

[RBPLC]

I've seen similar at random times. I usually try to download again and it goes the second time. I've never checked the log to see if there's any kind of timeout issue. See below for something similar:
https://forum.hosteng.com/index.php?topic=3758.0

[BobO]

A loaded PLC will slow down comm responses. At times that can cause the mode chance dialog to wrongly conclude the mode change didn't happen. I wanna think we've touched up the timeout on that with the hope that we eliminate it, but I could be misremembering.

As for a watchdog firing, that should never happen. That points to either a programming error or a PLC bug. If you can dupe it, I'd love to see it.

[JeffS]

Not sure how to replicate it exactly as sometimes it works and others it doesn't.  I will add that I also get this error when I try a RUN mode write.

[BobO]

Not sure how to replicate it exactly as sometimes it works and others it doesn't.  I will add that I also get this error when I try a RUN mode write.

That's just a side effect of not being able to do comm with the PLC.

[franji1]

I wanna think we've touched up the timeout on that with the hope that we eliminate it, but I could be misremembering.

Designer 2.9.3 added support for asynchronous mode change - up to 2 seconds.  Make sure you have 2.9.3 or 2.9.4.

[BobO]

Designer 2.9.3 added support for asynchronous mode change - up to 2 seconds.  Make sure you have 2.9.3 or 2.9.4.

Good. I thought I remembered that.

However if the PLC watchdogged and rebooted, it would take longer than 2 seconds. With or without our tweak he'd still see those failures.

[JeffS]

I am running Do-more 2.9.4 and attached a screenshot of the PLC firmware.

Should there be evidence of a comm issue that I can look at if the PLC is failing to communicate?   Other than this error when I try and do a RUN mode write I don't get any Link errors.

My PLC isn't currently talking to any other PLCs and the average scan time is 15ms (Max/Min 23ms/2.5ms).  This is my test PLC, not actually hooked up to a full system, and to test load on the PLC I have everything configured to be on. That means it is currently attempting to ping 25 different devices once a minute along with attempting some DLRX/DLWX commands, reading and writing to the SD card, and sending data to a server, and all that appears to be working fine. 

In the system log I see where I did get a watchdog timeout when I did a Program/run update but it was actually still successful.  I don't see any other watchdog timeouts after that when I do my RUN mode updates. Pic attached.

[BobO]

I am running Do-more 2.9.4 and attached a screenshot of the PLC firmware.

Should there be evidence of a comm issue that I can look at if the PLC is failing to communicate?   Other than this error when I try and do a RUN mode write I don't get any Link errors.

My PLC isn't currently talking to any other PLCs and the average scan time is 15ms (Max/Min 23ms/2.5ms).  This is my test PLC, not actually hooked up to a full system, and to test load on the PLC I have everything configured to be on. That means it is currently attempting to ping 25 different devices once a minute along with attempting some DLRX/DLWX commands, reading and writing to the SD card, and sending data to a server, and all that appears to be working fine. 

In the system log I see where I did get a watchdog timeout when I did a Program/run update but it was actually still successful.  I don't see any other watchdog timeouts after that when I do my RUN mode updates. Pic attached.

According to the log, that isn't a hardware watchdog/reboot, that is a software watchdog, which is the result of logic taking too long. The default is 200ms, unless you have changed it.

If the scan spikes to something very high, as suggested by the software watchdog, then that could easily affect comm.

[JeffS]

Yeah, I misread that one as a hardware watchdog.  Seems my software watchdog timeout is 1000ms, and my recorded MAX scan time is still 23ms.

[BobO]

Yeah, I misread that one as a hardware watchdog.  Seems my software watchdog timeout is 1000ms, and my recorded MAX scan time is still 23ms.

I'm sure it was something misbehaving during the program update. Not sure what.

[JeffS]

There anything I can look at to try and narrow it down?

Thanks