@gloomyandy Due to the design of the tool holder, the probe and the tool (paint brush) can't be fitted at the same time. We have to swap one in, do the ABL measurements, and then put the brush back in again.
I'll take a look at changing the endstop configuration from low to high and let you know how it goes -
Thanks for the top!
Best,
D
@gloomyandy here are some example start and end snippets from files I've been running - do you see anything which looks like it might cause this delay?
;FLAVOR:Marlin
;TYPE:WALL-OUTER
G1 Z-25.0 F4800
G1 F40000
G1 X766.234 Y2018.286 Z-4.0
G1 X766.348 Y2016.803 Z-4.0
G1 X766.862 Y2010.128 Z0.601 E0.0243700882
G1 X764.58 Y1989.589 Z1.165 E0.0620192331
G1 X761.862 Y1974.838 Z-4.0
G1 X759.31 Y1960.983 Z-4.0
...
...
G1 X1027.692 Y2299.21 Z1.521 E0.0046168879
G1 X1026.736 Y2300.688 Z1.508 E0.0052808428
G1 X1025.724 Y2302.405 Z1.491 E0.0059793560
G1 X1024.768 Y2304.19 Z1.472 E0.0060749237
G1 X1023.866 Y2306.046 Z1.451 E0.0061910443
G1 X1022.928 Y2308.18 Z1.425 E0.0069935888
G1 X1022.092 Y2310.296 Z1.398 E0.0068259599
G1 X1021.308 Y2312.497 Z1.368 E0.0070099653
G1 X1021.308 Y2312.497 Z-4.0 E0.0161040000
;Print End Script
G1 Z-25.0 F500
;FLAVOR:Marlin
;TYPE:WALL-OUTER
G1 Z-25.0 F4800
G1 F40000
G1 X296.07 Y2098.485 Z-4.0
G1 X291.339 Y2084.251 Z0.618 E0.0470832812
G1 X305.337 Y2088.952 Z0.634 E0.0442989046
G1 X313.206 Y2091.849 Z0.644 E0.0251560098
G1 X326.903 Y2097.612 Z0.663 E0.0445800746
G1 X330.952 Y2099.163 Z0.667 E0.0130076963
G1 X335.86 Y2100.829 Z0.671 E0.0155491583
...
...
G1 X572.105 Y2354.19 Z1.187 E0.0001434364
G1 X572.016 Y2354.171 Z1.171 E0.0002772039
G1 X571.514 Y2354.023 Z1.121 E0.0015772356
G1 X569.362 Y2353.29 Z0.999 E0.0068300434
G1 X569.362 Y2353.29 Z-4.0 E0.0149970000
;Print End Script
G1 Z-25.0 F500
I'm running a g-code generator which we developed inhouse so we have lots of control over what it does.
I know the final Z move is slow, but it doesn't take anywhere near 10 seconds
Any ideas?
Cheers!
D
I'll take a look at daemon.g thanks Phaedrux - do you have any advice as to whether this is best done by looking at the object model or by looking at what M522 returns?
@fcwilt - the machine isn't static and is sometimes set up on networks which we don't control. The flexibility of DHCP here is really useful - but - I'd like to have a static fallback IP which I can use for commissioning in the workshop or if I'm connected directly to the controller because the local network is down/unavailable.
Currently, I'm using a USB cable to toggle the network settings back and forth over the serial link in this instance but it would be nice to side step this if possible.
I'm building a CNC machine which paints pictures. Each picture is its own Gcode file and occupies a small area of a larger canvas - the pictures usually come in batches.
I have written a simple queue manager which runs available jobs one after the other so I don't have to manually select and run them which is great as I don't have to babysit the machine while in the studio.
I have noticed that there is a delay of 5-10 seconds between one job finishing and the next one starting - is there a way of reducing this time lag? A few seconds doesn't seem like a lot but for many jobs in sucsession, it adds up quickly to minutes at a time of the machine doing nothing. I imagine that this delay between jobs is actually a short delay at the end of one job and a different short delay at the start of the next job (there is a delay at the start of the process between the first request being sent and the machine starting for the first time at the top of the queue).
The queue manager is written in python and makes use of the HTTP interface - it works like this:
//Pseudo code, not actual python
//Assume all gcode is already on the SD card
//Assume we have a list of all the g-code file we want to run
print("Start queue")
foreach gcodeFile in listOfFiles:
//Make a HTTP request which starts the first job in the list
httpRequest("my_duet_address.local/rr_gcode?gcode='M32 "0:/gcodes/" + gcodeFile)
//make periodic requests to the status endpoint to see if the machine is idle or not
while(true):
response = httpRequest("my_duet_address.local/rr_status")
machineStatus = response.json.get("status")
//If the machine is idle, leave this polling loop and go back to the top of the foreach
if machineStatus = "I":
break;
//Wait a small arbitrary amount of time to not overwhelm the HTTP interface on the duet
sleep(0.25)
print("All done")
While there is a little delay in my status polling loop it is much shorter than the time between one job ending and another starting.
Are there any configuration options I can change on the duet to reduce this gap time?
Many thanks!
D
Hey folks,
The machine I am working on at the moment has an unusual Z axis configuration where the ABL probe and Z end stop are at opposite ends of the tool's travel. That is, Z homes away from the work bed and drives towards the work bed to take ABL probe measurements.
I tried a few different combinations of axis direction and end stop position to get this to work but always ended up with the probing and homing direction being the same (and smushing the tool head into the end stop or the work).
Currently, I have a work around where:
Which produces a good looking height map and CSV.
For reference - here's what that looks like:
M561 ;remove any existing ABL profile
;Make sure the Z axis is the right way around (Z+ tward the canvas)
M569 P121.0 S1 ; reset physical drive 121.0 goes forwards - Z
M584 X0.1:0.2 Y0.3 Z121.0 E122.0 ; set drive mapping Xbot MB0-Driver0, Xtop MB0-Driver1, Y MB0-Driver2, Z TB121-Driver0, Extruder TB122-Driver0
M208 X0 Y0 Z0 S1 ; set axis minima
M208 X4800 Y3300 Z100 S0 ; set axis maxima
G28 ;home all axes
G1 Z25 ;move Z to be closer to the canvas so it doesn't bash against the end stop
;Reverse the Z axis for bed levelling
M569 P121.0 S0 ; reverse direction of Z drive motor
M584 X0.1:0.2 Y0.3 Z121.0 E122.0 ; set drive mapping Xbot MB0-Driver0, Xtop MB0-Driver1, Y MB0-Driver2, Z TB121-Driver0, Extruder TB122-Driver0
;Z+ is now AWAY from the canvas and Z- is TOWARD the Canvas
; Z-Probe config
M558 P8 C"121.io0.in" H20 F1500:800 T40000 ; set Z probe type to unfiltered active high and the dive height + speeds
G31 P500 X0 Y10 Z3 ; set Z probe trigger value, offset and trigger height
;M557 X20:4650 Y120:3190 S310 ; define mesh grid - full canvas
M557 X20:4680 Y100:3100 P21:21
;M557 X20:4650 Y120:3190 S310 ; define mesh grid - full canvas
;Do the probing
G29 S0 ; do bed levelling - save to SD card
;Reset the Z axis
M569 P121.0 S1 ; reset physical drive 121.0 goes forwards - Z
M584 X0.1:0.2 Y0.3 Z121.0 E122.0 ; set drive mapping Xbot MB0-Driver0, Xtop MB0-Driver1, Y MB0-Driver2, Z TB121-Driver0, Extruder TB122-Driver0
M208 X0 Y0 Z0 S1 ; set axis minima
M208 X4800 Y3300 Z100 S0 ; set axis maxima
The height map which is produced by this process is also flipped, so I am currently downloading the CSV, multiplying all the height values by -1 and reuploading the 'inverted' file. This fully works - and I can see the Z axis moving around and taking the height variations into account while it travels.
Is there a way I can have the duet invert all the values for me when it takes the readings, or invert the mesh when calculating the bed levelling so I don't have to do that step manually? I have seen there's an invert tick box in the mesh viewer in DWC but this only seems to flip the view of the mesh in the browser rather than how its actually applied.
Alternatively, is there some configuration option I have missed which would allow for the probe and end stop to be at opposite ends of the Z-axis travel and forgo all these shenanigans in the first place?
Any pointers much appreciated,
Cheers,
D
Hey folks,
Is it possible to configure a timeout for DHCP and have a Duet3 fallback to a static IP if it doesn't receive an IP from a DHCP server? I've looked through the documentation and there doesn't seem to be a way of doing this directly. I did some experiments configuring both a static IP and DHCP in the config file but that didn't work (as you might expect).
Are there any commands which return DHCP status specifically? I can't seem to find one - so I figured it might be possible to have a macro which:
And have this run at startup as part of config.g
Is this the 'most correct' approach or should I be using meta commands to query the object model? I could look at network.interfaces[].actualIP to see if the IP is still 0.0.0.0 perhaps? I also saw that network.interfaces[].state can have a state of 'obtainingIP' but I'm not sure if that means that DHCP has started and the duet is waiting to get an IP or that the link is active and the duet is waiting for the DHCP process to start. If it were the latter I could check this status after a few seconds and toggle to a static IP if nothing happens.
Any guidance is much appreciated,
D
@Phaedrux I flipped the order of the switches in my config and now everything works just fine. The overshooting was a result of the sensor stopping the 'wrong' motor and then the other one never reaching a place it could trigger its end stop.
I am confused though - If this is my motor config:
M584 X0.0:0.1 Y0.2 Z121.0 E122.0 ; set drive mapping Xbot MB0-Driver0, Xtop MB0-Driver1, Y MB0-Driver2, Z TB121-Driver0, Extruder TB122-Driver0
The X motors are ordered 0 - 1
Then in my end stop config - this works:
M574 X1 S1 P"!^io1.in+!^io0.in"
and this didn't:
M574 X1 S1 P"!^io0.in+!^io1.in"
Which seems backward to me.
I know the sensors are not connected the wrong way - this week I've been running with only io.0.in connected in single end stop mode and the machine was homing correctly.
Can you explain how I got this muddled up?
Thanks again for your help!
D
Hey @Phaedrux - thanks for your reply.
I'll set that up and test it against the machine when I'm back at the workshop.
I've checked the order of the end stops vs motors in their respective set up lines and they do match.
It would be good to be able to conduct a self-squaring when homing - the length of the Y axis means it does walk out of alignment over time and I do have fixed endstops. Can you advise as to how to get that working. My attempted configuration failed and I'm not sure what I got wrong.
Hello everyone,
I'm building and commissioning a large wall-mounted plotter and am having some trouble getting the X-axis to home properly.
Background info
Here's a photo for some context: https://www.dropbox.com/scl/fi/sz3vvjem5lfj9oh27qymf/IMG_7640.jpg?rlkey=ety6ned3zbdai1smagn2k973i&dl=0
The gantry is 6m long and 4m high.
The X and Y axes are driven by clearpath SD servo motors and so far they have been working well. The carriages are belt driven from the servos directly (no gear boxes).
Drives are being run from a Duet 3 Mainboard 6XD
M115
FIRMWARE_NAME: RepRapFirmware for Duet 3 MB6XD FIRMWARE_VERSION: 3.4.6 ELECTRONICS: Duet 3 MB6XD v1.01 or later FIRMWARE_DATE: 2023-07-21 14:11:58
Duet Web Control 3.4.6
The X-axis has a motor on both sides X-top and X-bot(tom)
There are inductive end stop switches set up for all axes, the Y axis homes without issue so I'm fairly sure their configuration is correct/wiring is working.
Issue
When homing the dual motor axis using both end stops while both the inductive sensors fire (their built-in LEDs come on) duet continues to drive the top motor and the Y gantry starts to twist/become skewed and the only recovery is to e-stop the machine.
As the gantry starts to skew, one of the motors errors out as it goes over its torque limit - is there a way to have any drive error stop all other drives?
While getting things set up, I connected the I/O pins for these end stops to some flying wires so I could manually simulate the home switches going off and this would stop both motors correctly. In this setup, I tied the I/O pins together so I would only need to short one pin to ground to get both of them to fire at the same time.
Now that the real sensors are connected (and that they are far apart) it is difficult to do a simulated trigger like this.
Do you have any advice as to how to go about debugging this issue?
Investigations to date
Currently, the 'most working' version of things uses a one of the inductive switches to stop the homing procedure - we square the Y gantry by hand and hope it doesn't go out of plumb (not ideal).
Here's the relevant config files:
config.g
; Configuration file for Duet 3 MB 6XD (firmware version 3.3)
; executed by the firmware on start-up
;
; generated by RepRapFirmware Configuration Tool v3.3.16 on Fri Sep 15 2023 20:09:09 GMT+0100 (British Summer Time)
; Edited by DJ - 20230917
; General preferences
G90 ; send absolute coordinates...
M83 ; ...but relative extruder moves
M550 P"name" ; set printer name
; Wait a moment for the CAN expansion boards to start
G4 S2
; Network
M552 P192.168.1.200 S1 ; enable network and set IP address
M553 P255.255.255.0 ; set netmask
M554 P192.168.1.254 ; set gateway - we don't always know what the gateway will be, how do we do DHCP with a static fallback?
M586 P0 S1 ; enable HTTP
M586 P1 S1 ; enable FTP
M586 P2 S0 ; disable Telnet
; Drives
M569 P0.0 S1 T3:3:3:3 ; physical drive 0.0 goes forwards - Xbot - set Minimum driver step pulse width, step pulse interval, direction setup time and direction hold time, in microseconds - driver is active low (default)
M569 P0.1 S1 T3:3:3:3 ; physical drive 0.1 goes forwards - Xtop - set Minimum driver step pulse width, step pulse interval, direction setup time and direction hold time, in microseconds - driver is active low (default)
M569 P0.2 S0 T3:3:3:3 ; physical drive 0.2 goes backwards (zero at bottom) - Y - set Minimum driver step pulse width, step pulse interval, direction setup time and direction hold time, in microseconds - driver is active low (default)
M569 P121.0 S1 ; physical drive 121.0 goes forwards - Z
M569 P122.0 S1 ; physical drive 122.0 goes forwards - Extruder
M584 X0.0:0.1 Y0.2 Z121.0 E122.0 ; set drive mapping Xbot MB0-Driver0, Xtop MB0-Driver1, Y MB0-Driver2, Z TB121-Driver0, Extruder TB122-Driver0
M92 X40.00 Y40.00 Z400.00 E420.00 ; set steps per mm (max 52 steps/mm at 8000 counts/rev on clearpath)
; Steps per mm calculator https://blog.prusa3d.com/calculator_3416/
M566 X900.00 Y900.00 Z60.00 E120.00 ; set maximum instantaneous speed changes (mm/min)
M203 X30000.00 Y30000.00 Z1800.00 E1200.00 ; set maximum speeds (mm/min)
M201 X600.00 Y600.00 Z200.00 E250.00 ; set accelerations (mm/s^2)
M906 X800 Y800 Z800 E800 I30 ; set motor currents (mA) and motor idle factor in per cent
M84 S30 ; Set idle timeout
; Axis Limits
M208 X0 Y0 Z0 S1 ; set axis minima
M208 X5000 Y3600 Z150 S0 ; set axis maxima
; Endstops
M574 X1 S1 P"!^io0.in" ; configure switch-type (e.g. microswitch) endstop for low end on Xbot via pin !^io0.in only
M574 Y1 S1 P"!^io2.in" ; configure switch-type (e.g. microswitch) endstop for low end on Y via pin !^io2.in
M574 Z1 S1 P"!^121.io2.in" ; configure switch-type (e.g. microswitch) endstop for low end on Z via pin !^121.io2.in
; Z-Probe
M558 P1 C"121.io0.in" H5 F120 T6000 ; set Z probe type to unmodulated and the dive height + speeds
G31 P500 X0 Y0 Z2.5 ; set Z probe trigger value, offset and trigger height
M557 X15:4500 Y15:3500 S100 ; define mesh grid
; Heaters
M140 H1 ; disable heated bed
; Fans
M950 F0 C"121.out2" Q500 ; create fan 0 on pin 121.out2 and set its frequency
M106 P0 S0 H-1 ; set fan 0 value. Thermostatic control is turned off
M950 F1 C"122.out2" Q500 ; create fan 1 on pin 122.out2 and set its frequency
M106 P1 S1 H-1 ; set fan 1 value. Thermostatic control is turned off
; Tools
M563 P0 S"Brush" D0 F0 ; define tool 0, no H here means no heater. D0 = extruder 0, F0 = fan 0
G10 P0 X5 Y10 Z20 ; set tool 0 axis offsets
G10 P0 R0 S0 ; set initial tool 0 active and standby temperatures to 0C
; Custom settings are not defined
;M301 P1 ; disable heaters so we don't have an error
;M562 P1 ; reset the heater error - feels like a hack; doesn't seem to work here - maybe it has to go at the top of the job file?
; Miscellaneous
T0 ; select first tool
M17 ; enable all axes ( holds Y in place without brake) - this needs to change when the brake connects to the IO pin
homex.g
; homex.g
; called to home the X axis
;
; generated by RepRapFirmware Configuration Tool v3.3.16 on Fri Sep 15 2023 20:09:09 GMT+0100 (British Summer Time)
G91 ; relative positioning
G1 H2 Z5 F6000 ; lift Z relative to current position
G1 H1 X-5005 F1800 ; move quickly to X axis endstop and stop there (first pass)
G1 H2 X10 F6000 ; go back a few mm
G1 H1 X-5005 F360 ; move slowly to X axis endstop once more (second pass)
G1 H2 Z-5 F6000 ; lower Z again
G90 ; absolute positioning
Earlier when testing, both end stops were used for homing (connected to flying leads on the bench):
config.g snippet
...
; Endstops
M574 X1 S1 P"!^io0.in+!^io1.in" ; configure switch-type (e.g. microswitch) endstop for low end on Xbot via pin !^io0.in AND endstop for low end on Xtop via pin !^io1.in
M574 Y1 S1 P"!^io2.in" ; configure switch-type (e.g. microswitch) endstop for low end on Y via pin !^io2.in
M574 Z1 S1 P"!^121.io2.in" ; configure switch-type (e.g. microswitch) endstop for low end on Z via pin !^121.io2.in
...
homex.g
; homex.g
; called to home the X axis
;
; generated by RepRapFirmware Configuration Tool v3.3.16 on Fri Sep 15 2023 20:09:09 GMT+0100 (British Summer Time)
G91 ; relative positioning
G1 H2 Z5 F6000 ; lift Z relative to current position
G1 H1 X-5005 F1800 ; move quickly to X axis endstop and stop there (first pass)
G1 H2 X10 F6000 ; go back a few mm
G1 H1 X-5005 F360 ; move slowly to X axis endstop once more (second pass)
G1 H2 Z-5 F6000 ; lower Z again
G90 ; absolute positioning
This worked on the bench but overshoots the top x rail on the real machine.
I also tried doing a split axis homing using RR2 style commands using the following config:
config.g snippet
...
; Endstops
M574 X1 S1 P"!^io0.in" ; configure switch-type (e.g. microswitch) endstop for low end on Xbot via pin !^io0.in
M574 U1 S1 P"!^io1.in" ; configure switch-type (e.g. microswitch) endstop for low end on Xtop via pin !^io1.in - U axis is a temporay axis used only during homing
M574 Y1 S1 P"!^io2.in" ; configure switch-type (e.g. microswitch) endstop for low end on Y via pin !^io2.in
M574 Z1 S1 P"!^121.io2.in" ; configure switch-type (e.g. microswitch) endstop for low end on Z via pin !^121.io2.in
...
homex.g
; homex.g
; called to home the X axis
;
; generated by RepRapFirmware Configuration Tool v3.3.16 on Fri Sep 15 2023 20:09:09 GMT+0100 (British Summer Time)
G91 ; relative positioning
G1 H2 Z5 F6000 ; lift Z relative to current position
M584 X0.0 U0.1 ; Split X axis motors
G1 H1 X500 U500 F1800 ; move quickly to Y axis endstop and stop there (first pass)
G1 X-5 U-5 F6000 ; go back a few mm
G1 H1 X25 U25 F360 ; move slowly to Y axis endstop once more (second pass)
G1 H2 Z-5 F6000 ; lower Z again
G90 ; absolute positioning
M584 X0.0:0.1 ; Combine X-Axis
but this fails before the motors move - Duet reports an error :
G28 U
Error: Failed to enable endstops
where axis U is really Xtop.
Questions
Do you see anything wrong with the configuration
Are there any other tests I can run to narrow down what the issue might be
Is there an issue here with my mapping of Xbot=0, Xtop=1, and Y=2 motors as it doesn't match the default - from what I've read this shouldn't be an issue as the values are being explicitly set
Does dual motor dual endstop homing still need the RR2 style split in homex.g or not?
Any advice you can provide or guidance would be much appreciated - if there's any other details you need please do let me know,
Ciao!
Dev