Strange behavior after 3.1.1 upgrade
-
I have been running a 3.0 RC for awhile and it was rock solid.
Recently I upgraded to:
Board: Duet 2 Ethernet (2Ethernet)
Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.1.1 (2020-05-19b2)
Duet Web Control 3.1.1Rebooted.
My existing config.g and all settings seemed to work fine and required no changes. I did need to insert the baud rate command at the end of my config for my Paneldue but that was easy enough. Paneldue has been updated to the most recent firmware as well. All seems to work fine.
When printing I get these strange messages that only pop up on the PanelDue and can not be found in the console or browser pop-up messages. The commands do not make sense at all.
Error Bad Command: I408 S9 R15
Error Bad Command: R11*36
I have searched the g-code and none of the offending errors are present. Moments I had a print just stop. It didn't show failed or paused. Just hung. It has never done that before. It is almost as if something is corrupted? Would redoing the firmware update via drag and drop of the .bin into the DWC do anything at this point?
Update: Once my current print is finished I am going to try lowering the baud a bit to see if that fixes the issue. Seems strange to do so as I hadn't had any issues with this prior to the updates.
-
by the looks of it is a similar issue as one other user recenctly solved by moving the paneldue wiring away from noise sources. It does seem to be the normal paneldue traffic, just corrupted and/or partial messages.
lowering the baud rate can help with noise, but finding the source might be a better solution; however it does raise the question is there anything in 3.1.1 that is causing the checksums to not silently supress the bad commands due to noise, or maybe differences in noise generated by the stepper or heater wiring?
-
@bearer , Thanks. Ideally this is just a paneldue issue.
All of my steppers are twisted pairs but the panel due is just the standard flat ribbon cable.
I am surprised to be having issues after the upgrade since prior to this everything was rock solid. Perhaps you are onto something with the newest firmware potentially lacking some error correction/tolerance that the previous version seemed to handle better.
I could switch the PanelDue over to twisted pairs for the serial commo lines to see if that makes a difference.
I do not use the SD card slot on the display at all so that cable isn't attached. That being said, perhaps lowering the Buad is a viable option as well.
-
@mitch said in Strange behavior after 3.1.1 upgrade:
Perhaps you are onto something with the newest firmware
there is at least one issue related to buffer handling if you use the stop button on the paneldue you will get a bad command; so it could be there are related issues (and iirc dc42 have said there is something different with the stepper driver settings with regards to audible noise, so maybe it also affects electrical noise)
i'd lower the baud rate as a start and see what dc42 says when hes done putting out the assembly house fire with the duet3 boards.
-
I have also noticed since moving to 3.1.1 that I have had to really widen my range of error on my laser filament sensor. I am in the process of switching that over to an indirect approach as well as adding some shielding to that connection.
-
Is your wiring run alongside any stepper motor wiring?
-
Do you have the correct M575 command in config.g? Normally this:
M575 P1 B57600 S1
The S1 parameter normally causes RRF to throw away corrupted commands.
-
@mitch See dc's response above. Also, ribbon cable is uninsulated, so quite probe to picking up interference. If you're not using the SD card, it would be best to use the 4-wire cable, and twist the comms wires together (usually the green and blue wires).
If you change the baud rate in config.g, don't forget to change the baud rate on the Paneldue settings.
Ian
Bed-slinger - Mini5+ WiFi/1LC | RRP Fisher v1 - D2 WiFi | Polargraph - D2 WiFi | TronXY X5S - 6HC/Roto | CNC router - 6HC | Tractus3D T1250 - D2 Eth
-
@droftarts for the four wire cable I am using two sets of twisted pair already.
I did verify that I was using the correct M command per DC's message. I stepped the baud rate down to the next lower rate. I was about to test it out with a new print and then we got hit with 100MPH winds and it took out the power for 400k people. Got a little gen for the basics but won't have the printer back online for at least a week.
-
@droftarts said in Strange behavior after 3.1.1 upgrade:
...Also, ribbon cable is uninsulated...
Ian
I think you mean unshielded and that is true of most flat cable you will encounter BUT you can actually can get shielded flat cable. But it can be a bit of a bear to use.
Frederick
-
@fcwilt I did mean unshielded. I think my phone's autocorrect must have completed the sentence wrong. That being said, I went back to verify the connection and realized I was actually using two twisted pairs from stranded cat6 cable. With the serial data signals as a pair.
One pin was not completed seated in the connector. I reseated the pin and also dropped the baud rate to the next lower rate. I verified the panel came up but then we got hit by a huge storm and power has been out so unable to retest after the changes.
The 4pin cable does not follow a stepper cable (also using twisted pairs) so I feel I can rule that out.
Ideally it will turn out to be an intermittent connection from that loose pin.
-
Power has been restored and I have begun testing with the lower 38400 baud rate. I also made sure the Green/White wire was fully seated in the connector this time.
No change in behavior. I still get random errors popping up on the Paneldue during prints (never when idle). I did notice that I never see any errors when homing but the errors are so sporadic so it is hard to tell if that is really any kind of indication.
My serial lines are cat 6 twisted par in the attached image they are the brown pair. The power lines are the green pair.
My Paneldue wiring does not follow stepper path. It comes directly out of the enclosure and up one leg of the frame to the display mounting position. In this image it is hard to see but the two pairs are in a braided cable and tucked into the frame T slot channel to hide the wire where it travels straight down and enters the enclosure.
Right now both the display and the config.g are set for:
M575 P1 S1 B38400 ; set the PanelDue BaudrateI have made no configuration changes other than upgrading the firmware. DWC, Duet 2, and PanelDue. I was previously running from 3.01 RC12 to 3.1.1 on the Duet 2.
-
I'd be tempted to whip up a new 4 wire cable to test with.
-
@Phaedrux I will do just that. I can dig around in my wire bin to see if I can find a USB or similar cable that is shielded and will be long enough. It just seems strange after nothing but firmware updates I am having issues with EMI noise. Even if I can fix the display and filament detector with better cables will that just be masking the real problem?
-
There had been a few other similar issues identified with garbage commands and the PanelDue with fw 3.1.1, as mentioned by @bearer, so they may be related.
If you went back to FW 2.05.1 you could confirm.
The question would still remain though, does RRF 3.1.1 cause the issue, or does it simply illuminate an existing wiring issue. There haven't been widespread reports of this, so it seems to be isolated.
If you test a different cable and rolling back the firmware that might give us some more clues.
-
@Phaedrux said in Strange behavior after 3.1.1 upgrade:
does RRF 3.1.1 cause the issue, or does it simply illuminate an existing wiring issue.
i think perhaps both. zaptas thread about the stop button seems to be 3.1.1; but random errors may be errors that 2.05.1 suppressed
-
@Phaedrux I have built a new cable from a shielded USB cable.
Old cable with twisted pair Cat 6:
PIN # Pair/Wire Signal 1 Brown 5VDC 2 Brown/White GND 3 Green URXD0 4 Green/White URTD0
New Wire Configuration with shielded cable:
PIN # Pair/Wire Signal 1 Red 5VDC 2 Black GND+Shield 3 Green URXD0 4 White URTD0
The cable connects to the Duet and exits the case taking a path away from extruders to the display. I also changed my baud rate back to 57600 on the paneldue and the config.g
Display looks good. I started up a test print. So far so good.
-
Sorry to bring up an old thread, I am having the exact same issue. Has there been any updates to this?
-
@Phaedrux said in Strange behavior after 3.1.1 upgrade:
If you went back to FW 2.05.1 you could confirm.
The question would still remain though, does RRF 3.1.1 cause the issue, or does it simply illuminate an existing wiring issue. There haven't been widespread reports of this, so it seems to be isolated.
If you test a different cable and rolling back the firmware that might give us some more clues.Try
-
After I made a "super" cable I no longer have issues. The documents say that a shielded cable is not necessary. After the firmware update to both the Duet and the PanelDue for 3.1.1 I had to use an old USB cable to resolve it. I never bothered to try old FW as I needed to get back up and running.
