Topics created by garethky

@chrishamm Thanks Chris!

@Veti Ahh, sure you could do that. I just put it in bed.g, you can run that from the GUI already via the calibration menu under G32 True Bed Leveling

I switched to a SanDisk Extreme 128GB card and that totally cleared up the issue. This is one that I use for recording 4K video.

The card I had before was a Kingston 16GB card I got with the Pi.

I'm happy that I figured out a way around this, but I'm surprised that the async/await programming constructs don't protect us from I/O flakiness!

The file is wrapped in a StreamWriter that should have a 4K buffer The whole call chain is async/await. Log writing doesn't have to complete before the next GCode instruction executes (at least from what I can read without debugging it).

I was going to suggest keeping a queue of logging data and writing it on a separate dedicated thread for I/O. But StreamWriter is basically that. (the only difference being that the log time can be captured without trying to lock the file)

So yeah, not sure how the code should change. But if you are having problems, get a FAST SD card.

@chrishamm awesome! I will make both PRs. I don't think its very complicated at all, and from what I read in the C code there wont be any side effects. It doesn't cause a memory leak or anything like that.

@garethky said in M572's D parameter doesn't process expressions:

@dc42 said in M572's D parameter doesn't process expressions:

M572

AHH! That makes sense, I was going to separately ask how that worked because I couldn't figure out the syntax for extruders:

; this doesn't work: M92 E{13.6 * 60}:{13.6 * 60}:{13.6 * 60}:{13.6 * 60}

I'm guessing it would be something more like this, which is more complicated to evaluate as currently no expression can do array assignment:

M92 E{[13.6 * 60, 13.6 * 60, 13.6 * 60, 13.6 * 60]}

I really hope that when variables happen we will be able to declare arrays. I think this is a good case for including that.

Your first example should work in standalone mode, but won't work in SBC mode. Your second example (or something like it) is what we plan for release 3.4.

This is really turning out to be the right answer. One of the benefits of using the work offsets is that they are one of the few things that can be stored with M500!

(I thought I could store things from the object model by exploiting M28/M29. But no expressions between those commands gets evaluated, so you can't store the result of an expression.)

So I explained above how to store things by writing gcode to a file you run on startup. But what if you want to store something in the work offsets during operation of the printer? You have a tool number, say 2, and you need to write a gcode expression with an axis letter, G10 L2 P5 Z.... How do you get that Z?

Well, you can write an if block to do that but that code is pretty long and you wouldn't want that cluttering up your all your macros. So I wrapped that up into macro itself so I can re-use it everywhere I need to store something. The trick is we don't have a way to pass variables into macros yet. So I just write the tool #, value to store and desired coordinate system index into coordinate system #9. Basically coordinate system #9 is now the stack for my program:

; copy_var.g ; ; this macro copies a variable from the temporary variable slot and stores it in the requested slot for the specified tool: ; ; How To use: ; ; G10 L2 P9 X{state.currentTool} Y{value_to_store} Z{target_coordinate_system_index} ; M98 P"/macros/scripts/copy_var.g" ; ; Inputs: ; ; move.axes[0].workplaceOffsets[8] - tool number to store the value for ; move.axes[1].workplaceOffsets[8] - the value to store ; move.axes[2].workplaceOffsets[8] - the coordinate system number to store it in if move.axes[0].workplaceOffsets[8] == 0 G10 L2 P{floor(move.axes[2].workplaceOffsets[8])} X{move.axes[1].workplaceOffsets[8]} elif move.axes[0].workplaceOffsets[8] == 1 G10 L2 P{floor(move.axes[2].workplaceOffsets[8])} Y{move.axes[1].workplaceOffsets[8]} elif move.axes[0].workplaceOffsets[8] == 2 G10 L2 P{floor(move.axes[2].workplaceOffsets[8])} Z{move.axes[1].workplaceOffsets[8]} elif move.axes[0].workplaceOffsets[8] == 3 G10 L2 P{floor(move.axes[2].workplaceOffsets[8])} C{move.axes[1].workplaceOffsets[8]} else abort ; if you pass -1 you call at the wrong time!

Now that is solved I can combine it with M500 and I give you per-tool baby stepping adjustment that persists between reboots:

call this in tfreeN.g

; save_babystep.g ; writes the baby stepping value into the work offset 7 and then stores it with M500 G10 L2 P9 X{state.currentTool} Y{move.axes[2].babystep} Z6 M98 P"/macros/scripts/copy_var.g" M500

and call this in tpostN.g

; restore_babystep.g ; restore the absolute babystepping value from its storage slot M290 R0 S{move.axes[state.currentTool].workplaceOffsets[5]}

Then call M501 at startup before you write any config values as described in the post above.

alt text

😸 🍻

I did a little investigating under RRF 3.1:

M28 cant be used to log the results of commands. Anything after M28 isn't executed, its just copied into the file on the SD card. So I looked at M929, under 3.1 it does not log any information, not even direct requests for a report like M408 or M411. So there I hope that in 3.2 we will be able to log info level events and maybe these will be included. Next step is to get on the beta firmware train...