VFD integration: M3, M4, M5 Macros and RPM measurement

  • I have just completed integration of a Duet 2 running RR3 into a small CNC with a low cost VFD/spindle.

    Apologies if this is a noob question, but is there a way to replace the behaviour of the M3, M4, M5 commands with macros: e.g. M3.g, M4.g, M5.g ?

    This would enable users to configure Duets to fully match the requirements of their VFD/spindle rather than working around the current assumptions embedded in the CNC mode of RRF3. For example:

    a) My VFD needs three pins to operate: analogue 0-10V, Run and Forward/Reverse whereas RRF3 assumes only two pins need to be controlled by M3: forward PWM, reverse PWM.

    b) after a speed setting has changed, the VFD needs time to spin up/down to the new speed (much like an extruder heating up).

    To address these points, I’ve set up pins to match my VFD and then edit the g-code to insert appropriate M42 commands plus G4 to dwell whilst the VFD spins up, but it strikes me that it would be much neater (and more extensible to cope with different VFD) if M3, M4, M5 could call related macros to fully configure the correct sequence of operations.

    A second question relates to spindle speed (RPM). With many VFD there is an output pin whose frequency is directly proportional to the spindle speed (e.g. one pulse per revolution). Is there a way to define a corresponding timer input on the Duet CPU to measure frequency as an RRF3 variable?

    In this way, one could use this variable to wait for the correct RPM to be reached or even close the loop around the spindle speed. This would be analogous to the temperature variable used for extruder/heated bed control.

    My guess is that with interesting developments such as combining additive 3D printing with subtractive machining (for precise finishing) in a single machine, the spindle is probably going to become a more common tool in machines controlled by Duets. In this case, farming out M3/M4/M5 configuration to macros that users can write and providing means to measure/control spindle RPM might be worthwhile?

  • As an addendum, having had more time to explore the depths of this forum I realise I’m playing catch-up and see that similar concepts were discussed during the genesis of CNC mode: e.g.


    Nonetheless, I’d still like to suggest M3/4/5 macros as, to my mind, controlling the VFD/spindle is machine specific and so is analogous to homing, where the RRF “g-code for everything philosophy”, as implemented through the home all.g and related macros, is simple and works to great effect.

    Whilst it’s also possible to implement the extra spindle machine specific commands by modifying each CAM post processor, this seems a backward step as otherwise the simple M3/4/5 are universal across different CAM applications.

    Anyway, just my ha’pennies worth...

  • Virtually every VFD has a forward/reverse, on/off and speed control. I am kinda baffled at the implementation of M3 and M4 -- it doesn't make sense, the configuration should be which pin turns on the VFD, where pwm goes, and which pin toggles direction. I have not found a VFD which has 2 analog inputs. Also, mach3 has a 10 second dwell after the M3 command, not sure why it's not baked into Duet either
    The problem with macros is there is no way to pass in the desired speed into a macro. At least no macro is capable of it.

  • administrators

    @kazolar, can you provide a link to the data on the I/O interface of the type of VFD that you have in mind?

  • @dc42 https://littlemachineshop.com/products/product_view.php?ProductID=4213

    This is pretty common config for Mill CNC -- on/off, forward/reverse and analog 10v speed.
    What would be ideal is M3, M4, M5 simply do what they do now AND execute M#.g -- then inside M3 I can issue and M42 command to turn the spindle on -- same for M4, and toggle direction if so required, and M5 would turn the spindle off.

    With Duet 3 larger capacity drivers to easily run nema 23 steppers -- it only made sense to not need a PC to run my mill, already have 2 windows PC running my other 2 CNCs... Getting rather silly now.
    CNC is going to be a bigger target, integration with a VFD is important.
    Looking at 2.2kw water cooled spindle -- most ubiquitous VFD is based on the huanyang -- there you have a common and forward/reverse + spindle speed control -- typically it's setup to only go forward although reverse is easily doable. You have a digital pin going into a relay that closes common - forward run or reverse run and an analog 0-10v speed control, so you see we're missing the digital on/of pins for forward/reverse interaction. My big CNC -- mach3 will also toggle the on/off pin to off if I send it M3 S0 or M4 S0, which is a nice to have, but we can live with M5 doing that only.

  • @cjm i just add some really simple code and my duet 3 will now execute a macro before m3 -- called m3-start.g then set the rpm then execute a macro m3-end.g, same for m4 and m5 -- so this way I can add some m42 commands to toggle some relays in m3 and m4 and m5 and G4 S10 for a proper dwell after the spindle rpm is set so that all of that is automated.

  • @kazolar do you have any more details on those and how you have everything wired up?

  • @kazolar
    Thank you, this is also what I ended up with.

    My post was just to suggest that it would all be much neater if M3 called M3.g and then we could put all this machine specific stuff in M3.g/M4.g/M5.g

  • @dc42
    This is a typical manual for an affordable VFD:

    Page 12 has the connection details, but the essence is this:

    a) Spindle speed is controlled by an analogue voltage, that can be derived from either a pot. on the front panel, or an external signal, depending upon the VFD setup. The voltage range is usually 0 to 10V, but sometimes can be set to 0 to 5V (0-20mA May also be an option). Typically a PWM to 0-10V converter is used to take the Duet M3 pin configured in the M453 command and generate the 0-10V Spindle voltage and this works fine for spindle speed control.

    b) Spindle On/Off is controlled by a RUN input, typically a single control line that is pulled high for On and left low for Off. This is not a logic level input, but rather must be pulled high to a reference voltage provided by the VFD. In my case, I use an Opto-isolator to do this driven from a Duet GPIO pin. An M42 command in a macro enables this pin.

    c) Spindle direction is controlled by a FWD/REVERSE control line of the same input type as the Run line. In my case, I use another Opto-isolator driven from another Duet pin and with another M42 macro to set the direction.

    d) Spindle speed feedback is available as a 0 to 10V pulse whose frequency is directly proportional to the speed of rotation (I believe it is 1 pulse per revolution). Ideally, it would be good to be able to use this to close the loop/calibrate the spindle speed vs PWM level and, perhaps more importantly, detect a fault condition e.g. the spindle has stalled or the spindle isn’t spinning for some reason (good to check before allowing the CNC to start to making cuts).

    Other VFD have serial data interfaces (I’ve seen RS485 on several) to control the spindle.

    There are other variants as well, for example instead of RUN and FWD/REV, some VFD have two separate FWD and REV control lines where taking either of them high turns the spindle on in the required direction (what happens if you take both high is not usually covered in the Chinglish manual!)

    With a few Opto-isolators and a PWM to analogue converter, the Duet boards easily have enough pins/capability to handle all these variants (apart from the RS485, although I suppose a RS485 transceiver chip could be used to convert the logic level RS232 with a GPIO Pin to set the direction) but the current Duet CNC control approach (PWM on either a forward or reverse pin) is not actually compatible with any of them.

    As a result, all of us CNCers end up writing macros to control our spindles via some custom interface hardware so you can see that being able to name these macros M3.g/M4.g/M5.g and have them called automatically by the associated G-codes would be much the neatest solution.

    Hope this is helpful.

  • @jay_s_uk I haven't done the wiring yet for the relay, that is trivial. I have the PWM port next to the 12v output on the duet 3 going to my 0-10v analog converter, I have a 5v 4 input relay board, 1 input will turn the spindle on of as appropriate, and the other input will toggle direction. It would be nice to get feedback back into the duet, but having the ability to toggle relays as appropriate is all I was after. Will also add relay toggle in my eStop trigger -- one of my main concerns is the lack of a proper eStop -- which I also added. Now just 2 minor code tweaks and i'm good to go.

  • You maybe able to use a current limit output on the drive as some sort of warning. I am not sure about the Chinese VFD’s, but I know all the big companies ones that I use (Schneider, Danfoss, WEG) have relay outputs to indicate they are in current limit. Provided you are not getting close to current limit while machining, if the spindle was to stall, you could use that to trigger a macro to shut down. This could also be for any other fault, output phase loss, under voltage etc.

    Once I have my new house built, I am going to build a CNC router with a 3-4kw 3 phase spindle and will probably use a Schneider VFD, which will be 4-20mA so will need to look for a frequency converter. I absolutely hate 0-10v or 0-20mA for two different reasons.


  • @samlogan87 if you're going to build a large CNC, with such powerful spindle, duet is not the platform for it. I have a 5'x3' CNC with a 2.2kw 220v water cooled spindle -- super rigid, cuts like a dream, runs mach3, i'd go linux cnc or mach4 route now. Duet web and panel due is not designed for CNC workflow, I am doing a small X2 mill conversion, it has 500w spindle, high torque, but max 2500 rpm, I've made some code changes to RRF3 to make hard limits work, and properly interface with the VFD in this mill, I think I'll get the ooznest web UI for the web interface and will work on the panel due firmware to customize it for CNC better. Duet is great for printers, for CNC, the hardware is great -- though if you go for a nema34 or something bigger you'll need an external driver anyway, the software is lacking.

  • @kazolar yeah I don’t think I will be using Duet either. I am going to be using servos on mine so it won’t integrate nicely. Will likely use linuxcnc.

  • administrators

    @kazolar said in VFD integration: M3, M4, M5 Macros and RPM measurement:

    though if you go for a nema34 or something bigger you'll need an external driver anyway

    Duet 3 can drive Nema 34 motors, as long as you are not looking for both high torque and high speed, which would need more than 32V. We're looking at supporting 48v power in future.

  • administrators

    @kazolar said in VFD integration: M3, M4, M5 Macros and RPM measurement:

    @dc42 https://littlemachineshop.com/products/product_view.php?ProductID=4213

    This is pretty common config for Mill CNC -- on/off, forward/reverse and analog 10v speed.

    Thanks. Unfortunately the datasheet doesn't specify what the inputs do or the signal levels, just how to connect it so some existing machines of aspecify types.

    @cjm said in VFD integration: M3, M4, M5 Macros and RPM measurement:

    This is a typical manual for an affordable VFD:

    Thanks, that's very informative. Look like you can configure it to use either separate FWD and REV inputs, or RUN and DIR. A board with 3 opto isolators, a comparator and a few passive components would be ideal for driving it.

    To both of you (any anyone else with experience in this areas): do you think it is sufficient to support configuring only on/off, fwd/rev and speed outputs, or are there some controllers that require separate run-forward and run-reverse inputs (as well as the speed output)?

    Doing all the work in macros isn't really an option until we can pass parameters to macros.

  • @dc42 hardware is sufficient, there are too many software changes that need to be made to make RRF on par with mach3 -- I've made some of them -- like a proper eStop trigger to honor hardware limits, and M3,4,5 macros, the web ui is totally not appropriate for a CNC, ooznest is better, but I want to see and be able to set the spindle speed, adjust it -- that's not in the stock UI. I'm running at 30v now, hardware is not the limiting factor. After I made my tweaks, I have the MUST have features for a CNC, I still need to bring in the webUI and then look at the firmware for the paneldue to show machine coordinates vs work coordinates, and spindle speed,etc.

  • administrators

    I am not looking to make RRF on a par with Mach3 in one go. It appears that the biggest limitation is the M3/M4/M5 handling, so I am looking to do that first.

    There is work planned (some already started) to make DWC and PanelDue more suitable for CNC applications.

  • @dc42 actually macros work perfectly fine for VFD - i have a macro executing right after the spindle speed is set-- also there is an assumption that for going forward or reverse there are 2 pwm pins, there are not, so added a check if the reversePwm isValid, then use it otherwise use the forward for reverse as well -- the macros simply toggle 2 relays -- that works super well -- I issue 2 M42 commands -- it's fine to set the rpm, toggle relays then do a G4 for whatever is reasonable. Which is similar to a dwell.

  • @dc42 CNC mode MUST honor hardware limits. That is a non-negotiable. I added code to support a trigger that trigger my custom eStop if a hardware limit is hit when not homing, that gets me the safety measures -- I also toggle the relay that would normally be closed for spindle on -- and that's perfect for eStop.

  • administrators

    You already have the option to have the endstop switches trigger emergency stop via triggers, so I see this as less urgent. There is a separate thread about whether emergency stop should require a full reset afterwards.

  • administrators

    My thinking at present is to change M452 to this:

    M452 C"port1+port2+port3" F10000

    • F is the PWM frequency, as now
    • port1 is the speed control (PWM) port
    • port2 if present is the on/off port
    • port3 if present is the reverse/not-forward port (if not present then reverse is not supported)

  • @dc42 there needs to be a way to stop movement when a machine hits hardware limits. There isn't in current firmware. Ask any CNC operator who uses a large CNC machine 1 meter and up, they never home it. It takes too long and serves no purpose the only zero that matters is the work coordinate zero. I honestly would not bother homing my mill either since all I care about are work coordinates too. I added limit switches to prevent a crash

  • @dc42 i think M452 like that would work -- add an option for dwell time (how much it should wait after m# command issued before proceeding to the next line -- spindle needs time to get to speed before cutting or stop cutting and be safe to handle), and you got it. reverse forward is handled like -- floating if forward, close means reverse.

  • administrators

    @kazolar said in VFD integration: M3, M4, M5 Macros and RPM measurement:

    @dc42 there needs to be a way to stop movement when a machine hits hardware limits. There isn't in current firmware.

    Yes there is. Surely you know about M581, https://duet3d.dozuki.com/Wiki/Gcode?#Section_M581_Configure_external_trigger ? Trigger 0 was specifically provided for this purpose.

  • 0 trigger requires you to reset the machine manually it should work the same way as the eStop on the web UI or the panelDue -- there is no option to do that presently -- I added that for me, and it works great - -

Log in to reply