Labview UI project for Linuxcnc

Thank you for your interests. Since National Instruments came out withe the 2020 Community version of Labview it is a lot more of a worthwhile project since many individuals will be able to use it or some version of it. I'm in the process of doing some clean up work and converting the project files to the 2020 Labview Community version.

I have placed the Network TCP interface for the main status Vi on github. It can be used to check connectivity with LinuxCNC. I down loaded it as a zip file and run the StatusMain.vi in the StatusMain folder and it connects to LinuxCNC and runs fine. You should be able to use this to check your Labview configuration.

Requirements are: Labview 2020 Community version, the VI package manager for installing additions to Labview, and after the package manager is installed use it to install the JKI state machine. The link below should get you started and others will be available as I clean them up a bit. The next one will likely be the network NML command interface.

Link to the the network status interface is below.

github.com/auto-mation-assist/LinuxCNC-Labview

I have 2017 and 2018 licensed version of LabVIEW.

2020 community version are available for down load from NI windows and Linux/Mac at no cost.

I updated to the latest development version today and find that latest 2.9 version has affected debug and that none of the debug statements for executing NML commands and others print out anymore in the terminal window as before.

Also the problem with the unknown data being put out with emcStaus buffer due to the tool info is also still there. Which is an easy fix locally for now by reducing the the tool table back to 56 from 1001 and changing the NML config file. This appears to prevent the status shared memory pointer from changing its start read location at about one second intervals to an area that is not actually the start of the real emcStatus data.

With this newest version of linuxCNC 2.9 it has further become impossible to turn my machine on because of a constant Estop condition that is generated within linuxCNC and no direct NML command will get it out of this condition. To me this seems to indicate that a change in the way Estop is handled has changed and that it is looking for something that is not NML based. Halui just indicates than Estop is on with no control over it.

In past testing.

Sending direct NML commands has worked really well but there are things within LinuxCNC 2.9 that do not always seem to update status when external NML commands are issued. These could be python related issues or even C code that may not have been fully tested for proper responses when external NML commands are issued to thier built in NML functions. You could say that its kind of like the left hand does not know what the right hand is doing. As an example, say that Python is on the left of CMC/NML and NML command is on the right with its designated default port access of 5005. You can send a command to port 5005 at any time and if that command is properly formatted it will be accepted and acted upon if that command type is defined but a Python process may not be coded properly to capture such a command or note a status change. This a a problem with having too many captains and only one ship.

If we look at history we can seen that users of LinuxCNC are never totally satisfied with any user interface and as a result we see more and more being added in as either concepts or allowed to be added into linuxCNC by some well meaning and talented people. But in the end this will become unmanageable because there is no universal users interface that can simply be plugged into and run on its own. Such a interface only need a available command list, status info and some kind of notification for error. Which is exactly what the right side as I defined it above offers with its port 5005. It was likely designed to provide one such standard user interface.

So this brings me back to the Labview UI which is indeed a interface that runs on its own, but with some limitation due to how data is handled by other processes that have been added in over the years that then to look like master control and that have no ability to deal with commands arriving from NML via port 5005.

Without pulling linuxCNC apart to much to make it more friendly with UI's that are not packaged with linuxCNC there appears to be at least the below items available that could be used to interface with Labview and to establish a standard universal interface.

1. Direct NML commands
2. Add Redis into LinuxCNC to interface with the Redis-Labview tools lib
3. Use Labview Node to interface with the linuxCNC .so files which in Windows are DLL files
4. Use Labview PythonNode to interface with present linuxCNC python code .py files

Number 1 is already usable as is and is very responsive. Commands can be added as desired and HAL pins controlled.
Number 2 is already in use by PathPilot with great success and compiled with linuxCNC in my development version but not used yet.
Number 3 could provide a fast interface and able to use C or C++
Number 4 would be the slowest and least desirable

It does appear to me that prior versions of linuxCNC development versions were more stable than those being issued now and this is causing me some concern. Or it could be that I just notice them more because I can see the negative effect they have on my own progress. But I do not want to be to far behind either.
.

One of the problem that I ran into was the amount of space the tool table was using in the emcStatus buffer which was causing issues with invalid data being received over the TCP link. I posted some information on this separately and it looks like a cure for that is being worked on and effective already. I don't use a tool changer so cant say if that work is totally complete. Here is a link to that post.

forum.linuxcnc.org/38-general-linuxcnc-q...97-tool-table-issues

Now that this is mostly resolved I went back to solving why the continuous jog functions would not stop any axis/joint when a properly formatted NML 136 command was sent.

The command was being excepted but not acted upon due to missing "int nr; members in the jog class definitions in the emc_nml.hh file. I added these as, int nr; // axis or joint number
in the classes listed below.

class EMC_JOG_CONT:public EMC_JOG_CMD_MSG {
class EMC_JOG_INCR:public EMC_JOG_CMD_MSG {
class EMC_JOG_ABS:public EMC_JOG_CMD_MSG {
class EMC_JOG_STOP:public EMC_JOG_CMD_MSG {

I figure that "nr" was a a recent name change and assume it was meant to represent 'number' and that they were not put back in when the old names were removed. I have seen this happen when focusing to much on internals and not considering external use also.

There may also be at least one "int jjogmode; // 1==> joint jog, 0==> axis jog"
missing but I did not add that.

It may need to go into
class EMC_JOG_CMD_MSG:public RCS_CMD_MSG {

This solved my continues Jog not stopping problem.

It should be nated that the NML 136 command worked fine when it was executed by gmoccapy but it also depends on other internal linuxCNC processes in addition to the NML 136 command.

The Jogging functions in linuxCNC could use some cleanup work and is a bit difficult to follow due to name changes here and there and things not always ways being in the same order in the code.

The VI in you project are password protected, may I have the password?

Yes this project is: sRd579qZ8^

I'm working on updates for the main and sub.vi's. It will take a while before these are completed. The main status vi has had changes to its reconnect function to allow the vi the vi itself to be stopped white in that loop.

Other updates have to do with the notifier system control commands that are sent to the main command vi that handles all the NML and MDI commands sent to linuxCNC to a three state instead of two states. This is a new CmdControl variable within the main and all subvi type defines.

0 = Do not send command on a button release
1 = Send command on button release
2 = Send command on button down

I have not worked on a tool table .vi yet and if anyone wants to start one that would be helpful. All subvi's need to be coded to use the JKI state machine.

I'm scheduled to have eye surgeries during the next several weeks and that may prevent me working on this project for a short period of time.

I have not had the time to do anything with the rmcsys.org/ website that I started to set up for this labview project and to share .zip files.

Since I mentioned that I have not coded a tool table subvi that reads the toot table file and allow for changes to be made yet I figured that if someone wanted to work on this that it may be helpful to have some info as to the panel size to stuff this into.

If you look at the upper left area of the picture below you will see SubPanel_1A area which is normally displaying the 3D Gcode preview. This area has a height of 457 and a width of 540 and things that get displayed in this area are those selected by the 9 horizontal buttons on the bottom left. It is also possible to display these to the maximum size which covers the entire area that does not have the vertical and horizontal rows of buttons. To do this is just a matter of calling up a different SubPanel.



And some info about this particular SubPanel.




I have always tried to get this to fit into a compact screen area of 768x1024 which reduces the length of arm movement when using a mouse and still provide large enough work area. The SubPanels panels can be rearranged simply by dragging then into a new desired location and lining them up properly. I'm right handed so I set these up to best suite me.

My subvi's that fill some SubPanel locations may have a lot of buttons. However the number of buttons that are actually displayed on these subvi's is controlled by entries in the .ini file. For these the values that those enter when a particular button is clicked on is also set by the same line in the .ini file.








.

Do you think something like this can work



or may be like this

@auto-mation-assist

Hi to all and thanks for this topic. At least I hope so.

I'm building a new interface to connect a plc (LogicLab with etherCat master) pure nml .
Now getting the status was pretty simple but now I'm stuck. First thing that I need now is how to send the act. joint (encoder) value to lcnc with nml.
All done in c/c++.