How to upgrade from 2.05.1 to 3.1.1?
-
Just don't see how updating RRF would affect the PanelDue firmware; interesting issue if nothing else:/
-
@bearer said in How to upgrade from 2.05.1 to 3.1.1?:
Just don't see how updating RRF would affect the PanelDue firmware; interesting issue if nothing else:/
One explanation is that the PanelDue behaved the same but RRF2 didn't detect and response to the bad command, for example if it took longer time to reboot. (this is a speculation). I may try to restore RRF2 and look again with the logic analyzer.
-
4 wire or ribbon cable for the Panel?
-
@Phaedrux , 4 wires.
-
I might try a different 4 wire cable. I had some bad command and the panel being stuck on "connecting" occasionally and it turned out to be a bad 4 wire cable. I also braided the replacement since it runs along with some stepper wires. Haven't had an issue since.
-
@Phaedrux said in How to upgrade from 2.05.1 to 3.1.1?:
I might try a different 4 wire cable.
The problem was very consistent. I just reverted my printer to RRF 2 and the problem disappeared. I will check tomorrow with logic analyzer if the transmission from the PanelDue is corrupted the same and possibly RRF2 is just more tolerant somehow.
-
@Phaedrux, I use a logic analyzer to capture the duet/paneldue serial traffic under RRF2 and RRF3. In both cases the results are very consistent, with same hardware, same cables, etc, always works cleanly with RRF2 and always giving an error message with RRF3.]
Looking at the capture signal, RRF3 behaves differently from RRF2. With RRF2, the duet lets the paneldue sending the entire M112 message with no response, with RRF3, the duet response immediately with an error message.
https://github.com/Duet3D/PanelDueFirmware/blob/master/src/UserInterface.cpp#L1674
This is how it looks under RRF2:
And this is under RRF3
This is from the rrf3.csv, it shows how the the duet response (TX) before the paneldue completes its transmision (RX):
3.274821000000000,TX,1 3.274994000000000,TX,} 3.275168000000000,TX,\n 3.476848000000000,RX,N (0x4E) 3.477020000000000,RX,4 (0x34) 3.477193000000000,RX,9 (0x39) 3.477365000000000,RX,3 (0x33) 3.477538000000000,RX,4 (0x34) 3.477710000000000,RX,' ' (0x20) 3.477883000000000,RX,M (0x4D) 3.478055000000000,RX,1 (0x31) 3.478228000000000,RX,1 (0x31) 3.478400000000000,RX,2 (0x32) 3.478573000000000,RX,' ' (0x20) 3.478745000000000,RX,; (0x3B) 3.478918000000000,RX,'240' (0xF0) 3.479090000000000,RX,'15' (0x0F) 3.479263000000000,RX,* (0x2A) 3.479435000000000,RX,2 (0x32) 3.479608000000000,RX,5 (0x35) 3.479685000000000,TX,{ <<-- RRF3 doesn't like the M112 message 3.479780000000000,RX,5 (0x35) 3.479858000000000,TX," 3.479953000000000,RX,\n (0x0A) 3.480032000000000,TX,s 3.480205000000000,TX,e 3.480378000000000,TX,qThis is the corresponding section from RRF2:
4.297585000000000,TX,1 4.297759000000000,TX,} 4.297932000000000,TX,\n 5.048296000000000,RX,N (0x4E) 5.048468000000000,RX,1 (0x31) 5.048641000000000,RX,8 (0x38) 5.048813000000000,RX,8 (0x38) 5.048986000000000,RX,' ' (0x20) 5.049158000000000,RX,M (0x4D) 5.049331000000000,RX,1 (0x31) 5.049503000000000,RX,1 (0x31) 5.049676000000000,RX,2 (0x32) 5.049848000000000,RX,' ' (0x20) 5.050021000000000,RX,; (0x3B) 5.050194000000000,RX,'240' (0xF0) 5.050366000000000,RX,'15' (0x0F) 5.050539000000000,RX,* (0x2A) 5.050711000000000,RX,1 (0x31) 5.050884000000000,RX,9 (0x39) 5.051056000000000,RX,6 (0x36) 5.051229000000000,RX,\n (0x0A) // 1 sec later, per the 1000ms in the source code 6.050462000000000,RX,N (0x4E) 6.050635000000000,RX,1 (0x31) 6.050807000000000,RX,8 (0x38) 6.050980000000000,RX,9 (0x39) 6.051152000000000,RX,' ' (0x20) 6.051325000000000,RX,M (0x4D) 6.051497000000000,RX,9 (0x39) 6.051670000000000,RX,9 (0x39) 6.051842000000000,RX,9 (0x39) 6.052015000000000,RX,* (0x2A) 6.052187000000000,RX,4 (0x34) 6.052360000000000,RX,2 (0x32)Any idea why the RRF3 doesn't like the M112 message and responds immediately instead of waiting for the M999 ?
-
@zapta said in How to upgrade from 2.05.1 to 3.1.1?:
Any idea why the RRF3 doesn't like the M112 message and responds immediately instead of waiting for the M999 ?
i think the 0xf0 0x0f is a special case to reset immediately without getting stuck in the queue; so the difference must be in how RRF3 reacts to this? time to put up the
batdc42 signal? -
@dc42 is away on vacation until next week, but I'm sure he'll find this interesting.
-
@bearer, I think you are right. The code actually says that RRF2 and RRF3 are different in their handling of the stop command:
// We send M112 for the benefit of old firmware, and F0 0F (an invalid UTF8 sequence) for new firmware SerialIo::SendString("M112 ;" "\xF0" "\x0F" "\n")https://github.com/Duet3D/PanelDueFirmware/blob/master/src/UserInterface.cpp#L1674
-
i did get the sense when dc42 commented the 0xf0 0x0f thing that new firmware also included newer rrf2 but couldn't find any refrence to it
but its odd that duet3 people have been using paneldue since the first rrf3 with no similar reports, so there might be more to it (or they never pressed the stop button).
on the other hand there isn't any reason the paneldue should transmit anything between 0xf0 0x0f and 0x0a (0x0a being the newline)?
(edit I have a 4.3 regular paneldue and a 7i here - I was hoping to log the same data from, but looks like a case for tomorrow. but should at least be able to confirm if those behave the same)
-
@bearer said in How to upgrade from 2.05.1 to 3.1.1?:
I was hoping to log the same data from, but looks like a case for tomorrow.
Thanks @bearer. Looking forward for your findings.
-
@bearer said in How to upgrade from 2.05.1 to 3.1.1?:
on the other hand there isn't any reason the paneldue should transmit anything between 0xf0 0x0f and 0x0a (0x0a being the newline)?
Its the checksum thats before the newline
N13 M112 ;ð␏*247
N2 M112 ;ð␏*199
So the bad command would change with the line number and checksum presumably.I.e. the issue is with RRF3
-
Yeah, its definitively the Duet reacting to the rx buffer after 0x70 0x07 and ending up parsing it as a bad command.
If you increase the baud rate you get one less digit, and if you decrease the baud raute you get the asterisk plus the digits as well, i was hoping the asterisk would get the parser to see it as checksum and discard it, but no.
Poked around a bit, but didn't find where the 0x70 0x07 is handled, it seems M112 is clearing out the rx buffer as part of the estop. Id test flushing SERIAL_AUX_DEVICE rx buffer as its initialized but messed up the build env somehow.
It'd be interesting to see one of the Duet3 users with PanelDue tap the stop button and see if they get the same error. Is searching for
M575 P1 B57600 S1and tagging everyone who didn't read the upgrade notes bad form?:P -
@bearer said in How to upgrade from 2.05.1 to 3.1.1?:
So the bad command would change with the line number and checksum presumably.
Yes, this is what I experienced, different code numbers in the error messages.
Is searching for M575 P1 B57600 S1 and tagging everyone who didn't read the upgrade notes bad form?
Can you explain? I am using Duet2 wifi with 57600 baud to the PanelDue. Were there upgrade notes to change the baud rate?
-
@zapta said in How to upgrade from 2.05.1 to 3.1.1?:
Can you explain?
sorry, just a bad joke - there was a buttload of people posting something like "oh my god my paneldue stopped working" after upgrading to 3.1.1 ... figured one of them could test estop on the duet3 ... so most recent posts containing M575 would be one of those.
Anyways, back on topic - is there an signal we can analyze to indicate the actual reset? curious if the bad command comes before or after the duet being reset.
PanelDue Duet N162 M112 ;ð␏*192 > < {"seq":3,"resp":"Emergency Stop! Reset the controller to continue.\n"} < {"seq":4,"resp":"Error: Bad command: 192\n"} N163 M999*46 > N164 M408 S0 R2*47 > N165 M408 S0 R4*40 > < {"seq":1,"resp":"WiFi module started\n"}looks like it might be before, or it gets reset again by M999?
-
@bearer said in How to upgrade from 2.05.1 to 3.1.1?:
is there an signal we can analyze to indicate the actual reset?
Maybe one of the outputs that are turned off on reset? Heaters, PS_ON, etc? I don't know thought what is the delay added by the power mosfets so maybe the signal before the mosfet driver.
BTW, what logic analyzer are you using? I am using an 8 bit saleae which is good enough for the rare occasions I need it but its software is not great.
-
Maybe one of the outputs that are turned off on reset?
I tried a few different ones, was just surprised by the spread; but it definitely looks like its the code that was supposed to clear the buffer that isn't doing it and the firmware has time to process the rest triggering a "Bad command" error before reset occurs.
BTW, what logic analyzer are you using?
I got a Pro8 from Saleae; and v1 software is junk but I'm quite happy with the v2 beta that they just did a survey asking if v2 was mature enough to replace v1. I said 95%, they're pretty good at bugfixing, but not quite superhero level like dc42.
If you haven't tried the beta, then I'd give that a go, I've only seen two bugs that are just visual representation and as far as I can tell they were hunted down a while back.
If you were wondering about the side by side serial representation then I did that by hand, but its quite easy with the Pro8 as it has the data terminal, I just added some spacing.
Anyways, all the planets aligned and the mail man just dropped off my Hemera, and seconds later the UPS guy came with the power supply and 3-wire fans so stuff to do:)))
-
@bearer said in How to upgrade from 2.05.1 to 3.1.1?:
I'm quite happy with the v2 beta...
Thanks, I will give it a try. The serial analyzer dump of V2 seems to be easier to to understand.
-
@zapta said in How to upgrade from 2.05.1 to 3.1.1?:
The serial analyzer dump of V2 seems to be easier to to understand.
The "data terminal" shown is for some unkown reason reserved for the Pro8 and Pro16, but everything is easier to read and use in v2 imho.
