Semi-realtime hal component

Dear community,

I have the following setup

Computer                Debian RT                                    XYZ closed
Vision <==(ethernet)==> Linux CNC <=========> Mesa 7i96 <=========> loop rotating
PC                        PC with dual                                platform
(CVPC)                  ethernet (CNCPC)                            (no encoders)

CVPC independently processes visual information in realtime (15-20FPS or 50-65ms) and computes the target position for the rotating platform.
This information is communicated via ethernet to CNCPC using low-latency messaging library (e.g. ZeroMQ) that has support in both python and C++.
Based on the target position information the rotating platfrom can:
a) Start movement to the given position
b) Abandon the last target position (even if the move hasn't finished yet) and update it with the newly available data. Start rapid movement to the target position.

My questions are mostly:
1. Should my component be realtime or non-realtime. Even though 15-20FPS is guaranteed, the exact timings when new position measurements arrive are not strictly defined. Communication in ZeroMQ can be blocking, i.e. wait on the function call and return if a message has arrived or non-blocking, i.e. check for new messages in a loop. So, the arrival of new data is not realtime, but target position update should be performed asap.
2. How can I update the target position in HAL (e.g. with axis or motion) such that velocity and acceleration are updated properly? As mentioned above the last movement might be still ongoing, so it has to be interrupted and the new move started.

I did my best and went through the documentation and the following forum topics:
forum.linuxcnc.org/24-hal-components/409...position-in-realtime
forum.linuxcnc.org/38-general-linuxcnc-q...ontrol-with-linuxcnc
forum.linuxcnc.org/38-general-linuxcnc-q...r-cnc-control-in-c-c
forum.linuxcnc.org/24-hal-components/528...bot-arm-in-real-time
forum.linuxcnc.org/38-general-linuxcnc-q...391-realtime-control

Unfortunately, I haven't found the recipe suitable for me. Also, there is a chance I might have overlooked the right solution cause I am still quite new to the LinuxCNC ecosystem. Any help is appreciated. Thank you!
 

Sorry, the tabs got messed up.
Here is the setup once again

Computer                           Debian RT                                                                               XYZ closed
Vision <==(ethernet)==> Linux CNC <=========> Mesa 7i96 <=========> loop rotating
PC                                       PC with dual                                                                           platform
(CVPC)                                ethernet (CNCPC)                                                                   (no encoders)

you can take a look at this (non-realtime) component,
there i use sliders in python(qt5) to move my robot-joints.

it can also change the target position while moving, like you need.

github.com/multigcs/riocore/blob/main/ri...s/robojog/robojog.py

the script is not big and you already have an insight or you can use it as a basis, throw out qt and simply replace the inputs with ZeroMQ

Thanks for your reply!
The solution seems promising. I went through the code and I see how you control the axes using jog-counts like with MPG. The only doubt I have is that whether these jog-counts will respect the coordinated motion of XY axes. Say if I change both counts at the same time in my component, will it result in synchronous movement of X and Y and will it do proper velocity & acceleration/deceleration, or will it be just a linear motion with constant velocity? Please let me know if you have any idea. Thanks!

Thanks for your reply!

I went through the topic you referred to and it seems quite suitable for my needs. In essence, this is very similar to what the other commentator has suggested. But as compared to MPG these external offsets can actually rely on coordinated motion planners when modifying g-code controlled motion.

Now answering your question, this stream of coordinates is the only source of movement commands for the rotating platform. Hence, I can implement it the way the original author of the topic you referred to has done (i.e. 'M66' + 'G1' g-code commands in loop) or just issuing python/c++ MDI commands in a loop. In my understanding the algorithm might look like this:

1. Run G1 command in loop. Target point is the last available position received
2. If new data comes and the motion is still ongoing (e.g. check 'motion.motion-type') -> compensate the target position with 'eoffset-counts'
3. If new data comes and the motion has stopped -> signal to M66 input
4. If new data comes and the target position has not changed -> do nothing

The only thing I am not sure about is what would be my final position with offsets enabled. Say I finish one G1 command with the offset, and for the next one in the loop the same offset will still apply, right? So I have to set it manually to zero (e.g. with 'eoffset-clear'). Please let me know if you think it makes sense what I have written and whether you have any additional comments/suggestions. Thanks!

I use the same approach here:
www.youtube.com/shorts/VGWusrDVHlg

I think that's even closer to what you have in mind

github.com/multigcs/riocore/blob/main/ri...ons/camjog/camjog.py