Advanced Search

grandixximo wrote:

For example YangYang is now looking at stopping to destination with vel0 acc0 jerk0 all at the same time at the ends of an arc segment, in the servo-thread we compute next position forward in time, they keep adding up, and this leads to numerical errors, which make the jerk overshoot near the final destination, then you have to clamp down the error smoothly to arrive at destination, within current architecture you have to overshoot, you have to readjust, he has tried multiple avenues to fix this, nothing so far has worked.
How commercial TP fix this? they don't plan forward, they plan from destination backwards at each time increment with dedicated hardware, and deal with feed override changes by re-planning to a different time destination.
You can probably understand how different LinuxCNC is from commercial controllers, they practically work in the complete opposite way...
Many of the issues we are faced with, have similar kind of solutions in the commercial space, they just don't do it how LinuxCNC does it.
When I wrote "we are limited to what we can do", I intended it in the scope of implementing jerk limiting within the current TP, with tangential jerk limiting code that is being enabled with planner_type 1, and some blending and look-ahead improvements, to try and stick to jerk limited motion, without introducing any non-realtime code in servo-thread, sure a complete rewrite you can do whatever, but that is not something you do overnight. And we are also limited by physics, you can't have high-speed accuracy smoothness all at the same time, physics just don't allow this. I understand most here would sacrifice speed, but there is a camp that would like to squeeze out a bit more speed if possible sacrificing some accuracy within what's allowed by the gcode.




 

You'll need to change the TP. I'm not offering a $3000 cnc as a bounty for something you can vibe code overnight

Speaking of, a little bird told me that someone with the skills should request tormachs latest source....

DO IT NOW!

Hi Hakan,

If LinuxCNC always receives the position feedback ~2 servo cycles late, can I simply “ignore” this by increasing the following-error limits (FERROR / MIN_FERROR), or does this latency actually affect the LinuxCNC motion planner/trajectory execution?

In other words:
Does LinuxCNC only use the feedback for monitoring/fault detection (so the part accuracy is still fine as long as the drive itself tracks well and has near-zero internal following error)?

Or does LinuxCNC actively “react” to the delayed feedback (e.g. by slowing down, modifying the commanded motion, degrading contour accuracy), meaning I cannot machine precise parts even if the servo drive is perfectly tuned?

So the decisive question for me is:
Can I still mill accurate parts with this inherent 2-cycle EtherCAT feedback lag, as long as the servo drive is properly tuned and its internal following error stays low — or does the lag directly reduce machining accuracy?

Thanks a lot for clarifying this.

For example YangYang is now looking at stopping to destination with vel0 acc0 jerk0 all at the same time at the ends of an arc segment, in the servo-thread we compute next position forward in time, they keep adding up, and this leads to numerical errors, which make the jerk overshoot near the final destination, then you have to clamp down the error smoothly to arrive at destination, within current architecture you have to overshoot, you have to readjust, he has tried multiple avenues to fix this, nothing so far has worked.
How commercial TP fix this? they don't plan forward, they plan from destination backwards at each time increment with dedicated hardware, and deal with feed override changes by re-planning to a different time destination.
You can probably understand how different LinuxCNC is from commercial controllers, they practically work in the complete opposite way...
Many of the issues we are faced with, have similar kind of solutions in the commercial space, they just don't do it how LinuxCNC does it.
When I wrote "we are limited to what we can do", I intended it in the scope of implementing jerk limiting within the current TP, with tangential jerk limiting code that is being enabled with planner_type 1, and some blending and look-ahead improvements, to try and stick to jerk limited motion, without introducing any non-realtime code in servo-thread, sure a complete rewrite you can do whatever, but that is not something you do overnight. And we are also limited by physics, you can't have high-speed accuracy smoothness all at the same time, physics just don't allow this. I understand most here would sacrifice speed, but there is a camp that would like to squeeze out a bit more speed if possible sacrificing some accuracy within what's allowed by the gcode.

Ok, found it, this should be it
forum.linuxcnc.org/27-driver-boards/3497...iers?start=90#337507

Hakan wrote:

Position feedback from a drive is always two servo cycles behind.
 

Thank you pointing this out, somehow everyone keeps skipping this.
Not a deal breaker, but nice to know.

It's possible some percent of emails get put in the spam bucket
but losing many in a row would not be common.

Who did you email?



 

Ferrite beads on the motor wires near the drive are usually a must, and having an LC filter on the mains side never hurts.

They (PCW) always replies here, and almost always inside of a single day, no idea about e-mails.
What is your exact issue?

You hit the weak point in linuxcnc Ethercat.
Position feedback from a drive is always two servo cycles behind.
Following error due to this is at least axis speed x 2 x servo cycle time.
You can easily verify this.
 

In a terminal:Click on "glxgears" several times (5-10), leave it on for 15-30 minutes while doing something like copy files, watch youtube, etc and post the resulting screenshot.

Thank you very much.
It works perfectly.
Now we are trying to link all the inputs and outputs.

rodw wrote:

How can you expect the 1 ms servo thread to work when it takes 1,6 Ms on average to talk to the card
Ditch the laptop! 
 

Rod,
I'm want to understand if the laptop is the problem or the adapter?

These are the ping results from the working laptop:
60000 packets transmitted, 60000 received, 0% packet loss, time 60029ms
rtt min/avg/max/mdev = 0.269/0.311/0.600/0.006 ms

These are the ping results from the newer laptop:
60000 packets transmitted, 60000 received, 0% packet loss, time 102174ms
rtt min/avg/max/mdev = 1.297/1.631/3.302/0.044 ms

So obviously the newer laptop is MUCH slower, what I would like to know is the problem the laptop or the external USB-c to Ethernet adapter.

I'm thinking it would be worth trying another adapter, thoughts?

As a reality check, can I force the LinuxCNC timing to extra slow, say 2ms just to see if the error goes away?
If so how would I do that?

rodw wrote:

BUT for a square with NO programmed corners, blend with arcs and parabolas are acceptable? 
This is hypothetical and the gcode is really bad, an error waiting to happen. You might as well attempt to cut a 7 pointed star and break things properly!
Time to get out of the office and onto a real machine!
You should be either looping the corners or adding fillets to the part. If you choose to write bad gcode, be prepared to suffer the consequences. Fixing that is your problem, not the S code developers.

This is the mix up between cv and jerk. This square either has to exact stop at each corner, where linuxcnc has no jerk limiting and makes a big bang, OR, you are running g64 and it rounds the corner base of feed and p value and already functionally works in linuxcnc (it can be better absolutely, but it is that part that DOES work good enough). So clearly we want jerk limiting on the first case (option 1) and its a bit less important in the second case (option 2)... BUT in no way should jerk limiting be directly influencing the path. At all. Ever.

There should be no talk of altering the path, or corners when discussing jerk limiting. In the same way you don't talk about path deviation when discussing acceleration, or velocity. The TP has to hit the path precisely in exact stop mode.

And 100%, you need to be using this on a real machine while you work, not vibe coding and saying "look I made a thing, try it on your expensive equipment for me!". Not even disparaging vibe coding here either if it gets the job done, but you need to actually understand what you are trying to achieve first, and I'm not 100% sure everyone is on the same page.

As I've dug into linuxcnc from a "not particularly good coder" stand point just learning the functional structure, I reaaaaally don't think this is going to happen without a ground up new TP. Option 1 or 2. What seems to be the case is linuxcnc TP is "built different" from most industrial ones and the order of processes causes some problems for simple higher order motion integration.

Can people involved with the existing TP can maybe offer some more complete explanations here? Do we need a structurally new TP to get what we want (option 1 first, 2 second)? I always get some glossed over answers when I search that never supply a definitive "not this isn't going to work at all because:" And we also have the bizarre paradox that linuxcnc in fact surfaces better than many low to mid end jerk limited controls, so we don't want to be losing that either.

And as always, not discouraging anyone or any idea, I have just seen this start and fail SO many time, when literally every other control has had it since the 80s and it always feels like the exact same failure mode: distraction away from the root task.

The 7i96s is a drop in kind of replacement.
At the risk of adding far more complexity, you could consider Ethercat. There are some interesting options emerging. eg The Lichuan 4 axis stepper driver in a single package. I only hope I can get this going, Also available in closed loop. At USD $92 plus shipping, it competes on price depending where you live.

 
 

rodw wrote:

At least in Australia all this is illegal now. You can't make firearms parts without an armourer's license... Maybe our overregulation will save us.

This is the valid way to go I think. You cant make a weapon of a certain type without a license. Get caught, go to jail.

The printing thing is just a kneejerk: "omg you can make the guns cause of this new fangled machine... from 1986". You could always make guns off the radar. Yes, printing an unregistered weapon is certainly easier today than it was yesterday, but I don't really think the rules change here. Punish the people who commit the crimes, not everyone who doesn't.

This is also different from a lot of other dubious new efforts to control internet consumption for example. Printers literally CAN'T be controlled any more than a soup spoon. You can certainly harass buyers of brand new consumer printers, but that wont have any impact on making weapons.

As it relates to us CNC people, here is how the dual use laws have played out - a far more serious set of laws.  I cannot buy a VFD over 599hz because all the manufacturers have applied the law to their products due to the dual use export restrictions.... In canada. So I bought my VFD from vietnam. Yup... real good law there. Literally does nothing. zero, nada except annoy people that want high speed CNC spindles. I get the reason for the law too, and I even agree with the principle... but the implementation is utterly useless. You still need to track all your illegally exported goods the exact same way as before. You gained nothing you wanted from this law. (on a VFD, other items on the dual use list are more realistically managed)