reach of params - Possible bug on object model in SBC mode
-
Hello. The event system reports some values in the form of params, for example the filament error, triggers some codes. I can read the filament error code using param.P.
This parameter P is a global variable or is it local?Example: param.P is sent to filament-error.g , insode that file I can put an M25
Can I have access to param.P from inside the pause.g file or param-p exist only in the world of filament-error.g?
-
@Tinchus said in reach of params:
This parameter P is a global variable or is it local?
As it is a value passed to a specific .g file, it is only valid within that context. So it is strictly local.
-
@Tinchus
params. are local variables that have been passed to a macro (typically in an M98 call)
You could use them to set a global if you wish.
Or you could use it as a parameter and call pause.g directly from within filament-error.g rather than calling M25
M98 P"pause.g" S{param.P}
Hard to say without knowing the use case.
-
@OwenD Ohhhh! ok, i was thinking inside a little box jajajaj, M25 call pause.g
So if I understand correctly: if Y call M25, param.p wont be accesibvle from inside pause.g, BUT if I call pause.g using M98, I can pass param-p and it value will be accesible from inside pause.g. Is it like this right? -
@Tinchus
You can use the value taken from param.P in your M98 call.
You can't use P as a parameter in your call.
See the docs for valid parameter definitions -
@Tinchus
Bear in mind that if your pause.g is going to act on a parameter then you need to check for the existence of that parameter.
Otherwise your pause.g will fail if called from DWC for example.Is there a reason the whole thing can't be handled in filament-error.g ?
-
@OwenD Not very clear to me: if I use from inside filament-error.g something like this :
M98 P"pause.g" S{param.P}
and the in pause.g i use:
if param.P = 2
Will work?
Why not handling everything from inside filament-error.g? If I do so, how can I make the DWC to show the resume/cancel print buttoms status?
-
@Tinchus said in reach of params:
@OwenD Not very clear to me: if I use from inside filament-error.g something like this :
M98 P"pause.g" S{param.P}
and the in pause.g i use:
if param.P = 2
Will work?
You should use
if exists(param.P) if param.P = 2 ; your code here
Why not handling everything from inside filament-error.g? If I do so, how can I make the DWC to show the resume/cancel print buttoms status?
DWC will show those buttons when the machine state becomes "paused"
It occurs to me that might not happen if paused.g is called directly with M98 rather than by using M25So in fact the best option is still probably handling everything in filament-error.g
M25 if param.P = 2 ; do your thing
-
@OwenD Will try but handling all fropm inside filament error.g is problematic from this point of view: M25 triggers pause.g, wich is a "normal" pause.
in the case of filament error, if I want to handle a potential jam or a filament run out, these different situations will be handle AFTER M25 routines, makes sense? -
You can check the status of the filament monitor in your pause.g and act accordingly
if sensors.filamentMonitors[0].status != "ok" ; do stuff for filament problem
Possible status's are listed here
https://github.com/Duet3D/RepRapFirmware/wiki/Object-Model-Documentation#sensorsfilamentmonitorsstatus-filamentmonitor -
@OwenD I tried that before but the status never changes. I have just repetaed the test, I forced a fail, print was paused as suposed to, error message on screen was shown but the status never changed:
I can be sure that param.P was detected and the error is a code 4 error because filament-error.g has:M25
if {param.P = 2}
M291 S1 R"Filament sensor error" P"An error reading filament sensor."
if {param.P = 4} | {param.P = 5}
M291 S2 R"Filament error" P"possible jam on hotend. "And I got the second message on screen so param.P was detected with code 4 in this case (I manuall stopped the filament from being feed into the extruder)
-
@Tinchus
Are you sure the error persisted until after M25 completed?
The error will trigger as soon as you stop filament feeding, but the sensor state will revert as soon as you allow it to feed again.
Try putting your message(s) before the M25EDIT:
However for your use cae, does not the value of the P parameter suffice to carry out your different requirements? (regardless of the OM state?) -
@OwenD This is my pause.g wich is called at the begginning of filament-error.g```
nce I forced the error, the machine was paused, then I received on screen the configured message inside filament-error.g
And I was looking at the object model web interface. Thje status never changed from "ok"I ned the pachine to go into pause state, if not how do I restart the print from the interface? so the answer is: the param.P parametr could be usefull, but not from inside filament-error file only.
I will make a work around and assign param.p to a global variable so pause.g will be able to get the error code, but I think something is wrong on the object model approach, the status never ever changed from "ok" once the error was triggered
if sensors.filamentMonitors[0].status != "ok" if sensors.filamentMonitors[0].status = "noDataReceived" M83 ; relative extruder moves G92 E0 G1 E-1.2 F1000 ; retract 10mm of filament G91 ; relative positioning G1 Z5 F360 ; lift Z by 5mm G90 ; absolute positioning G1 X10 Y150 F6000 ; go to a side M568 P0 A0 M84 S0 if (sensors.filamentMonitors[0].status = "tooLittleMovement") | (sensors.filamentMonitors[0].status = "tooMuchMovement") G92 E0 G1 E-120 F100 G91 ; relative positioning G1 Z5 F360 ; lift Z by 5mm G90 ; absolute positioning G1 X10 Y150 F6000 ; go to a side M568 P0 A0 else M83 ; relative extruder moves G92 E0 G1 E-1.2 F1000 ; retract 10mm of filament G91 ; relative positioning G1 Z5 F360 ; lift Z by 5mm G90 ; absolute positioning G1 X10 Y150 F6000 ; go to a side M568 P0 A0 M84 S0
-
@Tinchus
I am not seeing that on RRF 3.5.0rc2 - Duet 2 standalone.
DWC takes a moment to show the change, but the OM appears to be updated immediately.I only have a simple switch so can't test your exact case.
My filment-error.g is as follows (note I don't do an immediate pause as I want to use the filament between the spool and the extruder when I run out. The pause is done in daemon.g when that is used up.
I commented out the usual test I do to see if there is a print running and used M591 S2 before testing by activating the switch.;0:/sys/filament-error.g M98 P"test.g" ;run when a filament sensor error is detected. Print will be paused bt Daemon.g after runout distance. var runoutDistance = 300 ; this is just so you can change easily ; first check that we are not currently in an error state and the switch has been toggled again. ;if (global.filamentDistance !=0) || (state.status != "processing") ; echo "Filament sensor triggered, but no print in progress. No action taken" ; M99 ; exit macro ;echo "filament-error.g run" G4 P10 ; delay 10ms to debounce if sensors.filamentMonitors[0].status="ok" echo "switch bounce detected - error cancelled" M99 ; break out if sensor value is zero again (bouncing) else echo {"Filament error type " ^ param.P ^ " detected on extruder " ^ param.D} var thisExtruderValue = move.extruders[tools[state.currentTool].filamentExtruder].position set global.filamentDistance = var.thisExtruderValue + var.runoutDistance echo "filament error detected - print will be paused after " ^ var.runoutDistance ^ "mm"
test.g simply contains
echo sensors.filamentMonitors[0].status
As you can see it is reporting "noFilament" and then the rest of the macro filament-error is run
So again I wonder if the error still persists by the time you're doing the OM checks.
Also perhaps put a "catchall" in your first section in case the status is not "ok" , but also not what you were expectiing.if sensors.filamentMonitors[0].status != "ok" if sensors.filamentMonitors[0].status = "noDataReceived" M83 ; relative extruder moves G92 E0 G1 E-1.2 F1000 ; retract 10mm of filament G91 ; relative positioning G1 Z5 F360 ; lift Z by 5mm G90 ; absolute positioning G1 X10 Y150 F6000 ; go to a side M568 P0 A0 M84 S0 elif (sensors.filamentMonitors[0].status = "tooLittleMovement") | (sensors.filamentMonitors[0].status = "tooMuchMovement") G92 E0 G1 E-120 F100 G91 ; relative positioning G1 Z5 F360 ; lift Z by 5mm G90 ; absolute positioning G1 X10 Y150 F6000 ; go to a side M568 P0 A0 else echo "Filamant status is " ^ sensors.filamentMonitors[0].status echo "no defined moves" else M83 ; relative extruder moves G92 E0 G1 E-1.2 F1000 ; retract 10mm of filament G91 ; relative positioning G1 Z5 F360 ; lift Z by 5mm G90 ; absolute positioning G1 X10 Y150 F6000 ; go to a side M568 P0 A0 M84 S0
-
@OwenD I have changed my config in order to eliminate all possible problem causes. Now, my filament-error.g file is only this, so at the moment an event is triggered by the filament monitor my if should be evaluated right? I can confirm that this evaluation never detects a different status other than ok, i always get the message "no monitor status chenged detected". So, in duet3, SBC mode, with 3.4.6, something is wrong in this part of the object model behaviour. Im doing a work around assigning the param.P value to a global variable in order to be able to work with it on pause.g:
code_text ```if !(sensors.filamentMonitors[0].status = "ok") echo "filament monitor status changed)" else echo "no monitor status changed detected"
-
@Tinchus
It would appear that there is a possible bug when using SBC mode.
Perhaps you can change the subject of this thread to reflect this?
It is probably worth giving details of your firmware, hardware such as any expansion boards, filament type, where it's plugged in etc. -
-
@OwenD I have done so. Im thinking on something, still not tested though: the flow I was using was a file nbamed filament-error.g. Inside that file the first line was a call to M25. So there was a jump to M25 where we alkready discussed that M25 would not have access to param.p... After M25 was completed, control was returned to filament-error.g where I requested the filament monitor status
Would be possible that this switch to M25 make the filament monitor status to return to an "ok" status" so that is why the monitor status is not being detected by the later check on filament-error.g? Just thinking. Because the later code I showed is AFTER the call to M25
-
This post is deleted! -
@Tinchus said in reach of params - Possible bug on object model in SBC mode:
Would be possible that this switch to M25 make the filament monitor status to return to an "ok" status" so that is why the monitor status is not being detected by the later check on filament-error.g? Just thinking. Because the later code I showed is AFTER the call to M25
Yes that's possible (even probable), especially if the error was something like "too little filament" because you restricted it.
As soon as you let it go, the error would clear in the OM.
If you test using filament runout then you will have an answer as the error will persist