@dc42 Thanks, David!
Posts made by wackyfrog
-
RE: Unexpected behaviour of expression { } in command parameters.
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
-
RE: Unexpected behaviour of expression { } in command parameters.
@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
-
RE: Unexpected behaviour of expression { } in command parameters.
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
-
RE: Unexpected behaviour of expression { } in command parameters.
@jay_s_uk said in Unexpected behaviour of expression { } in command parameters.:
@adegtiar there should be + in between , not a ,
Thank you! It works
-
RE: Unexpected behaviour of expression { } in command parameters.
@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 '}'
-
Unexpected behaviour of expression { } in command parameters.
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!
-
RE: Spindle immediately turns off on error
@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
-
RE: Spindle immediately turns off on error
@bearer Cam simulations is OK. Out of bounds of coordinates occurred due to the incorrect WCS (a few mm was insufficient).
-
RE: Spindle immediately turns off on error
@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.
-
RE: Spindle immediately turns off on error
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.
-
Spindle immediately turns off on error
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 -
Emergency STOP does not work immediately
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!
-
RE: Firmware 2.0RC6 and 1.21.1RC6 released
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! -
RE: Firmware 2.0RC6 and 1.21.1RC6 released
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.
-
RE: Axis max travel & G0-G3
Z probe (G30) also leads to non-observance of the limits of the Z axis
-
RE: Axis max travel & G0-G3
Hi, David! I found out that G92 X0 (or any other axis) leads to incorrect processing of the limit. For example: G28, then move head to the XY center of bed, G92 X0 Y0. Now we are in machine position 100, 100 and logical position 0, 0. G0 X-100 Y-100 does't work (configured as M208 X0 Y0 Z0 S1 M208 X212 Y117 Z212 S0), but ! G0 X212 Y117 will lead to a breakdown head/other hw. IMO, any movement/offsets/move to predefined position/etc commands needs to be controlled over movement abstraction. It's seems the good idea to have "machine coordinates" for each axis in primitive ticks/steps/movements from 0 (home) to limit to controlling limits. Of course, it can be resolved by set two limit switches on each axis, but it will be overkill.
-
RE: Axis max travel & G0-G3
I can understand that in a CNC environment, any move that would exceed the movement limits is likely to indicate a serious error. However, in a 3D printer a common cause of movement outside the limits is that the slicer has generated a skirt around the print, and the skirt breaches the limits slightly. In this case, limiting the motion so that the skirt is compressed is a reasonable action.
If specify wrong (just by mistake, a typo) parameters in the slicer, we get damage to the machine because it supposedly should not happen. Why allow the head to move beyond the established limits? Fo what reason ? This does not make sense for any printer mode. In which cases is it necessary?
Perhaps the behaviour on an attempted move outside the limits should change if M452 or M453 has been used to switch the printer into laser or CNC mode?
M450
PrinterMode:CNCThe video shows how it looks and what it leads to https://youtu.be/evGKM8Zwan4
I set a fairly low current of drivers so as not to damage the mechanics during the experiments (0.7A), but in the operating mode there will be 2Amp and this will allow the NEMA23 motors to seriously damage the mechanic.
In the firmware, you limit the driver current to 2A because it can overheat. Following the same logic, you need to remove all limitations in the firmware, because simply there must be a correct configuration and good ventilation of the board. Isn't it ?