Trajectory Planner using Ruckig Lib

very nice, my only other bitch is that, encoder and position feedback are not interrupt driven but polled, this creates issues with positional accuracy at very high speeds and very high accuracy.

Unfortunately I'm bad programmer))) But if you you will be successful (as it seems it is) in multi threaded running of g-code interpreters.
It would be good and easily to implement for user to add such possibility as "assign each axis to it's own g-code interpreter and path-interpolation with help of HAL.ini".
For example: assign axes X1,Y1,Z1, A1,B1 to thread 1.
assign axes X2, Y2, Z2 to thread 2.

@Collins,
very nice, my only other bitch is that, encoder and position feedback are not interrupt driven but polled, this creates issues with positional accuracy at very high speeds and very high accuracy.

I don't really get the outcome of the problem. Is this related to a PID controller that's going wild using high speeds?

@Aleksam,
Yes, that's exactly how it should be.
You can setup multiple thread's attached to work with a certain memory region to create hal pins in.
Each thread can run on it's own assigned cpu.

Then when using a interpreter with multiple sub-interpreters, we can likely run this from userland.
Then the position command's of the interpreter's will be passed to a buffer to be executed by
motion components.

** Current status **
As the current status is testing real hardware with ethercat. No interpreter's are running yet.
Only a few realtime thread's are running over some hal pins, to test and verify all is working.

I realized that the original linuxcnc-ethercat source code is not able to parse the command: "$ ethercat xml" output.
This command gives a xml ethercat bus configuration or esi file output in the terminal.

You should expect that using this as configurator is the ultimate solution. This way could setup the hal pins automaticly for each slave.

As i am diving deeper into the etherlab's source code, we can ask for the slave list in c++ by scanning the network :

Output:
Slave 0: Name: EK1100 EtherCAT Coupler (2A E-Bus), Vendor ID: 0x00000002, Product Code: 0x044C2C52
Slave 1: Name: EL2124 4K. Dig. Ausgang 5V, 20mA, Vendor ID: 0x00000002, Product Code: 0x084C3052
Slave 2: Name: EL2124 4K. Dig. Ausgang 5V, 20mA, Vendor ID: 0x00000002, Product Code: 0x084C3052
Slave 3: Name: EL2124 4K. Dig. Ausgang 5V, 20mA, Vendor ID: 0x00000002, Product Code: 0x084C3052
Slave 4: Name: EL1004 4K. Dig. Eingang 24V, 3ms, Vendor ID: 0x00000002, Product Code: 0x03EC3052
Slave 5: Name: EL2808 8K. Dig. Ausgang 24V, 0.5A, Vendor ID: 0x00000002, Product Code: 0x0AF83052
Slave 6: Name: EL2794 4K. Dig. Ausgang 24V AC/DC, 2A, kurzschlussfest, Vendor ID: 0x00000002, Product Code: 0x0AEA3052

Then there are more commands to use, to retrieve more info.

The idea is then to automaticly create the ethercat hal pin's  at runtime, conform the network scanning.

For example, this is a handmade setup file to setup the slave's, add hal pin's etc. It's a lot off work to do.
For new users this can be difficult task.

However it works fine and gives a complete overview how ethercat interact's with the outside world.

Will try to automate the ethercat configuration process for hal pins. image missing /media/kunena/emoticons/smile.png

 

Polling requires a delay loop , which takes time, the higher your encoder resolution and the faster your machine moves, the closer you move to missing counts. So as each loop iterates you can and will at some point drop the count. I know that the asics on a lot of the cards and a lot of the new servo drives are broadcasting position info but there are limitations on all of this. The issue is that even if we have a infintely fast loop with perfect capture, you still want your position to be fed from the interupt into a calculation that handles the machine position in realtime, and if we are being honest we really want the machine to predict the position the machine will be in and at what velocity with a feed forward algorythm to really hone accuracy. given the speed of modern processors this isn't really much of a issue these days, but encoder feedback and position feedback should be interupt driven as just a good point of design. 

@Collins,

Using a base thread of 20,000ns = 50.000 HZ

Example 0:
Suppose the encoder has P=10,000 pulses per revolution and the machine rotates at
R=3 revolutions per second.
f=10,000×3=30,000 Hz

Example 1:
Suppose the encoder has P=10,000 pulses per revolution and the machine rotates at
R=6 revolutions per second.
f=10,000×6=60,000 Hz

I see the problem. At high speeds, and high encoder resolution, it just can't keep
up with the second example.

***
For ethercat to get device information, i poked around in the etherlab's source and
found a solution.

Made a file to hold device data : device data struct (this data is equvalent to the "$ ehtercat xml" command.)
Add a few function's in the tool section of ethercat's source code : .h file   cpp.file
Recompile ethercat...

And then when we start the realtime app, it retrieves all the ethercat information there is by
using the get info function.

This works perfect.

We now have all the ethercat data (master info, slave info) at startup.
This is then the moment to automaticly create hal pins etc. Let's try this.

In what setups this is a problem? Parport?
If you have an ethercat servo, the servo takes care about the encoder pulses and you just read the position from the drive. So as long as the servo drives can keep up, lcnc side is ok.
I would assume this is the same with mesa stuff. The FPGA counts the pulses and lcnc just retrieves the pulse count periodically.

Or maybe I just misunderstand something.