@jens55 said in Food for thought.....:
My biggest worry when using an open source project ... will it be around in a year down the road. On the other hand, there is no guarantee that a closed source project will be around a month from now either.
With closed source, I must switch to another solution, sometimes without warning. With open source, I have the option to continue using it (by starting my own production or using clones).
@o_lampe I don’t have it, that’s why I posted. And it is not pop-up or ad blockers.
@jens55 said in Duet 6HC v1.02 burns by electric short circuit:
I do not know if a fast acting fuse will be fast enough but if you find out, I would be interested to hear about that. To my knowledge, the only way to protect the output MOSFETS is with operator brain power (which I admit has been an issue with me in the past)
In my previous life, I worked for one of the biggest electronics companies in the world. The design group had done some research on this and had huge experience library. So: Both fuses and chips die from overcurrent by burning. Chip lines are literally microscopic and much better heat insulated (related to their size) than any fuse. On short circuit situation, the chip is always way faster. Fuses are good in preventing fires: something downstream heats up which generally means resistance is getting lower which means even more current etc. Equipment protection against short circuits is totally different subject.
I’m sure there used to be a “mark forums read” function. I’d like to get it back. (Safari on iPhone)
what sort of machines do your customers use - in other words, what is your special case?
This is a pick and place machine. All I care is to get from one point to another as fast as possible, but smoothly. The catch is (if it is a catch) that the machine sizes vary. For this discussion, the main point is the Y axis. The gantry travels on a moving bar, which can be different length. Also, some customers have done modifications to their machines, and some (not necessarily paying customers) use my software on other machines, not sold by us. I'd like to support them as well. (An anecdote: My best customer, by far, didn't pay for his machine. But he paid back by far more value by improving my open source design.) So, one fixed value determined by us is unlikely enough.
I am not aware of S-curve acceleration being important in any of these applications.
On the other hand, I am very confident that some acceleration management is necessary. It doesn't have to be s-curve, but a constant value is not sufficient. (FYI, this is where I gave up on Duet and decided to wait for 3.5: a thread )
RRF provides a custom input shaping mode...
And apparently, this is where I will look next. As said, I rather use something that doesn't need extra hardware and setup effort. However, I do know I need a better control board. The Duet3, with its software features and powerful drivers is way above anything suitable that I've come across - and the support given on this forum is superb. I'd love to use it.
I know s-curve works (for this application) and would be a simple, cheap and sufficient solution (for this application) . There were some hints that RRF might get it one of these days, perhaps on 3.5, so I asked. Nothing more in it, I'm not arguing it is a necessary function for RFF or better. I also accept (with no hard feelings) that it is not beneficial to your main customer base and you consider input shaping being superior. You can't please everyone, and if this time I "lose", so be it.
@dc42 Fair enough. I totally get the motivation and it makes perfect business sense to focus on your primary target group (3D printers). For a given development effort, you probably sell 100 boards for printers to 1 board for robotics, cnc and other similar stuff. And still I suspect that most of these projects would be happy to spend effort in tuning their machines with accelerometers and such. Still, I was hopeful for 3.5, as I know s-curve is a "one bit" solution in my special case. Maybe I'll look again at input shaping and providing an accelerometer kit with really good instructions to my customers.
For a one off job, the solution @dc42 gave would work. You can even do it on your kitchen stove, if you have a good fume hood. A piece of aluminum (or iron, if induction) will help regulate the temperature. Do practice with a scrap board first!
@OwenD Not as it is currently implemented. My customers have a variety of machine implementations, and need a ready to run solution, not something that needs extra time, work, knowledge and equipment to get working.
(I’m about to give up my mostly done Marlin upgrade for the same reason. Marlin does not really allow a setup where some software runs a Marlin board, which is connected to different machines. Marlin wants end users to edit configuration files, recompile and reflash, if their machine is not exactly as the manufacturer supplied. RepRap doesn’t mind, the controller can set it up in startup as it likes.)
I know I'm asking a question that has been asked many times... But I would so much like to use Duet 3 on my machine: Can you give me any hints on S-curve implementation schedule?
Motivation: My product is not a 3-d printer, but a pick and place machine. S-curve is the only way I know to make a heavy machine to move fast and smooth. There is no such thing as too fast PnP machine, so when pushing to the limits, any mass on the gantry is eventually the limiting factor without S-curve.
@dc42 The non-helpful answer is “short”. The transition from smooth to clunky is not sharp and depends on speed and acceleration settings. My impression is that @deckingman is right: When the machine starts decelerating when it is still accelerating, the effect of the inertia of the gantry is amplified.
(I’ve run the same machine with a jerk controlled driver, and with that, the moves are always smooth. That is why I’m hopeful for the 3.5.)
@dc42 “you could either detect USB disconnection/reconnection in your C# program…” Yes, I was asking how to do that. It is possible but not trivial to get notification for this on a particular device. Further, it needs deeper knowledge of the actual driver providing the serial interface to the application, which I don’t have. So I asked if anyone might have this.
But my approach was wrong. I don’t have that info, but I don’t need it either: The right way to do it is to hook to the general device event and know that some device dis-/reconnected. That is enough, I can then look at the uptime or a variable to find out if it was the Duet.
@deckingman @deckingman I guess I need to do that, and wait until a beta of RRF 3.5 is released. @dc42 implies in this thread that 3.5 has s-curve acceleration.
@chrishamm M205 doesn't seem to do anything on single axis moves. ? Specifally, at 26000 speed, 2000 acceleration, starting from Y=0, "G0 Y10" shakes the table, "G0 Y100" doesn't. 20mm moves are still shaky, 40mm moves are not. 16x microstepping, interpolation on, 0.9 deg/step motor.
@chrishamm Thank you! So, I'm doing it basically right, setting speed by M203 and acceleration by M201. Why are my long single axis moves smooth but short moves are not?
I'm adapting Duet3 to a pick and place machine. the goal is to have minimize movement time. The limitation is that movements must be smooth: the parts are picked by a vacuum nozzle, so the grip is not particularly strong. Any shaking will cause the parts to move on the nozzle. I'm learning, so asking advice.
Currently I tune long moves by speed, acceleration and motor current, mostly by trial and error.
Q1: Is there a better method to find machine limits? The RepRap or other calculators don't seem to give results that reflect to real world. I'm not surprised, since I haven't found a calculator that takes moving mass inertia, yet still a method that maximizes results. I guess I'm looking for a more scientific method that tells me "with these motor parameters and that mass, the max result you can except is this, and you get that with these control parameters".
Today, although unlikely as fast as they could be, long moves are smooth. Short moves are not. I guess that is because the machine is still accelerating when it needs to start decelerating.
Q2: What parameter controls the acceleration changes?
Q3: Am I missing something useful M code entirely?
Thank you for your insight!
This might be a long shot, but...
I'm controlling a Duet 3 from my own C# program. I would like to get a notification on board disconnection or reset. Windows sees that, there is disconnect and reconnect sounds. I have so far found out, that the solution is very much device dependent. Does anybody have deep enough knowledge of the Duet USB implementation behaviour to give me pointers on how to do that?
If no: I suspect that Duet3D people did not write that themselves, but use a driver from the chip manufacturer or some other third party. I could dig deeper on this, if I would know better where to dig...
@jay_s_uk Seems you are right. No problem, I can do that.
As the subject line says. Last lines on my config.g are
M564 H0 ; allow moves before homing
M555 P6 ; ok message comes after command done
M118 P1 S"Duet 3 start"
After reset, M564 reports movement before homing is allowed. From web interface M555 says "Output mode: RepRapFirmware", and from USB, it says "Output mode: Marlin". After sending M555 P6 manually from USB, it says "Output mode: NanoDLP" as expected.
It still doesn't change it on the web interface. Is this as expected? Is M555 actually output channel specific? If so, is there a way to make it work for USB using a command in config.g?
Here is the full config.g:
; Configuration file for Duet3, LitePlacer hardware
; executed by the firmware on start-up
; General preferences
G90 ; send absolute coordinates...
M550 P"LitePlacer" ; set machine name
; Network
M551 P"" ; set password
M552 P192.168.86.206 S1 ; enable network at fixed address
M586 P0 S1 ; enable HTTP
M586 P1 S0 ; disable FTP
M586 P2 S0 ; disable Telnet
; Drives
M569 P0 S1 ; physical drive 0 goes forwards
M569 P1 S0 ; physical drive 1 goes backwards (Y)
M569 P2 S0 ; physical drive 2 goes forwards (Z)
M569 P4 S1 ; physical drive 4 goes forwards (A)
M584 X0 Y1 Z2 A4 ; set drive mapping ****** note A!! *******
M350 X16 Y16 Z16 A16 I1 ; 16x microstepping with interpolation
M92 X160.00 Y160.00 Z400.00 A420.00 ; set steps per mm
M566 X900.00 Y900.00 Z30000.00 A1200.00 ; set maximum instantaneous speed changes (jerk) (mm/min)
M203 X30000.00 Y24000.00 Z15000.00 A4500.00 ; set maximum speeds (mm/min)
M201 X2500.00 Y1500.00 Z1500.00 A250.00 ; set accelerations (mm/s^2)
M906 X800 Y1200 Z600 A400 I20 ; set motor currents (mA) and motor idle factor in per cent
M84 S10 ; Set idle timeout
; Axis Limits
M208 X0 Y0 Z0 S1 ; set axis minima
M208 X400 Y600 Z40 S0 ; set axis maxima
; Endstops (active low)
M574 X1 S1 p"!io0.in" ; X home
M574 Y1 S1 p"!io1.in" ; Y home
M574 Z1 S1 P"!io2.in" ; Z home
; M574 X2 S3 ; stall
; Z-Probe
M558 K1 P8 C"!io3.in" ; create z probe: To pin io3.in, fast switch, probe #1, inverted
; Heaters
; Fans
; Tools
M563 P0 S"Dummy" ; create a dummy tool and name it (for probing to work)
T0 ; select it
;
M453 ; CNC mode, make all g0 moves at max set speed
M950 P4 C"out4" ; output pin for down cam LED
M42 P4 S1 ; switch it on
M950 P5 C"out5" ; output pin for up cam LED
M42 P5 S1 ; switch it on
M950 P6 C"out6" ; output pin for testing
M42 P6 S0 ; switch it off
M950 P7 C"out7" ; output pin for pump
M42 P7 S0 ; pump off
M950 P8 C"out8" ; output pin for valve
M42 P8 S0 ; valve off
M564 H0 ; allow moves before homing
M555 P6 ; ok message comes after command done
M118 P1 S"Duet 3 start"
After the coming (close to) real-time coordinate display in 3.5, the only CNC related feature I miss is a soft stop: Stop the current move now (don’t wait for it to end), honor jerk and acceleration settings and keep motors powered (that is, don’t lose position).
Not knowing how the 3.5 position report works: A separate message after move command is done would be nice. The NanoDLP emulation workaround works, but can be clunky. A cleaner solution would be a status report style: when machine moves, send position during set intervals, with “accelerating, moving, decelerating” info, and a final “stopped” message immediately after stopping.
For my first printer, I went for low price. For my second and following printers, I went for reliability. (I use printers for work. I have other things to do than babysit a printer. I appreciate a fast printer, but if I really need more output, I buy more printers and/or plan better.)