Labview UI project for Linuxcnc

I agree that shared memory access is the best option and Labview has that option available for Linux. I really like being able to interface directly with NML but there are some issues.

One of these is keeping track on command serial numbers. Command serial number tracking on the network side is not separated from the command serial numbers used on the internal side. Commands generated internally like perhaps the python interface increment the command serial number and thus the external world has no idea what the actual next serial number should be.

Even sending a command directly to nml that causes multiple additional commands to be executed internally automatically increments the command serial number. It thus becomes impossible to keep them in sync with present Linuxcnc code. To overcome this under present conditions the command serial number verification checking has to be disabled for commands coming from from the network side.

If I recall correctly Linuxcnc version 2.9 got some code changes in the handling of the command serial numbers for internal commands. But the above problem will remain until there is a way to store the last command serial used and pass it automatically to the network side when a remote logs on, and each time the command serial number is incremented by any method.

My thoughts on Redis. Redis has the potential of being very useful in that it can provide a relatively simple way of providing an additional option to provide network connectivity. It would thus be a addition and not replace the direct nml interface. With Redis being compiled by the Linuxcnc make process it is only active when Linuxcnc is running. Redis would not be installed into linux itself, which in my case is linux mint.

Its been a while since I worked on my project but its time to continue with the main parts. I have my test environment working with my modified Linuxcnc version 2.9 for testing with network access from port 5005 directly into nml. So far I have not found any issues with the work I did with Linuxcnc version 2.8 and migrating those to version 2.9.

Some additional items that I have also added for potential use later on are the Redis interface, USBio and Suttlexpress.

One of the main things that I need to work on is decoding more items contained in the 9196 Byte status string which would likely give the best performance but will take considerable effort. Part of the 9196 bytes is a header, with debug selection types at the end.

As a point of interest I have attached some pictures of part of the command data link Labview code and its current front panel that allows for monitoring of various data points. Also a overall view which will see some changes later on the top left side.





The K dro handles the linear scale on the knee of the mill.

Hi, as a test engineer I have worked for a long time with LabVIEW and TestStand, for data acquisition and test purposes, in business environments. as you previously mention many people have access to a LabVIEW license, because of business or education, I have been following your project and trying to figure it out what is the value-added of your project.
on one hand one of the most well supported and business-oriented development ecosystem.
on the other the greatest open CNC control software, product of big altruist effort.

Then you come up with this combination, it is clear to me that it has:
-Great academic value
-Open LunuxCNC to a big and talented developer community (LabVIEW people).

I want to congrats you for the brave attitude.

Just a short update.

I'm primarily working on adding hal pins and insuring that they can be accessed locally and from the network. Status from those pins is also being routed to the NML status buffer for verification use by the local and network side.

Using status on the remote side requires decoding of the raw status data from the NML status buffer once it arrives via one of the network communication processes. All coding required on the Linuxcnc side has been done in C++ and with Labview for the remote side.

Very good thread .... but I haven't seen it until today when AndyPug told me about the user list.

After a few years I dusted off my whole C ++ interface project. Now while getting the status from nml is a relatively simple thing, I still haven't figured out how to send the commands to nml.

This problem derives from the fact that
1 - I am an amateur
2- I do not use the terminal as a debug for applications since '96
3- and this is the most serious thing, I have never properly studied the Lcnc files always referring to tomorrow. ..

now my doubt:
so I have to call the class RCS_CMD_CHANNEL or the function int emcFormat (type NMLTYPE, void * buffer, CMS * cms) using the TYPE of emc.hh ??

ok I found these old thread ... (solution given from jeff epler)

To send commands you will use an RCS_CMD_CHANNEL:
// command channel
RCS_CMD_CHANNEL *cmd =
new RCS_CMD_CHANNEL(emcFormat, "emcCommand", "xemc", file);
int emcCommandSerialNumber = 0;
and sending a command consists of something like
EMC_TASK_ABORT m;
m.serial_number = ++emcCommandSerialNumber;
// most commands have other fields that must be initialized
// such as EMC_TASK_SET_MODE::mode
cmd->write(m);
// at this point, many UIs have logic to "wait for task to receive
// the command", though xemc does not


anyhow .... EMC_OPERATOR_ERROR_TYPE ,11(these "11" is the serial number of command?? from emc.hh)

regards
bkt