Posts made by r3cvr

@dc42 It may have been a signal issue the first time, however I don't think it is anymore when it won't stop crashing despite rebooting itself. I see when it gets stuck - I had the usb console hooked up hoping to see some output on it, which means that the duet wasn't completely power cycled even when I attempted to hard power cycle it. Anyway, there is some left-over state maybe in the lis3dh itself that causes this crash even after it reboots, and there is no longer a signal issue, at least temporarily.

To reproduce in console:
M955 P0 C"spi.cs4+spi.cs3" I25
M955 P0
Accelerometer 0 type LIS3DH with orientation 25 samples at 1344Hz with 10-bit resolution, SPI frequency 2000000
M956 P0 S1000 A0
<crash>

Was intermittently working (I captured many traces) and crashing, but now consistently crashing for some reason.

config-3.g

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.5.0-beta.4 (2023-06-08 23:39:39) running on Duet WiFi 1.02 or later
Board ID: 08DGM-956GU-DJMSJ-6J9FG-3SD6J-9UPHG
Used output buffers: 1 of 26 (24 max)
Error in macro line 56 while starting up: Heater 0 not found
=== RTOS ===
Static ram: 23236
Dynamic ram: 77116 of which 12 recycled
Never used RAM 9924, free system stack 164 words
Tasks: NETWORK(1,ready,15.4%,219) HEAT(3,nWait,0.1%,329) Move(4,nWait,0.0%,364) MAIN(1,running,84.0%,743) IDLE(0,ready,0.5%,29), total 100.0%
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 00:03:23 ago, cause: software
Last software reset at 2023-06-18 18:55, reason: HeatTaskStuck, Gcodes spinning, available RAM 7780, slot 0
Software reset code 0x0143 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f80f BFAR 0xe000ed38 SP 0x20004770 Task ACCE Freestk 4294946641 ok
Stack: 20005958 2000412c 20000150 e000e000 006af974 0045f435 0045ddf6 6100f000 00000001 e000e000 0045f435 2000d0e0 00023264 2000d110 0043104b 2000d0e0 a5a5a5a5 a5a5a5a5 20004bb4 a5a5a5a5 004310ef a5a5a5a5 0045dd1d a5a5a5a5 00000000 00000000 00000000
Error status: 0x00
Aux0 errors 0,0,0
MCU temperature: min 30.5, current 32.2, max 32.7
Supply voltage: min 24.3, current 24.4, max 24.6, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/2, heap memory allocated/used/recyclable 2048/32/0, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: standstill, SG min n/a
Driver 1: standstill, SG min n/a
Driver 2: standstill, SG min n/a
Driver 3: standstill, SG min n/a
Driver 4: standstill, SG min n/a
Driver 5: 
Driver 6: 
Driver 7: 
Driver 8: 
Driver 9: 
Driver 10: 
Driver 11: 
Date/time: 2023-06-18 18:59:03
Cache data hit count 4294967295
Slowest loop: 133.66ms; fastest: 0.19ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 0.7ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 83, segments created 0, maxWait 0ms, bed compensation in use: none, height map offset 0.000, ebfmin 0.00, ebfmax 0.00
no step interrupt scheduled
=== DDARing 0 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 2 is on, I-accum = 0.0
=== GCodes ===
Movement locks held by null
HTTP is idle 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
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Q0 segments left 0
Code queue 0 is empty
=== Network ===
Slowest loop: 61.46ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 1 of 8
= WiFi =
Interface state: active
Module is connected to access point 
Failed messages: pending 0, notready 0, noresp 0
Firmware version 1.27
MAC address 5c:cf:7f:76:6c:93
Module reset reason: Turned on by main processor, Vcc 3.36, flash size 4194304, free heap 21968
WiFi IP address 192.168.1.188
Signal strength -48dBm, channel 0, mode 802.11n, reconnections 0
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0

@gloomyandy The moves that do not trigger stall detection are manual moves from DWC, or issuing gcode to the console like G91; G1 X25 F5000 to move the toolhead (or Z platform) past the physical stops so the motor hard stalls.

Machine is a FlashForge Creator Pro with Duet2Wifi 3.4.5

An additional experiment I tried was setting the motor stall up as an axis endstop. That didn't work either. Although I haven't been able to gather from the documentation if two endstops on a single axis are supported (microswitch and one end and stall detection at the other).

Config attached. config-2.g

I have stall detection successfully triggering during prints if I turn the S value down 2 notches to S17 or below during print:

M915 X Y S19 F0 R3

driver-stall.g executes here and displays a message and rehomes.

However, when doing moves to hard stops with the axis limits removed, it detects no stall and the steppers skip, no matter how low I make the S value (-63) or how fast the move is? I also tried changing H and motor torque during the test, nothing has made it trigger even once here.

@jay_s_uk yup, that worked, thanks!

@jay_s_uk said in PanelDue 7.0i erased and USB com port won't appear?:

@r3cvr just update it from the duet itself https://docs.duet3d.com/en/User_manual/RepRapFirmware/Updating_PanelDue#firmware-update-via-duet

It was on 1.x, I don't think it will work. That seems like a new feature "From RepRapFirmware version 3.2 (beta 4.1), you can flash the PanelDue firmware from the Duet itself, provided you have a V3/5i/7i PanelDue running firmware 3.2.2 or later"

Tried updating my PanelDue 7.0i after many years over USB, the USB com port will not appear - tried 3 cables and 4 machines (Mac and Windows). I figured the port would detect after it was erased but that does not appear to be the case. Now it just boots with a white screen with grey lines. What do I do now?

I kind of remember it was tempramental the last time I updated years ago too, but it did work eventually last time.

@dc42 said in Heater Fault debug facility:

A falling temperature may be caused by the heater or the thermistor falling out of the heater block. Either could cause a fire.

But false positives lead to effectively disabling the feature?

Is there any way to measure the resistance/power consumption of the heater? Could try and use the resistance as a secondary temp measurement and set thresholds for disabling. I'm assuming most heaters have some positive coefficient of resistance.

@dragonn said in Heater Fault debug facility:

@r3cvr and what is wrong with that? One step of setting up a new printer is always do a PID tune.

Print fails with no extrusion after heater fault shuts down heater. That's how my first dozen or so print attempts on DuetWifi went. I actually have several PID tunes, done at different model fan settings. No surprise it comes up with different parameters. Doesn't help this issue that much.

With default settings, I was getting a heater fault whenever the model fan came on, as it would cause a dip in extruder temperature until the PID caught up. Had to greatly relax the fault detection. Should detect on temperature direction instead of anomaly from set temp?

Dive height has a huge impact on the time to probe the bed. However one point that's too high will abort the calibration with an error. Why not simply dive again until it's not triggered, and try again? This would let you set dive heights approaching 0 as it would always automatically find the trigger point.

I wanted to add some LED's to the extruder using the same wires as the Z IR probe.
Thanks

@doctrucker said in blobs due to firmware stalls:

What you propose would result in the machine extruding a bead of polymer between the last point of the previous layer and first of the next. In other words a line with increasing z-component.

Well that's right. That's actually what happens anyway, because you can't have an instantaneous movement in the real world, even though that what the gcode is coding. So, blob. Ideally XYE momentum wouldn't stall at all for a layer change. Then there is no need to mess with extrusion.

Are you using relative extruder moves? I think absolute is favoured to reduce the influence of rounding errors.

I just switched to relative, but that didn't make any difference.

I have been playing with pressure advance. Seems the most effective parameters so far, at least on a 20mm cylinder. Using 0.095, but it seems somewhat dependant on at XYZ acceleration parameters. Working way better than coast settings in Simplify3D.

@deckingman said in blobs due to firmware stalls:

Err, yes - that's what retraction is for. When the print head has to move to a different position in X Y or Z, then one has to stop the flow of plastic while that non-print move is being completed, otherwise it will continue to ooze out of the nozzle and get pulled into a stringy bead. Simply stopping the extruder won't work because latent pressure in the hot end and other factors will cause the filament to continue to ooze. So we have to reverse the extruder to pull that blob back up into the hot end, then do the move, then un-retract the filament. For the same reason, it can't be a "5 dimensional move" as you call it - the retraction must occur before the non-print move commences and not during it. Hence, retract-move-unretract.

The time it takes to retrcat/unretract is a function of speed and distance. So to reduce the time, you need to retract faster or reduce the retraction length. But too high a retraction speed can break the bead of filament inside the hot end, rather than stretch it. If you have a long Bowden tube, then you may not be able to reduce the retraction distance because it takes a certain amount of movement to "unbuckle" the filament inside the tube.

To tune the retraction settings, you could consider using firmware retraction which allows you to change parameters "on the fly" during a print. Not all slicers support it though. Once you've found the best setting (for that filament and print speed) then you can either continue to use firmware retraction or revert to slicer retraction but use the same numbers as firmware retraction.

Well for a Z move like Simplify3D is trying to do, retract should be combined with the Z move, in the least.

However, I have tried doing an experiment as follows: 20mm radius single wall cylinder, layer insertion points all lined up, increase from 0 retraction to 2.5mm retraction (good max value for direct extruder) every 10mm Z. Guess what looks the best? 0 retraction. Not by much however. All other values of retraction look similarly bad.

I don't know if this is a new problem, or I just never noticed it before given the quality of 8 bit printing.

This is what the slicer is producing for 0 retraction:
G1 X5.367 Y-61.649 E0.0442
; layer 44, Z = 8.750
M105
G1 X5.371 Y-61.649 F9000
G1 Z8.750 F6000
G1 X6.299 Y-61.657 E0.0388 F1890

I think this is what is should be producing:
G1 X5.367 Y-61.649 E0.0442
; layer 44, Z = 8.750
M105
G1 X6.299 Y-61.657 Z8.750 E0.0388 F1890

@mak said in S-Curve/ sinusoidal , Jerk +acceleration:

https://www.youtube.com/watch?v=qYJpl7SNoww

Bottom is a square wave, not a trapezoid. You'd see 4 sploshing events if it were a trapezoid.

@phaedrux I am not using pressure advance. I have direct extruders, do you think it will help here?

@deckingman I worked on the settings some more, and I discovered I was getting blobs at layer changes. I'd expect the Z move to be a 5 dimensional move, but it's not, it's a lone E retract, then a lone Z move, then back to XYE (no hop). No matter how fast these moves are this seems like a stall, well really it is a stall as far as the plastic flowing out of the nozzle is concerned.

It seems the only way for this to print without artifacts is to include the Z dimension in the move without retract. I guess simplify3d can't do that? I just tried switching the Cura too, which doesn't seem better.

Turned on retractions and travel moves display. Doesn't seem to match the pattern of blobs?

0_1530460551039_config-override.g
0_1530460543912_config.g
0_1530460641086_FanDuctMod3.gcode


Upon further close examination, it almost seems like there is middle zone of speed where the problem happens, slower or faster than that the quality seems better. I almost wanted to blame the non-print move speed, but there is high quality in some of this print with moves across the print going on. But obviously this is a complex model. Going to have to try some prints with test objects.

Quality is high in the obscured part of the image near the bottom, and that was moving 75-100mm/s

@dc42 SD card, uploading through web interface. Yes my slicer has this feature. But these are actual slowdowns, not pauses. Any sort of pause will produce an artifact.

I upgraded from a mightyboard, which was extremely underpowered, hoping the motion kinematics could be physics accurate on DuetWifi. Although printing is much improved, I've discovered that often motion will stall for very short durations. This always results in a blob followed by underextrusion as the plastic is still flowing. Strangely, I noticed that this seems to happen more as it slows down, i.e. layers that would be under 15 seconds are long running at less than half the speed of better printed layers.

Are there any firmware settings I can tweak to try and avoid this? I know on the mightyboard polling status on the serial port would cause such stalls due to the inadequate processor. I tried disconnecting from the web interface but it did not help.