I use this code in my homez.g to run automatic tramming (three motor bed) and mesh levelling only if the machine has been off or been reset:

if move.calibration.numFactors = 0 ; no bed levelling run yet G32 M98 P"homing/unsafe-homez.g" G29 else M98 P"homing/unsafe-homez.g"

with unsafe-homez.g containing

G1 X{move.axes[0].max/2} Y{move.axes[1].max/2} F15000 ; move to homing position M558 H10 ; careful when homing G30 ; home precise with Z-probe M558 H3 ; back to speed

@Phaedrux said in Whats does the roadmap look like for variables?:

@deckingman said in Whats does the roadmap look like for variables?:

No I don't fancy the idea of running a beta firmware at this stage

While I understand the reluctance, wouldn't it be helpful to test the firmware before release to ensure the bugs are resolved rather than wait for the final release and discover there are the same or different bugs meaning having to wait again for another firmware release? Just sayin.

Up until a few months ago I used to do exactly that. But I've had my fingers burnt a few times in the past.

Classic example - earlier design versions of my hot end suffered a lot of stringing and I thought it was the complexity of the mixing chamber making retractions less effective. It turns out that the cause was the poor step pulse frequency. I had been using 64x micro-stepping (because that's what I used on Duet2) but RRF 3 did not report hiccups on expansion boards so I had no way of knowing about the firmware step pulse frequency issue. It was only when 3.1.1 came along that hiccups were reported and could see immediately that I was getting very high hiccup count during retractions. So I wasted a lot of time and effort re-designing my mixing chamber to reduce stringing when all I needed to do was reduce the micro-stepping from 64X to 16X to get around the firmware problem and restore proper retractions.

So if something strange or unexpected does happen with this hot end version, and I change the firmware as well, I can't be sure whether any problems would be related to the design or configuration of the hot end, rather than caused by a potential bug/change in behaviour of the firmware.

In a nutshell, I don't have a working hot end as a baseline against which I could evaluate any firmware changes. So any feedback I could give might be flawed due to some sort of mechanical issue with my experimental hot end.

The old adage "change only one thing at a time" is the only sensible way to develop something IMO.

@callielli said in G-Code to slow down printing at corners of objects.:

Is there an override somewhere I might be missing?

Some slicers can set the jerk value in the sliced gcode, so check your sliced gcode to see what's actually being executed.

You can also send M566 by itself in the gcode console during a print to see what the value is actually set to to check if it's been changed from what you have in config.g

There's also acceleration to consider.

@callielli said in G-Code to slow down printing at corners of objects.:

down to 12 mm/min from 100 mm/min in the config

Can you post your config file?

@Phaedrux For info, FTP also stands for Federal Test Procedure which define how vehicle emission tests are carried out (among other things). Back in the 80s, that caused no end of problems and confusion when software engineers and vehicle emission engineers got together and started to develop computer controlled test equipment. 🙂

@TypQxQ said in GCode to put heater in standby:

Is there a GCode to put the heater in standby from off without selecting the tool?

The usual procedure is (using tool 1 as an example):

T1 P0
T-1 P0

Perfect, thank you!

That isn't possible at present.

Thanks everyone. That was dumb on my part. I was looking for an F modifier and totally discounted the T parameter without reading what it said in the doc.

Topic tools, then ask as question, then topic tools again and mark as solved.

Yes exactly like that

Awesome - Thanks!

I'm still on 3.1.1 and I'm still having issues with the the M291 command. Here is the macro I'm trying to run:

; ToDo check Temp of bed and nozzle, so both are cold ; Cancel any currently active mesh compensation M561 ; Set z-probe trigger height to 0 G31 Z0 G1 X0 Y0 Z200 F6000 M291 P"Move to point were the z probe shall be calibrated." X1 Y1 S2 M291 P"Get a 0.1 mm thick metal spacer" S2 while iterations <= 5 G1 Z50 M291 P"Remove the z probe sensor if it is already or still attached" S2 G1 Z5 M291 P"Move FFF nozzle down until it just grabs a 0.1 mm thick metal spacer and then remove it." Z1 S2 G92 Z0.1 G1 Z50 M291 P"Attach the z probe" S2 G30 S-1 M291 P"Now calculate the average of the test. The average is the z probe trigger height for that point. Set it the config.g with G31 Z{ave} " S2

After I click OK from the first M291 in line 7 the machine just stays busy and the second window does not open.

When variables are added to the gcode meta commands you will be able to use the arduino to set user variables for those fields and then write a DWC plugin to display them.

If you wanted to do that before variables are implemented you could either:

hack a work around by using fields that exist in the object model (things like settings for an axis that you did not use and was hidden). write the file to the SD and and then have your display plugin read the file

Thanks all! Ill try it out.

After running multiples tests at a reasonnable speed (Feedrate : 15000 mm/min), I can tell that the motion is continuous between multiple G0/G1 commands!

By the way, I don't understand how the "T" parameter from the M670 works (when using the "P" parameter in a G1 command). I thought at first that is was the delay between the beginning of the movement and the beginning of the output being set to '1'. But when testing with multiple values for "T", the output was always set to '1' immediatly after the beginning of the G1 command.

Edit : The "T" parameter appears to be important when using the P1 parameter with a G1 command on a very short distance. Reduce the "T" value if you're looking to trigger an output to '1' on a short distance and high speed (30 mm and 15000 mm/min).

@dc42 OK. I'll give it a try.

In regards to running real-time loops in daemon.g, would it be possible to use a loop in daemon.g to call for a variable that can reduce the feedrate mid-print to 1% while a long single line segment is being printed? Ideally I would be able to pause mid deposition, but I know the current command needs to complete before a pause can be invoked.