Labview UI project for Linuxcnc

My milling machines have been idle for a long long time one is using a early 2.9 LinuxCnc version and one of the normally supplied LinuxCnc default UI's that is functional but I really like. The other uses Mach and is gantry machine that can do Tangential moves using its rotary A Axis. Originally I built it for doing printed circuit board work such as drilling holes and engraving work.

I started developing my Labview based UI.Why Labview?I chose Labview since I have used it in the past to build complete remote control systems and those ran twenty four hours a day for years without problems. Labview has complete flexibility to handle everything required, communication, data processing, user interface, high speed, and can interface directly into the NML primary control system of LinuxCnc without difficulty.  A Labview UI can be run locally or remotely while interfaced directly with NML allowing for optimal response speed.Labiew can also interface directly with Redis which is a in-memory data structure store, used as a database, cache, and message broker.  This is used by the Tormach and other LinuxCnc versions that have added this to LinuxCnc. Check out Redis using your favorite search engine. One of the last problems I was working on was to pull accurate status data out of LinuxCnc and decoding that information for use within the Labview UI. I can request all status data at one time via NML but determining type and offsets is a quite a bit more difficult. Then there is a problem with developers making changes that affect how NML data storage is stored in memory. Developers do not seem to check how or if changes they make during updates affect NML status memory itself since they use direct offsets to get status data they want to look at. These memory offsets are generally not available as part of the NML status data transfer and thus cause some difficulty in decoding the raw received status data. This is the area I was working on before Covid and needs the most work by all involved in LinuxCnc coding work..I will power up my development computers in the near future that have been powered down and continue this project. One computer runs Linux Mint and the other Windows 7. Both will likely need to be upgraded  to newer versions. 

Nice to know you will be back to this project!!!

I have been thinking about how to proceed on the Labview UI project. The largest issue that I see is that LinuxCnc does not have a process that consolidates all system status information in a tagged and thus use full format that can directly output all status data for use with any user interface whether local or remote. It is possible to interface to shared memory via status request but this returns raw data with no tags to tell what is what since only internal processes know what memory locations contain specific data and what format it is in.  Also decoding raw data without knowing where to find specific data and format it is in provides a significant problem to overcome.

When looking at all the various sources that provides status within LinuxCnc it can be seen that there are many that are generated by things that have been added over the years that are really external to  LinuxCnc proper since they are not available in status shared memory. The processes that generate these use an assortment of programming languages which makes this issue more difficult to overcome.

So why does this problem exist?  I believe that there is not a a single developer who is not aware of this issue but to fix it requires a lot of effort and planning possibly to the point of a major rewrite.  A programmer once told me that to many fixes and work a rounds make things harder to fix.  I see the lack of a very fast and consolidated status system within LinuxCnc as a very significant problem for future development work..

I would love to get any information on things related to consolidating status info something that is universally accessible and very fast. Does any one have a complete list of all processes that generate specific  status information and how many of these are not consolidated into the LinuxCnc status memory ? 












 

The subject of unifying status/error messages was raised by Michael Haberler a decade ago.
emc-developers.narkive.com/x9PTgFlc/unif...eporting-in-linuxcnc
I know that you did extensive research into the inner workings of linuxcnc , but just in case you missed this website which has details on the relationship between linuxcnc modules which might help you in your effort.
alvarestech.com/temp/RoboAseaIRB6S2-Fiat...f/emc/hierarchy.html
I would love to see a headless standalone linuxcnc controller and a separate ui system. This will simplify the maintenance of Linuxcnc controller sans ui. As you know there are many ui/hmi software packages source code free/commercial users could choose from. As for communication protocol Modbus would be a good candidate for a start and may be later the industry standard OPC UA.Good luck in your endeavorBen

When I look at my prior work in the past in and in regards to building a Labview interface I have in effect started on building a headless standalone linuxcnc controller since most all code that is not required to run linuxcnc itself gets removed and some gets changed and relocated that is presently required but needs to be changed and possibly eliminated at some future time. The problem with all of this that this effort is coming from the wrong place. It should be worked on by the LinuxCnc developers group and if such development work would come from such a group this work and life would be a lot easier.

As has been pointed out the problems caused by keeping on adding code to LinuxCnc to address special requirements for a few users is not desirable and lead to software management problems. As an example Tormach worked around this problem with the utilization of Redis as middle ware to in effect turn LinuxCnc into a headless system.  My efforts have also added Redis as an alternative to the direct  NML interface which is not at very secure and always active.  Redis was looked at many years ago and implemented by a number of groups into LinuxCnc as a data management system for linking directly into LinuxCnc. Redis itself has had many improvements over the years since it was first linked into LinuxCnc and its use has shown that it is reliable.  ZMQ s also available as an alternative for a middle ware function and is available. The data management system provided my Redis handles all data coming or going to or from LinuxCnc to either a Local or remote UI. Very simple and desirable.

Just look at this directory in master,  src/emc/usr_intf

It contains 10 special interest user interfaces that don't need to be included in LinuxCnc since they can all be made available as items that interface to a data management system. Thus management of those items are handled over to the developers of those UI's while LinuxCnc itself stays in a more controlled and more reliable state. This usr_intf directory also includes items that support information routing to UI's but not all  information.

So what to do:

I would be nice if no more additions were added to LinuxCnc and development was aimed towards streamlining it and turning it into a headless system that can be easily interfaced into by separate and secure methods for local or remote control.

Just leave the present LinuxCnc  code alone and make a break point to a new headless streamlined version.  Until such time as a decision is made to do this persons like myself will likely continue to bang there heads against the wall in frustration.
 

I really sounds like machineKit would have been a better base for your project.
They embraced the distributed Gui idea.

It would be nice to combine machinekits HAL work with linuxcnc's motion controller work.
Linuxcnc's documents are worlds better the MK too.

If you are truly interested in the development of linuxcnc, why not get involved?

I would love to see a headless standalone linuxcnc controller and a separate ui system.

Linuxcnc is already, what you expect it should be.
You can start the backend without using any of the existing frontends.
The helperscript linuxcnc is just a helping hand to start a complete (userfriendly) system.

If you develop your own ui - you only need to change ONE variable in your ini-file.
Set display variable of display section to the name of your app - and here you go. linuxcnc starts your app without bothering with any of the 10?!? existing ones. That works for my java app as well as for my qt-project.

Just look at this directory in master,  src/emc/usr_intf

It contains 10 special interest user interfaces that don't need to be included in LinuxCnc since they can all be made available as items that interface to a data management system.

Obviously your research was just a skimming about directory names.
stepconf and pncconf are just "helper scripts" to help you create a machine configuration, gremlin is the 3d-preview and qtvcp is a support lib. So only 6 remaining ui

... and if you really did a research you'd know, that all use the same interface.
Well, linuxcnc does not use the interface library of your choice - but it does use a robust and fast interface library that can easily be used by anyone.

linuxcnc has a lot of issues, but being not able to run headless is not an issue.

I'm bouncing around between various projects and getting the LinuxCnc Interface that I would like to see is just one of those. I believe that I can develop it myself to suit myself but the hope was and that LinuxCnc developers would be interested such and interface for the increase in flexibility it could provide. 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.

As a point I would like to mention that networking as you likely know can take place inside a computer and does not have to leave it and is typically used to make interfacing a lot easier. I have read the latest posts and aware of all the options available or suggested by my own research in the past over the years. This included keeping silent and just doing my own thing without sharing. But that would be not being involved. Being involved includes making desires and suggestions known.

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.

To work on my project further.

One of the things that will help is to make a diagram of how the important parts of LinuxCnc links things together in a very detailed way. In the past I when I was working of qtpyvcp I made a chart of its hierarchy.  It is likely somewhat out of date but below is a copy of the file.



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. Surely there must be something like that available and I'm wondering if anyone has already generated such maps and willing to share. I have not been been able to find any that provide really good details yet.

This project will need to be on my back burner for a bit since I have to do some electronic design and circuit board work before I can proceed further.

Developers in linuxcnc work mostly in two way, as far as I can tell.

Fixing things so linuxcnc still works ie python2 to python3 / required disto changes
Whatever interests them or is needed by them.

There is very little 'planned' work. There is no official plan or even a mission statement.
We have really a very little amount of active (with commit access) devs - something like 5 I'd say.

The only guide we have is the docs (look under developer information):
It will be out of date but still relevant.
There are some good google videos made by machinekit that explain things in better detail.

If you did make a code map that would be a very useful thing for the project!

I would like to mention that networking as you likely know can take place inside a computer and does not have to leave it and is typically used to make interfacing a lot easier.

That's only true, if you don't care for processing time and don't care for the internals.
LinuxCNC is designed to be fast and have fast interfaces.

Not sure if you know that, but network byteorder is bigendian, whereas pc has littleendian. So using network without leaving workstation boundary is wasting processing time as each number has to converted at entering network and converted back on leaving network.

For me, that's far from being easy.

NML on the other side is fast and easy. Well not as fast as it could be, as you get a copy for each client/request, but there's no conversion. With NML you can use several clients at the same time (beside the error messages - all works well).

So if you "need" multiple network channels, why not implement a nml/network translator?