Labview UI project for Linuxcnc

More
6 years 1 month ago #180889 by rodw
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.

Please Log in or Create an account to join the conversation.

More
6 years 1 month ago #180894 by Reinhard

... 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 :dry:

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.

Please Log in or Create an account to join the conversation.

More
6 years 1 month ago #181977 by auto-mation-assist
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.

The following user(s) said Thank You: Mud

Please Log in or Create an account to join the conversation.

More
6 years 1 month ago - 6 years 1 month ago #181978 by auto-mation-assist
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













Last edit: 6 years 1 month ago by auto-mation-assist.
The following user(s) said Thank You: Aciera

Please Log in or Create an account to join the conversation.

More
6 years 1 month ago - 6 years 1 month ago #182181 by auto-mation-assist
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.



Last edit: 6 years 1 month ago by auto-mation-assist.
The following user(s) said Thank You: rodw, Aciera

Please Log in or Create an account to join the conversation.

More
6 years 1 month ago - 6 years 1 month ago #182231 by auto-mation-assist
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":
Last edit: 6 years 1 month ago by auto-mation-assist. Reason: Added "This makes it a bit easier to read:"

Please Log in or Create an account to join the conversation.

Time to create page: 0.083 seconds
Powered by Kunena Forum