Labview UI project for Linuxcnc

I have been away for a while due to digging into NML and RSC for several months. RSC having been created several years before the EMC project was created back in the early 1990's. NML classes used for handling internal and external messages between process was part of the NIST Gov RSC project but separate to it. Thus these are both about 30 years old.

There have been some upgrades to these over the years on these but those upgrades do not appear to be useful for Linuxcnc (EMC) and provide no real benefit for it.

This thus calls for an alternative to the existing NML-RSC combination. But integrating a working alternative to replace the NML-RSC combination will be a time consuming task but well worth the effort. Once completed it will be a lot simpler to to provide a standard interface for any remote or local UI to link into Linuxcnc without any requirement to be an actual part of Linuxcnc itself which would reduce future Linuxcnc maintenance requirements significantly.

I have started my own project and starting to get things installed in one of my development systems to accomplish this. To replace the NML-RSC combination I have CapnProto C++ Installed as part my Linuxcnc make configuration which I call RMC for Remote Machine Controller. CapnProto uses schema file to define messages. I suspect that the MachineKit proto files for each Linuxcnc sub modules can be used for the CapnProto schema files, or at least as a guide as to what is needed with potentially minimal changes.

The way I hope to proceed is to make parallel test paths within Linuxcnc, one for the old and one for the new CapnProto on the same running copy of Linuxcnc and then assure that both produce the same results. I will be using my Labview user interface running on Win7 machine to link into both the legacy and CapnProto servers in Linuxcnc for all testing. I hope to be able to post some info as I go along on this project on www.rmcsys.org but I have not found the time to set up the site yet. It will be a while before this can be done and will focus mainly on developing Labview Gui's.

I don't believe that milestone was completed.
They did add remoTe HAL capibility.

But I'm certainly not up to speed.
It would be nice to replace NML with something documented though.
The NML barrier is very high for potential developers.
Good luck!

I must say it saddens me that most of the interesting development work is being done outside the linuxcnc project.
Seems to suggest a problem with our project.

Chris

Its been a while since I have worked on this project. The Labview Community edition has been out for a while for noncommercial and nonacademic use from NI. I that believe only the 32 bit version is available at the present time from: www.ni.com/en-us/support/downloads/softw....labview.html#345658.

For those of us that like Labview and the flexibility it offers has great value not only as to its capability to process data but also as a intelligent user interface that can be interfaced into LinuxCnc in various ways. Thus I would like to see more development work done to make interfacing LinuxCnc and Labview easier.

I'm looking at Redis again as one good solution especially since it is already being used by PathPilot which uses primarily the Redis commands, (hdel, hexists, hget, hgetall, hkeys, hmset, hset, lindex, llen, lpop, rpush, save) to link into the Python part of LinuxCnc.

Since there is a Labview toolkit available for Redis it should be possible to to use Redis to interface to Python within Linuxcnc from a remote network UI as an alternative to using the NML interface I have been testing with in the past.

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.

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.