Labview UI project for Linuxcnc

But the future of Linuxcnc should indeed include complete remote control capability via a standard well defined interface for user control and programing.

I don't agree with that requirement.
Linuxcnc is a machine-controller, which runs locally on the machines CPU (whatever that is). All remote requirements may be status information or run outside the machine controller (like file transfer or the like).

I don't want, that remote command access is possible to the machine controller. As if it is possible, it can be abused.

But anyway ...

I created an UI application, that uses NML-layer for command and status handling. Of cause only locally!

... let's look at your problems:
1. command number handling - I use the same code as axis UI and never had problems with rejected commands. Even with running my app simultaneously with axis and issue commands from both applications alternately didn't cause that problems (and no app did no about the serial numbers of the other app)
What might be a problem is the error-channel - if I run my app synchronously with axis together. Its unpredictable, which app receives the error.
But as two simultaneously running UIs are not common, this is not an issue of linuxcnc

3. status member offset - I run into the same problems, due to update changes. So I wrote a little checker, that I run at each update. This checker tells me each member, where its offset has been changed. Its a very small programm, so this is not an issue of linuxcnc

4. status reading frequency - first of all, status in shared memory should be considered private to linuxcnc backend and for so, the backend may read or update status at any frequency that might be appropriate for the backend.
All other users are "RO-clients" and none of them has realtime requirements.
For example if the backend updates the position 10 times faster as the UI reads position - so what. Human eye is not capable of reading number faster than 10 times a second - so why should an UI application read the values faster than humans can consume it?

5. changes to linuxcnc - I created a little library for my application, that handles all nml and hal tasks. That library is part of my project and I have the tools, that ensure interface compatibility. Same could be worked out for mathlab - there's no reason to blame linuxcnc
.

I think if NML is a preexisting standard that is not captured by the Linuxcnc GPL license, the standard must be followed faithfully.

I don't see a license problem. But if someone likes to use an internal interface of another application, it should be taken for granted, that the interface definition belongs to the creator and the user has to live with it.

Reinhard wrote:

I think if NML is a preexisting standard that is not captured by the Linuxcnc GPL license, the standard must be followed faithfully.

I don't see a license problem. But if someone likes to use an internal interface of another application, it should be taken for granted, that the interface definition belongs to the creator and the user has to live with it.

The same goes for Linuxcnc. If its using a documented standard (NML), it needs to stick faithfully to the standard. After all thats what standards are for.

I totally agree that external programs should not be accessing Linuxcnc's shared memory.

There is definitely a license problem mixing closed source software with GPL2 code like Linuxcnc. But then I wondered if Linuxcnc actually has the ability to include the NML core in its GLP2 license as it might not be theirs in the first place. I just don't know enough of the Linuxcnc/EMC/NIST/NML history

rodw wrote:

The same goes for Linuxcnc. If its using a documented standard (NML), it needs to stick faithfully to the standard. After all thats what standards are for.

Hm, afaik NML is not a standard, but a well known layer created for linuxcnc, that is part of linuxcnc. That layer uses CMS as interface, which is part of linuxcnc too.
.

rodw wrote:

I totally agree that external programs should not be accessing Linuxcnc's shared memory.

Hm, all UI applications access linuxcnc shared memory - but treat them (I hope so) as readonly.
.

rodw wrote:

There is definitely a license problem mixing closed source software with GPL2 code like Linuxcnc.

Hm, please help me - where is closed source related to NML?
If that would be closed source, I wouldn't be able to write my application.

Andy thank you very much for clarification.
Didn't know, that NML is used outside of linuxcnc.

Tutorial said, that java port exists too - didn't know that. I developed the java part on my own. Well, derived from axis code

Second link does not exists. Outdated or wrong?

Andy, thanks, very interesting.
Their license in git
github.com/usnistgov/rcslib/blob/master/COPYING

And their overview in GIT


I've never even attempted to decipher how to use NML so hats off to Reinhard for tackling it.
Its a shame its not made clearer in the Linuxcnc docs the licensing model for this interface.

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