Labview UI project for Linuxcnc

I ended up moving my development system today and after this was completed and everything talking together again I decided to capture some of the debug files which show the interaction from commands send from the Labview based remote Ui that I have been working on. I thought that these may be of interest to those individual working or planning on a project such as this.

The attached RAR file containes 5 separate files, StatusInfo.txt, CmdlinkPolling.txt, IssueCommands.txt, Shutdown.txt and StartUp.txt.
The startup text is to large for a .txt attachment thus the use of a RAR file for all.

The StartUp.txt and ShutDown.txt were initiated on the Linux machine not the Windows one.

Hi Rod,

the picture from nistlib looks quite complicated. You only need to follow that picture if you want to create a new application that uses NML. I don't use generated code - all code is handwritten.

I didn't want to create a new memory scheme, so I followed the linuxcnc-way, which is much easier. Backend offers 3 channels for UI apps:

• command channel
• error channel
• status channel

which basically needs just one function each. All other functions are "nice to have" ...
src/emc/usr_intf/axis/extensions/emcmodule.cc is the base for this.
I coded these three functions as C-code / JNI-code, which gets loaded and executed by the java runtime (way before my app gets started).
Commands are sent just in time and my app does not care about command serials at all.
Status function has to be executed only once - to get the address of the nml status buffer.
Java has a very powerful buffer class called ByteBuffer. That class is able to do integer conversion between different memory models (that works under the hood - you don't have to care about).
So all status reading happens in java code. There I have descriptors for each field of interest and I read the status area unrelated to backend thread frequency.

If I got it right, halio works the same way - and I predicate that such a stub would be the best way to connect remote applications to linuxcnc backend.

If you want to know, what commands could be sent to linuxcnc backend, have a look at src/emc/nml_intf/emc_nml.hh.

cheers Reinhard

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.