Labview UI project for Linuxcnc

I have been thinking about the best way to proceed with my project. I have used Linuxcnc for testing and developed a method to be able to interface with NML but there are a number of issues with this due to the fact that many processes that have been developed over the years also interface with NML and conflict with direct access with NML from the outside world via port 5005 now.

Well, I would have tried to leave internal communication work with shared memory and develop a bridge from shared memory to your network ...
.

I have the latest version of MachineKit installed and it is able to control my milling machine which uses a Mesa 7I80 board as its networked interface.

Hm, MachineKit looks like a fork that already is driven far away from linuxcnc. Some of their solutions are good stuff (i.e. generalized logging or changed shared memory handling). They work on replacement of nml, so you have to recode your whole project.
is it worth that amount of time?

Linuxcnc has always been my first choice since I first ran into it many years ago when I was still using Mach3. As a matter of fact I still have a machine that uses Mach3 that needs conversion some day. Mach4 came along and I was set up as a plug in developer/provider for it and licensed to use it. Im not sure when I ran into Machinekit for the first time. But Linuxcnc kept most of my attention, however it had and has no real network interface other than Telnet.

The way I see the future of Linuxcnc is that all Guis would interface to it via TCP connections either using localhost or remotely, and all user interfaces would be removed from Linuxcnc proper and replaced a standard well documented network interface. Machinekit developers have already accomplished this with their more distributed way of looking at things and handling interfaces. Thus my focus will be on working with Machinekit for a while.

It is not a minor task to develop remote interface such as the one the Machinekit developers have developed. I have run into comments on the internet that it took over two years for developers of Machinekit to develop the present version of their haltalk network interface.

Back to my project: Changing over the TCP interfaces of the Gui that I'm working on from Linuxcnc nml to Machinekit remote will likely not be to difficult. The TCP network interfaces are actually just a small fragment of the Gui code.

I have been working on this project a bit more using Linuxcnc version 2.9. From this version I have removed all normally supplied user interfaces since they would not be used on a system that runs user interfaces via either localhost or remotely. A few items were isolated from the axis user interface before it was deleted since the system required some items that are located in the axis extensions and scrips folders.

In doing some research going back to 2012 there was some effort at that time to include Redis into Linuxcnc to allow local and remote access. I suspect that from the effort in 2012 that this was found to be very useful and that thus possibly lead Tormach to use it within their user interface. I have also found Redis to be very useful and thus have added the latest version (Redis 5.0.7) to my 2.9 Linxcnc version. I added so that it compiles during the normal Linuxcnc build process with modified and additional Linuxcnc build commands that run automatically.

I have been able to communicate from Labview to and from Linuxcnc Redis. Using manual commands Redis is handling the commands and command verifications properly on both its local and remote network connections.

Information on Redis can be found here: redis.io/

In order to make special hal pins that may be required later I decided to use halui.cc for this. It already has quite a number of pins that is used by everyone so it is very useful as is but it can be made more useful. When I eliminated all the user interfaces halui was also deleted from my version of Linuxcnc 2.9. I copied it before deletion to its own folder and renamed it x1Millui so as not to cause confusion later. I made internal name changes to the items in the file and also in other locations that had the name halui. Items that were required to be taken from axis were also placed in that folder. All these compile now with the normal modified Linuxcnc build process.

Using halshow show the pins generated under group 1xMillui and all its pins all have the prefix off x1Millui. Now I need some code that can communicate with both Redis and Linuxcnc to actually set and get data from hal pins when the Display in my .ini file is set to dummy. I suspect hat there are various ways that this could be done but its an area that Im not real familiar with. Redis does have Python and C++ clients available. Any suggestion will be greatly appreciated.

I have read on the internet that National Instrument may come out with a Community version of Labview. A time frame of May has been mentioned.

Hi,

when I started with my UI project I did similar researches than you. Don't know whether it is true, but my results where, that its not possible to interact with halpins from outside RT world.
As you already realized, ethernet ports are not usable for common usage too.
So my conclusion was: shared memory is the only interface fast and usable for multiple clients active at the same time. I used that during my development and it helped me a lot!
Therefore I don't understand, why you went different way.

any way - I think: if you create a halui counterpart with shared memory access, it could be the bridge between linuxcnc and your world

I will go this direction, when my hardware is ready to use.

cheers Reinhard

auto-mation-assist wrote: In doing some research going back to 2012 there was some effort at that time to include Redis into Linuxcnc to allow local and remote access.

The split between LinuxCNC and MachineKit happened before Redis was introduced, so I think that Machinekit might have it, but linuxCNC does not.

I have not seen Redis being used in any versions of machinekit that I have looked at over the years. As far as I can tell only PathPilot is using it in all the versions but it is a older version 2. I don't recall exactly which version of 2 it is. The latest PathPilot source code disk (version 2.2.4) includes it in the depends folder and appears to use a different installation method.