Need help with a macro
-
Er, so I just tried M25 which gives an M98 error message that that no file is being printed - that's fair enough. But M226 doesn't seem to work either. So running this as a stand alone macro….........
G1 X100 Y100 F2400; simulate a move
M226 ; initiate a pause
G1 Y300; move to rear
G1 R1 ; move back........stops at the Y300 position. Adding X0 and Y0 to the G1 R1 moves the head to the position X=0 and Y=0 not the original co-ordinates offset by the XY values which is how I read that it should work.
Is it that G1 R1 can't be used in a stand alone macro?
-
How would G1 R1 know where you wanted to move back to?
-
How would G1 R1 know where you wanted to move back to?
By reading the current position when the pause is initiated with M226. That's what I thought you said would happen when M226 is used. That's also why I started the macro with a move before the pause, (just in case that's what is needed to trigger reading of the current position).
Basically I'm trying to develop a sort of purge bucket mechanism but I don't want to use tpre, etc because it would only be applicable to certain prints - not every print. It may also be that I need to customise it for different filaments. The final thing will be embedded in the gcode file for any particular print, either by putting the commands directly into the file using a script, or by calling the macro from within the gcode file (if that is possible).
Eventually it'll will be a case of detecting when a tool change happens then retract, move away, unretract and extrude some more, retract again, move back to the origin, unretrcat and continue.
But for now I don't want to do a whole print every time I test it, because it'll take too long and time is short. I just want to develop the mechanism. Hence run it as a stand alone macro if that's possible. If it isn't just say so and I'll make a short test print that I can add the commands to it but it will be a tedious way of testing.
-
What I think you need is a gcode that copies the current coordinates to a restore point so that you can retrieve them later using a G1 R command. This is something I have considered implementing in the past.
-
What I think you need is a gcode that copies the current coordinates to a restore point so that you can retrieve them later using a G1 R command. This is something I have considered implementing in the past.
Sorry David, I'm really confused. Put it down to sleep deprivation but the wiki says this " (G1) R1 Return to the coordinates a print was previously paused at".
And you said earlier "You need M25 to pause the print, or M226 within the Gcode file itself. These commands also saves the coordinates that are picked up by the G1 R1 X0 Y0 command".
So isn't that the same thing as copying the coordinates to a restore point and retrieving them later using G1 R1?
I know I'm trying this by running a macro and not an actual print, but to my simple way of looking at things, a print file is a list of gcode commands that are run consecutively. A macro is also a list of gcode commands that are run consecutively. Both are run from the SD card. M226 embedded in macro doesn't generate any error message so I'd assume that it should work.
-
I would need to look at the code, but from memory, the pause mechanism only works when a file on the SD card is being printed. I think M25 does produce a message if it is invoked when no file is being printed, but perhaps M226 does not. And of course, pause.g and resume.g get executed when you pause and resume, which is perhaps not what you want.
Apart from the restore point used by G1 R1, there is a second one used by tool change, and you recover the coordinates using a G1 R2 command. So you might be able to do what you want by changing tool in the macro, then at the end of the macro use the G1 R2 command to restore position, and finally reselect the original tool. Of course the macro would need to know which tool to change back to. Or at the start of the macro you could select a different tool and immediately switch back, so as to save the coordinates.
HTH David
-
Hmmmmm. Thanks for that. I'll give the tool change thing a go but if not it sounds like it might be easier if I just create a dummy print file and play around with that. I should be able to unload the filament, allow cold extrude and use a cold bed just to get the head moving around and speed things up.
-
Update. Doing tool changes and using G1 R2 doesn't work in a stand alone macro either. Guess I'll have to do it the hard way…...
-
I've made a very simple "dummy" test. Basically it just selects a tool, moves the head to X50 Y50 lowers the bed 0.3mm, then moves the print head around a square perimeter of sides 150mm. Then it it repeats the Z, X and Y moves several times. There are no extruder moves, nor any heater or fan events but as far as the Duet is concerned, it's a print file that I can run.
So I then edited the file and inserted a tool change followed by a move, followed by a G1 R2 as follows:
…......print starts with T0 then a few XY moves then
G1 X50 Y50
G1 Z3.6 F21000.000
G1 F2400 ; new commands entered after this point in the file
T1 ; tool changed from T0 to T1
G1 X250 Y300; move to rear
G1 R2 ; move back
G1 X200 Y50 ; return to original file
.........continue printing.When I run this, after the X250 Y300 move, the head then moves to X200 Y50. i.e the G1 R2 doesn't seem to be acted on which I hoped would move the head to X50 Y50 (the XY coordinates before the tool change).
I also tried M226 to generate a pause followed by G1 R1 but that didn't work either. I wouldn't want to use this though as I guess all that would do would run pause.g which I don't want to happen in this instance.
I guess what I'll need to do is write a script that will read and store the last XY coordinates, do what I want to do, then move the head back to the previously stored coordinates. Unless anyone has any better ideas. I note that M114 will return the current position. Is there any way to utilise that?
-
G1 R2 won't do anything in firmware 1.19 and later, you need to use something like G1 R2 X0 Y0 Z0 because only axes that are mentioned will get restored.
-
G1 R2 won't do anything in firmware 1.19 and later, you need to use something like G1 R2 X0 Y0 Z0 because only axes that are mentioned will get restored.
Ahhhhhh. Yes that works. It also works in a "stand alone" macro. I was just using R2 thinking that X Y and Z were only needed if they had a non negative value as an offset from the origin (as per the documentation for R1 in the wiki). Thanks
-
G1 R2 won't do anything in firmware 1.19 and later, you need to use something like G1 R2 X0 Y0 Z0 because only axes that are mentioned will get restored.
Does this mean that the files pause and resume need to be changed after update to 1.19?
I must have missed that infoPaul
-
hey appjaws, yes its in the WHATS_NEW.md file on github
The behaviour of the R parameter in G1 commands has changed. Previously, G1 R1 with no additional parameters restored the head position for all axes to the values just prior to the last pause command, and G1 R2 with no additional parameters restored the head position for all axes to the values just prior to the last tool change. The behaviour now is that only axes that are mentioned in the G1 command have their values restored. So instead of using G1 R1 in resume.g to restore the head position, you must now use G1 R1 X0 Y0 Z0. As before, any non-zero axis parameters will be added to the saved position of that axis. This change has been made so that additional axes used as substitute X and Y axis are not automatically restored.
-
Thanks for the clarification
-
Bu**er. I missed that as well. Note to self - ALWAYS read the "Whats_new" and ALWAYS consider the implications on ALL existing files, not just config.g .
