Advanced Search

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

The relay contacts will have no voltage on them, that's why the one lead on the external relay needs to be connected to +5v and the common of the on board relay connects to ground. If you look at the diagram of the relay posted you will see what I mean.
The Bob board supplies no voltage to any on the NC NO COM or common contacts on the on board relay. Your board is not faulty. Get a multimeter use the resistance setting or continuity setting and place it across the NO & COM conatcs of the on board relay, the relay is just a couple of switch contacts activated by an electromagnet, as with a switch there is no power on the contacts until you supply that power. The power doesn't maigically appear on the contacts, it has to come from somewhere.
If you follow my description it will work.

 

So das müsste die richtige sein sry nochmal war gestern schon spät!

I think my board is faulty - getting nothing (AC or DC) from ground to the 5V connector. I've tested using ground/COM etc - all combinations. The relay light on the board switches on and off though. Going to order a new board - I want a spare anyway (I'm cutting several thousand pieces of foam)

1. Check if the first G01 command has I,J,K words
2a. if no then read the machine kinematics from the ini file and recalculate the tool vector from the ABC values
2b. if yes, use the IJK values to create the tool vector directly.

I think in my program if u have 5 axis gcode as you say that are only G0 or G1 segments.
Then parse I,J,K to letters A,B,C if a line has a G0 or G1. This could be done also by the 5 axis post processor.
The A,B,C are the tool vector. It doen's have to be a normalized vector.

Inside the program A, B, C has a transformation matrix, they are multiplied in order. Then multiplied by a tcp offset matrix.

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.

External Relay Yellow wire to +5v
External Relay Blue wire to on board relay NO if onboard relay turns external relay on
OR
External Relay Blue wire to on board relay NC if onboard relay turns external relay off
On board relay common to ground of the above +5v supply

Imagine the on board relay is a switch. Pretty much what I said in my first post, but now with colours

@Arciera,

Yes, that is because the 5axis CAM output only consists of straight line segments (ie no G02 or G03 commands) the CAM user defines the length of the line segments.

I wasn't aware off this. This makes things easyer.
But i think it's stupid to use no G2, G3 in 5 axis machine code.

--
We where wrong about connecting the ta knots with lines.
Proposing connect ta (tool dir points) knots with lines. :
 

The thin blue line is the recorded tooldir path:
 

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

This example uses gcode with no G64 fillets so far. This is just a example howto get where we want to.

Short movie how to tool tp and tool dir are recorded.


I will now try to create an idea to add clothoid fillets to the tool tp path and tool dir path.
 

Donb9261 wrote:

The problem with LCNC and ECAT is that the master which is lcec driver from EtherLabs has a lag over the true ethercat comm cycle. In their docs they show a .0005-.001 ms offset from the true 1 ms tick cycle required for true ether at frame rate. That means that the FB of position is at a lag. Therefore by the time the position is returned to LCNC and LCNC recalculates the new position and determines the error the data is outdated. So Lcnc will never be able to show the true error nor fully close the loop over ether at in the purest sense.

...

The other course of action would be to install a scale and set LCNC to use that position to monitor the actual position to derive error from. But it would be overkill and a waste.


With LCNC over ethercat think of LCNC as a GCODE sender kinda. The sender has no idea if the axis did its job for the most part and assumes it did. But since I have a really smart drive, my assumption can within solid parameters be correctly assume it did its job.

This is the best you will get with LCNC.
 

Maybe my use case is a bit different as it is on a milling machine which is comparatively slow compared to the numbers being mentioned in this thread. But at the 0.0005 - .001ms offset you mention at a 10000mm/min milling speed (max rapids in my case) would only result in a position deviation of 80~166nm!

My plan until reading this thread was to use the existing linear encoders on my mill to try and compensate for the cheap ballscrews it came with, using linuxcnc to close the loop (without spending thousands on drives that support linear encoders). I don't understand why that wouldn't work with ethercat? My existing linuxcnc control loop with my old stepper motors is 1ms so nothing has changed there, so what would I gain using for example a Mesa card and step/dir commands? The cheap servo I bought for testing cost the same as the non-ethercat version as far as I can see, so would be nice to make use of it if I can...

Thanks for all the info you're providing here, it helps with design decisions!

I found when I send an M3 and M5 that I can hear the onboard relay clicking on and off. So the config is correct (NO is pin 14) - I just dont know how to connect the onboard relay to the external relay