Labview UI project for Linuxcnc

More
30 Aug 2020 07:35 #180032 by Reinhard

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.

Please Log in or Create an account to join the conversation.

More
30 Aug 2020 07:50 #180034 by rodw

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

Please Log in or Create an account to join the conversation.

More
30 Aug 2020 10:20 #180048 by andypugh

auto-mation-assist wrote: Its really not my issue alone its more of a issue belonging to LinuxCNC because of extremely limited use and testing of its remote use potential. Some things are just going to require more thought so minor changes can be made to allow every mode of operation and control to work well.


I wonder if some form of "working group" would be a good idea?
If so then I would suggest a post here, and also to the user and developer mailing lists and maybe the cnczone linuxcnc forum section.

For the actual discussion perhaps gitter.io would work. It behaves a bit like IRC but is persistent and sends update emails. I only know it because STMBL use it. ( gitter.im/rene-dev/stmbl )

I can't see myself joining in. It's not very important to me and I am short of time.
The following user(s) said Thank You: rodw

Please Log in or Create an account to join the conversation.

More
30 Aug 2020 12:24 #180060 by Reinhard

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.

Please Log in or Create an account to join the conversation.

More
30 Aug 2020 12:57 #180065 by andypugh

Reinhard wrote: 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.


I think that NML pre-dates LinuxCNC, and exists separately from LinuxCNC.

www.nist.gov/system/files/documents/el/isd/cs/nml-tutorial.pdf

States that NML is public domain:

NML isfreely available
NML Availability
– developed by U. S. Government employees as part of their official duties, and not subject to copyright
– source code can be used for any purpose • understanding and debug
• porting to new platforms
• modification for commercialization
– Links to all NML documentation at
www.isd.mel.nist.gov/projects/rcslib/

Please Log in or Create an account to join the conversation.

More
30 Aug 2020 13:48 #180072 by Reinhard
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?

Please Log in or Create an account to join the conversation.

More
30 Aug 2020 14:26 #180078 by andypugh
It's the same link as the github (which appears to be active)
github.com/usnistgov/rcslib

Please Log in or Create an account to join the conversation.

More
30 Aug 2020 19:12 #180098 by rodw
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.

Please Log in or Create an account to join the conversation.

More
31 Aug 2020 05:32 - 31 Aug 2020 05:39 #180136 by auto-mation-assist
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.
Attachments:
Last edit: 31 Aug 2020 05:39 by auto-mation-assist.

Please Log in or Create an account to join the conversation.

More
31 Aug 2020 14:43 #180171 by Reinhard
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
The following user(s) said Thank You: rodw

Please Log in or Create an account to join the conversation.

Time to create page: 0.154 seconds
Powered by Kunena Forum