Posts made by norbs12

I'll have to toy around with it more later. I actually found out today I had a faulty PSU causing most of my headaches. On any load change it was causing my lighting to flicker a little. It was not enough to cause printing issues but it was noticable in the lighting and the main reason I was trying to get hardware PWM working (so I could do higher PWM frequencies and avoid the communication from klipper). But now that I got hardware PWM on the lights and the issue persisted, I realized it could be a bad PSU. I finally tried a different PSU and everything is perfect. Working on RMA now.

Either way, I appreciate all the info and quick responses as always.

@dc42 said in Safe to add capacitor to smooth LED powered by PWMed bed output?:

..all Duet heater and fan outputs provide.

Sorry missed the first time around.

I ended up moving to E0 pin and klipper allowed me to enable hardware PWM there. Not sure why the bed didn't work but this works fine too.

Thank you for the info.

OK, kind of thought it would would not be that simple. Though I was thinking I could maybe get around that issue by using a smaller cap.

Klipper does have option for hardware PWM but maybe just not on the heater bed port. Is it only the fan ports that support hardware PWM?

So I'm using klipper with a duet ethernet and because of the recommended limits on the PWM frequency in Klipper, it's a bit irritating to look at. Would it be safe to add a capacitor to the LED bar (i'm using the bed output pins)? If so what spec capacitor is recommended for a 24v system?

Just wondering if I could use the External PanelDue SD card slot for the Duet and not use the onboard slot at all?

Just thinking this could be useful if there was something wrong with the onboard slot or just for convenience.

So I'm using m42 to control pins, is there any way to read their current state with gcode?

@dc42 said in Bad command & Missing characters in Gcode since firmware upgrade:

@BlueDust said in Bad command & Missing characters in Gcode since firmware upgrade:

I assume the CRC checking is enabled by default. How do you enable/disable them?

It's at the bottom left of the Settings/Machine Specific page of DWC 2.04.

If the CRC errors only occur if you upload while printing, then maybe we need to reduce the SPI transfer speed to the Ethernet module if you upload while a print is active, or else adjust the bus priorities.

Would be possible to somehow make the SPI speed user configurable? I've got two boards, one that I just stopped using because of this and another that only works as long as I'm not printing. Would be awesome to recover the other board and use it for something.

@kmhudgins said in Bad command & Missing characters in Gcode since firmware upgrade:

Hi,
I am starting to have the same issue with bad commands. Was this problem every resolved?

I ended up just avoiding uploading during a print that seems to have solved the issue for one board. I still have another board somewhere that it happens to all the time no matter if I'm printing or not that I gave up on.

OK thanks for pointing me in the right direction. It was connected to E1, moved the cable to E0 now. Going to try again but I'm fairly certain that was it. And yes, the led on the board blinks along with the led on the sensor. Thanks again.

EDIT: Just to confirm, everything works now.

Sorry if this has been discussed but I did some searching and didn't have time to keep digging.

The lights all look correct, blinks a few times on power on, then flashes red/green when idle and rapidly blinks green when filament is moving. However, when I run a "M591 D0" I simply get the below, does not matter if the printer is printing or not. I'm assuming "no data received" is bad. Is there a limit to the wire length? I'd say I'm using close to 400mm of wire and could probably cut it down to 300mm but I want to make sure that's the issue. first.

Duet3D magnetic filament monitor on input 3, disabled, sensitivity 24.80mm/rev, allow 70% to 130%, check every 3.0mm, no data received

@T3P3Tony It does seem to be only while printing though I have not had a chance to confirm that it's not related to temperature of the board. Meaning I have not tried uploading immediately after a long print.

@dc42 said in Bad command & Missing characters in Gcode since firmware upgrade:
OK I got to testing a different ethernet board. Same issues unfortunately. I was thinking of trying out the secondardy SD card slot on my paneldue. I would have to wire it up, do you think it's worth the effort?

Also is there a way to slow down the communication between the network card and the processor in maybe some test firmware? I'd try this myself if I knew how... Was thinking just cut the speed in half just to see if it fixes anything, then if it works make this somehow accessible through a custom gcode command and allow tuning of it (if that's even possible).

Thanks for pointing this out. It's a bug, zeros are sometimes omitted. The SHA1 function was contributed code which I didn't check thoroughly. Will be fixed in next release.

No worries, it's close enough to get a good idea if it's the same file. Was just using 'grep' to speed up verifying if it matched and it didn't show up but looked like it should have, which is the only reason I noticed it.

@dc42 quick question, I noticed that M38 doesn't seem to return the exact sha1 even when files are the same. Is this just a bug or am I misunderstanding something.

(using "shasum <filename>" on a Mac)
a03e3b0b03697fccb2997d3e33140801713830c0
-vs-
(M38 on Duet)
a03e3b0b3697fccb2997d3e33140801713830c0

There is an extra '0' using 'shasum' near the beginning of the checksum. I ran the m38 command twice just to make sure it was not a fluke.

Just to make sure I ran a diff and it found no differences.

@dc42 I do have another ethernet chip, from a different board, I can swap it out today and try again. It might take me some time to get back to you since usually this only happens when the printer has been active and warmed up.

@dc42 said in Bad command & Missing characters in Gcode since firmware upgrade:

I am still hoping that one of you can send me a comparison of the original vs. corrupted files, using Windows fc /b or some similar command. See my reply of 20 September.

diff Orig.gcode Downloaded.gcode 
863362c863362
< G1 X69.968 Y5.986 E0.00274
---
> G1 X69.968 Y59.986 E0.00274
863364c863364
< G1 X70.502 Y59.729 E.00274
---
> G1 X70.502 Y59.729 E0.00274
863391c863391
< G1 X57.055 Y6 X4.310 E0.00357
---
> G1 X57.055 Y64.310 E0.00357
908950c908950
< 1 X62.824 Y98.654
---
> G1 X62.824 Y98.654
908990c908990
< G1 X1G02.446 Y66.725 E0.00361
---
> G1 X102.446 Y66.725 E0.00361
909168c909168
< G1 X103.024Y66.246 E0.00529
---
> G1 X103.024 Y66.246 E0.00529
909193c909193
< G1 X109.288 YY66.944 E0.00303
---
> G1 X109.288 Y66.944 E0.00303
909325c909325
< G1 105.718 Y70.234 E0.00378
---
> G1 X105.718 Y70.234 E0.00378
909346c909346
< G1 X103.8273 Y65.606 E0.00274
---
> G1 X103.873 Y65.606 E0.00274
909374c909374
< G1X108.523 Y68.658 E0.00274
---
> G1 X108.523 Y68.658 E0.00274
909399c909399
< G1 F21800
---
> G1 F1800
909426c909426
< G1 X05.883 Y46.145 E0.00355
---
> G1 X105.883 Y46.145 E0.00355
909435c909435
< G1 X08.937 Y47.507 E0.00355
---
> G1 X108.937 Y47.507 E0.00355
909450c909450
< G1 X1F207.974 Y52.969 E0.00373
---
> G1 X107.974 Y52.969 E0.00373
909488c909488
< G1 X06.991 Y46.409 E0.00341
---
> G1 X106.991 Y46.409 E0.00341
909501c909501
< G1 X2109.593 Y50.121 E0.00329
---
> G1 X109.593 Y50.121 E0.00329
909799c909799
< G1 X108.652 Y50891 E0.00274
---
> G1 X108.652 Y50.891 E0.00274
909806c909806
< G1 X106.9987 Y52.455 E0.00269
---
> G1 X106.987 Y52.455 E0.00269
933045c933045
< G1 X129.607 Y68.005 F1000.000
---
> G1 X129.607 Y68.005 F18000.000
933048c933048
< G1 X133.198 Y70.51 F18000.000
---
> G1 X133.198 Y70.751 F18000.000
933062c933062
< G1 X122.179 Y59.2 319 E0.00576
---
> G1 X122.179 Y59.319 E0.00576
933509c933509
< G1 X68.243 Y2.863 E0.00312
---
> G1 X68.243 Y62.863 E0.00312
933546c933546
< G1 X7Y3.197 Y64.893 E0.00307
---
> G1 X73.197 Y64.893 E0.00307
933736c933736
< G1 X53.455 Y66.03 E0.00355
---
> G1 X53.455 Y66.003 E0.00355
933738c933738
< G1 X52.239 Y65.621 E0.0009
---
> G1 X52.239 Y65.621 E0.00609
933760c933760
< G1 X53.400 Y.058.721 E0.00358
---
> G1 X53.400 Y58.721 E0.00358
1181427c1181427
< G1 X27.108 Y2.058 E0.00194
---
> G1 X27.108 Y42.058 E0.00194
1181429c1181429
< G1 X31.272 Y46.431 0.00343
---
> G1 X31.272 Y46.431 E0.00343
1181461c1181461
< G.01 X27.108 Y45.205 E0.12357
---
> G1 X27.108 Y45.205 E0.12357
1181488c1181488
< G1 X34.926 Y55.959 E000139
---
> G1 X34.926 Y55.959 E0.00139
1181513c1181513
< G1 X207.108 Y50.658 E0.09256
---
> G1 X27.108 Y50.658 E0.09256

@HBM-3D Yep.

I also did some minor additional testing.

I got a sha1 sum before upload, checked it again after it got uploaded to the printer and it changed. Afterward, I downloading back to my computer and the sha1 sum remained what it showed on the printer (so no longer the matching the original file).

So this means the failure is one-way, going to the SD card (or writing to it), but not reading down from it. @dc42 does this give you any ideas on possible causes? I now have two boards with this exact behavior. Both were normal for a good year or so before they started doing this.

Having this exact issue on multiple boards now.

Currently the problems is happening on:
Firmware Name: RepRapFirmware for Duet 2 WiFi/Ethernet
Firmware Electronics: Duet Ethernet 1.02 or later + DueX5
Firmware Version: 2.03 (2019-06-13b2)
Web Interface Version: 1.22.6

I swapped out sd cards. Seems to only work when machine has been off for long period of time. I've been uploading my gcode then downloading it to verify before printing, otherwise I'll get "bad command" due to dropped characters or just sloppy prints.

Has there been any update to how to get this fixed?

@fbg My issue turned out to be some sort of hardware problem. Thing is I've had odd issues since I bought the board but always though it was attributed to Wifi. When I moved to Ethernet the issues persisted and I'm already way out of my warranty period. Either way I ended up buying a Fystec Duet from Ali because in no way am I going to spend another $200+ for the real thing.

Either way my fystec has been working perfectly, and I'm saving the authentic Duet (with the hardware issue) for a klipper-based build since klipper doesn't rely on a network connection to the duet board.

That's working well, thank you.