@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.

@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.

@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.

@paulhew I've been using it since it was turned on and it actually been pretty accurate and is spinning up my case fans reliably. So Far.

@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...

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.

@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?...

@keyz182 Man both myself and my browser's search function are blind.... okay well i set it the way i should have it through dumb luck. I can live with that.

@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

@adammhaile Well they where working until I replaced them With Odroid C4's and then pulled off the odriod's from all but 1 printer. SBC mode has been more trouble than its worth.

yeah I must have done something stupid. I swear it had power. but ... now its working. thanks for the assist for whatever dumb thing i did.

m122 b121
Diagnostics for board 121:
Duet TOOL1LC rev 1.1 or later firmware version 3.4.0 (2022-03-15 09:00:04)
Bootloader ID: SAMC21 bootloader version 2.3 (2021-01-26b1)
All averaging filters OK
Never used RAM 2172, free system stack 62 words
Tasks: Move(notifyWait,0.0%,153) HEAT(notifyWait,0.2%,115) CanAsync(notifyWait,0.0%,65) CanRecv(notifyWait,0.0%,76) CanClock(notifyWait,0.0%,65) ACCEL(notifyWait,0.0%,61) TMC(delaying,3.0%,57) MAIN(running,91.8%,349) IDLE(ready,0.0%,26) AIN(delaying,4.9%,142), total 100.0%
Last reset 00:02:11 ago, cause: power up
Last software reset time unknown, reason: WatchdogTimeout, available RAM 2612, slot 0
Software reset code 0x00a0 ICSR 0x04413011 SP 0x20007f18 Task MAIN Freestk 5934 ok
Stack: 200047a8 00000002 42003800 20000000 41000000 000167bd 0000c1a8 01000013 00000020 00000020 200031a4 000167bd 200047a8 00000005 00000000 00b00b00 00000015 fffffffd 9ed18dcf 00000000 00000002 00000000 00000002 000191c7 00000000 2000213c 200020e0
Driver 0: pos 0, 400.0 steps/mm,standstill, SG min 0, read errors 0, write errors 0, ifcnt 12, reads 174, writes 12, timeouts 0, DMA errors 0, CC errors 0, steps req 0 done 0
Moves scheduled 0, completed 0, in progress 0, hiccups 0, step errors 0, maxPrep 0, maxOverdue 0, maxInc 0, mcErrs 0, gcmErrs 0
Peak sync jitter -3/9, peak Rx sync delay 627, resyncs 0/0, no step interrupt scheduled
VIN voltage: min 24.3, current 24.3, max 24.4
MCU temperature: min 28.1C, current 35.5C, max 35.5C
Last sensors broadcast 0x00000002 found 1 229 ticks ago, 0 ordering errs, loop time 0
CAN messages queued 2735, send timeouts 0, received 1210, lost 0, free buffers 37, min 37, error reg 0
dup 0, oos 0/0/0/0, bm 0, wbm 0, rxMotionDelay 0
Accelerometer: LIS3DH, status: 00
I2C bus errors 0, naks 3, other errors 0
=== Filament sensors ===
Interrupt 4 to 9us, poll 8 to 700us
Driver 0: pos 0.00, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0```

@nurgelrot No idea I removed everything and pulled it onto my test bench and no its acting fine. let me put it back in the dang printer...

@dc42 no looks like the board has no power but voltage is in the VIN wires going to the board.