Strange behavior after 3.1.1 upgrade

mitch · 8 Oct 2020, 02:58

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.1

Rebooted.

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.

A Former User · 10 Aug 2020, 03:28

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?

mitch · 8 Oct 2020, 03:43

@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.

A Former User · 10 Aug 2020, 03:50

@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.

mitch · 10 Aug 2020, 13:34

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.

Phaedrux · 11 Aug 2020, 02:14

Is your wiring run alongside any stepper motor wiring?

dc42 · 11 Aug 2020, 07:40

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.

droftarts · 11 Aug 2020, 09:34

@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

mitch · 8 Dec 2020, 01:32

@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.

fcwilt · 12 Aug 2020, 01:39

@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

mitch · 12 Aug 2020, 01:58

@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.

mitch · 13 Aug 2020, 23:08

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 Baudrate

I 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.

Phaedrux · 14 Aug 2020, 03:21

I'd be tempted to whip up a new 4 wire cable to test with.

mitch · 14 Aug 2020, 12:13

@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?

Phaedrux · 14 Aug 2020, 18:16

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.

A Former User · 14 Aug 2020, 18:28

@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

mitch · 23 Aug 2020, 21:02

@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.

theshabobo · 21 Sept 2020, 15:58

Sorry to bring up an old thread, I am having the exact same issue. Has there been any updates to this?

T3P3Tony · 21 Sept 2020, 16:00

@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

mitch · 22 Sept 2020, 00:32

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.