@T3P3Tony said in Solder on the bottom of the Duet 3:

Its not an issue at all, the wave soldering that is used to solder the through hole components on the bottom of the board also sometime leaves some solder on the vias used to transfer the heat. We may mask them in the future but it does not effect the performance.

A few points on solder in thermal vias:

• It’s bad if the vias to suck in solder from the top side. This can cause bad joint to the thermal pad in the bottom, voiding the whole point of the thermal connection. This is the matter of designing the via pattern and solder paste pattern to minimize the possibility. Via size matters.

• If the board goes to a wave, it is good if the vias suck in solder from bottom. This much improves the thermal flow.

• You don’t want to cover the vias from bottom and leave top side uncovered. This creates pockets of air under the chip, possibly covered with solder paste or melted solder from the top. All kinds of funny effects (up to exploding chips) can result.

• You can tent the vias on both sides, but tented vias for thermal pads are tricky.

And folks at Duet3D know all this already. I’m just commenting out from my manufacturing experience why it is made the way it is, and why I think it is according good engineering practice, even though it might not always look pretty.

This would also make it simple to implement jogging. Button down, send movement command towards machine limit. Button up, send stop.

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

Macro parameters have been discussed a few times before, but are not implemented yet. In my application, these would be huge. And almost everything I can think of now could be done by simple text substitution:

M98 P"examplemacro.g 100 200 300"

In the macro file, substitute all <P1> 's with 100, all <P2> 's with 200 and all <P3> 's with 300. You get the idea.

For me the most useful, by far, would be something that I can set myself: Set object value to something, use the value later. I write the software that sends G code to my machine myself, so I’d be happy with something simple, like
“var1 = xx.xx” and later use “G0 X%var1%”.

Perhaps more generally useful would be a way to set a value from a get command or a previously set value. Examples:
varX = M114 X // set varX to current X position
BedT = M140 S? // set BedT value to whatever was previously set by M140 command

@Sethipus already shoved the cause, effect and solution. I build pick and place machines, and one of my prototypes had GT2 belt going around a smooth idler with teeth towards inside. My machine has a microscope looking at the work surface and software to measure position relative to a mark, so I could measure this. FYI, the effect is about 0.01 - 0.015mm max. I would predict that it is visible on a shiny surface, as beautifully demonstrated above.

@jay_s_uk Seems you are right. No problem, I can do that.

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

@dc42

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