XYZ movement within the firmware

jml

I'm making a custom g-code, M77, which will move the indicated extruder to a particular coordinate and do other stuff.

I see this function:
const char* GCodes::DoStraightMove(GCodeBuffer& gb, bool isCoordinated)

But it requires gb to be input into it. Is there another function where I can just input the X, Y, Z, etc. coordinates to make the active tool go where I want? Or is there a way to use the above function?

(I know I can probably do what I want to do using macros, but I want to do more complicated stuff later that can't be done with macros).

dc42

'gb' is the GCodeBuffer for the input channel that the current command was received from. It's needed so that DoStarightMove can pick up all the parameters for the G0 and G1 command. So you could make your own copy of that function and change that copy to use hard-coded parameters. Alternatively, look at how movement to bed probing coordinates is done, for example in GCodes.cpp just after the case label GCodeState::gridProbing1.

What is it that you want to do that can't be done using macros? Hard-coding coordinates is very much against the spirit of RepRapFirmware.

jml

Well I want each extruder to move to the same spot on the stage one after the other and for each extruder to do something while at that particular spot. I thought I would need to access the current tool offsets within the firmware.

But I was researching more and realize that when you make a tool active with T#, then the G1 command automatically takes into account the offset ... so my macro can just put T# between the same G1 X# Y# commands.

I also was not sure how to launch a custom macro on the paneldue on a custom page (not the macro page), but I think I can figure it out based on what is already done.

jml

The easiest thing for me would be to just send g-code from within the firmware. Currently g-code can be sent from the paneldue, DWC, Pronterface, etc. but can g-code be sent from within the firmware?

dc42

What would you want to trigger executing the GCode?

jml

How about this hypothetical situation:

In config.g, I put M85 X# Y# where M85 is a custom g-code which just stores/saves the X Y coordinates. Then later, I'd like to use M86 which moves the current tool to the coordinates that were save with M85.

It would be easy to create these custom M85 and M86 commands if there was a simple function I could use within the firmware to move the current tool to a given x y coordinate.

If this can work, maybe M85 can have P# as an option and the user can save multiple coordinates (P1 meaning "position 1" and P7 meaning "position 7"). Then M86 P# can be used for sending the active tool to particular locations if necessary. Not sure if many people would find this useful, but I would.

jml

I'm looking at the code for GCodeState::gridProbing1, and seems like I can experiment with moveBuffer to see if that can be used to create these M-codes.

wilriker

@jml said in XYZ movement within the firmware:

How about this hypothetical situation:

In config.g, I put M85 X# Y# where M85 is a custom g-code which just stores/saves the X Y coordinates. Then later, I'd like to use M86 which moves the current tool to the coordinates that were save with M85.

What about G60: Save current position to slot isn't that doing what you describe here? These could be restored using G1 Rnnn. Also to work around a need to home and actually move the axis to this spot you could explicitly set the current position with G92: Set Position before. Not sure if you need the latter in your use-case but just wanted to add it anyway.

jml

@wilriker For G92, it looks like it sets only the machine position, not the position of the tool - so it will offset all the tools and not just the tool whose offset I want to adjust.

Thanks for pointing out G60! It looks like it requires me to actually move the tool to the coordinate of interest, then to call G60. Ideally I wouldn't need to move the printer to save the position, but this is ok for now. And it looks like if I pause the print, then my 1st position will be overwritten.

wilriker

@jml said in XYZ movement within the firmware:

@wilriker For G92, it looks like it sets only the machine position, not the position of the tool - so it will offset all the tools and not just the tool whose offset I want to adjust.

I saw your other post meanwhile and yes for this specific case it would not work with G92 - unless you have G10 already set but that is a chicken-egg-problem.