relative position in "Realtime"

Hi everyone,
i am using linuxcnc for Rasterengraving things with a solution based on Graster:
wiki.linuxcnc.org/cgi-bin/wiki.pl?Rastering_With_A_Laser

To reach high velocity the Laser-Control has to be in sync with base-thread.
I have to compare current position on X-axis with a target position.
Using the Pin "axis.x.pos-cmd" is working fine but it would be much better working with relative Position like "halui.axis.x.pos-relative" - but this Pin seems to be only refreshed in servo-thread.

Does anyone know a nice solution getting relative Position in a thread much faster than servo-thread (without moving everything to the faster thread )?

Thank you very much
I wish everyone a merry Christmas and a happy time between the years.

Version 2.9 includes the hal_port component that is designed to deal with this on the servo thread
Ref: linuxcnc.org/docs/devel/html/man/man3/hal_port.3hal.html

Unfortunately, the examples have not been added to the Linuxcnc repo but from the developers email list, Curtis Perry said:

Last year I retrofitted my laser engraver with linuxcnc. I do both
rastering and vector cutting on my laser, and it is a 4 axis laser as I do
complicated raster and vector cutting on 3D objects.

I found existing solutions out on the web but they weren't quite adequate
for my needs. Because I have a 4 axis laser (XYZA), controlling vector
power using the Z axis was out. Also my raster files are sometimes 200Mb
and streaming raster data at the servo period rate via gstreamer takes
quite a long time. I also did not want to have a separate raster data file
alongside the gcode file.

To solve these and some other problems I needed a way to pipe data through
the HAL at a rate much greater than what could be achieved with 1 data
point per servo cycle. Thus the HAL_PORT pin type was born. The idea was
taken from machine kit ring buffers.

A HAL_PORT pin allows for a writer component to send many bytes in one
operation to a reader component in real time. The PORT pins behave just
like any other pin in HAL and can be linked, unlinked etc...

In addition to the modifications to make hal ports some other modifications
and new parts were required.

halcompile.g - added port type. Also added (pin,param,variable)_ptr macros
to allow access to the actual pointer to those values.

pyhal.py - similar to the other python component pyhal.py uses the ctypes
python library to interface with hal, which is significantly less code than
the halmodule.cc python wrapper that currently exists.

laserpower.comp - allows vector control of a laser, scaling power during a
move and has no limitations of number of joints a machine can have.

raster.comp along with a python raster.py programming module to control the
raster, this allows control of the raster component from user space.

remapping of M codes to control the raster.py raster programming component.


Included is also some tests
/tests/pyhal - also tests hal_port implementation
/tests/raster - tests the rastering component and raster.py programming
interface

Included is also a sim config detailing how to implement a laser engraver
with vector and raster support. In /configs/sim/axes/laser


I have been using this in production for a few months now. I am open to any
and all suggesstions on how to structure, features, functions, etc.

I also think that the HAL_PORT can be used as a primitive to build or
replace a lot of code. Maybe even NML and other forms of shared memory
magic.

Eventually I would like to get this merged into master. I'm open to doing
this in an incremental type fashion so as not to disturb too much at one
time. This is my first "PULL request" with linuxcnc so forgive my ignorance
with regards to this process.

Link to commit, merged with latest master

github.com/OKComputers/linuxcnc/commit/0...934dc4d07765d40f2591

Good Luck!

Thank you very much for your reply.
I had a look on the suggested solution but the graster workflow is working very well in ma application.
For anyone who is still interrested in a "solution"/Workaround:
- I´ve not figured out how to do it propperly but adding the offset within the graster script is ok for me.