Labview UI project for Linuxcnc

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?

Reinhard wrote:

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 ?

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?

Thank you Reinhard, i would just add:
Use UGS or similar, or do a search as LinuxCNC already has something like that but no one i know uses it, or start writing something that you need.
LinuxCNC is a product of people who use it, see something missing and add it, not a product of people who complain ......