Posts made by astrn

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.

@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.

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.

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.

@dc42
You think is this can be easily implementable?

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.

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.

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.

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 S127

So 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.

So, any news on this one? I would really like to see the status of heaters via gcode commands. @dc42

@dc42 I am a bit confused since the duet 3 pin out diagram description says this:

2-pin JST VH OUT_1 thru OUT_3: these are intended for extruder heaters or fans. Maximum recommended current 6A each. If you connect inductive loads to these outputs, you must use external flyback diodes.

Does heater outputs has flyback diodes built-in?. I am trying to control 24VDC contactor via out9 but it seems it draws too much power and thus resets the whole system. I am going to give it a try with heater outputs but I am not sure if there are flyback diodes on them.

I wonder if this one works now? I encountered a similar problem with S4 command on my triple motor Z axis bed.

Connected it and it works fine. Thanks!

Got it. I probably misunderstood the whole flyback diode concept wrong :). I will go ahead and try it. Thanks. Still learning

The contactor is actually going to power the heatbed SSR. I added the contactor as a safety measure if SSR gets break and start heating the bed as it is own. Duet 3 is supposed to turn on/off contactor when its printing only.

Sorry for my noob question but I am no electronics/electrical engineer. I checked the specs and it should be fine on the paper. What concerns me if there will be a sudden current spike that flyback diodes cannot handle (I dont know if flyback diodes has max current limit?) when contactor turns on/off. I cannot measure it since it happens too fast. I dont know if anyone tried a similar thing before.

I solved it. It was a simple low voltage/current issue of Rpi. Now I am powering it via seperate PSU rather than with duet 3. It works flawlessly.

Hi everyone.

I would like to know if its possible to control 110VAC / 24VDC (Coil voltage) contactor via duet 3 fan outputs (OUT7 thru OUT9 with flyback diodes). Does it damage the board during on/off sequence?

I measured the coil power draw and its around 6-8W total (About 0.3 amps) when its active.

This is the contactor that I would like to turn on/off.
https://www.automationdirect.com/adc/shopping/catalog/motor_controls/iec_contactors_-z-starters-z-overloads/fuji_contactors-z-_overloads/9_to_25_amp/sc-e05g-24vdc

Wow I cant even connect a single 24AWG 6inch cable that is literally connected to nothing, not even a ground. RPi lost its power once it triggers M80. When there are no cable present it works just fine. How sensitive are those GPIO pins? I am using RPi3 on my prusa with a fairly long amount cable connected to GPIO and its working fine.

Also I found the real issue here. Somehow when M80 is triggered it interferes with the custom python script I am using to control the power on/off behaviour and initiating it. I simply see no way how it interfaces itself with it. So its not power related but a scripting problem. I am using this script with different GPIO port numbers. https://www.hackster.io/glowascii/raspberry-pi-shutdown-restart-button-d5fd07

Is it possibly a bug present with M80 command and GPIO pins are interfacing somehow?

The most weird thing is it only initiates the script when a cable longer than a inch that is connected no nothing to any unused GPIO pins.

Ok update. I discovered the problem but not the definitive reason or solution so far. I am using unused 2 gpio pins (one is unused ground and the other is GPIO26 and set to pull_up) that is going to be connected to momentary push button on RPi4 to control a power off script. When its connected it must be drawing too much power since its a fairly long cable. I disconnected that cable to see if there is a problem and viola it solved the issue. Cable itself is not connected anything so far and checked it with multimeter if there is a short but its seems fine. Any thoughts?