Feature request: Controlling stepper motor with M106
-
Hi all,
I would like to use a regular air compressor for part cooling.
To accomplish that I will connect a stepper motor to a air regulator via shaft coupling.So I can control the air via air regulator by turning stepper motor via gcode. It is possible to use a post processing script to convert M106 command to axis command like M106 S125 to G0 A125 to move the stepper to that exact position.
Only downside is it will act as an axis rather than fan control on duet web control and I assume it cannot be moved or changed during printing. There is also post processing script involved on slicer software.
Is it possible to add additional subcommand(s) feature to M106 to specify an axis to control and move it rather than PWM control.
Example
M106 KA P1 ; set P1 to A axis to be controlled via M106
Then it can be controlled like this
M106 P1 S127 ; set A axis to 127mm
or
M106 S127So additional K subcommand can be used to define an axis as fan and it can be controlled via P subcommand between 0-255
Axis step, travel limitation and acceleration can be set via config.g as regular way with M92, M208 and M201.
Max travel can be limited to max value of 0 to 255 like regular PWM with M208 and step count can be determined for travel distance.
That will be very neat solution.
-
@astrn Wouldn't it be easier to do it with a servo? https://duet3d.dozuki.com/Wiki/Using_servos_and_controlling_unused_IO_pins
Edit: though I suppose it depends if you need to do more than 1 rotation.Ian
-
Fan control cannot control servos as far as I am aware if I am not mistaken. It is basically same thing. Also servos has angle limitation and usually very weak compared to stepper motors.
-
@astrn said in Feature request: Controlling stepper motor with M106:
Only downside is it will act as an axis rather than fan control on duet web control and I assume it cannot be moved or changed during printing.
If an axis stepper could not be moved during printing very little printing could be accomplished.
Are you using v3 firmware?
Perhaps you could setup a dummy fan to respond to the M106 commands and use daemon.g to check the value for the fan, via the object model, and issue the appropriate stepper commands.
Frederick
-
I am not that tech savvy to write a proper code :P. Besides it will cut a lot of hurdles and put less stress on CPU. It is also another great way to control steppers without any mumbo jumbo in between.
-
@astrn said in Feature request: Controlling stepper motor with M106:
I am not that tech savvy to write a proper code :P. Besides it will cut a lot of hurdles and put less stress on CPU. It is also another great way to control steppers without any mumbo jumbo in between.
I fear that there would not be enough demand to justify implementing that feature.
Time will tell.
What firmware are you using?
What values need to be sent to the stepper?
Is the a simple relation to the value you would use in M106?
Frederick
-
I dont think it is that complicated to implement this, at least for a programmer that knows what he/she is doing. Since it will just convert 0-255 PWM value to move the stepper to between 0-255 mm. Travel distance can be adjusted with simple e-step calibration. Sensorless homing or a simple endstop can be used to determine 0 position as with like other axis using. Instead of adjusting PWM speed it will just use it as a coordinate and transmit that value to stepper driver. What firmware I am using is irrevelant with my request since no RRF cannot do what I am asking already. I have duet 3 with latest RRF3.2.2. It is much more user friendly and I believe there will be tremendous demand since most of the people nowadays looking to cool the print as much fast as possible. Using a simple air compressor is super cheap option as well as beat the berdair not only by price but also performance vise. Only problem is controlling air pressure in real time.
-
Well I question if there will be great demand since the issue of cooling is more complicated than cooling as fast as possible.
But if you rather wait for your request to be implemented rather than doing it with the features available now then that is certainly your choice.
Good luck.
Frederick
-
@dc42
You think is this can be easily implementable? -
@astrn
as you already wrote it would require an endstop and a stepper needs more than one pin to control enable, direction and last not least speed.
A programmer would have to implement all these definitions, while it seems much easier to use the daemon.g. Although I haven't heard of it before, but it sounds like you'd have to put the same commands you use for post processing into a file and connect it to the fan port you want to use. -
@astrn I think your biggest problem, assuming it could ever be implemented, is not so much controlling a stepper motor instead of a fan, but rather that M106 commands that slicers insert into gcode files are in the form of a numerical representation of speed - usually interpretted as a PWM value. I'm assuming that what you going to need instead is to set the position of a valve. i.e. to turn a motor or actuator by a given amount and then stop, rather than rotate continuously.
So it's difficult to imagine how the firmware which reads M106 values and outputs PWM values, could be adapted to move a motor or actuator by a given amount and then stop, whilst also outputting continuous PWM values for the majority of users who use continuous rotation fans.
-
If you know a bit about programming, an arduino can easily read pwm from the fan output. Then servo control/power boards for arduino are pretty inexpensive.
Downside is if you have obsolutly nothing on hand, there's a cost to get started. -
@astrn Regardless of how easy this is to implement (and that is very subjective!), I fear this request is unlikely to gain much traction, as it complicates an already complicated subject, ie fan control, unless there is a huge outcry of support for it. We're also under pressure from users NOT to implement features that are... dare I say... frivolous.
If you don't want to use a gcode post-processor to convert M106 commands for a 'phantom' fan to axis movement, another option would be to connect something like an Arduino, with a connected stepper driver, to the fan output on the Duet to read the PWM value, then create a simple sketch to convert that to motor movement. Then it's entirely within your control.
Edit: @tpra beat me to it!
Ian
-
@astrn in the short term (until a decision about implementing such a scheme is made) I suggest you use a post processor to change the M106 Pnnn to G1 Annn F... commands. See how that works.
-
@astrn
Instead of re-writing M106 to control a stepper (which it was never intended to do), why don't you just use a DC motor to drive the pump?
There are many that allow pwm control, just as a fan does.Note the current may exceed the rating for your fan output.
You may have to use a heater output and flyback diode as described here.
https://duet3d.dozuki.com/Wiki/Connecting_and_configuring_fans#main -
@astrn said in Feature request: Controlling stepper motor with M106:
I dont think it is that complicated to implement this, at least for a programmer that knows what he/she is doing. Since it will just convert 0-255 PWM value to move the stepper to between 0-255 mm. Travel distance can be adjusted with simple e-step calibration. Sensorless homing or a simple endstop can be used to determine 0 position as with like other axis using. Instead of adjusting PWM speed it will just use it as a coordinate and transmit that value to stepper driver. What firmware I am using is irrevelant with my request since no RRF cannot do what I am asking already. I have duet 3 with latest RRF3.2.2. It is much more user friendly and I believe there will be tremendous demand since most of the people nowadays looking to cool the print as much fast as possible. Using a simple air compressor is super cheap option as well as beat the berdair not only by price but also performance vise. Only problem is controlling air pressure in real time.
Except that a stepper motor requires a constant stream of command to move to specific point.
Your slicer will only issue M106 when there is a change in fan speed.
So how do you determine how long to keep issuing those commands?
You could set a huge distance, but again what's the right amount?
What if there's a change before that huge amount?
Stepper movements are sequential. It will finish whatever you asked before the next move.
Your request in fact would require a huge amount of work just to use the incorrect type of motor for the job. -
@OwenD said in Feature request: Controlling stepper motor with M106:
@astrn said in Feature request: Controlling stepper motor with M106:
I dont think it is that complicated to implement this, at least for a programmer that knows what he/she is doing. Since it will just convert 0-255 PWM value to move the stepper to between 0-255 mm. Travel distance can be adjusted with simple e-step calibration. Sensorless homing or a simple endstop can be used to determine 0 position as with like other axis using. Instead of adjusting PWM speed it will just use it as a coordinate and transmit that value to stepper driver. What firmware I am using is irrevelant with my request since no RRF cannot do what I am asking already. I have duet 3 with latest RRF3.2.2. It is much more user friendly and I believe there will be tremendous demand since most of the people nowadays looking to cool the print as much fast as possible. Using a simple air compressor is super cheap option as well as beat the berdair not only by price but also performance vise. Only problem is controlling air pressure in real time.
Except that a stepper motor requires a constant stream of command to move to specific point.
Your slicer will only issue M106 when there is a change in fan speed.
So how do you determine how long to keep issuing those commands?
You could set a huge distance, but again what's the right amount?
What if there's a change before that huge amount?
Stepper movements are sequential. It will finish whatever you asked before the next move.
Your request in fact would require a huge amount of work just to use the incorrect type of motor for the job.I got the impression that the M106 value (range 0-255) corresponded to the position of the stepper motor.
So I can control the air via air regulator by turning stepper motor via gcode. It is possible to use a post processing script to convert M106 command to axis command like M106 S125 to G0 A125 to move the stepper to that exact position.
If that is the case it can be done in daemon.g using the object mode values - I think I haven't tried it yet.
Frederick
-
I do already have a PWM controlled air pump connected to one of fan outputs but it is not providing enough air for my printing speeds. I am usually printing with 1mm nozzle with speeds of 150mm/s or sometimes faster. I need super airflow which no PWM pump will provide or the available ones are crazy expensive.
What I suggested is no need to rewrite the whole M106 command set to make some crazy PWM to Pulse conversions. Just mapping or directing the exact same PWM fan value coming from M106 as an axis position to an defined axis so the motor will simply move that position. If PWM value is 127 the axis will move to 127mm and hold there until next M106 command. That is it.
So I can use only one air compressor to provide part cooling air to multiple printers with simple air regulator and stepper motor for each printer.
I tried to play with daemon and object model stuff to solve another problem recently but some of those objects not working (e.g. I cannot get z-probe value read or processed by a daemon.g and throws error) or reading properly so my only option is using gcode post script which limits the usage here. Daemon seems to be half baked bandaid that sometimes not working at all or has very little documentation to do something with it. I dont wanna wait for another couple of months to get it fixed.
Also I dont want to chase any arduino solution since I dont have knowledge to do such complicated programming. Using gcodes are much simpler. It is why I am suggesting as a customer to provide or even think some sort of solution that might be super helpful for others as well.
Anyway thanks for the input. Seems like it is way too complicated for you guys to implement that simple feature. I will switch to klipper and different brand of board from that point. I just learned that I can do this without any complicated stuff like how I imagined, just by mapping M106 value to an axis with a simple extended gcode command with klipper built-in tools. It seems duet or RRF wont provide any solution for my needs from this point anymore. After the CAN BUS communication fiasco I decided not to buy expansion boards and another several duet boards for my other printers. Now just switching and converting my existing printers to a different solution all together seems like a better option.
-
@astrn said in Feature request: Controlling stepper motor with M106:
Seems like it is way too complicated for you guys to implement that simple feature.
Not "way too complicated" more likely just "way too small number of customers wanting it".
And just FYI here is a simple example of using the daemon.g file to covert M106 command values to an axis position:
if move.axes[3].homed G90 G1 A{fans[0].requestedValue * 255}The above assumes axis 3 is the A axis and fan 0 is the fan used in the M106 command.
Frederick
-
Thank you fcwilt but simply lack of documentation on some important stuff, weird bugs, half baked features and turning down simple user requests or even not accepting problems with firmware CAN BUS problems after a long debate wont cut it for me any more. klipper community seems more active and responsive on these matters.
Duet 3 hardware itself is great but I am really sad to let it go just because of lackluster firmware and software.
Nowadays I am thinking duet should stop developing a firmware and software at all and only focus on open-source hardware design and let others to write a firmware for it. Since the majority of income for duet seems to be coming from hardware sales, not software.
I wish a good luck to all duet family with their future endeavors.
