Topics created by JuKu

@o_lampe I don’t have it, that’s why I posted. And it is not pop-up or ad blockers.

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

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

@JuKu we may support a more fine-grained reporting of machine position in RRF 3.5 or 3.6.

Lots of cases on Thingiverse.

And, if you put 110 (or 220 if outside US) 'mains' in the same case with low voltage, be sure there is an internal, insulated, divider between High and Low voltage sections.

I plan to do something similar when I complete the work on conditional GCode.

Not really, but this is a minor point anyway, doesn't prohibit me from anything.

@dc42 Yes; something like that would be a nice enhancement for lots of odd, and not so odd, use cases.

@JuKu said in Cancel current movement, keep machine on:

Can we have something in between?

+1
Caveat: No experience of Duet CNC use, but I've read the rlevent bits of the docs and think this is another place to adopt some of the conventions set in the small cnc/engraver world.

You need three commands 'Hold, Resume, Reset' which should also be tied to IO pins (via Macros, or whatever).

Grbl's implementation is described here, this is very much a standard way of doing things in the CNC world where grbl's developers come from.

None of these depower the drivers, allowing positions to (mostly) be preserved.

The 'reset' is a soft reset, if the machine is in motion it assumes it might lose position and throws a (resettable!) warning. Hold does exactly what it says on the box, brings the machine to the fastest halt possible from current position while preserving status and movement queue. Resume is the opposite, also doubles as a 'start' button for jobs.

I strongly recommend reading the linked doc; it gives a good overview of what to be aiming for; even if the actual implementation is different (eg M commands, not grbl's escape commands, etc).

The simplest CNC pendents around just have three buttons. I use one:
tulip-buttons.jpg
Mine also has a terminal for probes; it's wired to the controller. The lump underneath is a Pi3 A+ with LaserWeb etc. which acts as a SBC for the system.

Disclaimer, this is not a Duet machine, it runs the crappy controller that came with my delta printer and grbl-mega. Actually a very good combo for the task at hand.

Perhaps we should add a parameter to M555 to specify which channel it should be applied to, so that it can be used in config.g.

Forgot to mention: This is on Duet 3 hardware.

Interesting, I didn't see the The following packages have been kept back: message. I ran the suggested code and it looks like the firmware is all up to date! Thanks for the support!!!