Labview UI project for Linuxcnc

Very interesting diagram Aciera, I don't really know what standards are out there, but yes Level 3 & possibly 4 are the ones of interest. I think today these levels are often incorporated into the one ERP system.

Coming from the printing industry there was XML based JDF (Job Definitition Format) and its companion JMF (Job Messaging Format) as defined standards. JDF was an electronic job ticket travelling with the job that could be added to and amended by the workflow (the full process may not be known at the start of the job). JMF was what was used by status updates so machines could provide updates on status back to the ERP/MIS.

So thats kind of what I had in mind. a method like JDF to send a job to a machine and may be start and pause operations with a JMF message.
And a method like JMF so that status updates could be posted back to an API hook published by the ERP/MIS/job scheduler that was listening for status updates.

We use a lot of web based interoperable systems every day in our business and they are tied together by API's with a standard XML or JSON API. These are very trivial to interface with using Python so at a simplistic level, a GUI written in Python on the machine could publish the necessary servers and hook to another IP address to send status updates to.

But in practical terms, for step 1, I'd like to be able to use a nesting program to layout a sheet to be cut on a plasma cutter, generate the Gcode and send it direct to the machine on the production floor. So its sitting there ready to cut.

step 2 might be: hey I've finished this job so schedule it on the next workstation but somewhere there is an operator, so maybe that is done by a human intervention.

or hey we've got some downtime here..

Hi Rod,

I very understand your situation and desires, but linuxcnc is not ready to fulfill your wishes.
The most important value for monitoring is time.
But linuxcnc does not provide any timers.
So what else makes sense to monitor remotely? I don't know.

If linuxcnc would provide toolbased timers, you could monitor a lot (in sense of ERP systems), but without timers?

The only remote thing, that makes sense to me with linuxcnc is a webcam. But a webcam does not need any changes to linuxcnc.
Your step 1 is already possible. As all requirements are outside of linuxcnc.

Step 2 - I don't see any sense in remote capabilities, as human intervention needs local machine controls. From formerly automation projects I know about machines, that had a push button for material request and a push button to signal ready materials to take off.
Such an interface can be realized with or without linuxcnc.

No my version of step 1 is to be working in say Fusion360, run the post processor and possibly nest parts in their manufacturing module and have the gcode loaded onto the machine from a remote location probably from a Windows or a Macintoch PC. Axis-remote allows this but that implies the system is not OS agnostic. Plus its tied to a single GUI.

... and have the gcode loaded onto the machine from a remote location probably from a Windows or a Macintoch PC.

Puh - loading the gcode in the machine controller from remote?
And possibly start the job from remote?

Not with me

At work we have lot of automation with robotics and so, but that's not possible and for sure not wanted. May be it makes sense with laser and plasma - I don't know.
But it does make no sense at all with milling and turning. Changing a job implies (at least in our company, that has machines with atc of 100 and more slots) changing of tools from atc, prepare the workpieces to use and manually run the first job.
After measuring of the first piece automation may start.

I know about companies which do die cutting of metal sheets and that spend a lot of effort in automation. They have automatic sheet feeders, but the man at the machine is stil needed. And although they punch a whole sheet of metal at once, they don't have remote control for the machine. Risc of damage is too high.
They do have remote monitoring of every machine, but no remote control.
.

... Plus its tied to a single GUI.

Hm, I never tried remote axis, but local GUI can of cause run more than one.
I used that during development of my app, where I always run axis and my app in parallel.
So if that is possible, it would be possible to create a remote stub that handles remote apps in parallel to a local GUI.

I have been working on updates to my network interface .vi files for my command and status links that link into port 5005 in LinuxCNC and also my added port 5015. This update resolved all my command serial number issues that I mentioned in prior post.

Status replies show that all serial numbers are correct for single or multiple commands that are issued at once. Some of the prior problems associated were due to time delays due to commands being processed in linuxcnc as each command is executed in sequence. As each is executed and reply is sent back. Three commands sent at once gives back three separate replies space depending on how long each command takes to execute which is a variable. This then also generates a variable length response and timing that needed to be adjusted to insure sufficient wait time is applied. Insufficient wait time leads to good replies for single commands but not with multiple commands being send as one serial string.

To insure that a command connection is maintained I use a watch dog that can be adjusted for a desired rate. For me this is 2000ms, and at 4100ms if no reply a reconnect is triggered. I have tested this with over one million commands sent at a rate of 10ms with no issues. Thus 2000ms is not a problem. Watch Dog is reset when a real command arrives

This TCP nterface also includes the NML command encoder for command data transfer. If a command requires additional string data to be added then this is done in the UI it self and that data is routed here though a event link from each of the main UI's sub-panels..

The watch dog command generates a 20 byte return response with the serial number contained in 4 bytes, 0 to 4. The serial number will always be one higher than the one that the Wdog command sent. The response back from LinuxCNC for each normal command is 12 bytes long with its serial number again being in bytes 0 - 4. The serial numbers will be a increment of the Wdog serial number. If three simultaneous commands are issued then the return reply will be 36 bytes long and each additional 12 bytes will have sequential serial numbers. LinuxCNC will expect the next command to be issued to use the highest serial number given in the reply data. If not debug will complain and if not corrected will eventually cause the LinuxCNC server to shut down due to excessive errors.

The below picture show some Wdog and a command with 4 individual NML commands send as one command and the response received back. The actual commands are encoded and not readable but Labview can easily display these encoded commands and replies as HEX data winch wakes it simpler to understand. The array on the right show these basic commands before being encoded into a string to send to linunCNC. The serial number received back from the issued command is separate and increments up on its own as each command is issued.

This LinuxCNC TCP interface could actually be used as basic UI to control LinuxCNC by adding few buttons to do selected tasks. Most of the items on the front panel now are for debugging and can be removed or hidden. It is coded as a statemachine.

These are some screen shots of some of the code my last post. Not is any particular order. Some of the parameters in the TCP receive have been changed a bit since the shots were taken

I was reading some earlier comments and saw mention of update rates. The update rates that I use for testing that are high rates are for testing stability and not associated with displaying variables on the UI's from panels. For those kind of updates 100ms is sufficient. Rates faster that 100ms are for use by internal processes or for testing.

I have been looking at my status TCP link .vi today and included a screen shot of its from panel below. This panel connects to the remote NML status buffer and associated server which I named xrmc. I assigned port 5015 to this link to handle my status data. Port 5005 is left as normal.

If you look at the screen shot of the front panel below you will find some notes that I added to help explain some of the displays and controls.

This status interface handles two functions, first it uses "Wdog" to obtain every item in the status buffer with one command. Once the status data transfer is made each item can be decoded and its internal update refresh rate set for obtaining new data and updating the UI's from panel displays. It would be nice if the location of each item withing the status data was given in the header of the status data transfer at startup but that is not the case "right now" with any LinuxCNC version. My goal is and has been to get this added to future versions.

If you look at the StatCmdReply byte 0-4 "0000 06EF" is the command serial number, while the next four bytes is the buffer number that gave the reply.

The second function gives the status interface the ability to send NML commands by local push button such as the one labeled command test, or by a notifier link from other potential panels. Pushing the Cmd Test button disables the automatic StatCmd update requests via "Wdog", These resume after the "Cmd Test" command is complete. I also added a decoder to recover the name of the buffer sending the reply using the standard NML command to obtain this info, value 12 in the CmdArray in the upper right of the panel. This array is serialized and then encoded for transmission to my port 5015.

Also on the upper right of the panel are some annotations as to which standard NML and CMS functions are used along with several references to the location of files that contain information relating to those.

I'm looking for addition information on the below from old NIST information and the examples to see if this is suitable for use to help with mapping the obtained status data. Unfortunately most of the links contained in the document are no longer valid.

Obtaining the memory map.

The memory map file provides the information needed to determine the position of each variable in the file. The first character in the file is either 'L' (0x4c) to indicate the file is little-endian or 'B' (0x42) to indicate the file is big-endian. It can be read with a text-editor or opened with a spread sheet program. To generate the file write a program such as this "write_mem_map.cc"which really only needs to be run once.
#include "nml_ex1.hh" int main(int argc, const char **argv) { NML nml(ex_format, 0,0,0); EXAMPLE_MSG example_msg; nml.writeEncodedMessageMemoryMapToFile(&example_msg, CMS_PACKED_ENCODING, "EXAMPLE_MSG_TYPE_map.csv"); }

To compile and run:
## Set RCS lib install directory. ## likely needs to adjusted for your system. RCSLIB_DIR=~/rcslib/; ## Set the path for finding librcs.so LD_LIBRARY_PATH="${RCSLIB_DIR}/lib/:${LD_LIBRARY_PATH}"; export LD_LIBRARY_PATH; ## Create nml_ex1.cc from nml_ex1.hh java -jar "${RCSLIB_DIR}"/bin/CodeGenCmdLine.jar nml_ex1.hh -o nml_ex1.cc ## Compile examples: g++ write_mem_map.cc nml_ex1.cc -I"${RCSLIB_DIR}"/include -L "${RCSLIB_DIR}"/lib -lrcs -o write_mem_map ./write_mem_map

This is from the below link:

www.nist.gov/el/intelligent-systems-divi...up/nml-message-files

This makes it a bit easier to read:

The memory map file provides the information needed to determine the
position of each variable in the file. The first character in the
file is either 'L' (0x4c) to indicate the file is little-endian
or 'B' (0x42) to indicate the file is big-endian. It can be read
with a text-editor or opened with a spread sheet program.

To generate the file write a program such as this
"write_mem_map.cc" which really only needs to be run once.

#include "nml_ex1.hh" int main(int argc, const char **argv) {
NML nml(ex_format, 0,0,0); EXAMPLE_MSG example_msg;
nml.writeEncodedMessageMemoryMapToFile(&example_msg, CMS_PACKED_ENCODING, "EXAMPLE_MSG_TYPE_map.csv");
}

To compile and run:
## Set RCS lib install directory.
## likely needs to adjusted for your system.
RCSLIB_DIR=~/rcslib/;
## Set the path for finding librcs.so
LD_LIBRARY_PATH="${RCSLIB_DIR}/lib/:${LD_LIBRARY_PATH}";
export LD_LIBRARY_PATH;

## Create nml_ex1.cc from nml_ex1.hh java -jar "${RCSLIB_DIR}"/bin/CodeGenCmdLine.jar nml_ex1.hh -o nml_ex1.cc

## Compile examples:
g++ write_mem_map.cc nml_ex1.cc -I"${RCSLIB_DIR}"/include -L "${RCSLIB_DIR}"/lib -lrcs -o write_mem_map ./write_mem_map


This produces the file "EXAMPLE_MSG_TYPE_map.csv":

I have been testing the status reladed NML Commands listed in emc.hh and here is what I found.

Please recall that: rmc or RMC - is equal to - emc or EMC for my development work.

The below 10 commands for status are not completely handled by LinuxCNC
in "any mode" and appear to have no way to process these commands further
at the present time. I don't see these in the allowed "instant command" lists.
Type 199 AXIS_STAT type appears to be unknown. RMC_RPIN_STAT:3199
is custom to my system (RPIN = Remote controlled HAL pin)

I only listed these for manual mode but other modes give the same results.

rmctaskmain - rmctaskmain - can't do that (RMC_JOINT_STAT:198) in manual mode
rmctaskmain - rmctaskmain - can't do that (UNKNOWN:199) in manual mode
rmctaskmain - rmctaskmain - can't do that (RMC_TRAJ_STAT:299) in manual mode
rmctaskmain - rmctaskmain - can't do that (RMC_TASK_STAT:599) in manual mode
rmctaskmain - rmctaskmain - can't do that (RMC_TOOL_STAT:1199) in manual mode
rmctaskmain - rmctaskmain - can't do that (RMC_AUX_STAT:1299) in manual mode
rmctaskmain - rmctaskmain - can't do that (RMC_SPINDLE_STAT:1399) in manual mode
rmctaskmain - rmctaskmain - can't do that (RMC_COOLANT_STAT:1499) in manual mode
rmctaskmain - rmctaskmain - can't do that (RMC_LUBE_STAT:1599) in manual mode
rmctaskmain - rmctaskmain - can't do that (RMC_RPIN_STAT:3199) in manual mode
Note: RMC_RPIN_STAT:3199 is custom to my system (RPIN = Remote controlled HAL pin)


LinuxCNC returns lots of 4 or 8 byte pointer range errors for these
status commands and returns no data. But at least they give a debug response.
I think that these errors could be listed in the build info of LinuxCNC as warnings when compiling but not sure.

RMC_MOTION_STAT TYPE 399 1 error
RMC_IO_STAT TYPE 1699 761 errors
RMC_STAT TYPE 1999 761 errors

A complete list of error messages is in the attached file

I have the MOTION_STAT command working now and displaying its values in the debugger.

If the machine is not turned on and in estop mode the RMC_MOTION_STAT command gives this reply which is good:

rmctaskmain - Issuing RMC_MOTION_STAT -- ( +399,+8228, +8, 1,0.000000,0.000000,0.000000, +0, +0, +0,\000,\000, +0, +0,\000, +0,\000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000


If the machine is out of estop and turned RMC_MOTION_STAT command gives this reply which is bad.

libnml/cms/cms_dup.cc 472: CMS_DISPLAY_ASCII_UPDATER: int 1072693248 is too large. (Use type long.)
libnml/cms/cms_dup.cc 472: CMS_DISPLAY_ASCII_UPDATER: int 1058780665 is too large. (Use type long.)
libnml/cms/cms_dup.cc 472: CMS_DISPLAY_ASCII_UPDATER: int 1563164632 is too large. (Use type long.)
libnml/cms/cms_dup.cc 472: CMS_DISPLAY_ASCII_UPDATER: int 663211969 is too large. (Use type long.)
rmctaskmain - Issuing RMC_MOTION_STAT -- ( +399,+8228, +19, 1,0.000000,-nan,0.000000, +0, +0, +0,\000,\000, +0, +0,\000, +0,\000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000

This results in the "-nan" (not a number) error. The problem occurs due to line 470 in cms_dup.cc not having sufficient number of 9 digits to make a valid length comparison. The present length was likely fine in the past but this needs to increase to at least "if (x > 9999999999" instead of the present "if (x > 9999999".

This will result in the good response:

rmctaskmain - Issuing RMC_MOTION_STAT -- ( +399,+8228, +11, 1,0.000000,0.000000,0.000000, +0, +0, +0,\000,\000, +0, +0,\000, +0,\000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000

Text file for the above is attached.