Trajectory Planner using Ruckig Lib
13 Nov 2024 11:14 #314371
by Grotius
Replied by Grotius on topic Trajectory Planner using Ruckig Lib
@Smc.collins,
That's more or less what's going on.
Maybe you could run multiple trajectory planners in lcnc. But still you have just one
shared memory region, and one interpreter.
Today the realtime example is tested on real hardware using ethercat bus.
This is source code looks like RTAPI & HAL, but is coded entirely from scratch.
Purposing it can load multiple instances of rtapi & hal.
// Ethercat EK1100 & EL2124
ethercat code
// Qt gui
qt_code
// Rtapi & hal lookalike code to run the application.
function loader
This test was going very well.
The qt app has buttons to set the ethercat digital io's.
The function loader also connect's the hal pins over different shared memory regions.
That's more or less what's going on.
Maybe you could run multiple trajectory planners in lcnc. But still you have just one
shared memory region, and one interpreter.
Today the realtime example is tested on real hardware using ethercat bus.
This is source code looks like RTAPI & HAL, but is coded entirely from scratch.
Purposing it can load multiple instances of rtapi & hal.
// Ethercat EK1100 & EL2124
ethercat code
// Qt gui
qt_code
// Rtapi & hal lookalike code to run the application.
function loader
This test was going very well.
The qt app has buttons to set the ethercat digital io's.
The function loader also connect's the hal pins over different shared memory regions.
Please Log in or Create an account to join the conversation.
13 Nov 2024 11:29 - 13 Nov 2024 11:32 #314372
by Grotius
Replied by Grotius on topic Trajectory Planner using Ruckig Lib
Last edit: 13 Nov 2024 11:32 by Grotius.
Please Log in or Create an account to join the conversation.
- smc.collins
- Offline
- Platinum Member
Less
More
- Posts: 684
- Thank you received: 119
13 Nov 2024 22:46 #314409
by smc.collins
Replied by smc.collins on topic 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.
The following user(s) said Thank You: Grotius
Please Log in or Create an account to join the conversation.
15 Nov 2024 12:19 #314516
by aleksamc
Replied by aleksamc on topic Trajectory Planner using Ruckig Lib
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.
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.
The following user(s) said Thank You: Grotius
Please Log in or Create an account to join the conversation.
16 Nov 2024 08:41 #314588
by Grotius
Replied by Grotius on topic Trajectory Planner using Ruckig Lib
@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.
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 :
// Scan network
ec_slave_info_t slave_info;
for (uint16_t slave_pos = 0;; slave_pos++) {
if (ecrt_master_get_slave(master, slave_pos, &slave_info)) {
break; // No more slaves
}
printf("Slave %d: Name: %s, Vendor ID: 0x%08X, Product Code: 0x%08X\n",
slave_pos, slave_info.name, slave_info.vendor_id, slave_info.product_code);
}
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.
The following user(s) said Thank You: Darium, smc.collins
Please Log in or Create an account to join the conversation.
- smc.collins
- Offline
- Platinum Member
Less
More
- Posts: 684
- Thank you received: 119
16 Nov 2024 16:23 #314599
by smc.collins
Replied by smc.collins on topic Trajectory Planner using Ruckig Lib
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.
The following user(s) said Thank You: Grotius
Please Log in or Create an account to join the conversation.
17 Nov 2024 09:29 #314649
by Grotius
Replied by Grotius on topic Trajectory Planner using Ruckig Lib
@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.
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.
The following user(s) said Thank You: Darium
Please Log in or Create an account to join the conversation.
17 Nov 2024 15:17 #314671
by RDA
Replied by RDA on topic Trajectory Planner using Ruckig Lib
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.
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.
The following user(s) said Thank You: Grotius
Please Log in or Create an account to join the conversation.
- smc.collins
- Offline
- Platinum Member
Less
More
- Posts: 684
- Thank you received: 119
18 Nov 2024 01:15 - 18 Nov 2024 01:16 #314708
by smc.collins
Replied by smc.collins on topic Trajectory Planner using Ruckig Lib
the faster the pulse count, and the smaller the unit of measure, at a fixed frequency, the bigger the problem becomes. I am referring to a edge case but it is something to beware of.
Last edit: 18 Nov 2024 01:16 by smc.collins.
The following user(s) said Thank You: Grotius
Please Log in or Create an account to join the conversation.
18 Nov 2024 12:24 #314748
by Grotius
Replied by Grotius on topic Trajectory Planner using Ruckig Lib
Hi,
The ethercat auto configurator works finally !!
When program starts, it initializes the ethercat devices by retrieving a digital xml configuration.
For this i poked around in the etherlab source code, and added some function's to retrieve this digital xml information.
From the given digital xml information, it then does some logic and it create's hal pins automaticly.
This is ideal for lazy system integrators.
For this to use you don't need a .xml config file like in linuxcnc-ethercat.
I also solved a etherlab_master software bug related to slave alias numbers, wich where not consistent and
resulted in head scratching for some time as the aliases are not printed by : "$ ethercat xml"
The terminal output when starting the program :
So far 4 data types are integrated : bool, uint, string, bit.
It currently looks at one master. But code may look at more masters in the future.
So far so good !
Integration in linuxcnc is not that difficult, as you can add this code into a component, using a function like
rtapi_app_main(); will then run the code, will also create hal pin's etc. with some slightly modifications.
The ethercat auto configurator works finally !!
When program starts, it initializes the ethercat devices by retrieving a digital xml configuration.
For this i poked around in the etherlab source code, and added some function's to retrieve this digital xml information.
From the given digital xml information, it then does some logic and it create's hal pins automaticly.
This is ideal for lazy system integrators.
For this to use you don't need a .xml config file like in linuxcnc-ethercat.
I also solved a etherlab_master software bug related to slave alias numbers, wich where not consistent and
resulted in head scratching for some time as the aliases are not printed by : "$ ethercat xml"
The terminal output when starting the program :
Starting EtherCAT master 1.5.2 done
init example 0.
init ethercat start.
Print ethercat devices and retrieve device data vector.
No alias given, alias -
pdo entry registration:
Name:EL2124 4K. Dig. Ausgang 5V, 20mA
Slave Alias: 0
Position: 1
Vendor ID: 2
Product Code: #x084c3052
PDO Entry Index: #x7000
PDO Entry Subindex: 1
Name:EL2124 4K. Dig. Ausgang 5V, 20mA
Slave Alias: 0
Position: 2
Vendor ID: 2
Product Code: #x084c3052
PDO Entry Index: #x7000
PDO Entry Subindex: 1
Name:EL2124 4K. Dig. Ausgang 5V, 20mA
Slave Alias: 0
Position: 3
Vendor ID: 2
Product Code: #x084c3052
PDO Entry Index: #x7000
PDO Entry Subindex: 1
Name:EL1004 4K. Dig. Eingang 24V, 3ms
Slave Alias: 0
Position: 4
Vendor ID: 2
Product Code: #x03ec3052
PDO Entry Index: #x6000
PDO Entry Subindex: 1
Name:EL2794 4K. Dig. Ausgang 24V AC/DC, 2A, kurzschlussfest
Slave Alias: 0
Position: 5
Vendor ID: 2
Product Code: #x0aea3052
PDO Entry Index: #x7000
PDO Entry Subindex: 1
Name:EL2808 8K. Dig. Ausgang 24V, 0.5A
Slave Alias: 0
Position: 6
Vendor ID: 2
Product Code: #x0af83052
PDO Entry Index: #x7000
PDO Entry Subindex: 1
Name:EL3162 2K. Ana. Eingang 0-10V
Slave Alias: 0
Position: 7
Vendor ID: 2
Product Code: #x0c5a3052
PDO Entry Index: #x3101
PDO Entry Subindex: 1
Name:EL3162 2K. Ana. Eingang 0-10V
Slave Alias: 0
Position: 7
Vendor ID: 2
Product Code: #x0c5a3052
PDO Entry Index: #x3101
PDO Entry Subindex: 2
Name:EL3162 2K. Ana. Eingang 0-10V
Slave Alias: 0
Position: 7
Vendor ID: 2
Product Code: #x0c5a3052
PDO Entry Index: #x3102
PDO Entry Subindex: 1
Name:EL3162 2K. Ana. Eingang 0-10V
Slave Alias: 0
Position: 7
Vendor ID: 2
Product Code: #x0c5a3052
PDO Entry Index: #x3102
PDO Entry Subindex: 2
Name: empty
Slave Alias: 0
Position: 0
Vendor ID: 0
Product Code: #x00000000
PDO Entry Index: #x0000
PDO Entry Subindex: 0
halpin names:
EL2124_1_0_0_IN_BOOL
EL2124_1_1_0_IN_BOOL
EL2124_1_2_0_IN_BOOL
EL2124_1_3_0_IN_BOOL
EL2124_2_0_0_IN_BOOL
EL2124_2_1_0_IN_BOOL
EL2124_2_2_0_IN_BOOL
EL2124_2_3_0_IN_BOOL
EL2124_3_0_0_IN_BOOL
EL2124_3_1_0_IN_BOOL
EL2124_3_2_0_IN_BOOL
EL2124_3_3_0_IN_BOOL
EL1004_4_0_0_OUT_BOOL
EL1004_4_1_0_OUT_BOOL
EL1004_4_2_0_OUT_BOOL
EL1004_4_3_0_OUT_BOOL
EL2794_5_0_0_IN_BOOL
EL2794_5_1_0_IN_BOOL
EL2794_5_2_0_IN_BOOL
EL2794_5_3_0_IN_BOOL
EL2808_6_0_0_IN_BOOL
EL2808_6_1_0_IN_BOOL
EL2808_6_2_0_IN_BOOL
EL2808_6_3_0_IN_BOOL
EL2808_6_4_0_IN_BOOL
EL2808_6_5_0_IN_BOOL
EL2808_6_6_0_IN_BOOL
EL2808_6_7_0_IN_BOOL
EL3162_7_0_0_OUT_UINT
EL3162_7_0_1_OUT_UINT
EL3162_7_1_0_OUT_UINT
EL3162_7_1_1_OUT_UINT
PDO entry registration ok.
Master ok.
domain1_pd ok.
init ethercat succes.
So far 4 data types are integrated : bool, uint, string, bit.
It currently looks at one master. But code may look at more masters in the future.
So far so good !
Integration in linuxcnc is not that difficult, as you can add this code into a component, using a function like
rtapi_app_main(); will then run the code, will also create hal pin's etc. with some slightly modifications.
Please Log in or Create an account to join the conversation.
Time to create page: 0.145 seconds