I thought I'd share something that I've been working on for a while (since October ) and made public earlier today - MillenniumOS, which is an "Operations System" for RRF 3.5+.

There's further documentation for the system, and the operations it implements, on our (Millennium Machines) documentation site, and I made a video a while back (while developing it!) of how the system works in practice - I'll be making more of these now that the repository is public including example videos of each probing operation.

MillenniumOS is a combination of 3 things:

• A G-Code dialect
• An RRF addon consisting of a set of custom G- and M- codes and system macros (tool change, pause, resume etc) that implement the gcode dialect and
• Post-processors for Fusion360 and FreeCAD (Realthunder branch until FreeCAD releases a version packaging Python 3.11)

This addon implements a bunch of CNC features designed to allow novice operators to approach their first cuts more safely and in a guided fashion, including:

• Guided workpiece probing (Bore - shown above, Boss, Rectangle Block, Rectangle Pocket, Outside Corner, Vise Corner, Single Surface) using both a touch probe and manually with a datum tool. Includes touch probe deflection and radius compensation as well as datum tool radius compensation.
• Protected moves when using a touchprobe so during travel moves, the machine will stop if an unexpected collision was detected.
• Workpiece rotation calculation on certain probe cycle types which will be used in future to apply G68 transformations.
• Tool changes with tool length compensation using a toolsetter, or re-triggering a z-probe on the workpiece if no toolsetter is enabled.
• Parking in Z and optionally X/Y for easy access to the table.
• Pause and resume with spindle control and delay.
• Variable Spindle Speed Control, which adjusts the spindle RPM up and down within a range to avoid resonance between the tool and workpiece.
• Configuration is handled using a Wizard process that runs on first-install, guiding operators through the process using RRF dialogs. Includes a guided procedure to measure touch probe deflection.
• Probing cycles gather information required using RRF dialogs as well.

The base design choice of this system is that all complex functionality is implemented as RRF meta gcode - there are some great post-processors for RRF but these all seem to take the approach of implementing rather complex functionality in the post-processor itself, rather than doing this directly in meta gcode.

One of the benefits of taking the MillenniumOS approach is that the post-processors are relatively simple, and implementing wider post-processor support to target this gcode dialect is much quicker than re-implementing all of the functionality in a new post-processor to support a different CAM package.

One thing I wanted to do with this was to make manual probing easier / safer. Not everyone has a toolsetter and touch probe, but the maths to calculate probing points and origins is the same whether using a touch probe or not - so MillenniumOS can guide the operator through manual probing in exactly the same way it would use a touch probe.

The probing macro is actually the same, but runs different underlying macros to trigger either a touch probe move or a M291-dialog-driven manual move. This avoids the RRF jog window as much as possible as I've found it too easy to hit the wrong button - the manual probing will only ever move directly towards or away from the surface that needs to be probed - it won't accidentally move up or down, or along the wrong axis.

You can see an example of how the probing cycles are the same between touch probe and manual probing in this video, and one of the early testers made a video of running through the installation and machining using the MillenniumOS post-processors and macros here!

This addon is designed to work with our (Millennium Machines) open-design desktop CNC mill, the Milo, but it should work with any machine that has the axes configured in the same direction (i.e. Moving tables with Y max when the table is at the front, X max when the table is at the left, and Z min when the spindle is at its' lowest point). I'd be interested to hear from anyone who decides to try and use this on a machine that isn't the Milo.

On machines that don't have the axes in the right direction (X and Y only, Z minimum must be the lowest spindle position), then certain settings like corner names or surface names will need to be changed as these would be back to front depending on which directions your axes move.

I've found while developing this that I have been pushing the capabilities of RRF and some of the boards we've been testing on (specifically the stm32f407) so this has been a really fun project and a bunch of the Duet and Teamgloomy guys have been a great help in tracking down a bunch of issues, so if you guys are reading this thank you so much for your help - this is why I was coming up with all sorts of random questions and issues and everything else.

My goal has been to reduce the learning curve for those just getting started with machining and hopefully what I've developed here helps with that - this is only a first public release and I'm hoping I'll be able to continue working on this more in future!

Just wanted to update to say I've been using daemon.g to control my VFD over modbus for a while now and it feels like it's working well. The error messages not being suppressed when writing to a variable is a bit of a pain but aside from that, it feels like a relatively robust way to do it.

For clarity, I still have the spindle configured to use enable / direction / PWM pins but these are not connected. I read the spindle state in daemon.g and send the relevant Modbus requests to start it and control the speed.

I've had a 2 second comms timeout set on the VFD so if there's no Modbus status check within 2 seconds the VFD will stop automatically.

There's a lot of functionality I could add to this to e-stop / pause / whatever if the VFD reports the spindle stopped or at high load or is completely unresponsive, but for the moment I'm pretty happy with the behaviour.

One of the features that I think would make RRF meta gcode more obviously powerful is an inbuilt way to return values from macros back to where they're called.

At the moment this is possible using global variables, but requires writing handler code into every calling and called macro to handle those global vars, and if you don't use the same variable name(s) across all macros you can end up polluting the global namespace quite quickly (with the associated memory implications).

I had a quick look this morning to see whether it would be possible to extend the M99 call so that it can pass values back to the caller, similar to how acknowledging an M291 dialog can put values back into the input variable, and I ended up with something that works like this:

G901.g:

; Run child macro
G902
echo { "Returned Value: " ^ retval }

G902.g:

var testval = 902
while { iterations < 5 }
    set var.testval = var.testval + iterations

M99 R{ "Test", var.testval }

M98 P"G901.g" prints the output Returned Value: {Test,912}.

Is this something that has legs to be added to RRF itself?

Has this been thought about already and rejected for reasons I'm unaware of? Would be grateful to hear any input on this front

I'm using a particular tool number (T49) to identify a touch probe (for CNC purposes). Part of the tool change process (in tpre.g) is to detect the touch probe is plugged into the machine (because a lot of Aliexpress touch probes are normally open, it makes sense to confirm the touch probe is plugged in before potentially ramming it into the machine).

I have a macro that looks for a status change on the touch probe in tpre.g, and runs abort {} when the touch probe is not detected. This successfully exits out of tpre.g but tpost.g is still executed, and the tool number is still successfully changed to T49. I've tried using M99 instead (same behaviour as abort {}) and running T-1 P0 inside the tool change macros themselves, but it doesn't seem possible right now to fully abort a tool change.

I think it would be a useful safety feature, particularly for CNC purposes, to allow tool changes to be aborted - that way it would allow the currently selected tool number to act as a 'guard' - for example macros that need a touch probe check if the current tool number is the probe tool, and exit if not. In the current situation, the tool number is changed regardless of whether the tpre.g or tpost.g were aborted or not.

E: I should probably add, this is likely safe inside a running gcode file because the abort{} will successfully cancel the "print" - but it still leaves T49 active even after the print is finished.

@gloomyandy said in MQL System with Diesel Heater Pump:

@NineMile Have you tried doing 1-5Hz just using M950?

I have a basic implementation of this now that uses M950 for anything equal to or over 1Hz, and then for anything lower I use daemon.g to run the on/off cycle, which seems to work nicely.

Implemented limit checks and machine position calculation so the moves work properly, this is how it works in practice: video

I'm using G38.x functionality to implement protected moves with a touch probe - the configuration of the probe itself is outside the scope of the macros I'm writing (the intention is for the macro "pack" to be usable on any RRF configuration in CNC mode) - so I'm picking up the probe speeds from the configuration of the probe itself (e.g. M558 K2 F{300,60} T1200).

Unfortunately, it seems like the G38 probe commands always pick the slowest speed configured, which means I have to override the speed on the probe using M558 to the travel speed, for example, and then reset it after the protected move (storing the relevant speeds in variables).

This however leaves an issue if the move aborts (due to colliding with something and triggering the probe, or if the probe isn't triggered during a probing move), because that leaves the probe speed settings inconsistent with what the user originally configured.

It would be good if the G38 probe commands could either take a feed override that does not require changing the underlying probe configuration, or an index parameter that specifies to use the rough, fine or travel speed for the relevant move.

I don't think this can be fixed by using machine speed limits either because if the fine probing speed is lower than the machine limit then that will still be the default for the probe.

@chrishamm A feature I've had in MillenniumOS (probing macro package for RRF, for use with touch probes on CNC machines) is protected moves.

The concept is pretty simple, rather than using G1 to move to calculated positions around the workpiece, every travel move is actually a probing move (using G38.3) as well - so if the touch probe hits something unexpected, like a clamp or vise then the move will stop instantly and mostly avoid any damage.

However - we still use the DWC MovementPanel and Dialog Boxes for jogging to the probe starting location, which leaves a big 'unprotected' gap as these features only ever send a G1 command.

I actually damaged my first probe by missing a Y- jog button and hitting the Z-25 button instead.

I'd like to implement protected movements in DWC when in CNC mode, and I think this would take either 1 or 2 settings - a probe ID selector to pick the probe to watch during moves, and potentially a toggle to enable or disable protected moves (this could be done as 1 input where the probe ID is set to -1 if protected moves are disabled).

Given that touch probes can be installed / removed, I think it's necessary to have the option to enable / disable protected moves via the movement panel and / or jog buttons in the dialog window directly, rather than it being in the machine settings page or something like that.

I'm happy to implement this and submit it as a PR, but I'd like to know if:

1. Would this be something you'd likely accept as a new feature to DWC?
2. Do you have any particular feelings about where these settings should go, or any thoughts on how this behaviour should function?

cc @jay_s_uk

@droftarts Thanks, I'll put in a feature request.

For what it's worth I think I'll modify a local build and see if the pin switching thing will be an issue in my particular use-case, but I suspect the timing is not an issue - if both forward and reverse are active then the spindle won't turn but it does not put the VFD into a fault state, and as soon as one of the directions are deactivated then the spindle will start spinning in the direction that is still active (and will decelerate to a stop before changing direction).

ETA: Confirmed, on my VFD at least there is no timing concern if the pins are not switched at the same time / there is no set delay - the spindle will just stop if both are active at once.

Noticed that the F parameter is already defined on G38.x commands to set the feed rate, but it wasn't implemented in RRF.

I've made the relevant changes here against 3.6-dev.

@dc42 I've been looking at implementing this and I have the J2 functionality working as described - however this also means that a J2 message box that times out will also return -1 (as well as if the user clicks Cancel).

I think this is the right behaviour, as in both cases it essentially means 'user did not supply a valid input', but I'd like to confirm that this is what you'd expect to happen as well.

I've tested on my stm32 based board and it works well - I have a Mini 5+ here that I'll test on once I get the build repo working. Happy to submit a PR for this if you'd like to look at the approach I've taken and verify I'm on the right track

@chrishamm Gotcha. Thanks for the info

@chrishamm Just noticed your next branch update in the DWC source

I don't think this warrants a separate topic so I thought I'd ask here - it looks like there's some significant changes to next that I haven't really grokked yet - is the plan for it to support existing plugins?

I ask because I have some plugin plans, and it would be pointless if I were to start now with the current plugin system only to find out that these need to be rewritten to work with next. Interested to hear about your plans for next if you're willing / able to share them?

Just wanted to update to say I've been using daemon.g to control my VFD over modbus for a while now and it feels like it's working well. The error messages not being suppressed when writing to a variable is a bit of a pain but aside from that, it feels like a relatively robust way to do it.

For clarity, I still have the spindle configured to use enable / direction / PWM pins but these are not connected. I read the spindle state in daemon.g and send the relevant Modbus requests to start it and control the speed.

I've had a 2 second comms timeout set on the VFD so if there's no Modbus status check within 2 seconds the VFD will stop automatically.

There's a lot of functionality I could add to this to e-stop / pause / whatever if the VFD reports the spindle stopped or at high load or is completely unresponsive, but for the moment I'm pretty happy with the behaviour.

@gloomyandy said in MQL System with Diesel Heater Pump:

@NineMile Have you tried doing 1-5Hz just using M950?

I have a basic implementation of this now that uses M950 for anything equal to or over 1Hz, and then for anything lower I use daemon.g to run the on/off cycle, which seems to work nicely.

Implemented limit checks and machine position calculation so the moves work properly, this is how it works in practice: video

@gloomyandy As mentioned, this is intended for use with a '3D' CNC Touch Probe, they can indeed detect contact in 3 axes. Generally the ones in use on the Milo and other CNCs look something like this internally:

These are installed in place of the cutting tool so generally don't have an X/Y offset.

When trying to probe a workpiece, the usual workflow is to position the probe near to the feature to be probed - either inside a pocket, over a corner, inside a hole or centrally over a rectangular block.

The probe tips and mechanics are incredibly sensitive, and overtravel of a few millimeters will easily damage the probe tip or the internals.

The idea behind the protection is to make sure the probe status is watched while the user is moving the probe around (manually) to position it near the relevant feature.

Accidentally jogging in the wrong direction might cause the probe to make contact with an unintended surface and when protected, that would cause the move to stop rather than continue to the target position and damage the probe.

@o_lampe said in Protected Moves with a Touch Probe:

For people not having that touchprobe thing, would it help to use modified "sensorless homing" moves as crash protection?
You'd check for contact , but don't set coords to whatever your homing coodrs are

That'd be interesting. There's a P10 probe type which means use Z motor stall detection as the Z probe trigger, so in theory that could be used with the same straight probes that I use to implement touch probe collision prevention, but whether or not that works for non-Z axes is an important question - there's no way to configure axis on the probe itself, but I wonder if running G38.2 K<z-stall-detection-probe> X<target> automatically switches to monitoring the X axis stall sensor?

If it was possible to configure the command used for movement sent by DWC then that would make everything easier but that opens a large can of worms and possible screwups.

Whether or not motor stalling will stop you from damaging anything though is another question. The Z axis on my CNC happily snapped my touch probe tip clean off before the motor even stalled, so depends on your axis power I guess.

I started looking at the touch probe move protection yesterday, adding a button to the CNC movement panel to allow the protection to be configured / unconfigured:

Doing this reminded me why protected moves was a pain to implement in the first place - G38.2 moves do not respect machine limits, and they appear to always run in absolute co-ordinates (although the docs say that was fixed in v3.11? ) - so there needs to be some validation of the current machine position and generation of the target absolute co-ordinate rather than being able to just send a static gcode like the current buttons do.

This means I'd need to refactor the way the button gcode is generated slightly - not a particular issue, but might make it a little more complex than I remembered

Gonna keep working on it and see what it looks like when fully implemented.

@oliof said in Protected Moves with a Touch Probe:

@NineMile an alternative would be to build your own UI with btncmd plugin

My end goal is to complete a DWC plugin (currently in progress) that acts as the user interface for the MillenniumOS probing macros (pre this plugin, the "interface" was driven by M291 dialogs) - adding protected jogging is a feature that I would add to this plugin in lieu of any other option.

I think protected jogging is a generic enough feature for CNC owners that integrating it into the CNC movement panel is the best approach, and while I think BtnCmd is great, I also think it would be great for the "default" UI to cater to more advanced CNC use cases.

@chrishamm said in Protected Moves with a Touch Probe:

@NineMile I'm sorry but my CNC machine isn't operational at the moment so I cannot really check your PR. Perhaps @Sindarius can comment on this, he developed the CNC frontend, too.

I've got a touch probe as well but it will take some more time before I have it working.

That's no issue I haven't written the code (for DWC) yet - currently my protected move code is only in RRF macros.

I'm talking here about a proposed addition to DWC, completely separate to my existing macro code, that would switch the gcode sent from the movement panel and movement dialogs so that if the user selects to protect their moves with a particular probe, the jog buttons would use G38.3 with the configured probe ID instead.

I was curious if you have any input on this before I write the code.

On the testing front, there's a ton of Milo CNC owners using DWC with touch probes who I think would be more than happy to test the changes if that would help.