Advanced Search

Post on either at any time. I am usually on both.

In #linuxcnc  IRC or LinuxCNC Discord #general

Differential is mainly useful for servo drives with line receiver inputs.
Optocoupler inputs do not really benefit from differential drive,
and the differential drive lowers the maximum output current.
(and inexpensive drives often require quite high drive currents)
 

This looks like a nice basis to create fillets for both the tcp path & tooldir path.

I agree.

I'm working on rpi4b with Lcnc version 2.9.2.

I have already installed Ethercat support and it can find all the devices that I connected.
I have no idea with HAL and setting stuff.  what should I do next?

Pinned.
Let us know when the times comes to unpin it.
Thank you.

One thing  I do see is that the thread order is wrong

The

addf   bldc.0  servo-thread

should be between the 5I24 read and 5I24 write

For tuning, I would add as much D as you can until it becomes unstable
then do the same with P,  and then I and worry about FF2 at the end
 

I will do it today and will report back. I have tried using MDI M3 S1000 and it does not run.

Cheers

If i add your move to the gcode.
Then we turn 180 radians.
 

When we turn pi radians, 180 degrees this happens :
 

Now the program loads showing the actual tool dir path.
This tool dir path is calculated at program load at the user side. Kernel isn't aware of this.
The toolpath segments are off type 3d_polyline. This is like a linestrip.
 

This looks like a nice basis to create fillets for both the tcp path & tooldir path.
 

That level of error leaves very little time for the loop to react to sudden disturbance. Even Fanuc typically has .002mm or more following error. The misconception is that a true motion control system should as close to real time as possible. This ignores the basic physics of motion control in the first place. P/T is a measure of velocity. V = P/T to be exact. The controller and the axis do not share the same time domain regardless of ones assertion otherwise. It is always a master slave relationship no matter how you drive the axis. The servo reacts to commands and does it's best to recreate the directives given form the controller. Therefore error is expect and even used in practice to place a sync tune across all axis in the coordinate system.

A servo has 1 job, to do what it is told. Some are tied direct to the controller in Closed Loop and others run Open Loop where the servo simply needs the count and speed to count leaving the servo to do all the leg work. The controller has no idea what the servo is going through. In closed loop control it can estimate the load the servo is trying to move around like a loyal dog but given the time domain shift the controller must wait until the servo sends enough warnings for it to react to error, over torque, etc. Modern servos move the function of TP(trajectory planning) and the tree loops position, velo, and torque internal to the drive.

There is little to gain in trying to chase nm of error by trying to over tune a poorly constructed load carrier. Even a modestly tuned servo will hit target within .001mm at speed if the load it carries is well designed to match the capacity of the servo. All servos have a base line inertia ratio. The lower the inertial ratio the more the servo costs. The lower the servo inertia and load inertia the more stable the driven axis will be during the phases of motion. ACC, CONTINUOUS, and DEC. Each phase has its' own concerns the designer must take into account. Almost every servo error issue is related to excess load characteristics caused by either under sized servos or mechanical failure from wear or moments created by poorly designed acc/dec profiles. Jerk tries to solve this but most off the shelf drives less than $1k only allow for trapezoidal velocity curves.

So, what does all that mean? It means that in order to meet the desired design demands the designer must spend a poop ton of cash on a properly engineered machine then try to adapt a control to that. Not the other way around. Even if your servo hits target at .0001mm, the axis mechanically will not be there. So, nm of error cannot help.

Consider this. DMG makes a machine called the DMF. It is a traveling column 5x vertical machine with a fixed table. It rapids at 1800IPM and has a max feed of 500IPM. The column weight is apporx. 12K lbs. Or around 6K kgs. The travel distance in X(column carrier axis(XYZB) is up 6m. The acc/dec profile is non linear or trapezoidal. It is Bell shaped with 2 tier jerk control. The acc of that 6K kg load is .2s and creates 1.3g force on all moments. The column rides on 4 75mm trucks on 75mm cross section linear rails with 24 M16 bolts holding it down. During the acc/dec the machine which has a Polymer Granite base weighing apprx 9K kg bends like a banana in the middle by .035mm during acceleration and deceleration. This machine is engineered to near perfection and still suffers over short time frames major failures of the linear rails every 2-3 years and must be replaced. It is known quantity the customer accepts in exchange for .002mm precision at that speed. The net cost for the 6m(DMF 600) version, 1.9 million.

Can LCNC achieve similar results? Sure. But the control is the slave to mechanics. Not the other way around. A machine made from Aluminum extrusion using rolled ball screws on standard c7 grade gothic linear rails will never improve because you put a Mercedes engine in it. The engine will simply beak the chassis into bits.

PCW wrote:

2. The TB6600 has very slow inputs, it will not see a 2 usec
(2000 ns) step pulse. I would try 20 usec (20000 ns).

 

Yes step pulse ended up being the issue.  I seem to recall this tripped me up once before.

Your first example, 3 wires single ended would make the wiring cleaner. 

I don't plan on using the enable so I would have only 4 wires running differential, not terrible.  What is the benefit of single ended? 

lol it's one page back in this thread, you replied to it.

We where wrong about connecting the ta knots with lines.

Yes, it's kind of obvious now that I see it:
If we are at X0 A0 and we have a move G1 X10 A180 then the connecting orientation line will actually intersect the toolpath.  l didn't think of that.

I think we need to create the recordedb blue toolpath before program starts. Then create the fillets, like
sketched in the image.

I agree.

But i think it's stupid to use no G2, G3 in 5 axis machine code.

Well, it can't be that stupid if the big players do it that way.

[edit]
BTW, also see the gcode posted in here (not a single arc move):
forum.linuxcnc.org/38-general-linuxcnc-q...lib?start=430#303983
[/edit]

But in any case, ABC path smoothing is not limited to 5axis machining. Which is why I'm not suggesting to tailor this to vector format gcode exclusively. It just seems to be something that could be an option because it's actually the easier case.

For now to keep it simple..
Let's say we stick to the 6 axis machine configuration for now to solve the toolpath & tooldir optimalisation.
Then if this works, we can expand the code with different kinematic models.

Absolutely, pick a kinematic and test it. No point in getting spread out too much. 

Thanks! that is very clear now

 

Simple diagram

Thanks - the continuity between NO and COM is working. I need some sleep now - so I can think straight again. Your help is much appreciated though