Labview UI project for Linuxcnc

Andy you are right in using such a conversion chain of Redis, Python code is not desirable and a totally inefficient way to go around interface problems that I have run into with direct access to NML via remote TCP access.

Here is a list of problems I have with my own development which I find difficult to overcome at the present time. These are related to remote access using TCP and NML.

1. Linuxcnc itself keeps good track of command serial numbers but a remote users has no way of knowing what the current expected next serial number should be. Internal Linuxcnc commands that kick of other internal commands increment the command serial number which is a problem for excepting commands from a remote UI since it has no way of knowing that internal commands are incrementing the serial number. I have worked around this problem in by disabling serial number checking from the remote so that commands do not get kicked out while doing development work.

2. If for some reason a command is processed from the remote via TCP and the serial number it sent is determined to be invalid and if commands continue to be sent with the next normally expected serial number the Linuxcnc TCP server it will stop responding and it will require a Linuxcnc restart to reactivate the TCP server. This appears to be due to the initial command being processed in a improper way somehow and not being discarded. This results in the next expected serial number to be a large invalid number which changes with each new command sent until the server stops responding. In such a case the serial number appears to be possibly merged with other values or fields in the command that was sent.

3. When requesting a status update (contains all values from the shared memory status copy) it is a problem to know for sure what the offset of each value is. I decoded a good number of values in this data transfer but I have also been told that these offset values can change based on configuration changes. This is a problem that needs to be overcome. Typically status when requested is done by name of a item and its offset is determined from there. The TCP server can output all status data at once extremely rapidly which can then be properly decodes by its offsets once received by the remote. Thus a offset versus items list is required by the remote but such a complete list is not presently available as a file or as part of added shared memory to the best of my knowledge.

4. Linuxcnc itself is constantly reading the shared memory status buffer at a extremely high rate and decoding its info by item name. There is information in the status buffer that constantly changing due to the "status" request itself. Thus it may actually be self polling at maximum system rate and not as expected by the currently used server method.

Note: The method used currently used for status was changed from a old method by Linuxcnc developers not long ago to a new server method which to me also seemed to change command serial number handling a bit.

5. There have been a number of changes made to Linuxcnc that I think may have been detrimental to using the remote capabilities of Linuxcnc due to having been changed from remote and local use to local access only. Such changes may have been due to the concept that "no body uses the remote functions and we have no way to actually check remote use". But the future of Linuxcnc should indeed include complete remote control capability via a standard well defined interface for user control and programing. It is time for such an interface to be developed and refined since so much more flexibility will be gained.

I'm sure that withing the Linuxcnc community that the expertise to accomplish this there but that a little nudge towards motivation may be needed. I would be glad to help with any testing required.

Is your desire to have a remotely-controlled LinuxCNC for your own use, or do you want to see the remote control capabilities of LinuxCNC improved?

In the former case I understand that Machinekit might be better for your purposes, as remote control was determined to be a core requirement in that project.

Have you seen the NML docs? Perhaps there is a hint in there how NML / CMS is meant to work?
www.nist.gov/el/intelligent-systems-divi...-programmers-guide-c

In reference to:
"Is your desire to have a remotely-controlled LinuxCNC for your own use, or do you want to see the remote control capabilities of LinuxCNC improved?"

Answer for first part:

The improvements I suggest will benifit all LinuxCNC users. I'm already using this for myself on stripped down version of LinuxCNC for remote use development use. However It would be much more beneficial if time could be spent on updating the remote use of LinuxCNC as a team effort. This should not be to difficult since there is absolutely no need to replace NML and its associated code.

Answer for second part:

Yes, I want to see the remote control capabilities of LinuxCNC improved by updating parts of NML and and associated code that it causing some issues relating to handling of command serial numbers and offset values for all items contained in the raw status data that is transferred by TCP link.

Work required: Requires review of how the values for these are presently handled and modifying them as required to make more suitable for shared use between LinuxCNC proper and any remote UI that also needs and uses this information for encoding and decoding the values.

In reference to:

"In the former case I understand that Machinekit might be better for your purposes, as remote control was determined to be a core requirement in that project."

I think Machinekit was started by persons like me that would like to see improvements with remote functions that are already available within LinuxCNC. I have run Machinekit and believe that LinuxCNC as is, but with updates to improve certain remote behaviors is a much better choice. Thus I disagree that Machinekit is a better choice for remote operations due to the many changes and additions they have made.

In reference to:

"Have you seen the NML docs? Perhaps there is a hint in there how NML / CMS is meant to work?"

Answer:

I have printed copies of all NIST documentation relating to EMC and have in the past read specific sections relating to NML and CMS that relate to specific problems that I needed additional supporting information for. I'm certainly far from being an expert but understand what information is needed for a remote UI to operated efficiently.

In my prior post I listed a number of items that I have identified as being problem areas, (1 - 5) and these are real issues that need a workable solution. But unless a remote UI such as the partially completed one I have been testing with and uses direct access NLM via a TCP network connection these problems will likely never show up. So what to do.

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 think if NML is a preexisting standard that is not captured by the Linuxcnc GPL license, the standard must be followed faithfully. The reason for that is that it would provide an opportunity for other closed source systems to interface with Linuxcnc. As an example, Les Newell's Sheetcam post processor wants to send jobs direct to the CNC controller but this is difficult to do this from Windows and comply with the GPL license without recoding the interface from scratch.

interoperability is the name of the game in computer systems today so the lack of such an interface will be to the detriment of the project into the future. Conversely, supporting closed source post processors give an opportunity to bring serious new blood into the the project that may bring well resourced development teams.

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