Feature request: Controlling stepper motor with M106
-
@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.
-
So basically, you'll stop using it because developers (of a consumer product) don't want to code a function almost only for you.
So, when you want, say a new feature in Windows, i assume Bill's coding it for you ? Lucky guy!Won't even write about the "semantic" weirdness of using a fan output to control a motor, it has to be a lot more clean than this, else the firmware becomes a mess.
Solutions have been given to this exotic use-case: post-processor and arduino box are easy to try, especially the post-processor.
disclaimer :
i have absolutly no link with duet except i bought some boards over the past years
i also noticed the documentation is getting less easy to get into since duet3's introduction. but it has nothing to do with not implementing an exotic feature... -
@tpra Exactly yes! Customers are the most important assets for companies. Without them they are cease to exist. Even a single request from one customer is important no matter how small or complicated. Just asked my problem yesterday on klipper forum and they answered and provided a solution immediately rather than turned it down with some vague answers. Seems like open-source communities are always a win-win.
I dont wanted to say this but you might see this as a "semantic" as well probably. I am one of the moderators of a very large 3D Printer group on facebook and discord and most of us now dumping duet hardware just because of these type of responses from here recently.
I paid for this board more than 200USD. It is one or even maybe the most expensive MCU you can get for a 3d printer and I suppose it is normal to keep my expectations a little bit higher than other companies since it is not some cheap stuff coming from China.
Disclaimer: I am not affiliated with some Chinese companies or klipper if you wonder. But I am certain I wont buy anything from duet anymore.
-
No one has rejected the feature request. It needs to be considered, planned, and scheduled.
-
@astrn , FYI, the people here with moderator or administrator tags next to their names represent the official opinion of Duet3D. The rest of us are just customers like you.
-
I know they represent the official opinion and it is good. Maybe they will start listening more.
My customer opinion is duet should stop developing firmware development all together and only focus on hardware design, make it open-source and let the others write a firmware for it. There are already tons of duet3 copies from Chinese manufacturers. It did not take too long for them to copy it. Look at other boards from other manufacturers, they don't develop any firmware for their boards yet they work better and sells like hotcakes. I will gladly buy more original cards rather than Chinese clone stuff. But RRF sucks massively. My reason to switch to duet was it seemed better firmware support with easier customization and top notch board. But it seems I jumped in a bag with full of bugs.
It is so sad to see that great hardware has numerous bugs and issues, random resets for no reason with little to no documentation on sight to solve.
Until you consider and plan it, there is gonna be many people left the train already. Now I have a expensive 230 USD paper weight that cannot work properly with expansion boards because of CAN BUS fiasco for months. And please dont tell me to use beta firmware. I don't wanna deal with unstable stuff anymore.
-
@astrn Which Discord server and Facebook group would they be then?
