Labview UI project for Linuxcnc

I was not aware that there was a stand alone interpreter but will keep it in mind.

I have used the data from the Parser to generate a 3D picture that can be dragged by the mouse to give views from any angle. Not totally happy with it and since it can have its view angle changed it presents a problem with inserting text and have it remain in the desired location. This could likely be compensated for by just using preset views. I will work on this.

Here is a rendering of the code as I have it right now. Size of the display is 600x400.

Just a brief update on my progress for the Gcode preview display. I think I have it working well enough to make it useful. Still working on potentially putting a text display it which is not hard but making it stay in its place is a bit of a challenge when the angles are changed by mouse drags. Overlays are not allowed with a 3D picture. In a picture such as this 0 for each axis is in the exact center of a virtual box with each axis having a value range of 1 to -1 for its current coordinate.

It is good for now and with this working work can proceed on other items.

Hi Johannes,

Nice to see you cross platform developing !

Is your project more or less resulting in a cross platform driver?

If you would use Beckhoff Ethercat, you can code magnificent things outside of the linuxcnc code, straight to the device.

My vision is that when u use Ethercat, you have much more option's than using Labview.

One example is : you can connect different open source code's together.
Pyton and C, connect's a cnc microscope with a digital canon camera, ethercat, etc. All integrated for example in the linuxcnc
gui python code. This is one of the powers of linux.

This guy has not joined the different source codes together, or made a cross platform driver, to be clear..


I am more a C++ guy, if you walk that way, it can result less progress in the beginning.

Good luck with your program from Holland !

Thanks, I have not had a chance to follow up on your suggestion yet. Holland that reminds me of my home town Delft.

Ran into a serious issue with xemc remote on port 5005 not working properly anymore. Not sure why it is no longer able to be set to remote in the .nml configuration file and not show up with continues self polling of the status buffer. It also appears unwilling to except commands that I have been using for months right now. It sets itself up as local host at 127.0.0.1 all the time.

I have been searching for a answer with some issues running a remote gui that interfaces directly with the NML interface due to internal Linuxcnc conflicts. These conflicts may have slowly started developing after Linuxcnc version 2.5 when the xemc gui started to get phased out a bit at a time. This was not noticed much because no one was using port 5005 much with TCP server (not the Telnet interface). The only place in V2.9 that mentions xemc now is halui.cc and the nml config where local or remote is defined.

Copied notes here from my another post today below.

For the most part I have traced this problem down to halui.cc which wants to be run at local host with the ID of xemc. Likely all part of the status polling system that GStat uses that listens to messages being sent internally by NML, and uses the them to control how and what a local gui can do. Unfortunately this totally conflicts with commands coming from a network interface.

As an example recently I was doing some testing with my networked gui. For this test I replaced my normal 'dummy' Gui running the Linux computer that interfaces with my milling machine with Gmoccapy which uses Gstat a lot. I switched my networked gui running on a windows machine to auto mode and send the commands to load a file and run it. As soon as I did this Gmoccapy changed from its initial mode screen to its auto mode screen and followed along, including displaying the file I loaded with my remote gui and also tracing it out in its preview display. It should be noted that my commands are sent directly to the NML interface via the network on port 5005 and not tied to Gmoccapy in any way.

I think there needs to be a way to completely disable Gstat but I'm thinking that as it is built right now it might take halui with it. My networked gui does its won polling directly from the status buffer and has no use for Gstat.

In version 2.9 the size if the status buffer reply has increased substantially from 8244 bytes to 9196 bytes but I have found no information on what is placed in the added area or a map on how to access what ever is there by byte offset..

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.

Grotius gave a link to a user using Machinekit several posts back and it reminded my that about a year ago I had started working on encoding and decoding Protobuff messages in Labview for use with Machinekit and dug out some of that code. In looking at my options to proceed I feel that right now Machinekit is a better choice for me since it is able to export NML messages and thus eliminate the conflicts that I have run into with Linuxcnc.

I will dig out the Labview ZMQ and ProtoBuff code and the enthought python integration toolkit for labview and see what I can come up with for interfacing with Machinekit. Its possible that the python module may not need to be used. 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.

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.