Modbus Spindle Control

gloomyandy

@NineMile I'm also planning to be at SMRRF, probably on the Sunday.

dc42

@NineMile I've added new command M290.4 in 3.6-dev to support nonstandard transactions that conform only partially to the Modbus specification. See https://docs.duet3d.com/en/User_manual/Reference/Gcodes#m2604-raw-modbus-transaction. It's unlikely that I will have time to do any more work in this area before the 3.6.0 release.

gloomyandy

@NineMile I've merged and pushed David's changes to the stm32 repos. I don't currently have a modbus setup so have not been able to test either the old or new code.

audryhome

@dc42 I have a suggestion for making things much simpler and not further complicating RRF GCODE.

We basically need M3, M4 and M5 commands to handle the spindle at the GCODE level, plus M950 to init the corresponding io.

As far as I understand, these commands, handle a spindle created with M950, which, in turn make the assumption we drive the spindle by pwm through a given pin. Nothing is related to modbus nor serial link in M950. This command is somewhat complex, because you handle many different peripherals (led strip,PWM, servo, temp, etc), everything that can be handled by DUET standard io at the hardware level.

As you said, there is little chance that you can support each and every modbus motor/controller on the market, and this should be the case, I think the program memory should be filled by unused code.

On the other hand, a GCODE command not implemented in RRF will call a macro of the same name ( e.g. M1000.g)
We could use a M3.1 M4.1 M5.1 to handle the modbus specific, but this would not be standard and would need some post processing.

I suggest that RRF, for limited control codes (M3,M4,M5...), instead of handling what is defined by M950, just call corresponding macros when instructed by M950.

This way, M3,M4,M5 would be handled by the user, it's the user's responsibility to handle all the modbus specifics inside these macros.

Introduce a parameter M (0 or 1, default 0) in M950 that tells, for the corresponding spindle (R parameter), to call M3_R.g, M4_R.g, M5_R.g R being the spindle number. To avoid a race condition, M3,M4,M5 commands called from inside these macros should not be possible, either raise an error or just do nothing.

modbus complexity would then be handled by a macro.

you can extend this to other devices (fans, heater, leds,....) managed through serial, spi or I2C devices.

M3 P1 S1000 would call the macro M3_1.g with parameter S=1000 exactly like M98 P"M3_1.g" S1000.
M950 with the M1 and R1 would also call a macro M950_1.g that would init the serial link, maybe check the modbus status to make sure it will work.

You could expand this to all codes related to M950 for handling special cases not handled by DUET ios.

I think it would solve the issues I have seen on the forum, included mine without introducing specific GCODES.

dc42

@audryhome that may be a neat solution. We will consider it. Thanks!

NineMile

@audryhome I like this idea - however there's areas other than M3, M4 and M5 that can control the spindle currently. The ones I'm aware of are at least M568 (set tool parameters, which can control spindle speed if the tool is currently active), as well as Tool::Activate() and Tool::Standby() which are called internally during tool changes, M109 and it looks like via an LCD screen as well.

Not sure how well these areas fit into overriding the 'public facing' gcode commands

audryhome

@NineMile Nothing prevent M568 to be treated like M3...4.. 5, since the spindle number should be used the same way.

dc42

@audryhome @NineMile does anyone actually use M568 to control the spindle?

However, there is still a need to turn the spindle off and on during pause/resume. So perhaps it would be better to define one or more standard macros to control spindles and have them invoked by M3/4/5/568.

NineMile

@dc42 said in Modbus Spindle Control:

@audryhome @NineMile does anyone actually use M568 to control the spindle?

I do

I use it to vary the RPM set by M3 or M4 from daemon.g, to implement variable spindle speed. It adjusts the spindle RPM over a set period between a high and low point, to avoid potential resonance conditions between the tool and workpiece.

I would say M568 isn't an issue though - it could be overridden in the same manner as M3, M4 or M5.

This isn't as clear cut with Tool::Activate() and Tool::Standby() as it appears that they can be called outside of a GCodeBuffer context (see: MovementState::SelectTool / GCodes::SelectPrimaryTool)

@dc42 said in Modbus Spindle Control:

However, there is still a need to turn the spindle off and on during pause/resume. So perhaps it would be better to define one or more standard macros to control spindles and have them invoked by M3/4/5/568.

Yes, agree. I think named macros for start / stop / rpm would work well. I'd prefer spindle details to be passed by parameter rather than part of the macro filename though.

audryhome

@dc42 I don't plan to, I just need to calculate and adjust the rpm from a tick sensor on spindle start.
I use a biffy BLDC that transmit movement to an ER16 spindle through a set of GT2 pulleys.

NineMile

@dc42 Just wanted to confirm, someone on the RatRig discord has used M260.4 to communicate with a Huanyang HY02D223B which was one of those VFD's that looks like Modbus but implements its own command model.

We compiled control examples for daemon.g for the Shihlin SL3 VFD and the Huanyang HY02 on this gist if anyone is interested.