Labview UI project for Linuxcnc

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.