Drivers implementation for ROS - rtt_soem

Hi,

I got it working.
The original "unix command wrapper" loadusr [flags] unix-command is not used anymore by hal-core.

Instead you can load the ethercat .xml configuration file with a direct "unix" command like :
$ /opt/hal-core/rtlib/./lcec_conf /opt/hal-core/rtlib/ethercat-conf.xml &

Where "&" is a system flag for "do not lock me"

Now I have to check it again without the "-mieee-fp" compile flags, to make it Rpi4 compatible.

 

Hi,

Github is updated. github.com/grotius-cnc/hal_core/tree/mai.../components/ethercat
Commits are merged.

Hi,

I don't have that linuxcnc directory created. Should I have it?

Great!

I will try it out right now!
I noticed how you implemented the lcec.so "All in one file". Good

Regards

Hi,

I don't have that linuxcnc directory created. Should I have it?
That's a /opt/linuxcnc install from a .deb mirror from linux-pro. It can be used to track down issue's, like the unix command yesterday.

I noticed how you implemented the lcec.so "All in one file". Good
That's retrieved by a "-v" verbose off the original Makefile command.

I hope you get your ethercat running today !

Everything working here!

EtherCAT is full compatible and with the lasts drives.

Here is the project in case someone is interested in:
github.com/grotius-cnc/hal-core

Hi Juniorfi,

Nice !

I was thinking. If you build a hal-core kernel module, programming style like the /components/DoFs module.
Then you could include a c++ header file from the ROS project in the c++ section.

In fact this is then the visa-versa interface between hal-core and ROS.
Then you don't have to use any ROS glue code?

If you use a matching c array[100~500] in Ros c++ and in hal-core "extern c", you can pass values visa-versa.

Another thing that could improve the ROS performance is to call the ROS program from hal-core at a thread time.
If ROS and hal-core are synchronized in time, that will be good for performance.

For example if ROS has a update time of 20ms. Then hal-core can request ros every 20ms and retrieve function values exactly
within the request time without overlapping other threads. For graphical display you need a seperate stand alone thread.






 

Hello,

Yes that was my idea days ago, to based on those components you have made there and integrate that with rtt_ros.

But I think the most tricky thing will be interact with the modules in real-time.

I'm trying to get something from the HAL documentation.

Regards

If you want to speak from userspace to HAL you need to use DMA. So either memory buffer or atomics.

Theres hal_streamer component that does the buffered approach and atomics can be used with normal hal apis.

Though you can't get these values into the normal motion execution path of linuxcnc at present unless you want to mess with NML.

Hello Roiki,

I have been reading about hal_streamer trying to find the way to implement it.
Thanks for the hint.

Right now I'm just looking to interact (Read/Write) values in real-time every time needed.
If for example one arm is moving get the real value when you ask for them and so. Same like using halcmd getp/setp.


Regards.