Labview UI project for Linuxcnc

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

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.

I agree that shared memory access is the best option and Labview has that option available for Linux. I really like being able to interface directly with NML but there are some issues.

One of these is keeping track on command serial numbers. Command serial number tracking on the network side is not separated from the command serial numbers used on the internal side. Commands generated internally like perhaps the python interface increment the command serial number and thus the external world has no idea what the actual next serial number should be.

Even sending a command directly to nml that causes multiple additional commands to be executed internally automatically increments the command serial number. It thus becomes impossible to keep them in sync with present Linuxcnc code. To overcome this under present conditions the command serial number verification checking has to be disabled for commands coming from from the network side.

If I recall correctly Linuxcnc version 2.9 got some code changes in the handling of the command serial numbers for internal commands. But the above problem will remain until there is a way to store the last command serial used and pass it automatically to the network side when a remote logs on, and each time the command serial number is incremented by any method.

My thoughts on Redis. Redis has the potential of being very useful in that it can provide a relatively simple way of providing an additional option to provide network connectivity. It would thus be a addition and not replace the direct nml interface. With Redis being compiled by the Linuxcnc make process it is only active when Linuxcnc is running. Redis would not be installed into linux itself, which in my case is linux mint.

Its been a while since I worked on my project but its time to continue with the main parts. I have my test environment working with my modified Linuxcnc version 2.9 for testing with network access from port 5005 directly into nml. So far I have not found any issues with the work I did with Linuxcnc version 2.8 and migrating those to version 2.9.

Some additional items that I have also added for potential use later on are the Redis interface, USBio and Suttlexpress.

One of the main things that I need to work on is decoding more items contained in the 9196 Byte status string which would likely give the best performance but will take considerable effort. Part of the 9196 bytes is a header, with debug selection types at the end.

As a point of interest I have attached some pictures of part of the command data link Labview code and its current front panel that allows for monitoring of various data points. Also a overall view which will see some changes later on the top left side.





The K dro handles the linear scale on the knee of the mill.

Hi, as a test engineer I have worked for a long time with LabVIEW and TestStand, for data acquisition and test purposes, in business environments. as you previously mention many people have access to a LabVIEW license, because of business or education, I have been following your project and trying to figure it out what is the value-added of your project.
on one hand one of the most well supported and business-oriented development ecosystem.
on the other the greatest open CNC control software, product of big altruist effort.

Then you come up with this combination, it is clear to me that it has:
-Great academic value
-Open LunuxCNC to a big and talented developer community (LabVIEW people).

I want to congrats you for the brave attitude.

Just a short update.

I'm primarily working on adding hal pins and insuring that they can be accessed locally and from the network. Status from those pins is also being routed to the NML status buffer for verification use by the local and network side.

Using status on the remote side requires decoding of the raw status data from the NML status buffer once it arrives via one of the network communication processes. All coding required on the Linuxcnc side has been done in C++ and with Labview for the remote side.

Very good thread .... but I haven't seen it until today when AndyPug told me about the user list.

After a few years I dusted off my whole C ++ interface project. Now while getting the status from nml is a relatively simple thing, I still haven't figured out how to send the commands to nml.

This problem derives from the fact that
1 - I am an amateur
2- I do not use the terminal as a debug for applications since '96
3- and this is the most serious thing, I have never properly studied the Lcnc files always referring to tomorrow. ..

now my doubt:
so I have to call the class RCS_CMD_CHANNEL or the function int emcFormat (type NMLTYPE, void * buffer, CMS * cms) using the TYPE of emc.hh ??

ok I found these old thread ... (solution given from jeff epler)

To send commands you will use an RCS_CMD_CHANNEL:
// command channel
RCS_CMD_CHANNEL *cmd =
new RCS_CMD_CHANNEL(emcFormat, "emcCommand", "xemc", file);
int emcCommandSerialNumber = 0;
and sending a command consists of something like
EMC_TASK_ABORT m;
m.serial_number = ++emcCommandSerialNumber;
// most commands have other fields that must be initialized
// such as EMC_TASK_SET_MODE::mode
cmd->write(m);
// at this point, many UIs have logic to "wait for task to receive
// the command", though xemc does not


anyhow .... EMC_OPERATOR_ERROR_TYPE ,11(these "11" is the serial number of command?? from emc.hh)

regards
bkt