@wieman01 The post above yours describes a way to do it.

@dc42 said in I think I would like a variation on M208:

@fcwilt https://docs.duet3d.com/User_manual/Reference/Gcodes#m599-define-keepout-zone.

Thank you.

Frederick

@Tech_Sam03 The autotune feature was removed as it hasn't been updated to include the M569.5 V and A parameters that were added with the RRF 3.5 release. Unfortunately we still haven't had time to work on this, and there is no timeline for this work at the moment.

Ian

@dc42 https://github.com/Duet3D/RepRapFirmware/issues/1097

jaysuk created this issue in Duet3D/RepRapFirmware open [FeatureRequest]: Add support for MFMT command in FTP implementation #1097

@droftarts Thank you I will look into this GitHub link. Hopefully the feature is implemented soon. In the meantime, I will try to add the functionality so I can learn more about RepRap firmware.

@rero said in Tool-change macros with parameters:

-> Maybe someone can add this information to https://docs.duet3d.com/User_manual/Tuning/Tool_changing ?

paging @droftarts

@T3P3Tony thank you 🙂

@Reine see my update here:
https://forum.duet3d.com/topic/35166/converting-datetime-to-string/10

@T3P3Tony It's is sort of round about, but it works reliably.

Just came across this old thread, and some of the thoughts in it are relevant to some work I am currently doing.

A few years ago when I was using a Marlin based IDEX machine with a fairly slow heating element I did write a gcode post processor that parsed the gcode and inserted pre-heat commands into the gcode stream approximately the right number of instructions ahead to take into account the likely execution time of the individual gcode instructions, plus the amount of heating time required based on approximate heat up rate, plus previous cool down rate.

I don't think the multiple motion systems enhancements really help with this so I am embarking on looking at preheating again based on a multiple motion systems/multiple idex/tool changer system I am working on:

Things that need to be considered are:

The faster heat up times of more modern extruders meaning timings need to be fairly accurate - or maybe they are fast enough to largely negate the benefits of preheating. Gcode queuing/multiple queues means that working out where in the gcode stream to place the preheat instructions is fairly complicated. Working out how long each move/extrude is actually going to take it quite tricky too given acceleration/slow downs both prior and after each instruction.

I guess ideally the slicer and firmware would handle this, but in the meantime
I'm thinking maybe some global variables indicating future preheat timings, and use of daemon.g might end up being part of the solution.

@dc42 Thank you very much, that looks perfect 😊

@timschneider I've logged this here: https://github.com/Duet3D/RepRapFirmware/issues/1074 But since you need to poll rr_reply for certain codes anyway, that solution probably isn't really applicable as a fix for your other problem.

chrishamm created this issue in Duet3D/RepRapFirmware open [FeatureRequest]: Add option to rr_connect request to prevent G-code replies from queuing up #1074

@SanderLPFRG the firmware is open source so you can do what you like. There is already some support for analog probes in the expansion board firmware because the scanning inductive Z probe is in effect an analog probe.

I have raised a feature request for the firmware part of this here:

https://github.com/Duet3D/RepRapFirmware/issues/1068

T3P3 created this issue in Duet3D/RepRapFirmware open Support BISS-C encoders #1068

@moth4017
yeah i agree, i think it's on the feature list for the future.
just out of interest, why do you call out to other macros?

@marzubus

I have been testing with the G60 command and have obtained good results.
Now I have the following problem:
With G60 I go back to a saved position and manage to go back, but when I run resume.g the printer returns to the coordinates where it paused and not at the G60 position.
I have checked both in the Gcode commands and in the Object model to see if there is any option to update the coordinates before executing resume.g but I have not found anything.

Any ideas or suggestions on this?

Thanks

@chrismbp thanks for your report.

We have the possibility of using separate input shaping for the Z axis in RRF 3.6 or later if it turns out to be useful.

@dc42 The use case is that it would be nice to know if I have messed up when I make a script change. The past several days have been challenging because I implemented a second "pebble wiper" for the tool changer and realized that the variable declarations were scattered and the naming was inconsistent. I now have a defGlobalConstants.g and defGlobalVars.g that is called by config.g and some tool unique code is being reduced using indexing.

While I have your ear, I wish there was a way to check the gcode for syntax errors without actually doing anything. I don't know if this is what "simulation" is meant to do; if it is, I need to read up on it. Having macros fail during prints is a very slow way to debug.