Labview UI project for Linuxcnc

I have been pondering over a efficient way to to decode the 9280 byte status transfer to the remote target that uses offset values from the top of the 9280 byte data. To do that requires at the minimum offset value from the top. Unfortunately how the shared status file is initialized depends on the configuration which may not be constant and thus location of items within the status data may vary.

Knowing the exact location of each items value in the status data can make retrieving those values at the remote very efficient. The difficulty is that there is no offset list generated from available pointers to that data and end up using things like emcStatus->motion.traj.actualPosition.tran.x because it always knows where to find that data. I think that sending individual commands like this, if excepted from a remote would not be very efficient.

1. In pondering is it not possible to generate a offset list from status commands like the one above or is a more complex method required? If so are samples of code available?

2. Does it require an Linux IPC expert to accomplish developing such a function, or making changes required ?

3. Would it be efficient to use Redis be used as a status data base for a remote user if all else fails?

I have attached a sorted file that show all the present emcStatus-> type commands on my rmc development system that is based on 2.9 pre 0 and likely available on most all other versions of LinuxCNC. I have 231 listed in order in the rmcStatusSorted.txt file.






.

auto-mation-assist wrote:

Knowing the exact location of each items value in the status data ...

You know the exact location after a call to status channel function, which returns the address. That function needs to be executed only once at runtime. Memory address may change at each start, but is stable during runtime.
I stored the offsets of all fields in my app - so its possible to work that way.
Java-world does not know anything about C structures.
.

... can make retrieving those values at the remote very efficient.

No. At least if you want to follow common standards. Many of the status fields are numbers, which have different coding in memory. PC uses little endian and network is known to use big endian.
So on a remote pc you need to convert from little endian to big endian (on the backend-pc), transfer the value and then convert the big endian to little endian on the target pc.
That's everything but efficient.
.

auto-mation-assist wrote:

I think that sending individual commands like this, if excepted from a remote would not be very efficient.

Then you didn't understand the command channel. It's quite different to status handling.
I already told the sample code. Take a closer look.

When I wrote: " I think that sending individual commands like this, if excepted from a remote would not be very efficient".

I meant this to refer to getting status values for everything that status has to offer by a single command for each item, Two hundred or so individual commands and replies would be inefficient for such a task.

In your comment "Then you didn't understand the command channel. It's quite different to status handling".

Since I have a working remote UI that encodes numerous commands and decodes responses I think that I have a fair understanding of the cmd channel and status data. It would be more correct to say that I don't yet understand how I can make a control list within LinuxCNC that links every available status item to a specific location in the raw status data. This is what I'm working on to overcome.

As an aid to finding the best method I'm currently reviewing: opensource.com/article/19/4/interprocess...cation-linux-storage

I don't yet understand how I can make a control list within LinuxCNC that links every available status item to a specific location in the raw status data.

Well, I don't understand, why you should want to do such things. There's no need to.

If you want to transfer a subset only, create your own struct and copy the desired values into your struct. As you have to convert each single value to big endian before sending it over network, copy is no overkill.
So read from linuxcnc nml-buffer, convert the values and put it into your struct. Then you have a well known address and the network format and can start a bulk transfer.

That's the stub I was talking about. No need to change anything of linuxcnc

If you want to transfer the whole status and don't care for standards, use the memory address retrieved from nml-status-call. That address does not change during runtime and you could issue bulk transfers with that pointer.

I had a long message ready in reply but hit the delete all button after attaching a file that does not offer 'are you sure' and lost the whole message.. So here is my very short answer instead.

In ref to: "Well, I don't understand, why you should want to do such things."

The status data that is currently available and transferred by LinuxCNC to a remote user using the TCP server needs to be improved to allow a more friendly way to decode the data contained in the raw data file that is transferred. The work around that is proposed does not resolve this and have already been considered on my end and not planned to be used unless all other options are totally exhausted.

In ref to: "There's no need to."

This would only be true if no problem is seen with the present TCP server status response request and the ability to decode easily and accurately. In my conversation with the NIST developer this a known problem. Being a user of the TCP server transferred data and having decoded some but not all data points I can verify that this is indeed a problem.

Coding work-arounds are presently being used on a individual user bases but this is not beneficial to everyone who desires to use the full capability of the TCP server status data transfers. It also does not provide a standard that all users can depend on.

LinuxCNC makes extensive use of memory management commands and I'm trying to get a better overall understanding of this. As a result I built a list for my development system of all files that have code to manipulate memory directly. The attached 'Memory-Cmd-List.txt' file lists memory 'command type', 'number of time used in a file', and also 'file location and name'. This list is likely similar to any ones system but has some changes in file names and possibly locations.

Redis is installed on my development system as part of LinuxCNC for testing but is not used yet, Redis by itself uses memory commands very extensively. I have not listed Redis memory items in the attached file

Here are three more files that break these down files for locations that I'm focused on right now.

\src\libnml\
\src\rmc\ rmc being emc
\src\rtapi\

The status data that is currently available and transferred by LinuxCNC to a remote user using the TCP server needs to be improved to allow a more friendly way to decode the data contained in the raw data file that is transferred.

You want to use linuxcnc api calls and you are unhappy with the data it offers?

All your "problems" lead to the same answer: don't use api that make you unhappy. Write your own stub, which is a tcp-server, that reads from shared memory. Well, I wouldn't go for tcp, but use udp broadcast. That's faster and is able to serve many clients at the same time ...
... and status data needs no answer from clients. So ...

Sorry, I'm at a bit of a loss here why there is a focus on memory functions. I still have not dabbled with remote access but what is wrong with using malloc() and memset() et al? (aside from the usual caveats)

I do like the idea of a modern API to interface with the older NML stuff. Why can't Linuxcnc be managed from a web browser on the other side of the world? Why can't we have a JSON hook or similar to update the screen ?

Why can't Linuxcnc be managed from a web browser on the other side of the world? Why can't we have a JSON hook or similar to update the screen ?

Hm, what do you suppose?
Do you want an axis that runs in a browser?
That should be no problem to realize - but someone has to take the time and write that app.

But what is the benefit of such a work? Do you really want to drive your plasma cutter resting in your living room and playing with your tablet?