Network links into new gui

I’m working on building a custom gui that will hopefully be able to link into linuxcnc via Ethernet link into the local host or remote port. I’m building the GUI with Labview which I have used a lot in the past for making very nice user interfaces for controlling remotely located industrial equipment.

I have been reading about nml commands and they just totally confuse me and I assume that nml will be discarded in the near future and replaced by newer methods. The nml documentation for linuxcnc mosly states look at the C code in various modules and use it to figure it out. Which does not help anyone not extremely familiar C and the sequence of events in linuxcnc.

Linuxcncrsh text based commands are easy to use but do not provide for very efficient use of resources, however I may be forced to use them for a while to be able to proceed on the gui work. The linuxcncrsh docs that I have read states that all features of LinuxCNC are available via the linuxcncrsh interface but the published command list for linuxcncrsh does not truly seem to support that. It leaves the feeling in my mind that linuxcncrsh is only partially completed and has been left unattended for a long time. Thus it could be a candidate for elimination and should not be used for new work.

My gui is partially completed and up to the point that my biggest problems now is with obtaining accurate information on the actual date stream formats that linuxcnc uses. All the material I have read over the past month has been somewhat helpful but not doing me as much good as I had anticipated. There does not seem to be a lot of in depth documentation available on the internet about these communication processes since they were developed many years ago.

Being somewhat stuck on how to format the data for the TCP data stream my thought is to actually print out the actual data stream to a linux terminal and actually having a look at the data packets being sent back and forth. I have used TCPflow to aid me in decoding some data but since I do not have a working remote gui it has not been very helpful yet. Can anyone provide some assistance in helping me understand the proper formatting of the data streams, especially those assigned sending and receiving data from the xemc ports and any related timing issues?

There are some comments on the internet that the communication processes of linuxcnc are in the works of being upgraded as was done in the machinekit version, if so is the preliminary work on this available?

I work in the same project but in qt ....

Linuxcncrsh text based commands are easy to use but do not provide for very efficient use of resources,

is my first option for work on, but my first impression is the same as your .... not the best way to do it .... so as second option I use libmodbus TCP and RTU using the single bit of libmodbus register (that are world uint16_t) so in this way it is rather quick to issue a command or more and receive a state (16 bit on 16 bit using halui as interface) .... the problem is rather send and receive coordinates .... this thing is not very fast .... I think the best idea is the one that had mackinekit developer (radzok ... unfortunately I do not remember the name now) who used QUIC google .... since last (oppss. 2015) year is available as a library C / C ++ ... In these manner send bytearray on the network and receive it is very fast more then normal ethernet .... QUIC is used in java and c/c++ ... wifi com. is the goal for these library....

said this ..... on PC use libmodbus & jamod2 on mobile is not so real bad things... ...

Regards
Giorgio

Just a update and some thoughts.

I looked at the numerous files used by nml and it looks they all mention the year 2004. So this is some really old stuff hiding within linuxcnc. This does not mean that it does not work, in modern terms it means it has severe limitations that prevent inclusion of more modern technology.

Over the years I have worked with a number of individuals who where great programmers but all preferred working in a terminal window and had no use for gui's. In their minds a gui was a waste of computer resources since the programs they developed ran just fine without them. To contrast this mindset old companies like Belll Telephone and others spend a great deal of time and money on the human engineering and software developers really should do the same. There is a human factor involved that cannot be overlooked. Humans need effective way to interface with machines and a good gui can do that pretty effectively. Its human engineering.

In a industrial environment not giving operators or technicians a good user interface will eventually lead to loss of productivity, waste man hours and add costs associated with overtime and other trouble shooting efforts. The same holds true for small business or home shop use. The individuals in those situations will have to absorb the cost associated with poor human engineering themselves. Poor human engineering in this case being a poorly designed user interface. Trust me I have absorbed my fair share of such costs over my 71 years.

In regards to current gui's. Lately there has been some interest in Tormach's PathPilot which is likely due to present gui's being offered with linuxcnc not meeting the desires of many users of linuxcnc. For me Gmoccapy is the preferred user interface right now, but I also think that Gmoccapy is trying to be too colorful which can be distracting in a gui. I will stick with gmoccapy untill my own gui is complete. I'm not at all interested in PathPilot after playing with it and having had it mostly integrated in linuxcnc v2.8-dev. Straight linuxcnc and gmocappy was a better choice for me and likely most others due to the custom nature of PathPilot.

I bring up PathPilot due to the fact that significant interest is being raised about Tormach's PathPilot by some users. This should alert the developers of linuxcnc that something needs to be done about upgrading the user interface to modern standards to allow different UI development methods than currently used and allowed. Gui's should be able to be made totally independent of Linuxcnc and linked in with only knowledge of the command and status formatting required either via local host or external network connections. My choice as I mentioned before is Labview since I'm used to using it for just such applications.

I googling around the internet I have found a few things about efforts to upgrade the user interface on linuxcnc. This all seems to stop some time in 2013. That is almost four years ago, and around the time work on the upgrade was being worked on by the machinekit.io folks, who have since the pretty well completed all that work. From what I gather the machinekit.io folks were the driving force for a UI interface upgrade with the linuxcnc folks likely not being all that interested. Witness to that fact is mahinekit.io work was completed while linuxcnc work on the upgrade concept stalled and is not yet completed..

The developers of linuxcnc are likely very busy working on new things to add to linuxcnc and as part of that work I hope a modern network accessible user interface. But beware the machinekit.io folks have already done this so the knowledge on how to get this done in a special development version should be available.

No body can be an expert in everything and I sure would would like to see this done before I reach 72 this year.

many aspects of the work I makinekit are unclear .... send the network feeds for LinuxCNC is a great thing, to use virtual machines less ... send a network signal is good thing, but I think that security is something that should be taken into account .... there are currently a couple of realtime network projects which are awaiting certification .... why not connect with those technologies that have commercial future although with GLP or LGPL or other instead that delve on things too niche ?? .... we are all linux family ... keep in touch with other big linuxfoundation project ....

regards
Giorgio