@dc42 Good timing as I just sat down to work on this a bit. It's happening when homing the machine. Our Z-axis is belt driven and uses two steppers with brakes. When homing X or Y (and Z is unhomed) the gantry is raised 5mm for protection. It was that move (G92 Z0 followed by G1 Z5 F6000) that would first energize the Z steppers, release the brakes, and begin moving it all at the same time. This was resulting in one of the two steppers missing steps which throws the gantry out of alignment until it was homed.

To correct this, I've just added M17 Z followed by G4 P500 prior to the first moves. This appears to be working well and will protect most cases outside of manually moving the machine before homing.

@mikeabuilder said in Add a trigger for a user gcode file after print header is read:

@t3p3tony has the gist of my objective. I think the initial implementation using daemon.g looks like this:

in start.g:
Set a variable called "stop_print = true"

In daemon.g:
Check the value of "stop_print". If true, abort the print, if not true, continue.

In the slicer, I put a line in the custom gcode for this printer type (PrusaSlicer has this capability, I assume others do too):
Set "stop_print = false"

With this setup, any slicer that does not incorporate the "stop_print =false" line will result in a print aborted within one second.

It will be possible for anyone to maliciously edit their gcode file, but I'm not worried about that user. I'm worried about the user that sliced for some other printer by accident.

Basically that will do what you seek.

A couple of things:

I think the variable will have to be global You will need to create the variable in config.g OR have code in start.g that creates or sets the variable as needed The daemon.g file runs every 10 seconds - unless there has been a recent change I am not aware of

Just FYI it is quite possible to run the same sliced code on different printers. It all depends on how much in the way of printer specific elements are included in the generated code. I use at different times Simplifi3D, Cura, Prusa or ideaMaker and generally I can run any of the sliced code on any of my printers.

Best of luck!

Frederick

@fcwilt thats why i've raised it

@t3p3tony Recent versions of DWC should use the paths defined by directories in the object model. So if there was a way to change the directories.gCodes value from RRF, DSF/DWC should use that instead of the default 0:/gcodes path.

For info, this is how my draft release looks like on GitHub after the automatic creation
bear_duet_config_release_01.jpg

@aerouta yep it is now part of firmware so if your slicer labels objects you can issue commands to cancel them individually:
https://duet3d.dozuki.com/Wiki/M486

There is a lightweight plugin you can install if you only want a simple 2D view of the bed:
https://forum.duet3d.com/topic/24762/object-cancel-plugin-1-0

Or the 3D gcode visualisation plugin distributed with DWC supports object cancelation directly

@dc42 from my side I don't have the requirement, I had only the idea. I was referring to https://forum.duet3d.com/topic/18830/m557-number-of-probe-points and they will probably be interested in increase. But @OBum_2020 used a Duet 2, so this may not be possible.

@aprz thanks it is on the wishlist but cant comment on how soon it will be implemented. in the mean time you can use the trigger system to command a pause when the switch senses filament out.
https://duet3d.dozuki.com/Wiki/M581#Section_M581_RepRapFirmware_3_01_and_later

Thanks @T3P3Tony and @mfs12.

@dc42 Not lie. I want to be able to adjust the offset Im observing in the thermistor readind between the place the thermistor is located and the real temperature in the hotend. My example saud 20 degrees, that was exagerated. The correction I want to do is exactly 7 degrees

@dc42 said in M557 Exclude centre of polar bed from mesh definition:

@cncmodeller that should already be taken care of by function IsReachable in file PolarKinematics.cpp. Any point that is less than the minimum radius from the centre (the first R parameter in the M669 command) should not be probed.

@dc42 Ahh ok that makes sense. I've been using min R as zero since I never change it from when I was tramming in the printer. I've now set it to 50mm all seems good.

Many thanks
Barry M

@gixxerfast said in (EDIT) Already supported in RRF - Mesh probing with Rel Ref Ind:

BTW: The -3 flag to the G30 will produce the same result just the other way around, adjusting the probe offset instead of the read height value ?

Yes, G30 S-1 will adjust the trigger height to match the current Z instead f the other way round.

Use the K parameter on the G30 and G29 commands to select which Z probe to use for each command.

@piet moved to firmware wishlist because I am not aware of a way to confirm if M291 has been acknowledged or timed out.

@taconite We can store variables on SD-card with RRF3.4.beta4. That's a big step ahead, compared to misusing the workplace-coordinate arrays.
See the echo command

@engikeneer said in Simulate file to extract heightmap correction?:

split up your sliced files into 5mm max segments and apply mesh comp as an extra 'C' axis etc for each head?

You're right, I haven't thought about the consequences, when they all have their own mini-Z: they don't need to know from each others Z-height! But the main problem stays the same...
I still need to extract z-height for every segment and rewrite it either as ABCD stepper command or use Hobby-servos. (remotely with pull-pull application)

Would be cool if it already came segmented from the slicer.

@jay_s_uk thanks - I'll give it a try and get back to you if needed!

@marcossf this is now implemented and will be in the next 3.4 beta release.

@o_lampe if you have a tool selected, then T-1 will run the tfree file for that tool. If no tool is selected, there is no tool to free so no tool change macros get run.

@deckingman you've misunderstood my idea.

Found the original (timestamp 2:35)
https://youtu.be/TQYYHrxIG90

See how the extruder motor is turning, despite not extruding?
The extruder motor turns even during G1 X5 Y5 E0 (E relative), to compensate the XY movement.

@cosmowave said in Filament Meter messurment?:

I think, the solution with a scale will be more accurate...

I'm not sure a weighing approach is fundamentally more accurate, but I think it's easier - I tend to have about eight spools 'on the go' at a time (currently PETG in black, clear, orange, white and PLA in black, grey, orange) and I'd need to make sure to keep track of which spool is loaded so the counters are decrementing the correct register. I'm sure other people have more part-spools.

The advantage of weighing is that you don't need to know everything that has happened previously, you just need to have the spool in current state and know the tare weight. I'm not sure if all manufacturers declare a spool weight - I buy without spools (from Das Filament) and know the weight of my spools (70g).

I keep intending to build a strain gauge element into the filament holder on my printer, to directly read teh filament available, but haven't got round to it yet...