Labview UI project for Linuxcnc

I had worked for a while with Qtvcp and did develop a UI that was mostly functional but my interest has wavered a bit in doing additional work on that project at the present time. The files for that project, which need further work are available on github. My interest has been to convert my prior work with QTvcp and implement the basic UI layout and functionality using labview and interface it with Linuxcnc using either the Python module via TCP or interface it into shared memory again using TCP connections. That will likely be my biggest problem since it is not something that I'm familiar with doing. But I intend to overcome that as time progresses. I will very likely need assistance from others that have more knowledge it that area.

Presently I'm busy converting my prior work on the x1Mill UI to Labview code to get the UI where it will be usable for testing without Linuxcnc via network connections and simulator. Progress on the code conversion has been moving along well but I have concerns on how to best handle the TCP interface to Linuxcnc.

Here are a few pictures of the several panels that have been converted to Labview with all the buttons functional for sending commands but not interfaced beyond the basic functions.

The probing panel is the most complex while the linear jogging panel shows the slider with both its slow and fast rate sliders. The button values and labels will be loaded from a configuration file as was done in the QTvcp version for all button that need that functionality.

The goal of this project is to be able to run this UI remotely from either a Linux or Windows system and to develop a Network interface to linuxcnc that can be used for other UI's as well that may not use Labview.

The pictures of the below files are the Labview versions.

quite nice
as so many using now Probe screen
the thing is you wont be able to change the probe speed during probing by a UI

In regard to changing probing speeds while probing.

Probing speeds are to be set before a probing macro file started by the default values from the systems configuration file or by modifications to those values by the numeric controls on the probing UI panel before selecting a probing macro file to run.

The small preliminary sample UI panel showing the fast and slow sliders are used only while manual jogging mode is active. This is one of five UI panels associated with jogging and not associated with probing process.

it woudt also be interest to get a big jogging bar to gmoccapy and the option to connect to a poti so on mashine you can fast see the jog speed

I'm getting closer to duplicating the panels I generated a while back for Qtvcp converted to Labview code and pleased with the results so far. I have attached a picture that shows nine subpanels that are being placed onto the main control panel programmatically.



.

Perhaps those functions can be made available from Norbert in the updated versions on gmoccapy in the future. Big sliders that are easy to control from a touch screen can take up a lot of space and that may be one of the reasons why sliders have seen limited use.

Been working on the UI's on screen keyboard with the help of some available examples and have it working now. It is also accepting input from the PC's regular keyboard. The text in the display is from the on screen keyboard. It should work with touch screen.

I will need to work on reading and writing to configuration files next and once that is done I can start on network programing and testing.

It has been a while since I gave a update. My progress has been good and I have been working on the actual interface to LinuxCnc. Many have said that the NML interface should be removed but there is actually no real need to do that. My interface will link into TCP port 5005 which in my opinion has been ignored but is perfectly usable but somewhat scary if you read all the NML and encoding and decoding information available. The below shows that port 5005 actually works from one of my hex encoded commands from IP address 10.10.20.1.

(time=1566596264.230845,pid=8022): Socket opened by host with IP address 10.10.20.1.
(time=1566596269.241978,pid=8022): read 20 bytes from 4
(time=1566596269.242003,pid=8022): TCPSVR request received: fd = 4, serial_number=1, request_type=2, buffer_number=1
(time=1566596269.242018,pid=8022): read 4 bytes from 4
(time=1566596269.242038,pid=8022): rcs_sem_post(2293760) called.
(time=1566596269.242069,pid=8022): wrote 12 bytes to 4
Issuing EMC_TASK_SET_STATE -- ( +505,+24, +17, +0,)
emc/task/emctaskmain.cc 2352: error executing command 505:EMC_TASK_SET_STATE
emcTaskIssueCommand() returning: -1

It is returning an error because the actual selection of Manual, MDI or AUTO data was not sent. Thus the +0 value instead of a 1 (Manual), 2 (MDI) or 3 (Auto) value in EMC_TASK_SET_STATE -- ( +505,+24, +17, +0,).

The value required in that field is actually a sub command which is determined by a enum value as defined in emc.hh. I'm working on building commands to handle sub command parts now. The command required to be sent to execute EMC_TASK_SET_STATE in binary via TCP without the sub command is: 0000 0001 0000 0002 0000 0001 0000 0004 0000 0004 0000 01F9 0000 0000 0000 0000.

I have attached a command list that I have partially completed for each NMLtype in file src\emc\nml_intf\emc.hh for info. Work is in progress to get a complete command set for remote Gui use.