Posts made by SAtech

Not sure if this is already known, but I think I have encountered a bug. On the first couple layers of a small object, the temperature setpoint changes, and the fan turns on to 100%, according to my slicer settings. However, the hotend struggles to keep up, and faults with "temperature rising too slowly". I do have a pretty powerful fan, but I'm also using a block sock. This is with a v6 hotend. I did tune with the new algorithm using M303 T0 S245, which did activate the fan.

@chrishamm All appears to be good. I'll update when the current print finishes.

Update: Print finished successfully and with no unwanted artifacts. That seems to have solved it!

@chrishamm I actually am using a Duet2 an SBC mode, but would be happy to test.

Alright, I've managed to capture a DCS log of an affected print. It seems like an underrun of the movement buffer, but it also happens sometimes in the middle of travel moves, so I'm not really sure there.

dsf_log.txt

Also, a picture to better show what I mean.

All those little blobs are what I'm talking about. They're caused by the print head dwelling for a bit at that location.

@Phaedrux I have separate 5v and 24v power supplies with the grounds connected. The pi and the 5V_EXT pins of the duet are powered by the 5v supply, which is always on. The duet switches the 24v power supply via a relay.

I believe that undervoltage event is due to me switching off the 24v supply once since the duet was last reset.

@oozeBot @TypQxQ No, what I am describing is different. I can only describe it almost like if your jerk is set too low on curved segments, only that it happens randomly and not only on curves, if that makes any sense.. It doesn't loose steps, but it's as if the controller hangs for a bit. I'll see if I can get a video.

I think what you both are experiencing is similar, and I have also experienced it way back on 3.1.1. If my travel speed was too high, it would loose steps exactly as in your videos. Haven't tried it without compensation, I should try that.

I can confirm that this does NOT occur in standalone mode. I have tested the same file in SBC mode and in standalone mode and get no jerkiness in standalone.

@dc42 @chrishamm anything else I can do to help?

Edit: DCS log coming soon

Sorry to bring this back up, but after updating to RRF 3.2-b3 I am still observing unwanted jerkiness during print moves. As the print head is moving, it stops for about 50ms at a time randomly, occurring roughly 1-2 times/10s. M122 shows no unusual information:

=== Diagnostics ===
RepRapFirmware for Duet 2 + SBC version 3.2-beta3 running on Duet 2 1.02 or later + SBC (SBC mode)
Board ID: 08DGM-917N9-FLMS4-7JTDG-3SJ6J-9HV4G
Used output buffers: 1 of 24 (21 max)
=== RTOS ===
Static ram: 20636
Dynamic ram: 103772 of which 60 recycled
Never used RAM 5580, free system stack 124 words
Tasks: Linux(ready,79) HEAT(blocked,306) MAIN(running,381) IDLE(ready,19)
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:27:46 ago, cause: software
Last software reset at 2020-11-10 22:45, reason: User, GCodes spinning, available RAM 5580, slot 1
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task Linu
Error status: 0x00
MCU temperature: min 30.3, current 30.6, max 30.6
Supply voltage: min 23.8, current 23.9, max 24.0, under voltage events: 1, over voltage events: 0, power good: yes
Driver 0: position 27804, ok, SG min/max 0/281
Driver 1: position 1608, ok, SG min/max 0/295
Driver 2: position 8662, ok, SG min/max not available
Driver 3: position 0, ok, SG min/max 0/279
Driver 4: position 0, ok, SG min/max not available
Driver 5: position 0
Driver 6: position 0
Driver 7: position 0
Driver 8: position 0
Driver 9: position 0
Driver 10: position 0
Driver 11: position 0
Date/time: 2020-11-10 23:13:11
Cache data hit count 2641989901
Slowest loop: 1.58ms; fastest: 0.13ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 30.0MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
Hiccups: 0(0), FreeDm: 153, MinFreeDm: 142, MaxWait: 0ms
Bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 19876, completed moves 19837, StepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state 3
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, StepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
Heater 0 is on, I-accum = 0.0
Heater 1 is on, I-accum = 0.6
=== GCodes ===
Segments left: 1
Movement lock held by null
HTTP* is doing "M122" in state(s) 0
Telnet is idle in state(s) 0
File* is doing "G1 X163.770004 Y147.505005 E-0.137980" in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger* is idle in state(s) 0
Queue* is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== SBC interface ===
State: 0, failed transfers: 0
Last transfer: 7ms ago
RX/TX seq numbers: 53001/53003
SPI underruns 0, overruns 0
Number of disconnects: 0, IAP RAM available 0x021ac
Buffer RX/TX: 400/1624-0
=== Duet Control Server ===
Duet Control Server v3.2.0-beta3
File:
Buffered code: G1 X162.728 Y146.619 E-0.07341
Buffered code: G1 X162.510 Y146.265 E-0.08215
Buffered code: G1 X162.298 Y145.707 E-0.11819
Buffered code: G1 X162.209 Y145.116 E-0.11819
Buffered code: G1 X162.248 Y144.521 E-0.11819
Buffered code: G1 X162.391 Y144.024 E-0.10221
Buffered code: G1 E-0.05000 F2400.00000
Buffered code: G1 X147.391 Y145.007 F14400.000
Buffered code: G1 E1.00000 F2400.00000
Buffered code: G1 F1500
Buffered code: M204 P1000
Buffered code: G1 X147.362 Y145.355 E0.01088
Buffered code: G1 X147.295 Y145.666 E0.00993
Buffered code: G1 X147.170 Y146.010 E0.01138
Buffered code: G1 X146.903 Y146.451 E0.01605
Buffered code: G1 X146.818 Y146.555 E0.00418
Buffered code: G1 X146.549 Y146.826 E0.01188
Buffered code: G1 X146.123 Y147.115 E0.01605
Buffered code: G1 X145.644 Y147.307 E0.01605
Buffered code: G1 X145.136 Y147.392 E0.01605
Buffered code: G1 X144.621 Y147.367 E0.01605
Buffered code: G1 X144.489 Y147.342 E0.00418
Buffered code: G1 X144.000 Y147.179 E0.01605
Buffered code: G1 X143.557 Y146.916 E0.01605
Buffered code: G1 X143.283 Y146.673 E0.01138
Buffered code: G1 X143.080 Y146.428 E0.00994
Buffered code: G1 X142.883 Y146.128 E0.01116
Buffered code: G1 X142.694 Y145.667 E0.01551
==> 1296 bytes
Pending code: G1 X142.606 Y145.171 E0.01570
Code buffer space: 2232
Configured SPI speed: 8000000 Hz
Full transfers per second: 31.10
File /opt/dsf/sd/gcodes/retraction_calibration_0.2mm_PETG__10m.gcode is selected, processing

I plan to get the DCS log and in-depth USB log soon.

Also, I will try in standalone mode as well, hopefully tomorrow.

Edit: added config.g

Just to add another data point, I have also experienced this same behavior. However, I am running a duet 2, also on corexy.
Edit: I have observed this since RRF 3.1.1.

I have experienced this exact behavior. The print head jerks, almost as if it's skipping a step multiple times mid-print. I am running a duet 2 with SBC on a corexy machine with rrf 3.2-b2 as well.

I have been testing out the SBC functionality of RRF 3.2-beta 2, and it looks to be pretty good. However, I am experiencing a lot of movement hiccups, mostly stalls, at a rate of about once every 10 seconds. Checking the diagnostics, no hiccups are reported. I have not been able to test without the SBC, but I will try soon. The SPI communications are very good, with no errors reported by DSF or RRF.

This is just after finishing a print:

=== Diagnostics ===
RepRapFirmware for Duet 2 + SBC version 3.2-beta2 running on Duet 2 1.02 or later + SBC (SBC mode)
Board ID: 08DGM-917N9-FLMS4-7JTDG-3SJ6J-9HV4G
Used output buffers: 1 of 24 (12 max)
=== RTOS ===
Static ram: 23252
Dynamic ram: 100672 of which 564 recycled
Exception stack ram used: 544
Never used ram: 6040
Tasks: Linux(ready,54) HEAT(blocked,161) MAIN(running,411) IDLE(ready,19)
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 131:29:15 ago, cause: software
Last software reset at 2020-10-16 11:30, reason: StuckInSpinLoop, GCodes spinning, available RAM 5876, slot 0
Software reset code 0x4083 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f80f BFAR 0xe000ed38 SP 0x2000412c Task MAIN
Stack: 000007b0 0041861e 010f0000 3efae148 3d4ccccd 3edb6db7 b7803800 40c80003 3d800001 43c80000 42480001 00000000 3f800000 c1a00000 4354c416 c0a66666 3f000000 3f800000 3efae148 60000011 004185d9 20002198 ffffff01 00000000 20009618 2000d020 20002aec
Error status: 0x00
MCU temperature: min 22.0, current 28.6, max 31.6
Supply voltage: min 0.3, current 24.1, max 24.2, under voltage events: 6, over voltage events: 0, power good: yes
Driver 0: position 28445, standstill, SG min/max 0/1023
Driver 1: position -32000, standstill, SG min/max 0/1023
Driver 2: position 343918, standstill, SG min/max 0/1023
Driver 3: position 0, standstill, SG min/max 0/1023
Driver 4: position 0, standstill, SG min/max 0/1023
Driver 5: position 0
Driver 6: position 0
Driver 7: position 0
Driver 8: position 0
Driver 9: position 0
Driver 10: position 0
Driver 11: position 0
Date/time: 2020-10-21 23:00:29
Cache data hit count 4294967295
Slowest loop: 260.64ms; fastest: 0.10ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 30.0MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
Hiccups: 0(0), FreeDm: 169, MinFreeDm: 108, MaxWait: 433821936ms
Bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 43213, completed moves: 43213, StepErrors: 0, LaErrors: 0, Underruns: 0, 1060  CDDA state: -1
=== AuxDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0  CDDA state: -1
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
Heater 0 is on, I-accum = 0.0
Heater 1 is on, I-accum = 0.4
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP* is ready with "M122" in state(s) 0
Telnet is idle in state(s) 0
File* is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger* is idle in state(s) 0
Queue* is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== SBC interface ===
State: 0, failed transfers: 0
Last transfer: 9ms ago
RX/TX seq numbers: 60071/51096
SPI underruns 0, overruns 0
Number of disconnects: 0
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.2.0-beta2
Code buffer space: 4096
Configured SPI speed: 8000000 Hz
Full transfers per second: 32.50

Well it seems that by twisting MOSI, MISO, and SCK with ground has basically solved my issue. I am now getting NO errors, and I can print successfully. Seems there was significant crosstalk in the lines.

The only thing that is a little troublesome is sometimes the movement is quite jerky. Like in a long travel move it will just stop for a few ms and resume, as if the duet is choking on step generation. I don't think this is happening, but that's how I can best describe it.

It seems like it must be something software related, since I can't see any reason why it shouldn't work.

Just so I'm not crazy:

@wilriker I do. I have two PSUs, one 24v and one 5v. All the grounds are connected in star topology, and the red/black connector on the pi is connected to 5v and ground.

@arhi Simulation seems to work. However, if I have the heaters on, it will give a few errors:

=== SBC interface ===
State: 0, failed transfers: 2
Last transfer: 11ms ago
RX/TX seq numbers: 27937/27939
SPI underruns 0, overruns 0
Number of disconnects: 0
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.2.0-beta2
Code buffer space: 4096
Configured SPI speed: 4000000 Hz
Full transfers per second: 28.70

In the DCS log, it gives a few more than that, mostly bad checksum errors and disconnects.
When I try to print, that's when I get problems. When and how it errors out can vary. Sometimes it just stops, sometimes it causes erratic behavior (mis-probes the bed, halts in the middle of a move):

=== SBC interface ===
State: 0, failed transfers: 3
Last transfer: 8ms ago
RX/TX seq numbers: 34957/34958
SPI underruns 0, overruns 3
Number of disconnects: 0
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.2.0-beta2
Code buffer space: 4096
Configured SPI speed: 4000000 Hz
Full transfers per second: 31.21

In this instance, it got through the homing procedure and tried to probe the bed. It only probed one point, but three times, and then stopped.
DCS log:

[warn] Bad header checksum (expected 0x2001, got 0xfb88)
[warn] Bad header checksum (expected 0x2001, got 0xfb88)
[warn] Bad header checksum (expected 0x2001, got 0xfb88)
[warn] Note: RepRapFirmware didn't receive valid data either (code 0x00004000)
[warn] Restarting transfer because the number of maximum retries has been exceeded
[debug] Cancelled M83 ; use relative distances for extrusion
[debug] Cancelled G92 E0 ; set extruder to zero
[info] Aborted macro file bed.g
[warn] File: ==> Cancelling unfinished starting code: G32 ; home axes, calibrate bed leadscrews, and load saved mesh heightmap
[warn] Controller has been reset

More info:

• Letting the printer sit idle (heaters off, motors off) produces almost no errors.
• Letting the printer sit idle (heaters on, motors off) produces more errors.
• Running a simulation has no effect.

Scoping the SPI pins, the waves look to be well-formed. A little bit of jitter, but otherwise good.

Overall, it seems pretty random to me.

I've been having comms issues since installing one of @deadwood83's boards. It will connect fine in DWC, but every so often it will reset the controller. Looking at the log, it keeps getting bad checksum errors. I don't believe my wiring is to blame, but it could be. Any ideas?

The thick white cable + yellow wire comprise the connection to the pi. It is a bit of cat5 cable with connectors crimped on.

P.S.- Measuring the cable length, it's about 200mm. Maybe that could be the issue?

P.P.S- I do not have a duex. Just the duet.

Interesting. I use nearly the exact same settings as you do, but the main difference I think is the part cooling. You have a single fan blowing from one side, and I have two fans blowing from both sides at an angle. I think what may be happening is that there is turbulence where the two airstreams converge on my duct, and this causes the heat to build up. I might try redesigning my cooling duct so that the two airstreams are more aligned.

Also, I really like your quick change toolhead. Very compact.

I'm starting to think it might be related to cooling. Watching closely, it doesn't necessarily start to generate a string at a retraction, but only when the nozzle leaves the part during a travel move.

This was printed at 215c, and towards the top I turned retraction to 0 to see what would happen.

A different print:

Also, here's a picture of my extruder carriage:

And no, I don't have any other brands of filament to try other than Hatchbox black PLA right now.

Well I tried a print at 240c, so if the temperature really was off, it would fix it. Unfortunately, no luck. Still the same as 215c.