Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: JeffS on April 25, 2023, 04:54:34 PM
-
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?
-
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.
-
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.
-
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.
-
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
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
There anything I can look at to try and narrow it down?
Thanks
-
There anything I can look at to try and narrow it down?
Thanks
Not really. The big help to us would be if you could dupe it semi-reliably. Barring that, we can do a special build of the firmware that adds in some additional diagnostics that might give us an idea of where the scan spike is coming from.
-
So far this morning I have consistently(12 times in a row so far) gotten the "Unable to determine if OLD to New project transition has complete." error. Always happens during the ROM update phase. If I try to write again pretty quickly after the error I get "Waiting for previous ROM operation to complete" and takes 15-20 seconds to clear.
So far as reproducing... My current setup and the current change I am trying to write the PLC is consistently giving me this error. What can I do to shed some light on the issue?
-
Is this a RUN mode edit (i.e. PLC is staying in RUN mode while the PROGRAM is being written), or does this Write have a SYSCONFIG change, so the Designer Write to PLC Dialog changes the PLC to PROGRAM mode before it initiates the Write to PLC?
-
Currently what I am testing is the RUN mode edit. Sticking to it since I can make it repeat currently, the problem has been sporadic previously where it might fail 5 times then work. So far it hasn't worked yet.
-
Also I tried to do a compare to list off the differences I was trying to write and ... says programs match. Disconnected and connected with another instance of Do-more to see what the PLC showed, and it has the bits of code I added along with documentation. So I'm not sure what it thinks is different and is failing to write to the PLC at this point.
When I connect back with my saved program it still indicates the rungs I had changed(but are showing up in the PLC when I connect with a different instance) are different from the PLC. And still fails the RUN mode update.
No idea if this matters, but this is the same program that has the duplicate nicknames for bits because my nicknames are at max character length(https://forum.hosteng.com/index.php?topic=3786.0). Also I am using 62514/65536 of the program memory.
And I can confirm that if I change something in the program and write the PLC, even though it gives the "Unable to determine if OLD to New project transition has complete." error the changes are being written. Program still indicates the PLC and Software are different though.
-
Next time you write to the PLC, bring up a Data View and look at
ST200:B in HEX/BCD format
It should be 0x00 after all the Project updates to FLASH are finished.
We poll that value at the end of the Write Project to PLC process, looking for it to go to 0x00. We give it 60 seconds, then we error-out if it stays non-zero.
What are you seeing for this in Data View?
-
Looks like it takes another 49 seconds after the error before the contents zero back out. Showed 0x04 for part of the update then 0x05 up to and past the error until it finally went to 0x00.
-
ST200 is PROGRAM ROM Update (0x01)
ST201 is SYSCONFIG ROM Update (0x02)
ST202 is DOCUMENTATION ROM Update (0x04)
so
0x04 is just DOCUMENTATION
0x05 is DOCUMENTATION and PROGRAM (0x04 | 0x01)
0x00 is none
-
Ok, so it is taking extra long to update the program and documentation ROM? Much more so than the program anticipates at maximum?
-
EDIT (see below)
Yes. It polls those values, looking for the value 0x00, for up to 60 seconds.
But you're seeing that it's another 49 seconds after that, so it's taking 109 seconds to write the Project to ROM.
FYI, you definitely need to wait for ST200:B to get to 0x00 before trying any other Project Writes. The 60 second "max" was just a guess. With huge programs with huge scan times, with large documentation files, doing RUNTIME edits, it obviously can take longer than 60 seconds. We can definitely tweak that.
But I don't think this is your issue (could be?), especially if you try another Write to PLC while the previous one is still updating flash!
SORRY - 60 seconds is the maximum amount of time we wait BEFORE we start a NEW Write to PLC. Designer makes sure none of the PREVIOUS ROM updates are occurring BEFORE it starts a NEW Write Project to PLC. If it takes longer than 60 seconds, Designer does not try to write the Project - it just tells you to try again.
-
As a work-around, just do PROGRAM mode changes. This may mess with your logging file entries, but the integrity of the project in the PLC flash is crucial.