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

@honeycris I think you be better off replacing the fuse with the same size that blew. Then move that 800W bed onto its own external mosfet and power line.

@shifu87 The issue is when the motors are not powered the can free spool and the weight of that 360mm bed can make one side or the other drop. Anti backlash nuts help with this but its not a 100% fix. Also when you power the motors back on they will jump to the nearest step. Over time this drift will make your bed not level to the x axis anymore and you have to manually correct it. With two Z controllers you can let your probe and a macro just fix it for you from time to time.

@fcwilt Yep Thanks for the help Put my settings inside the loop like you have. Works perfectly.

I got it... I love it when a plan comes together... Found the correct GPIO pin:

#68 located in device /dev/gpiochip1

thanks for putting up with my noise everyone

If you have one of these SBC's feel free to hit me up if you run into issues.

@nurgelrot Nope. Don't use this one either It cools the board but causes it to drop below 4.6V from time to time... Who would think it so hard to find active cooling that works. Guess I'll wire a Noctua 40mm 5v right of my 5v PSU. Was hoping to not have to do that but since no one can make simple fan that doesn't block the header or screw up the voltage...

@reflexlab Well other only time I've seen it suck in Connecting like that and my config was right I had Tx -> Tx and Rx -> Rx rather than having them crossed so the PD and board couldn't actually hear each other. If that's not it try reflashing the Firmware on the PD at that point your sorta out of options.

Oh and just confirm you're plugged in IO.0 on the duet right? Or are you trying to use the ribbon cable?

Also looks like you might be on <v3 firmware on PD based on the location of the "." between the numbers. if your on firmware V3 on the Duet you probably want to update the firmware on the PD anyway. Don't know what the compatibility is between version but everything current is usually the best way to go.

@phaedrux said in Ask user to set bed temperature before bed mesh probing:

M291

How about writing a conditional macro placed the start gcode in your slicer to load a low|medium|high heightmap based on printing temp?...

Not that it's perfect and will require some changes from your config. But : https://github.com/Nurgelrot/RatRig-VCore-3-Configs/
I suggest you joining the RatRig Discord server. the Duet channel there has a few people to help with that specific printer.

@fart_plume Right. That's correct. they only receive data during a print. should switch to :

Pulse-type filament monitor on pin io4.in, enabled, sensitivity 7.000mm/pulse, allowed movement 50% to 200%, check every 15.0mm, no calibration data

while printing. I cant remember what condition they collect calibration data under... if in doubt cut the filament.

Wire and crimps/housings. I use Newark (newark.com). They are in the the Mid-West US. But any reputable electronics supply will do. I happen to like their search functions but most of the other place have similar. Probably not the most economical in the small order numbers we typically need. But at least you know your getting the right parts.

@dc42 tanks sorry for the noise then need to keep up on my reading.

Don't know if this is an issue with the Duet3D TOOL1LC firmware or with the TeamGloomy STM32 Firmware on the main board. However when using 3.5.4 everything is fine. When updated to 3.6.0 beta2 the 121.temp0 sensor reports ~20C less and fluctuates +/- 1 deg very rapidly.

i.e. Right now its reporting 26C (the correct ambient temp) if I update everything to 3.6.0.beta2 it will report 6C +/-1

m122
=== Diagnostics ===
RepRapFirmware for STM32F4 based Boards (octopuspro1_0_f4) version 3.5.4 (2024-11-27 23:16:40) running on STM32F4 (standalone mode)
Board ID: V10S4-0J0JA-DQNT8-6L186-ZG2QN-40000
Used output buffers: 1 of 40 (18 max)
=== RTOS ===
Static ram: 21932
Dynamic ram: 97148 of which 1036 recycled
Never used RAM 9928, free system stack 173 words
CCMRam static ram: 24680 dynamic ram: 35772 free ram 5080
Tasks: NETWORK(1,ready,15.8%,163) HEAT(3,nWait 6,0.1%,289) Move(4,nWait 6,0.0%,345) CanReceiv(6,delaying,3.2%,300) CanSender(5,nWait 7,0.0%,436) CanClock(7,delaying,0.1%,372) TMC22xx(4,nWait 6,0.0%,167) TMC51xx(4,nWait 1,9.9%,138) FSWRITE(2,nWait 4,0.1%,485) MAIN(1,running,70.2%,501) IDLE(0,ready,0.6%,29), total 100.0%
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 00:11:07 ago, cause: software
Last software reset at 2024-12-12 10:32, reason: User, Gcodes spinning, available RAM 9916, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
MCU temperature: min 44.9, current 48.7, max 48.7
Supply voltage: min 24.0, current 24.0, max 24.0, under voltage events: 0, over voltage events: 0, power good: yes
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 5160, SG min n/a, mspos 8, reads 9515, writes 16
Driver 1: standstill 5160, SG min n/a, mspos 8, reads 9515, writes 16
Driver 2: standstill 5160, SG min n/a, mspos 8, reads 9516, writes 11
Driver 3: standstill 5160, SG min n/a, mspos 1016, reads 9516, writes 16
Driver 4: standstill 5160, SG min n/a, mspos 8, reads 9516, writes 16
Driver 5: standstill 5160, SG min n/a, mspos 1016, reads 9516, writes 16
Driver 6: standstill 5160, SG min n/a, mspos 8, reads 9516, writes 16
Driver 7: not present
Driver 8: 
Driver 9: 
Driver 10: 
Driver 11: 
Driver 12: 
Driver 13: 
Date/time: 2024-12-12 10:43:14
Slowest loop: 49.66ms; fastest: 0.15ms
=== Storage ===
Free file entries: 20
SD card 0 detected
SD card longest read time 5.0ms, write time 48.0ms, max retries 0
=== Move ===
DMs created 83, segments created 0, maxWait 0ms, bed compensation in use: none, height map offset 0.000, max steps late 0, min interval 0, bad calcs 0, ebfmin 0.00, ebfmax 0.00
no step interrupt scheduled
Moves shaped first try 0, on retry 0, too short 0, wrong shape 0, maybepossible 0
=== DDARing 0 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== DDARing 1 ===
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 1 is on, I-accum = 0.0
=== GCodes ===
Movement locks held by null, 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
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
File2 is idle in state(s) 0
Queue2 is idle in state(s) 0
Q0 segments left 0, axes/extruders owned 0x0004003
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== CAN ===
Messages queued 5999, received 13284, lost 0, errs 0, boc 0
Longest wait 3ms for reply type 6031, peak Tx sync delay 378 free buffers 50 (min 49), ts 3334/3333/0
Tx timeouts 0,0,0,0,0,0
=== Network ===
Slowest loop: 194.05ms; fastest: 0.00ms
Responder states: MQTT(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0)
HTTP sessions: 1 of 8
Uploads/Errors: 58/0
=== WiFi ===
Interface state: active
Module is connected to access point 
Failed messages: pending 0, notrdy 0, noresp 0
Bad header: 0/0
Firmware version 2.2.0
MAC address 2c:bc:bb:bc:86:bb
Module reset reason: Power up, Vcc 0.00, flash size 4194304, free heap 180920
WiFi IP address 192.168.10.59
Signal strength -128dBm, channel 0, mode none, reconnections 0
Clock register 00003043
Socket states: 0 0 0 0 0 0 0 0

m122 b121
Diagnostics for board 121:
Duet TOOL1LC rev 1.1 or later firmware version 3.5.4 (2024-11-24 10:42:45)
Bootloader ID: SAMC21 bootloader version 2.3 (2021-01-26b1)
All averaging filters OK
Never used RAM 3848, free system stack 136 words
Tasks: Move(3,nWait 7,0.0%,134) HEAT(2,nWait 6,0.3%,112) CanAsync(5,nWait 4,0.0%,54) CanRecv(3,nWait 1,0.0%,70) CanClock(5,nWait 1,0.0%,58) ACCEL(3,nWait 6,0.0%,52) TMC(2,delaying,3.6%,52) MAIN(1,running,91.2%,314) IDLE(0,ready,0.0%,26) AIN(2,delaying,4.8%,112), total 100.0%
Owned mutexes:
Last reset 00:11:54 ago, cause: software
Last software reset data not available
Driver 0: pos 0, 562.0 steps/mm, standstill, SG min 0, read errors 0, write errors 1, ifcnt 51, reads 29589, writes 13, timeouts 0, DMA errors 0, CC errors 0, steps req 0 done 0
Moves scheduled 0, completed 0, in progress 0, hiccups 0, segs 0, step errors 0, maxLate 0 maxPrep 0, maxOverdue 0, maxInc 0, mcErrs 0, gcmErrs 0, ebfmin 0.00 max 0.00
Peak sync jitter -2/13, peak Rx sync delay 211, resyncs 0/0, no timer interrupt scheduled
VIN voltage: min 23.8, current 23.8, max 23.8
MCU temperature: min 29.4C, current 30.4C, max 30.4C
Last sensors broadcast 0x00000012 found 2 95 ticks ago, 0 ordering errs, loop time 0
CAN messages queued 14239, send timeouts 0, received 6419, lost 0, errs 210, boc 0, free buffers 18, min 18, error reg 100000
dup 0, oos 0/0/0/0, bm 0, wbm 0, rxMotionDelay 0
Accelerometer: LIS3DH, status: 00
I2C bus errors 0, naks 3, contentions 0, other errors 0

@Simon-1 I wired a slider switch into the 5v power line mounted to the side of the PD cases. Super easy if your using serial. Might be harder with the ribbon cable. However, I almost never use the switch the screen saver seems good enough.

@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