Welcome to LinuxCNC.org

Hi Michael,

The requirement I have is pretty specific and minor, for testing and diagnostic purposes.

When I last wrote and tested a RT component, I had to open Machine Configuration, then select Pins, then select the component, then select Watch, and finally select all the pins I want to watch, every single time I restarted Axis to test a change to code.

I wanted a way to link the relevant signals to a userspace component, which in turn fed a socket-server from whence they could be retrieved by another program.

That will enable me to write a C++ QT program (since that is what I am familiar with) which can read and display the relevant values, without having to hook into the underlying code for EMC.
It can stay open all the time as it has no need for the RT system itself, just reads the data sent when Axis and EMC are running

Your suggestion of using redis was ideal, saved having to set up a simple database structure for reads and writes.

Doubtless there is a far simpler way to do this, making Machine Configuration a standalone app without RT reliance perhaps?
But that requires python knowledge I don't have and it would be more productive to find a method in a language and SDK I am familiar with.

So nothing earth shattering, just a different approach to something.

regards

Hi.
I finally did some experiment with memcache and redis.
My testing ground is a rappresentation of my machine, drawn with VPython. I wanted to try that because i find Vismach a little jerky, and difficoult to personalize.
From my gladevcp i'm recording 6 floating into the server (one server per time, first redis, then memcache.)
these vars are x,y,z of my machine (static) and x,y,z of the end-effector.(of course, changing..)
I've found both ways not responding much fast, in the sense that the resulting movement into the VPython drawing is a little jerky too. in both ways.
maybe i should add an interval, let's say every 1/30 of a second to record the vars. I know (imagine) it's not VPython problem, because it can print on the window the refreshing interval, and it is around 30-50 ms.

One difference i've noted is that using memcache, when i get a value that was a float, i can read as a float, while using redis i have to float(get) it to convert.

Then, if someone cares, I have to say VPython is infinitely simpler to use as a graphic visualizator. and really much personalizable.
Did anyone else tried?

Again about memcache/redis, if anyone knows a faster way to record and read vars, than the standard set & get of those modules, i'll try.

Ciao, Davide.
EDIT: EHMM..... Maybe I only talked too soon.. i'm looking at the L_CNC scope and found out that the jerkiness comes from halui, and DOESN'T depend on memcache, nor on redis.
I'll study this issue a little more, but considering that i'm doing on a sim setup, maybe i don't have to expect a lot.

Yes, infact if I net the hal_pins from which i record for redis/memcache to 'axis.x.pos-cmd' instead of netting to 'halui.0.pos-commanded', the Vpython movement aren't anymore jerky.
I'll do the same for the vismach object (that in the picture).


I wonder why the halui pins give those steps...

Ciao Davide.

let me clarifiy what I intend to use redis for, and where it fits in the overall picture IMV; also with the intent to avoid disappointment:

I plan to use it as a name space for state which are to be shared between different parts/processes of LinuxCNC. What is currently lacking in communication between different components is:

- there is a lot of state in task and the interpreter which does not fit into the current HAL and NML framework, and there is no way to access it in an extensible fashion

- some areas of LinuxCNC are severly limited in options by not having a way to access/modify this state while still retaining the option of running UI's on a different machine than the RT control part - which I think is a good design decision and should be retained, even if not used much now

- the state seen/exported by task and interpreter is currently fixed at compile time, despite the fact that we have now an embedded Python capability which makes access to internal state very easy, and HAL does not help here much either.

- a good example for the type of problem the redis integration will help with is tool information handling. Currently tool information is quite limited and not extensible with new properties (think of wear information, arbitrary changer arrangements etc). This kind of state is not realtime in nature, but should be extensible, by the user/integrator.

- the way this information typically will be handled is event-driven: some part of LinuxCNC change some part of state *when it's relevant*, but the redis DB doesnt necessarily track state in other components like HAL immediately shares variables between userland components and kernel modules. However, redis would work over TCP just alike; even if one extended HAL that wouldnt help with networked configurations.

While redis is very fast, keep in mind it isnt shared memory.

- Michael