Writing M29 to file

DonStauffer

Is there a way to write M29 to a file? Even with a filename, it just interprets it as the end of the current write.

Thanks!

DonStauffer

I was able to do it like this:

M560 P"/macros/Test2"
M29

But M560 says "Now deprecated." I wonder if there's a better way.

sinned6915

@donstauffer I started a similar thread to output the echo output to a file as well.

i'm hoping that one of us gets some traction.

gloomyandy

@donstauffer Might help if you explain what it is you are trying to do? I'm struggling to see why you would want to have an M29 in a gcode file that is stored on the Duet, but them I probably don't understand what it is you are doing.

DonStauffer

@gloomyandy Sure. I want to write a macro that writes a macro that writes a macro. As I said, I figured a deprecated way to do it, but I want to have a more durable solution.

My slicer controls fan by layer and speed by feature (perimeter, solid fill, infill, supports). I wanted to control both by both. So I could say, on layer 121, set fan and speed just for the solid fill, because it's the first layer going down on infill, so I want more fan and slower speed. So I was originally going to set up a bunch of "scenario" macros and use Simplify3D's post-processing {REPLACE...} to insert calls to those macros where the comments show those features begin.

My plan was to insert into the layer script commands that replaced the macros called for each feature, based on the specifics of the actual object I'm printing. I was going to just copy the appropriate macro and overwrite the one called by the feature, except looking at RepRap GCode, there didn't seem an easy way to do that. It looked easier to just add a level of indirection, and write out macros using M28/M29 to call the desired scenario's macro.

One thing led to another, and I have the system in place, but there's a macro that writes the macros, and some of those macros are the aforementioned ones that write the macros that call the scenario macros. So, like I said, I'm writing macros that write macros that write macros.

I'm pretty excited about the possibilities of this arrangement. It's basically finished. I can now use conditionals in the layer change script to prepare the desired scenario with just a subroutine call or two, and the scenario macros will get called each time that feature prepares to print, until I change the scenarios later in the print.

So in the layer change script, I can say "starting layer 121, for any solid fill, give me the fan and speed for solid fill on top of infill, whenever solid fill prints." Other features have independent settings. Then later, I can say "starting with layer 132, for any solid fill, give me the fan and speed for 'normal' solid fill, whenever solid fill prints, until further notice."

And if I want to change those fan and speed settings during a print, I can just edit the macro that is active for that scenario, and change it, and it will use those new settings the next time that feature prints, even if it's in the same layer!

DonStauffer

@gloomyandy To answer your presumed question:

"Yes. Quite insane. But it has its value."

dc42

@donstauffer, have you considered using a single macro, passing it parameters, and using conditional GCode in it to set the fan according to those parameters?

M560 is deprecated as a way to upload web files, but I have no plans to remove it. I'll remove the "deprecated" text.

DonStauffer

@dc42 Upgrading to 3.x is on my list. I didn't know it had calls with parameters. And thanks for the insight into the specifics about the command's "deprecation". It appears to be working nicely for my purposes right now.

Thanks! This is great stuff! I'm really enjoying it.

DonStauffer

@dc42 My testing indicates neither M559 nor M560 terminates from M29, but both terminate from .

For instance, running the following:

M559 P"/macros/Test"
M106 S0
M29

writes

M106 S0
M29

to the file, the same as using M560.

According to the documentation, only M560 should work that way. M559 should terminate from M29; it seems to be implied that M559 should not terminate from .

dc42

I think the documentation is wrong. M29 is for terminating a file upload started by M28.