Advanced Search

Now the linuxcnc error is once again about the mac address (as in my first post)
Then, I tried to install the drivers for the lan card as you suggest, but this is what I get:

and trying to follow your tutorial on youtube, as soon as I try to install grub-customizer (at the very beginning of the tutorial) I get this:

I really think this conversation is going around in circles. Lets ust step back and let 
grandixximo and his team get on with his coding. Too much navel gazing. where are the machines? where are the beautiful surface finishes? where are the accurate parts and their measurements? That's what most of us want to see.

@Gogonfa, yes you can just increase ferror limit. Even better if you can use the real following error from the drive, there is often a pdo for that.
Not sure how to feed real ferror into motion but maybe there is a way.

Consequence is to not use PID loops involving linuxcnc. Let the drive do the job, tune it well like Gogonfa seems to have done.
Time sensitive signals like for homing - do it on the drive. Most other signals are not that time critical and can accept a couple of miilisecond delay without problem. Zeroing of encoder counters - on the drive.

Here is how it works.
Hal variable with direction In and Out are exchanged with the Ethercat drive, InOut is not suppported.
There is a distinct time when data is taken into hal: lcec.read-all. And written from hal: lcec.write-all
Data is then exchanged with the drive at the end of lcec.write-all.

It is a double exchange: out an in. Data for the pdos are sent from the ethercat master to the drive and
a few microseconds later data is received from the drives. Data is exchanged with the ethercat clients'
sync manager. The client app need a little time to prepare that so data is sent ahead of the Sync0 event. 

At Sync0 - which is the time that counts for the drive -  the drive now have the new commanded position
and can go ahead and do its thing.
The client puts the current position value (at time Sync0) into the syncmanager for later shipping.

At next data exchange event, next lcec.write-all, the current position is sent to linuxcnc.
However, no-one is interested in the data at this point, it is well beyond the lcec.read-all that reads in data to hal.

At the start of next linuxcnc servo period, the previously read data is read into hal with the lcec.read-all function.
There is no actual data exchange at this point, actual data exchnage only happens at end of lcnec.write-all,
so it uses the data the Ethercat master has kept from the earlier data exchange.

Note that this compares commanded position with current position. Not sure if that's fair,
maybe one should compare commanded position with position at end of the cycle so one can
see the effect of how well the servo actually can control. Delay is then three servo cycles. And my brain hurts.


 







 

Aciera wrote:

This is the most important jerk control needed in linuxcnc. Option 2 is making it work fully with g64 and is FAR FAR less important.


I think that this might actually be point were many would beg to disagree.

And this is a problem.

Good morning, I received the 7i85s purchased from Eusurplus in a very short time, loaded the indicated firmware, now I wanted to do a configuration with pncconf but if I choose 7i80db 16 I see a maximum of 2 encoders and I can only decrease them. Is there any way to configure it?

This is the most important jerk control needed in linuxcnc. Option 2 is making it work fully with g64 and is FAR FAR less important.

I think that this might actually be the point were many would beg to disagree.

grandixximo wrote:

@ihavenofish I think there's some confusion here worth clearing up, you're right that filtering (like Tormach does) gives you unpredictable deviation, the path ends up wherever the filters spits out, that's not what we're after.

But I think you're mixing up two different things, how the machine speeds up and slows down is jerk control, whether we cut corners is G61 vs G64, these are separate knobs, if you want perfect path following, use G61, the machine will stop at every corner, follow the exact line, no deviation, with proper S-curve planning it'll do that smoothly instead of jerking around, you get accuracy, you give up speed, fair trade.

G64 P is for when you say "I'm okay with cutting corners by up to this much, just keep moving." That's already how LinuxCNC works today, S-curve doesn't change that, it just makes the motion smoother while respecting whatever tolerance you set.

Why Beziers instead of arcs for blending?
Arcs are a 2D thing. Works fine for XYZ, but what's an "arc" when you've got 9 axes moving at once? It doesn't really make sense.
Beziers are just smooth curves that work in any number of dimensions.Also arcs have constant curvature, so when you enter and exit a blend there's a sudden curvature change, the TP deals with this by speeding up and slowing down, which is why you see velocity bobbing up and down through corners, Beziers can match curvature at the transitions, so you get steadier speed through the blend, And on top of that, arcs need sin/cos every servo cycle while Beziers are just a handful of multiplies and adds, In a tight loop running 1kHz+, that matters. Same tolerance as before, just a better curve to fill it with.

This isn't like the clothoid thing, we're not trying to get fancy with exotic geometry, just trying to get smooth motion that respects whatever path constraints you set, does that make more sense?

Just to be clear, the only reason I'm talking about deviation is because S-curve has to work in all modes, including G64 P where the user has asked for corner blending, s-curve isn't only for G61 exact stop, and there will always be a fallback to trapezoidal via HAL pins, some operations like threading, tapping, and probing need the tighter timing that trapezoidal gives you. You can hook planner_type to an M-code and switch modes in your G-code when needed.

I am not mixing up anything. This is literally what I've been saying the whole time. You literally just repeated what I said several posts ago.

S curve DOES NOT HAVE TO WORK IN ALL MODES. This is the point of my "option1" for exact stop as I described earlier (and lead ins and outs of g64 moves). This is the most important jerk control needed in linuxcnc. Option 2 is making it work fully with g64 and is FAR FAR less important. Option 1 is critical, option 2 is... optional. This is why every single jerk control project fails. People jump at option 2 and give up.








 

Hallo Mario,

Laut mein Verständnis musst Du noch eine Konfiguration hochladen. Den Thread durchlesen ist sicher eine gute Idee, aber die ersten Beiträge sind 3-4 Jahre alt und nicht mehr unbedingt relevant.

Gruss,
Luca

@ihavenofish I think there's some confusion here worth clearing up, you're right that filtering (like Tormach does) gives you unpredictable deviation, the path ends up wherever the filters spits out, that's not what we're after.

But I think you're mixing up two different things, how the machine speeds up and slows down is jerk control, whether we cut corners is G61 vs G64, these are separate knobs, if you want perfect path following, use G61, the machine will stop at every corner, follow the exact line, no deviation, with proper S-curve planning it'll do that smoothly instead of jerking around, you get accuracy, you give up speed, fair trade.

G64 P is for when you say "I'm okay with cutting corners by up to this much, just keep moving." That's already how LinuxCNC works today, S-curve doesn't change that, it just makes the motion smoother while respecting whatever tolerance you set.

Why Beziers instead of arcs for blending?
Arcs are a 2D thing. Works fine for XYZ, but what's an "arc" when you've got 9 axes moving at once? It doesn't really make sense.
Beziers are just smooth curves that work in any number of dimensions.Also arcs have constant curvature, so when you enter and exit a blend there's a sudden curvature change, the TP deals with this by speeding up and slowing down, which is why you see velocity bobbing up and down through corners, Beziers can match curvature at the transitions, so you get steadier speed through the blend, And on top of that, arcs need sin/cos every servo cycle while Beziers are just a handful of multiplies and adds, In a tight loop running 1kHz+, that matters. Same tolerance as before, just a better curve to fill it with.

This isn't like the clothoid thing, we're not trying to get fancy with exotic geometry, just trying to get smooth motion that respects whatever path constraints you set, does that make more sense?

Just to be clear, the only reason I'm talking about deviation is because S-curve has to work in all modes, including G64 P where the user has asked for corner blending, s-curve isn't only for G61 exact stop, and there will always be a fallback to trapezoidal via HAL pins, some operations like threading, tapping, and probing need the tighter timing that trapezoidal gives you. You can hook planner_type to an M-code and switch modes in your G-code when needed.

Hakan wrote:

There was a question on that drive before in the forum, was that of any help?
Not exactly the problem you have if I recall right, but anyway.
Hoping to avoid looking at all supplied files hehe.
 

Maybe not so Lucky. I did find a thread on a 2 axis drive that had the same issue but it was never resolved.  I think this is  a deeper problem but don't know why. At least I have the config sorted out and working BUT....

Joint 0 is working perfectly now but Joints 1, 2 and 3 do nothing. The statusword etc are not updating so I am beginning to think this is an issue with our drivers etc. Is it because there is not a slave for every drive? Maybe there is something to enable the later drives so will dig.
I've updated some files attached here.


 

There was a question on that drive before in the forum, was that of any help?
Not exactly the problem you have if I recall right, but anyway.
Hoping to avoid looking at all supplied files hehe.

rodw wrote:

Hakan wrote:

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.

 
Not sure how this can be. The servo thread fires every 1 Ms (1000 usec), If you do a trace, It might take 200 usec to execute, then it sleeps for the remaining 800 usec) until it fires gain. The Ethercat thread and the Linuxcnc servo thread are synchronized. We read from lcec at the beginning of the servo thread execution, do our stuff, pids and position adustments etc then write write the result back to lcec then sleep as normal for the remaining 800 usec. How does it lag 2000 usec behind?
  

I thought it was 1 frame behind. but it definitely is behind. People trying the lichunan drives were having this issue when trying to use velocity command.

The WHY is above my pay grade.

grandixximo wrote:

If filtering is what you call s-curve, that will not take long to implement, but that is practically the same as setting s-curve on your servos, but you have a nice parameter in the gcode which you can tweak. But  mind that jerk filtering WILL change your path, this is as far as I understand just a lazy afterthought patch fix.

Mine and YangYang's approach: "We will deviate from the commanded path by at most P, using this specific mathematical curve."
Tormach's approach: "We will filter the output and try to keep deviation reasonable, probably, mostly."
For you to object to Beziers on path-purity grounds while advocating for Tormach's method is... inconsistent, to put it politely.

Sigh.

There should be no deviation. ever. period. If the word deviation comes up, we are not talking about jerk control anymore. 

Option 1, then option 2. Option 2 is mostly useless without Option 1. Filtering doesn't work for me as it is not controlled motion. As you say, we can just soften the servo response for that and we all know that is NOT a good plan.

So it does sound like we need a ground up new TP to actually get anywhere with this. A bit disappointed as this means tormach's implementation was kinda misrepresented to me (not by rob, I never talked to him directly).

That's said, I still feel like this would be great to get implemented anyway, as it might make a bit of a stop gap incremental improvement even if its not the end goal. it would not meet any of the requirements for the lemontart bounty though.

Sleepy time.



 

If filtering is what you call s-curve, that will not take long to implement, but that is practically the same as setting s-curve on your servos, but you have a nice parameter in the gcode which you can tweak. But  mind that jerk filtering WILL change your path, this is as far as I understand just a lazy afterthought patch fix.

Mine and YangYang's approach: "We will deviate from the commanded path by at most P, using this specific mathematical curve."
Tormach's approach: "We will filter the output and try to keep deviation reasonable, probably, mostly."
For you to object to Beziers on path-purity grounds while advocating for Tormach's method is... inconsistent, to put it politely.

Hakan wrote:

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.

 

Not sure how this can be. The servo thread fires every 1 Ms (1000 usec), If you do a trace, It might take 200 usec to execute, then it sleeps for the remaining 800 usec) until it fires gain. The Ethercat thread and the Linuxcnc servo thread are synchronized. We read from lcec at the beginning of the servo thread execution, do our stuff, pids and position adustments etc then write write the result back to lcec then sleep as normal for the remaining 800 usec. How does it lag 2000 usec behind?