@dc42 After calling M665 the homing is required. And after that the top position again at the end of axis.
The probe is built-in delta smart effector, before each print I do bed probing (G32) with controlling max deviation less than 0.03
@dc42 After calling M665 the homing is required. And after that the top position again at the end of axis.
The probe is built-in delta smart effector, before each print I do bed probing (G32) with controlling max deviation less than 0.03
@dc42 Thank you for answer, David! The reason I'd like decrease limit is because when using sensorless homing (stall detection) the carriages almost hits the corners at the ends of the axes when the printer moves to the top position. So, It would be better to have some gap at the most top position for movements after homing done.
Hi, community!
The problem is that I can move outside upper Z limit on Delta printer configuration.
M665 L361.858:361.858:361.858 R181.089 H452 B145.0 X-0.148 Y-0.130 Z0.000
M574 X2 S3
M574 Y2 S3
M574 Z2 S3
; Configure motor stall detection
M915 X Y Z R0 F0
Some part of homedelta.g:
M400
G91 ; use relative positioning
; first pass
G1 H1 X500 Y500 Z500 F3000
...
M400
G1 Z-10 F2000 ; down a few mm so that we can centre the head
The coordinates after homing has been finished:
M114
X:0.000 Y:0.000 Z:441.996 E:0.000 E0:-0.0 Count 151321 151321 151321 Machine 0.000 0.000 441.996 Bed comp 0.000
Setting the current Z coord as upper limit:
M208 Z442
Axis limits (mm) X-145.0:145.0, Y-145.0:145.0, Z0.0:442.0
Moving up:
G91 G0 Z100
M114
X:0.000 Y:0.000 Z:451.043 E:0.000 E0:-0.0 Count 153133 153133 153133 Machine 0.000 0.000 451.043 Bed comp 0.000
The Z coordinate is outside the limit of 442. Axes were stopped a bit lower than set in M665 command. There was no error message, despite that previous Z (442) + movement +100 = 542.
Trying repeat the movement:
G91 G0 Z100
Error: G0: target position not reachable from current position
Now there was the message.
So, the question is: how to limit upper Z coords to arbitrary value ?
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.5.2 (2024-06-11 17:13:43) running on Duet WiFi 1.02 or later
Will appreciate for help.
As a workaround, I'm currently using the code below, but I would like to figure out how to correctly pass multiple values using variables in such parameters.
M581 T9 P-1
M581 T9 R0 S1 P{global.x_axis_endstop_pin}
M581 T9 R0 S1 P{global.y_axis_left_endstop_pin}
M581 T9 R0 S1 P{global.y_axis_right_endstop_pin}
M581 T9 R0 S1 P{global.z_axis_endstop_pin}
M581 T9
Result: Trigger 9 fires on a rising edge of endstops/inputs 6 7 8 9
@dc42 I've got the error:
M581 T9 R0 S1 P{global.x_axis_endstop_pin ^ "+" ^ global.y_axis_left_endstop_pin ^ "+" ^ global.y_axis_right_endstop_pin ^ "+" ^ global.z_axis_endstop_pin}
Error: M581: expected integer value
Returning to the question, I found that the solution still does not work.
Tested on Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.4.0 (2022-03-15)
Operator '+' just summarizes pins values and as result I have one pin number 30 instead of 4 pins (6:7:8:9)
G-CODE to reproduce
; Variables
global x_axis_endstop_pin = 6
global y_axis_left_endstop_pin = 7
global y_axis_right_endstop_pin = 8
global z_axis_endstop_pin = 9
; remove all pins from trigger
M581 T9 P-1
; check the trigger configuration
M581 T9
Result: Trigger 9 is not configured
; setup new pins
M581 T9 R0 S1 P{global.x_axis_endstop_pin + global.y_axis_left_endstop_pin + global.y_axis_right_endstop_pin + global.z_axis_endstop_pin}
; check what we have
M581 T9
Result: Trigger 9 fires on a rising edge of endstops/inputs 30
@jay_s_uk said in Unexpected behaviour of expression { } in command parameters.:
@adegtiar there should be + in between , not a ,
Thank you! It works
@dc42 said in Unexpected behaviour of expression { } in command parameters.:
@adegtiar I have updated https://duet3d.dozuki.com/Wiki/GCode_Meta_Commands#Section_Use_of_expressions_within_GCode_commands to show the correct syntax.
I have tried that syntax, but got an error:
M581 T9 R0 S1 P{global.x_axis_endstop_pin, global.y_axis_left_endstop_pin, global.y_axis_right_endstop_pin, global.z_axis_endstop_pin}
Error: M581: expected '}'
Hi, David!
It seems that not more that one expression can be used when it is necessary to specify several values, for instance:
M581 P{var.myVar1}:{var.myVar2}:{var.myVar3} ...
My test g-code:
global x_axis_endstop_pin = 6
global y_axis_left_endstop_pin = 7
global y_axis_right_endstop_pin = 8
global z_axis_endstop_pin = 9
echo {global.x_axis_endstop_pin}
echo {global.y_axis_left_endstop_pin}
echo {global.y_axis_right_endstop_pin}
echo {global.z_axis_endstop_pin}
; Emergency stop trigger on endstops hits
M581 T8 R0 S1 P{global.x_axis_endstop_pin}:{global.y_axis_left_endstop_pin}:{global.y_axis_right_endstop_pin}:{global.z_axis_endstop_pin}
Only the first pin triggers when its state changes. The rest 3 specified pins does not cause the trigger.
Am I use wrong syntax or it is a bug ?
Echoed values are correct, additionally I have checked them in the object viewer.
And all 4 pins work correctly only when I specify them manually, like this:
M581 T8 R0 S1 P6:7:8:9
Board: Duet 2 WiFi (2WiFi)
Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.4.0beta5 (2021-10-12)
Thank you very much!
@dc42 Good idea! But in order to correctly interpret when it happened (just) or a long time ago, it would be good to either reset this status on request (for example, after processing inside a trigger) or so that the last status has the time of the event, how long ago it happened at the time of its reading. Just for example:
if {job.lastPrintStatus='some failure code'} && {job.lastPrintStatusAge < 10} ; react if it is a 'fresh' event, not older 10 seconds (or a couple seconds would be enough for process)
echo "Last recent job failed";
; proposition for event age value
; if this code executes just after error event
echo {job.lastPrintStatusAge} ; will be 0 sec
G4 S1.0
echo {job.lastPrintStatusAge} ; will be 1 sec
G4 S10.0
echo {job.lastPrintStatusAge} ; will be 11 sec
@bearer Cam simulations is OK. Out of bounds of coordinates occurred due to the incorrect WCS (a few mm was insufficient).
@dc42 said in Spindle immediately turns off on error:
Stopping all commands in the buffer could lead to a positioning error. Alternatively, I can have the spindle kept on until the buffer is empty. Would that be acceptable?
Yes, this will solve the problem of a broken cutter due to movement with the spindle off.
But, Is it possible to catch the error event to run a script to handle the situation? Is it possible to determine that the last job failed? I would like to determine (inside trigger handler) whether it was done manually (canceled) or as a result of an error ? The trigger fires when machine state is idle.
The main reason - safe machining, and catch all inconsistent operations. I have power outage sensor, connected to spindle and the trigger for it:
if job.file.fileName=null
echo "KRESS tool has been UNPOWERED."
T-1
else
echo "Power lost. Emergency stop."
M112
When I turn off spindle manually – it is just reports that tool is unpowered. But in case of movement error, the trigger raises after job was canceled and can't catch this for safely up Z axis or for immediately stop all machine (like M112).
Look at the screenshoot: first, the execution of the hob canceled, then the power failure trigger was triggered, and only then an error message appeared.
IMO, in the event of a positioning error, stop everything immediately, but do not execute the remaining commands in the buffer.
I have configured duet to CNC mode:
M453 C"fan2+exp.heater4" Q1 R1
(I use 'fan2' pin to control spindle power relay, and pin heater4 not for real PWM control, but for the reason that only on / off control cannot be specified).
The problem is that the spindle shuts down immediately if move accidentally goes out of range - on error "G0/G1 target position outside machine limits".
And machine after that doing some movements (i suppose it depends on buffer), instead of stops all movements further.
On this error, no scripts are executed (neither stop.g, nor cancel.g or other).
Due to the fact that the power is cut off, there is a high probability of damage to the cutter. My temporary workaround is to remove the spindle control from the M453 (without C param) and use M42 command to control spindle instead of M3/M5 commands :(. Thus, in the event of an error, the spindle simply remains switched on inside the workpiece.
Is it possible to execute script stop.g on such errors ? It is necessary to somehow find out that the work was interrupted and canceled. An emergency stop in this case would be better than just stopping all job.
Info:
Board: Duet 2 WiFi (2WiFi)
Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.1.1 (2020-05-19b2)
Duet WiFi Server Version: 1.23
Hi, David!
I found that the emergency stop button does not work immediately after pressing in some situations, for example, during auto calibration. While the stop button in the browser acts instantly.
PanelDue FW 1.22.1(28b1)
DuetWifi 2.02RC2(RTOS)
See video https://youtu.be/PVWf7YoQxQw
Is it possible to make the emergency stop button always available to be pressed (and so that it is easy to get into it with your finger)? Some pop-up windows overlap it, so when you really need to quickly stop the printer, it is much faster to turn off the master switch than to get to this button.
Thank you!
If you are powering the Duet with 5V power only, that's normal for now. There will be a new PanelDue firmware release in the next few days that supports the new Standby status returned by RRF 2.0.
Yes, using only with 5v.
One more thing: when jogging not homed axis I see errors in g-code console:
M120
G91
G1 X-0.1 F3600
M121
Error: G0/G1: insufficient axes homed
Error: Pop(): stack underflow!
PanelDue v3.0a 5" FW 1.20(b15) can't connect after update DuetWifi to FW 2.0(RTOS)RC6 (2018-05-29b4), works well until now. PanelDue displays "Connecting...", tried to reset setting. Connected via 4 pin cable.