Labview UI project for Linuxcnc

This is gone a little off topic......

I'm a little naive regarding Labview, so.........

So to use your interface one would need labview ?

Does one need to pay for Labview, all references I have seen point to this being the case. tho if this is not the case.

Making an assumption....(which I would refer to my naivety)
Maybe the resistance could be having to pay for Labview to run your interface.

Now I'm not much of a prgrammer, anything at a higher level than plain old ANSI C makes life hard for this old boy.
Tho it would be nice to have a standard interface, say by something like sockets (with docs ), that would allow one to create an interface in the language of their choosing.
Now would that allow one to run Linuxcnc without X using ncurses....maybe something similar to the Turbocnc interface.A Resurrection Keystick or along those lines.

Although I may have this all wrong.

Would linuxcnc without X be more suitable for lower power ARM boards, perhaps using something Allwincnc or Remora (I know currently targeted at the RPi) . Would this also benefit those in areas where lower specs PC's are available (to run a GUI only) and an ARM board to run motion control.

Maybe the ARM board could be "sold" as a "black box" to windows users in the same way as GRBL is ? A Linuxcnc compatiable GUI runs on a windows box and the meat is done by the "ARM Black Box".

Apologies to all for going off topic.

Hi,

But there appears to be a lot of resistance but then I have also not seen any comments to date that adding a universal interface is would not desirable.

If i look at projects like Reinhard's interface, he is on his own. In my perspection his project is a challenge.
But he did it.
Maybe you could replace restistance into unkwown. Breaking down lcnc is almost impossible trough all the
entanglement. A few weeks ago someone posted a sort of pre-compile overview. This shows the nightmare scenario
we are facing.

The python club is quite large and supported. If there is a question
about python most of the time Mr. Morley and others know how to deal things.

Some time ago i made a universal interface from the c++ side of lcnc to python, it was a request.
The process of making the python interface was more or less automated by script, i found out.
It was for interfacing nml and linuxcnc to python.
The converter step had 2 things, 1. Sip, and 2. Qt5 to PyQt5. archives

I can imagine if you do the same for your project with other language tools, you can have a interface in a short time.

I think to aid in my work that I will need to breakdown LinuxCnc into its major blocks  and generate maps to get a better understanding of how data is routed between various building blocks.

When compiling for lcnc the compile slogan tells a lot about the building blocks, but you already know.
-Isrc/emc/rs274ngc -Llib -lnml -llinuxcnc -llinuxcnchal -llinuxcncini -DULAPI -lposemath

A few years ago, when i started to be working with lcnc, i also made a interface based on glade and python.
And it used a component. After that i merged the adaptive feed and external offsets into my own github lcnc clone.
After that i was getting stuck making progress.

I also decided to break down lcnc. So i did, but i was only interested in a clean hal environement without any entanglement.
When this was done, i could design a new system. The complexity i sometimes face is related to understanding high level
c++, like using templates, or complex code like trajectory planners, etc.

The most significant issue that I see is that I would like a interface as I have mentioned many times in the past that is not available right now but has the potential of being extremely beneficial. I sure such a interface will be incorporated in some way or other at some point in time.

When you have the interface working in your language, then the interface to python or c++ has to be made.
When you are sure, why not code it? If it's good, it will be incorporated, or just provide it as git repository like Reinhard does.

Oke. I wish you good luck and happy times !











 

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.

It is just a problem when messages get out of sync nothing more. NML expects certain number of bytes for each command. It is not happy when it gets more or less. My code is fine but improvements are always a possibility.

I'm interest in looking at your work but have no idea where I can find it.

I have been busy cleaning out my development computer. Its running on Linux mint  20.2 now and using the 5.10.0-9-RT-amd64 kernel. The latest Linuxcnc master is installed and compiled without problems.

I'm now working on installing Redis version 6.2.6 in my added depends folder in the source folder of Linuxcnc. The Redis Python module has also been placed in its own folder there. Once this is all done I  will migrate what is needed from my old code. I expect that this will take a while since Linuxcnc appears to have had many changes in the past year.

I ran into a minor issue while working on the makefiles for the addition or Redis and the Python module, when run "make clean" it deletes my nice "depends" folder and all its contents, kind of rude if you ask me. I need overcome this shortly and let Linuxcnc know that these are part of the team and not invaders so that I can get  Redis and the PY module compiled.

In reading back the history of Redis in Linuxcnc it was removed back in 2013 or so. Linuxcnc has been improved since 2013 and so has Redis. But it is has been used for years by Path Pilot with great success even with a much older version of Redis for handling Python transactions. Was removing it a mistake ?