Conditional GCode - Filaments?
-
@ChrisP - a unified macro that contained conditional statements was my thought, but I am new to this and am still learning the functionality. In my mind, I saw a unified Load/Unload macro that prompted the user on which filament was selected for confirmation and then conditionally set the temps, etc for the routine. Ideally, the functionality would be built in to allow the user to dynamically select a different filament on demand, but canceling the script if the wrong filament is selected also seems reasonable.
-
@oozeBot said in Conditional GCode - Filaments?:
unified Load/Unload macro that prompted the user
I had the same thought, here's the thread and my solution/workaround:
https://forum.duet3d.com/topic/17566/single-macro-for-filament-handling?_=1598546261930 -
@Kolbi that's great! thank you. I'll dive into this now.. In general, do you feel your solution covered everything you wanted to happen? Do you still see a need to expose Filaments as an Object for this or other similar needs?
-
@oozeBot I may be misunderstanding something here, but is your overall aim to be able to use the UI to be able to select a filament from a list of available ones and then have the temperatures etc. set based on the material chosen? If so, this is already possible using the filaments individual config.g.
That said, this doesn't work for loading as config.g isn't parsed pre-loading and isn't typically useful for un-loading as usually you'd want a lower temperature... in which case the the load and unload temperatures can be put in load.g and unload.g.
For a unified macro, then yeh, you'd just need to match filament names against the OM. In which case, I think the only current restriction is whether the filament name field is populated pre-execution of the load.g script. -
@ChrisP - I think Kolbi is way ahead of me on this one and what he has come up with likely handles what I was after. However, like I just mentioned, I can see other scenarios where exposing Filaments as an object could be useful - Ideally, they would all be dynamically loaded to expose common properties. I'm sure that makes this idea much more complex and is likely why it wasn't originally added..
-
@Kolbi - I see you are relying on a filament sensor to detect a loaded state. I am still teetering on this and haven't yet implemented it. What I'd like to see if M291 S3 expanded to:
- allow other prompts than "OK" and "Cancel"
- have the "Cancel" state returned to the script after user interaction instead of dropping out so that logic can be applied
If this occurred, a prompt could be displayed with the "Load" and "Unload" options and the script would be able to react to either case
-
@oozeBot For me, the script set I came up with worked as I mostly use the panel, or when in DWC I use the macro I made. I use the RRF system filament to get the basic settings established the loaded filament via start.g and then the slicer to fine-tune from there - mostly because of different manufactures of the same filament type need profile refinements made because different blends or such.
These are the latest files to look at:
https://github.com/rkolbi/RRF-machine-config-files/tree/master/Prusa MK3s -
@oozeBot said in Conditional GCode - Filaments?:
allow other prompts than "OK" and "Cancel"
1000% agree
-
@Kolbi I too have been toying with this concept lately but had a few slightly different ideas.
-
I am updating my duet laser filament sensor to include the microswitch. I think having the ability to detect static filament presence would be useful in the conditional code or just macros in general.
-
I would like to be able to select a specific filament from a list in the slicer and the slicer g-code would send the appropriate M701 such as M701 S"PLA_Blue"
-
Ideally we could start taking advantage of the Filament remaining tally to easily determine filament required versus remaining
-
-
@mitch That sounds good, #3 is interesting. How would you handle when switching filament spools back and forth work?
-
@Kolbi the system already keeps track of the "loaded filament" if you use the M701. So as long as you are using the system to change filament it should always know what you have. It seems to just be a simple CSV file. You would need a parameter to reset a spool. Like M701 S"PLA_Blue" xxxx, where x is the length in mm or maybe the weight in kg?
-
@mitch Yup, I use M701/2/3 to make the system aware of what filament type it has loaded. For awhile I was trying to access/parse the /sys/filaments.csv file via macro but it wasn't possible afaik. I do agree that with some firmware revisions to the M701/2/3 commands that it should be possible, and useful, but I don't think it is obtainable as of now - at least not with stand-alone configuration.
Once variables are enabled you could have the slicer's output write the required filament's weight to a variable, and then start.g could compare that with a weight-sensor's reading to give a go/no-go?
