Strange behavior after 3.1.1 upgrade
-
@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
Cartesian bed-slinger with Duet 3 Mini 5+ WiFi and 1LC : RRP Fisher Delta v1 with Duet 2 Maestro : TronXY X5S with Duet 3 MB6HC and Roto toolboard
-
@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.
-
This sounds a bit like this issue as well: https://forum.duet3d.com/topic/18790/panel-due-sd-card-1-problem-rrf3-1-1?_=1600741174633
