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

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.

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

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

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

https://m.all3dp.com/2/best-free-cam-software/

A word about idlers (I didn’t quite see if the designs have this): Smooth idler on the tooth side of the belt will cause small but noticeable irregularities on the movement (on one of my prototypes, about 0.02mm).

Another thing to check: I have a high resolution camera in my system also. It was a surprise to me to find out how little force on the camera module caused significant change in the image position, which looked like backlash in the machine. Lesson: The camera cable needs to be fixed to the machine really solid, so that when machine moves and the cable bends, it doesn’t transfer any force to the camera itself.

I don’t have enough experience on Duet, but in general, the best way to kill the driver chip is to connect/disconnect the cable with motor power on. A broken cable or bad connector with intermittent connection equals to disconnection.

Would it be possible to add a command to write directly to the driver control registers for those who know what they are doing? (I would love to kill my chips in experimenting, my system has two more drivers than I really need! )

Thank you! Your development is impressive, and this post put even more confidence to your company. I'm so looking forward to RRF3.4!

In the meanwhile, you said about RFF3.3:
@dc42 said in RepRapFirmware road map Q1 2021:

Some other easy-to-implement features may be included.

May I ask for yet another stop command? (See M112):

"M113: Not Emergency Stop
Any moves in progress are immediately terminated, honoring de-acceleration parameters. No other effect; motors stay on, heaters stay active etc."

The use case is CNC style jogging using a push button: Button down sends a command to move towards machine limits, button up sends this command to stop the machine.

The same approach also gives clean jogging: Key down, send move command towards machine limits; key up, send stop current movement command.

This would also make jogging simple. Start a move to machine limit on button down, send immediate stop on button up.

@dc42 said in Joystick Interface:

@massynrt said in Joystick Interface:

What Gcode can be used, if possible, to keep on moving until some other gcode is send.

There isn't one at present.

If there would be a command for stop and maintain the position, we could send g code to move on button down and the stop command on button up.