Labview UI project for Linuxcnc

When I stopped working on this early last year I used network connections for everything. From a Windows PC to LinuxCnc machine running Linux Mint which then connects to my milling machine in the garage using a custom programmed Mesa 7I80 FPGA card, again with a network. That is three network hops.

My configuration handled any standard NML command and also my custom ones that allow communicating with HAL no issues. It has proved that interfacing with Labview is viable. More work and refinement is needed and planned. I was polling status info over the net at 5 milliseconds intervals and running that into Labview based the status decoder.


Decoding the Status channel has been a challenge because NML status provides raw data with no flags as to data type or offset. The best way I had found in the past to decode all the data within it is to generate an offset and data format for each item when LinuxCnc firsts up. More work required here.

It was working on this when I found out that there are many status variables to are not actually in the normal shared memory segment at all and are possibly being written to some of the other status memory. I know that some status is merged with other status and handled separately and have not investigated this fully.

Do you recall the tool table problem when it was changed to 1000 tools?. This caused a terrific problem in shared status memory that no one saw. Thanks to this project I was able to spot this as very rapidly after I updated LinuxCnc from Master one day during my normal testing. I wrote some Labview code to analyze the problem and as a result traced this down to changes that were made in the size of the tool table some months prior in the updated version of LinuxCnc that I had just installed.

In my 'parked' development system I have commands to NML and HAL from my network working along with status from the shared status memory. NML was sending me back proper responses to my command messages and also the status polling requests to NML. The Labview network code automatically reconnects if a connection is lost. The weak point is in the LinuxCnc server or servers them selves. If these see to many many commands with induced coding errors they shut down and will not recover. Only a LinuxCnc restart can overcome this and is not a good thing.

My thoughts are to modify LinuxCnc to include item tags to each status variable in shared memory to simplify decoding on the remote end. Then gather all status data generated by any special functions and write that into shared memory in the same manner and send the data from both memory segment to the network when polled. But this is likely to change a bit when I look into the various channels and other bits that contain misc status data.

Since Redis has already been added to my development system in the past I will see if it can help me. I have kind of ignored it up to now.

The weak point is in the LinuxCnc server or servers them selves. If these see to many many commands with induced coding errors they shut down and will not recover.

Hm, I would consider this as a misconception.

One thing is - your UI could check for user input errors to avoid them.
On the other side - when you look at nml interface functions - the write functions have a timeout to check, whether the backend has processed the command.
So - I think that lockdown of the backend could be avoided.
I never happened to note the backend becoming unresponsive.

After all, linuxcnc is a machine controller. Not a webserver, that need to deal with dos-attacks. May be I made to less negative tests - but I don't want to break the linuxcnc backend. Just wonna create a solid ui that can deal with linuxcnc.

In my app, there are only 3 classes that deal with nml interface. One for each channel I use. So if there would be an interface change I only need to (ex-)change these 3 classes and my app will run again. I'll gonna reduce dependencies of linuxcnc as a next step.

Labview has had a community free versions available for a while now for both Linux and Windows and can be used for educational or none commercial use. They are easy to download and install with the Linux version being a bit more difficult. Register the Labview package to activate of your choice and your good to go.

Mini computers have come a long way in improved performance as compared to the first ones I programmed with using Dynamic C some fifteen or twenty years back. Running LinuxCnc on one is not something that appeals to me as much as using compact desk top computers for that purpose..

Your input is appreciated and I would like to comment on the shutdown of the servers in LinuxCnc to the outside world and specifically the command channel.

When all is well the servers that route data will likely never shut down. But for reliability testing I used to use the services of a co-worker who usually does unexpected things that I would not do myself because I know what inputs are usual and what is expected. Many times my co-worker could find bugs for me that were not very obvious without even having access to the actual code.

The point of this is that I have run many tests to find potential problems of which server shut down is one. Speed limitations checks have also been performed and kept at high rates during development to see if other factors could cause issues such as communication buffers filling up to maximum allowed and also causing a server shutdown.

Lets look a bit at what happens when the expected is not what is received either due to improper bit alignment or perhaps a incomplete message followed by another message and the server glues the two together as one message.

Now also consider what happens if it does not read the whole second message and makes the left overs bits the first part of the next message. The answer is total confusion and after while the server shuts down. It is possible that the error channel is the watch dog for such problem and thus actually be the actual one that shuts the command server down. So if that is the case not pulling error data out of the error channel buffer memory could also cause server shutdown if the error channel communication link is lost.

I assure you that this type of shutdown can occur and not a misconception. I don't worry about it but have become aware of what can happen when errors occur.

I don't see the point in mentioning a web server. LinuxCnc does not have a web server. It would be more correct to call them point to point communication links for command, status and error data. We are dealing with specific data from a specific machine not wandering all over the place on a external network.

auto-mation-assist wrote:

Labview has had a community free versions available for a while now for both Linux and Windows and can be used for educational or none commercial use. They are easy to download and install with the Linux version being a bit more difficult. Register the Labview package to activate of your choice and your good to go.

Mini computers have come a long way in improved performance as compared to the first ones I programmed with using Dynamic C some fifteen or twenty years back. Running LinuxCnc on one is not something that appeals to me as much as using compact desk top computers for that purpose..

 

First thank you thank you for the clarification re Labview. Will look into it.

I can respect that running Linuxcnc on "mini computers" may not appeal to you, after all we have our own likes, dislikes, goals and such.

Earlier on you mentioned a lack of interest ( or even resistance ) to your project, maybe that could be for the same reasons "mini computers" don't appeal to you.


Whilst I don't understand most of what you are getting at (I'm from a labouring background in carpentry and road works), I can appreciate that you would like a improvement in the way in which data is moved around and presented.

One thing I do understand is that a server is an entity (seems better than thing) that provides a resource to a client and a webserver is only one kind of server, and not the be all & end all.

All the best

Lets look a bit at what happens when the expected is not what is received either due to improper bit alignment or perhaps a incomplete message followed by another message and the server glues the two together as one message.

Sorry, but I would consider thus programming errors. On a propert interface, a user can't produce such errors.

I assure you that this type of shutdown can occur and not a misconception.

Well, I don't think, that linuxcnc has a misconception here. It's your interface code, that could be improved.

Have you had a look at halui?
I you follow that blueprint you get a rocksolid interface.

I thought about highfrequent commands too and tried where that could happen. The only situation I can think of is moving the slider of feed-/speed-override. I was not able to produce a bug - with whatever speed I moved the slider.
So if you talk about highfrequent command causing errors, I think, that's only a theoretically constructed situation without relevance to daily usage.