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