Posts made by Nurgelrot

@dc42 just a follow upletting you and anyone following this issue that in my case the expression nesting was still too deep even under 3.5.1. I corrected it by making my macro a little cleaner. Basically not loading so much into one variable assignment. but spreading out the math

I was just able to reproduce this issues using a detachable prob (Klicky) Homing works G32 works. manually running M401/402 to get and store the porbe works but when issuing G29 it error with 4/17/2024, 8:26:56 PM g29 Error: G1: Probe already triggered before probing move started and all hell breaks loose if you dont hit estop fast.

This was with 3.5.rc4 on an Octopusprov1.0 and a 1LC toolboard. So it dosen't seem to be port/board specific. Let me know what data you need. This is one of my best printing units so I'm loth to do too much damage to it testing but happy to help out as much as I can.

@Nurgelrot UPDATE @gloomyandy helped me identify someplaces where the macro could make better use of available stack space by loading some local varables with some expression results rather than parsing it all in one go. Fixed the problem. He specualated that in the Mini5+ and even some of the STM32F4xx boards that stack space was already pretty low in 3.4.6 and 3.5 pushed it over for this particular use case. Something for people to keep an eye on.

Hello, The print_area_mesh.g macro that many people have been using for a while now errors out on the Mini5+ under 3.5-rc4. with the following: (I cancelled the print.)

4/15/2024, 12:39:53 PM	Cancelled printing file 0:/gcodes/testring.gcode, print time was 0h 10m
4/15/2024, 12:39:41 PM	M25
Printing paused at X225.0 Y225.0 Z4.1
4/15/2024, 12:39:38 PM	Resume state saved
4/15/2024, 12:39:38 PM	Error: in file print_area_mesh.g line 58: unknown variable 'var.meshY'
4/15/2024, 12:39:38 PM	Error: in file print_area_mesh.g line 57: unknown variable 'var.meshX'
4/15/2024, 12:39:38 PM	Error: in file print_area_mesh.g line 44: in file macro line 0: Expression nesting too deep
4/15/2024, 12:39:38 PM	Error: in file print_area_mesh.g line 43: in file macro line 0: Expression nesting too deep
4/15/2024, 12:39:38 PM	Error: in file macro line 59: M557: unknown variable 'meshX'
4/15/2024, 12:39:38 PM	81 points probed, min error 0.010, max error 0.123, mean 0.063, deviation 0.026
Height map saved to file 0:/sys/heightmap.csv
4/15/2024, 12:31:23 PM	Error: in file macro line 50: M557: unknown variable 'meshX'
4/15/2024, 12:31:23 PM	Set probe grid to use X-min: 53.32040; X-max: 196.6800; Y-min: 53.32040; Y-max: 196.6800

Exact same g-code sent to a mini5+ running 3.4.6 works as expected. ALSO works as expected when sent to a Super8pro Running the TeamGloomy STM32 port of RRF 3.5-4rc4. Is there some memory/other restriction im unaware of with the Mini5+?

macro run with M98 P"print_area_mesh.g" A{first_layer_print_min[0]} B{first_layer_print_max[0]} C{first_layer_print_min[1]} D{first_layer_print_max[1]} in prusa slicer 2.7.4 start gcode

; This command will only create a mesh of the print area
; This will reduce the printing time considerably by only probing what is needed

var deviationFromOriginal = 20

var probeGridMinX = move.compensation.probeGrid.mins[0]
var probeGridMaxX = move.compensation.probeGrid.maxs[0]
var probeGridMinY = move.compensation.probeGrid.mins[1]
var probeGridMaxY = move.compensation.probeGrid.maxs[1]

var pamMinX = {var.probeGridMinX}	; Default the pamMinX value to the min x that is set for the mesh in M557. Originally coming from sys/printer_size_config.g
var pamMaxX = {var.probeGridMaxX} 	; Default the pamMaxX value to the min x that is set for the mesh in M557. Originally coming from sys/printer_size_config.g
var pamMinY = {var.probeGridMinY}	; Default the pamMinY value to the min x that is set for the mesh in M557. Originally coming from sys/printer_size_config.g
var pamMaxY = {var.probeGridMaxY}	; Default the pamMaxY value to the min x that is set for the mesh in M557. Originally coming from sys/printer_size_config.g
var meshSpacing = {move.compensation.probeGrid.spacings[0]}	; Grabbing the spacing of the current M557 settings
var minMeshPoints = 3				; The minimal amount of probing points for both X & Y.
var maxMeshPoints = 10				; The max amount of probing points for both X & Y

if exists(param.A)
	set var.pamMinX = {param.A}		; The min X position of the print job
	
if exists(param.B)
	set var.pamMaxX = {param.B}		; The max X position of the print job
	
if exists(param.C)	
	set var.pamMinY = {param.C}		; The min Y position of the print job
	
if exists(param.D)
	set var.pamMaxY = {param.D}		; The max Y position of the print job

if (var.probeGridMinX + var.deviationFromOriginal) >= var.pamMinX	; Check if the difference between the min X and the print job min X is smaller than the set deviation
	set var.pamMinX = {var.probeGridMinX}								; The difference is smaller than the set deviation so set minX to the minimal of the printer's X
	
if (var.probeGridMaxX - var.deviationFromOriginal) <= var.pamMaxX	; Check if the difference between the max X and the print job max X is smaller than the set devation
	set var.pamMaxX = {var.probeGridMaxX}								; The difference is smaller than the set devation so set maxX to the max of the printer's X
	
if (var.probeGridMinY + var.deviationFromOriginal) >= var.pamMinY	; Check if the difference between the min Y and the print job min Y is smaller than the set devation
	set var.pamMinY = {var.probeGridMinY}									; the difference is smaller than the set devation so set minY to the minimal of the printer's Y
	
if (var.probeGridMaxY - var.deviationFromOriginal) <= var.pamMaxY	; Check if the difference between the max X and the print job max X is smaller than the set devation
	set var.pamMaxY = {var.probeGridMaxY}									; The difference is smaller than the set devation so set maxY to the max of the printer's Y
	
var meshX = floor(min(var.maxMeshPoints - 1, (max(var.minMeshPoints - 1, (var.pamMaxX - var.pamMinX) / var.meshSpacing) + 1)))	; Get the number of probes for X taking minMeshPoints and maxMeshPoints into account
var meshY = floor(min(var.maxMeshPoints - 1, (max(var.minMeshPoints - 1, (var.pamMaxY - var.pamMinY) / var.meshSpacing) + 1)))	; Get the number of probes for Y taking minMeshPoints and maxMeshPoints into account

var consoleMessage = "Set probe grid to use X-min: " ^ var.pamMinX ^ "; X-max: " ^ var.pamMaxX ^ "; Y-min: " ^ var.pamMinY ^ "; Y-max: " ^ var.pamMaxY "; Probing points: " ^ var.meshX ^ ";" ^ var.meshY	; Set the console message
M118 P2 S{var.consoleMessage} ; send used probe grid to paneldue
M118 P3 S{var.consoleMessage} ; send average to DWC console

M557 X{var.pamMinX, var.pamMaxX} Y{var.pamMinY, var.pamMaxY} P{var.meshX, var.meshY}	; Set the probing mesh

G0 X{var.pamMinX + ((var.pamMaxX - var.pamMinX)/2) - sensors.probes[0].offsets[0]} Y{var.pamMinY + ((var.pamMaxY - var.pamMinY)/2) - sensors.probes[0].offsets[1]} 	; Move to the center of the print area
G30	; Set the z height for the center of the print area
G29	; Probe the print area

; Restore the probing mesh to the original settings
set var.meshX = floor((var.probeGridMaxX - var.probeGridMinX) / var.meshSpacing + 1)
set var.meshY = floor((var.probeGridMaxY - var.probeGridMinY) / var.meshSpacing + 1)
M557 X{var.probeGridMinX, var.probeGridMaxX} Y{var.probeGridMinY, var.probeGridMaxY} P{var.meshX, var.meshY}

@chrishamm Right that's basically what I do. But I don't know playing around with a pretty graph until things look "flatter" bugs me Is there was some way of knowing I'm doing it "Right"? I guess at the end of the day as long as the prints look corect its the only indicator. I doesn't help that in all the IS examples you see this clear peek none of my printers no matter how I adust them ever have pretty graphs.

Just what the title says I've got a printer, Voron in this case, it prints well. I can muck around with IS and get the ringing down to minimal but I've no idea what im really doing just playing with numbers. I just had to redo some parts on it so I thought I'd take a bare bones motion capture and post it here and ask the comunity to tell me what setting I should be looking for. I Know I'm not the only one that could use a IS leason

NVM my issue seems to be spacific to the experimental nature of the hardware in that printer. I tested with another printer using current supported toolboars and it worked fine. Will test again when I can get a supported toolboard installed.

Im basically seeing this same behavior with other monitors. Once the Monitor is qureried with an M591 D0 It will repeat the same value for the rest of the print. It will however trigger an error and pause the printer if I go over and interfear with the feed.

7/19/2023, 6:58:47 PM	M591 D0
Pulse-type filament monitor on pin 124.io0.in, enabled, sensitivity 0.156mm/pulse, allowed movement 75% to 120%, check every 2.4mm, measured sensitivity 0.162mm/pulse, measured minimum 86%, maximum 109% over 949.8mm
7/19/2023, 5:49:24 PM	M591 D0
Pulse-type filament monitor on pin 124.io0.in, enabled, sensitivity 0.156mm/pulse, allowed movement 75% to 120%, check every 2.4mm, measured sensitivity 0.162mm/pulse, measured minimum 86%, maximum 109% over 949.8mm
7/19/2023, 3:42:30 PM	M591 D0
Pulse-type filament monitor on pin 124.io0.in, enabled, sensitivity 0.156mm/pulse, allowed movement 75% to 120%, check every 2.4mm, measured sensitivity 0.162mm/pulse, measured minimum 86%, maximum 109% over 949.8mm

as you can see I've polled the monitor over a good sampling of time durring a print and its not changing.
Actaul filimaernt use at the time of the last poll:Filament Usage: 22419.1 mm

Granted I'm using the SMT32 port of RRF 3.5.beta4 (and an experimental toolboard) but seems to be the same or simular issue as the OP:

fly_super8_pro_h723	stm32h723-wifi	3.5.0-beta.4_101
Duet 3 Expansion FlySB2040v1_0	FlySB2040v1_0	3.5.0-beta.4_101
Duet WiFi Server	n/a	1.27-02S32-D
Duet Web Control	DWC	3.5.0-beta.4

@jay_s_uk Thank for checking I could have sworn that they added an exception for the the simple switches. Might be able to reproduce the same functionality with a trigger? M581.

Or do what I do and mount the filament monitor to the frame and run the wire down with the boden tube. Sucks but its the best I could come up with.

@Reine If you're only detecting the presence of filament you are supposed be able to wire a simple switch type monitor (1&2) to any board. Not positive if it was really implemented in 3.4+ or not. But I remember seeing some traffic on the subject.

@Phaedrux Yes everything should have been correctly wired and the problem did occur again two more times. I replaced the toolboard and that has solved the problem. I'm working under the assumption that I cooked the previous toolboard. As I have temps reaching 80+ C reported from the board for long periods on an identical build that has not been in service as long. It just a guess right now but... Will figure out how to drop the temps and continue to watch it.

@Nurgelrot I have the filament runout manually disabled if anyone see that -It's not part of the problem

Today on my Duet 6HC + 1LC I've run into a problem where while printing the 121.temp0 sensor reports 2000c and the heater turns off the printer continues to print (no longer extruding)

I receive no indication of an error until I cancel the print then i get

Error: Board 121 does not have heater 1
3/27/2023, 9:59:39 AM    Error: Failed to switch off remote heater 1: Board 121 does not have heater 1
3/27/2023, 9:59:39 AM    Error: Failed to switch off remote heater 1: Board 121 does not have heater 1
3/27/2023, 9:59:39 AM    Error: M106: Board 121 doesn't have fan 0

Oh before that while the printer was printing in aire I also got

3/27/2023, 9:37:07 AM    Warning: Driver 0.3 warning: phase A may be disconnected
3/27/2023, 9:36:32 AM    Warning: Driver 0.3 warning: phase B may be disconnected
3/27/2023, 9:36:32 AM    Warning: Driver 0.2 warning: phase B may be disconnected

which are 2 of my 4 z motors.

the M122 B121 log show this about the time i'd estimate it all went bad:

Last software reset at 2023-03-27 09:19, reason: WatchdogTimeout, available RAM 2204, slot 0

Any Idea whats going on here? Voron 2.4 RRF 3.4.5

m122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.4.5 (2022-11-30 19:35:23) running on Duet 3 MB6HC v1.01 (SBC mode)
Board ID: 08DJM-956BA-NA3TN-6J1FL-3S86M-9TBLT
Used output buffers: 8 of 40 (40 max)
=== RTOS ===
Static ram: 152760
Dynamic ram: 68964 of which 12 recycled
Never used RAM 125096, free system stack 114 words
Tasks: SBC(resourceWait:,1.8%,462) HEAT(notifyWait,0.0%,322) Move(notifyWait,1.4%,245) CanReceiv(notifyWait,0.0%,772) CanSender(notifyWait,0.0%,328) CanClock(delaying,0.0%,339) TMC(notifyWait,20.9%,57) MAIN(running,73.4%,923) IDLE(ready,2.3%,30), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 02:36:05 ago, cause: power up
Last software reset at 2023-03-27 07:04, reason: User, GCodes spinning, available RAM 129632, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x04
Aux0 errors 0,5,0
Step timer max interval 307
MCU temperature: min 33.3, current 40.0, max 41.3
Supply voltage: min 24.0, current 24.1, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.2, current 12.2, max 12.3, under voltage events: 0
Heap OK, handles allocated/used 99/0, heap memory allocated/used/recyclable 2048/96/96, gc cycles 4
Events: 3 queued, 3 completed
Driver 0: standstill, SG min 0, mspos 984, reads 15635, writes 70 timeouts 0
Driver 1: standstill, SG min 0, mspos 552, reads 15635, writes 70 timeouts 0
Driver 2: standstill, SG min 0, mspos 824, reads 15636, writes 70 timeouts 0
Driver 3: standstill, SG min 0, mspos 728, reads 15636, writes 70 timeouts 0
Driver 4: standstill, SG min 0, mspos 392, reads 15667, writes 39 timeouts 0
Driver 5: standstill, SG min 0, mspos 1000, reads 15667, writes 39 timeouts 0
Date/time: 2023-03-27 10:00:55
Slowest loop: 1000.25ms; fastest: 0.04ms
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 37.5MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 125, segments created 41, maxWait 2639172ms, bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 81149, completed 81149, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 110], CDDA state -1
=== AuxDDARing ===
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 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 0 is on, I-accum = 0.3
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP* is doing "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
=== Filament sensors ===
Extruder 0: no data received
=== CAN ===
Messages queued 156058, received 162512, lost 0, boc 0
Longest wait 4ms for reply type 6013, peak Tx sync delay 45773, free buffers 50 (min 29), ts 46826/46825/0
Tx timeouts 0,0,0,0,0,0
=== SBC interface ===
Transfer state: 5, failed transfers: 0, checksum errors: 0
RX/TX seq numbers: 46251/41411
SPI underruns 0, overruns 0
State: 5, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x2ad48
Buffer RX/TX: 0/0-0, open files: 0
=== Duet Control Server ===
Duet Control Server v3.4.5
Code buffer space: 4096
Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 1
Full transfers per second: 39.48, max time between full transfers: 90.8ms, max pin wait times: 3298.2ms/12.5ms
Codes per second: 9.26
Maximum length of RX/TX data transfers: 3272/1664

m122 b121
Diagnostics for board 121:
Duet TOOL1LC rev 1.1 or later firmware version 3.4.4 (2022-10-14 11:46:33)
Bootloader ID: SAMC21 bootloader version 2.3 (2021-01-26b1)
All averaging filters OK
Never used RAM 3080, free system stack 45 words
Tasks: Move(notifyWait,0.4%,91) HEAT(notifyWait,0.1%,115) CanAsync(notifyWait,0.0%,65) CanRecv(notifyWait,0.1%,74) CanClock(notifyWait,0.0%,65) ACCEL(notifyWait,0.0%,61) TMC(notifyWait,3.0%,57) MAIN(running,91.5%,441) IDLE(ready,0.0%,26) AIN(delaying,4.9%,142), total 100.0%
Last reset 00:41:31 ago, cause: software
Last software reset at 2023-03-27 09:19, reason: WatchdogTimeout, available RAM 2204, slot 0
Software reset code 0x00a0 ICSR 0x04413011 SP 0x20007ed0 Task CanR Freestk 6560 ok
Stack: 20004778 00000002 42003800 00000080 200032a4 a5a5a5a5 0000c63a 01000013 2000316c a5a5a5a5 0000c629 20004778 34441b56 20003194 40002800 0000cb31 00000020 00000020 20003194 000177ed a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5 fffffff1 200032a4
Driver 0: pos 342077, 80.0 steps/mm,standstill, SG min 0, read errors 0, write errors 1, ifcnt 25, reads 62661, writes 11, timeouts 0, DMA errors 0, CC errors 0, steps req 541579 done 541579
Moves scheduled 26181, completed 26181, in progress 0, hiccups 0, step errors 0, maxPrep 586, maxOverdue 876778178, maxInc 876778178, mcErrs 0, gcmErrs 0
Peak sync jitter 2/7, peak Rx sync delay 476, resyncs 0/0, no step interrupt scheduled
VIN voltage: min 24.0, current 24.0, max 24.0
MCU temperature: min 65.0C, current 67.2C, max 69.0C
Last sensors broadcast 0x00000000 found 0 243 ticks ago, 0 ordering errs, loop time 0
CAN messages queued 19975, send timeouts 0, received 43966, lost 41709, free buffers 37, min 0, error reg 0
dup 0, oos 3/1/0/9, bm 0, wbm 0, rxMotionDelay 47527, adv -873545583/876852842
Accelerometer: LIS3DH, status: 00
I2C bus errors 0, naks 3, other errors 0

@Falcounet yep I got /dev/spidev0.0 /dev/spidev0.1 to show up an got them merged into the current kernel passed in the bufsiz on the grub line options to the kernel cuz the modprobe.d method doesn't work. Just would not talk. Error 19. Maybe I'll get curious in few days and go for another round with it.

On the SBC side of the house. I had an idea to write a X Window app that is basically the PD layout. People may argue why not just run DWC? But in my mind this app would basically be the PD and screen for the SBC at the same time. and not connect via network but direct to OS&DSF. Basically klipper screen concept for RRF+SBC makes obtaining a touchscreen for your RRF printer really easy hardware wise.

I think this a great idea but lack the skill to actually make it haha. I'm useless that way

I just spent 2 day trying to get Le Potato working with RRF - with both the standard Duet3 boards as well as some STM32F4's.

No Dice. The issue isn't the TranferReadyPin thats pretty easy to find and use. Line 79 on /dev/gpiochip1. The real issues is the lack of OS images with working SPI overlays. I was able to get it loaded into the kernel with the Raspian image off the Libre Computers site and their wiringTools package. But was unable to get DuetControlServer to talk over it.

So I give up if anyone else gets it working drop me a note I'd love to know what I was doing wrong.

Working with anything other than a PI make sure you install the gpiod package. This gives you the gpioinfo utility that will list out all the pins whatever chipset you using has access to. And if you are super lucky the maker of your SBC will have them documented mapping to the the PI's heaader. Hardkernel is pretty good about this with the Odroid line of SBC but others vary.

As for the usefulness with current RRF. I'm on the fence. Some things about the way the pi works I like and others just make it more wiring... The one biggest feature I've stumbled onto is leaving the pi on leaves DWC up. This lets me power the main board on and off from a tasmota and the btncmd plugin. Also software updates are easier esp if you want to bounce between stable and unstable... That's about it so far.

@sgk Don't know if this will be helpful or not based on all the other work you have done but the Euclid is normally pretty simple to get going. Less is more with telling RRF what to do with it. Once M401/402 are working RRF knows when it needs to use them for the most part. If you look at the configs at https://github.com/Nurgelrot/Voron-2.4r2-RRF-configs (obviously you'll have to change the dock approaches for your printer) You'll see that once I have deploy|retractprobe.g done I only explicitly call M401 and M402 in homez and once in bed.g (just to make double sure the state of the probe.) Anyway hope reading over these is helpful.

I home my printer just fine from DWC. But on the PanelDue I get " Error: homeing file homex.g not found" same for homey.g and homeall.g. But if I go to DWC it works fine. Crazy thing is it just started happening. Its a new printer build and the PD was fine then seemingly out of the blue this starts happening. Thoughts? One observation if the PD is displaying my macro files. then homing will work. but if it sitting there and the right side of the PD is blank its going to fail. is it having some type of problem parsing the macro name Auto Z offset (the only file there right now) Inquiring minds want to know.

PD is a Fysetc 5" v3.0 running firmware 3.4.0
Other useful info:

m122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.4.1 (2022-06-01 21:09:01) running on Duet 3 MB6HC v1.01 or later (SBC mode)
Board ID: 08DJM-956BA-NA3TN-6J1FL-3S86M-9TBLT
Used output buffers: 1 of 40 (17 max)
=== RTOS ===
Static ram: 151000
Dynamic ram: 66712 of which 144 recycled
Never used RAM 132816, free system stack 202 words
Tasks: SBC(ready,1.2%,458) HEAT(notifyWait,0.0%,353) Move(notifyWait,0.0%,352) CanReceiv(notifyWait,0.0%,797) CanSender(notifyWait,0.0%,374) CanClock(delaying,0.0%,351) TMC(notifyWait,7.6%,94) MAIN(running,84.4%,923) IDLE(ready,6.8%,30), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:00:09 ago, cause: software
Last software reset at 2022-06-15 20:05, reason: User, GCodes spinning, available RAM 132456, slot 1
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0043c000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
Step timer max interval 164
MCU temperature: min 39.4, current 39.7, max 39.9
Supply voltage: min 24.1, current 24.1, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.2, current 12.3, max 12.3, under voltage events: 0
Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: standstill, SG min 0, mspos 856, reads 51706, writes 15 timeouts 0
Driver 1: standstill, SG min 0, mspos 184, reads 51706, writes 15 timeouts 0
Driver 2: standstill, SG min 0, mspos 856, reads 51706, writes 15 timeouts 0
Driver 3: standstill, SG min 0, mspos 184, reads 51706, writes 15 timeouts 0
Driver 4: standstill, SG min 0, mspos 872, reads 51706, writes 15 timeouts 0
Driver 5: standstill, SG min 0, mspos 552, reads 51707, writes 15 timeouts 0
Date/time: 2022-06-15 20:05:43
Slowest loop: 1.20ms; fastest: 0.05ms
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 37.5MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 125, segments created 0, maxWait 0ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
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 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP* is doing "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
=== Filament sensors ===
Extruder 0 sensor: no data received
=== CAN ===
Messages queued 77, received 125, lost 0, boc 0
Longest wait 3ms for reply type 6053, peak Tx sync delay 5, free buffers 50 (min 49), ts 47/46/0
Tx timeouts 0,0,0,0,0,0
=== SBC interface ===
Transfer state: 5, failed transfers: 0, checksum errors: 0
RX/TX seq numbers: 1667/1667
SPI underruns 0, overruns 0
State: 5, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x2b880
Buffer RX/TX: 0/0-0, open files: 0
=== Duet Control Server ===
Duet Control Server v3.4.1
Code buffer space: 4096
Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0
Full transfers per second: 212.33, max time between full transfers: 40.8ms, max pin wait times: 40.4ms/13.2ms
Codes per second: 9.92
Maximum length of RX/TX data transfers: 3080/940