Settings from G code file

24 Apr 2017 00:28 #91914 by islander261

I have been working getting cutting settings from gcode part files and into a working plasma setup that uses the new external offsets code. This is not new ground, CandCNC has this for their old Mach 3 systems and their new Command CNC systems. I couldn't find a specification document for this so I reverse engineered it from Sheetcam post processors that incorporate it and vague manual pages. There are probably errors in my interpretation of what is happening. I choose this route because there are tried and tested Sheetcam posts that use it. This uses M67 or M68 E0 Qxxxx to send over the command and motion.analog-out-0 to get it from the gcode interpreter. I will post this as series of code snippets because my files are large and very messy which will lead to much confusion.

I have tested this using MDI commands and monitoring the results on my GUI and halshow.

So to start things off we need to get the command value from the gcode interpreter for use by other parts, this is in one of my HAL files:
# hook up command from Gcode
net gcode-command     <= motion.analog-out-00
net gcode-command     => plasma_tab.Command-From-File
Now most of this is to modify working system values that are displayed in my GUI (Gmoccappy). To do this I used one of the Python files that is linked to one of Glade files for a tab. First we need some HAL pins to handle the io from the HAL:
      #input for control codes from gcode file (M67 E0 & M68 E0)
        self.command_from_file = hal_glib.GPin(halcomp.newpin("Command-From-File", hal.HAL_FLOAT, hal.HAL_IN))
        self.lock_height = hal_glib.GPin(halcomp.newpin("Lock-Height-From-File", hal.HAL_BIT, hal.HAL_OUT))

Then we need to link to that pin and link it to a function:
       #service command from gcode
        self.command_from_file.connect("value-changed", self.on_new_command_from_file)
Finally we have the function:
  #this function is used to decode command from gcode file
   # if real time control of height hold is desired then 1X and 2X need to be
   # decoded in a realtime component
    def on_new_command_from_file(self, hal_pin, data = None):
        if hal_pin.get() != 0:
             command = hal_pin.get()
             #THC run from file
             if 20 <= command < 30:
                    self.halcomp["Lock-Height-From-File"] = False
                    #no need to decode I% here no Hypertherm RS-485
             # height hold from file
             elif 10 <= command < 20:
                    self.halcomp["Lock-Height-From-File"] = True
                    #no need to decode I% here no Hypertherm RS-485     
             #global THC on
             elif 900 == command:
             # global THC off
             elif 999 == command:
             #get arc voltage
             elif 360 <= command < 400 or 3060 <= command < 3201:
                   if command >= 3060:
                        command = command - 3000
                        command = command - 300
             #get preset Amps not actually used
             elif 410 <= command < 500 or 4000 <= command < 4201:
                   if command >= 4000:
                        command = command - 4000
                        command = command - 400
                   #nothing else to do here for now
             #get arc servo delay time
             elif 50 <= command < 60 or 500 <= command < 600:
                   if command >= 500:
                        command = (command - 500)
                        command = command - 50
             #get THC tune
             elif 710 <= command < 720:
                   command = command - 710
                  #nothing to set yet

Now this much will get value changed on your GUI and in controls if it already has the adjustments, buttons or labels in place (notice no editing of the Glade file required to add this).

Now this still leaves the THC height hold function as a user space item, I will post the the modifications to a component and the HAL connections for this in my next post.

Oh by the way I am NOT a software professional and I am sure there are errors that I haven't found yet in these files.

The following user(s) said Thank You: tommylight

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

24 Apr 2017 02:57 #91923 by rodw
Replied by rodw on topic Settings from G code file

Thanks, very interesting post. I have 2 questions seeing I finally purchased a sheetcam license yesterday.
1. What post processor are you using? Is it one of the Sheetcam defaults?
2. Can you list the commands (eg the xxx in M68 E0 Qxxx) together with a brief description.

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

24 Apr 2017 02:59 #91924 by islander261

Back now with the real time part of the gcode command decoding. I choose to modify my Kerf-Crossing.comp to add the the real time decoding. This uses the hold-request input pin from eoffset_pid component to effect the height hold. This will mostly look like a repeat of part of the Python code to support the Glade tab from the user space controls.

First some HAL connections to get every thing connected:
#hold request from different sources
net realtime-gcode-hold    => or2.height-hold.in0
net gui-gcode-hold     => or2.height-hold.in1
net M:hold-request   <= or2.height-hold.out
net M:hold-request    => hc.hold-request
#kerf crossing connections
net kerf_crossing_threshold_main    => Kerf-Crossing.gui-set-point
net enable_kerf_crossing_main     => Kerf-Crossing.kerf-crossing-enable
net gcode-command     => Kerf-Crossing.command-value
net gui-gcode-hold    <= plasma_tab.Lock-Height-From-File
net realtime-gcode-hold     <= Kerf-Crossing.height-hold-out

Now the additions to the Kerf_Crossing.comp:
//this where we decode height hold from gcode file in real time
     if(command_value != last_command_value){
         command = (int)(command_value);
         if((command >= 20) && (command < 30)){
                height_hold_out = FALSE;
              if((command >= 10) && (command < 20)){
                  height_hold_out = TRUE;
      last_command_value = command_value;
      height_hold_out = height_hold_out | height_hold_flag;

That is all that is required.


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

24 Apr 2017 03:17 #91926 by islander261

Here are links to what I know about:
Scroll down to near the bottom of the page and get the Command CNC-DTHCIV-REV4 manual. What you are looking for is on page 144 of the PDF. There is a lot of interesting reading about using the Sheetcam post.

Then go here:
Again scroll down to near the bottom of the page and get the LINUX Command CNC Post Processor Rev. 23. What you are looking for is near the top of the file.

I am presently using a much modified Torchmate V2 post for my present machine. It is very simple because all of the Z axis control is done by the external THC.

The following user(s) said Thank You: rodw

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

24 Apr 2017 04:03 #91931 by rodw
Replied by rodw on topic Settings from G code file


Here are links to what I know about:


John, thanks, my version of sheetcam came with V16 of their post which I've been looking at. I'll go through your info this evening.

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

24 Apr 2017 10:28 #91946 by rodw
Replied by rodw on topic Settings from G code file

Now I've absorbed the links you published, I have to say I'm blown away with what you've put together. Not only have you solved how to set a variable from within the GUI and gcode, you have sketched out a complete framework that will allow LinuxCNC to be used to build commercial quality plasma control by spending just $70 on hardware for the Mesa THCAD and $140 or so for Sheetcam. that combined with an open source motion motion controller, that is a truly disruptive price point!

For those that are following along and have not looked at Sheetcam, it runs on both Linux and Windows and the free demo mode has enough features to really understand how it works and test your config.

Somehow we need to all work together to package this all up into a reasonably easy to deploy package.

But I have 1 question to get back on topic.

Where you define this pin in your GUI:
Is there a corresponding field in your glade file or is it just fully contained in the python file?

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

24 Apr 2017 13:50 #91962 by islander261

That is a HAL pin created in the Python file, it is in second of the code snippets in my post. The "Plasma_Tab" is the name of the Python file and the "Command-From-File" is the name of the pin in the Python file. This is part of the fun you have when you have multiple tabs. The main HAL file can't see these pins until they are connected to signals, that is why I have so many files. Each tab takes a Glade file for the screen, a Python file to connect to the screen and do stuff with the data if you don't exclusively use HAL widgets and a HAL file to connect the HAL widgets and pins created in the Python file to the outside world (HAL). It took me a long time to figure this all out as all the tuts only showed part of the process at a time. I have been told that you don't need all the files for each tab but that is how I got it to work.


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

24 Apr 2017 14:42 #91969 by islander261

I had originally set out to produce a package that would allow the control of a full featured plasma table that didn't rely on proprietary hardware, well almost I think the Mesa cards are a good deal at their price point. Then I started paying attention to the amount of support require by most table builders to get Mach up and running and decided I didn't want anything to do with that. That is one reason I have not posted anything about my progress over at Plasmaspider, maybe when I have an operational Linuxcnc controlled table. The other problem was that the lcnc plasma implementations that are published all seemed to lack one part or another, while the original authors all had working systems that fit their needs I wanted to move from a commercial table controller that works all day everyday to one I could control the features with and had excellent torch height control without a proprietary external add on box. Learning how to create these features in lcnc has been a real challenge for a non programmer. I also wanted out of the MS world with its planned obsolescence and need to repurchase operating systems every few years to keep sw running. Now if I was to start this project now I would use a different path, back to the dark side and use a KFLOP, simpler only one package to learn, MS Visual Studio (one that also works correctly everyday in an commercial development environment), as I already have a basic knowledge of the C language. So far I have had to learn to cope with the HAL, Glade and by extension GTK, embedded Python, at least HAL components are in C, very basic documentation on how use all of these. Needless to say getting and compiling tools that work most of the time is quite daunting to the non Linux programmer.

Yes, I started out with lofty goals for an open source table controller others could use. It has turned out to be much more difficult than I thought it would be and now just want to make the controller work. I could have developed a Rolls Royce external THC in a fraction of the time I have spent getting my head around Linux and Linuxcnc.


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

24 Apr 2017 16:48 #91977 by islander261

Please don't take this the wrong way. I am in awe of the developers who have put Linuxcnc together, most of it on their own time. The support I have gotten here is great, I didn't know the right question many times. I didn't understand about working in the open source world when I started this project.


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

24 Apr 2017 19:37 #92003 by rodw
Replied by rodw on topic Settings from G code file
John, I am sure you have not upset anybody. Thanks for the clarification. So looking at the Sheetcam post, use of a touchoff.ngc file is optional as the touchoff is handled by the code generated by Sheetcam. So my question is a gcode touchoff routine still required?

I agree 100% with what you say about Windows and Mach. I am OS agnostic as almost everything I do is cloud based. There is only about 2 applications I use that are OS specific. One of them is LCNC on Linux and the other is Adobe Lightroom for photo editing on Windows. All documents and spreadsheets are in Google apps.I have written my components and this post on a cheap Chromebook, often while my wife watches TV beside me. I got a rude reminder of how good the cloud is when a UPS failed at 4:00am this morning and its last plaintive bleats outside my bedroom before it died was enough to wake me up as it pulled my network down. pft! Who needs hardware? LEt Gooogle et al worry about it!

When I started this journey, I looked at mach3 as a friend in my street knows it backwards. But it was clear that it had had its day and when I saw commercial companies migrating from it to LinuxCNC. Like you, I never realised how much work there would be in this project.

Please don't inflict the Microsoft Developer environment on yourself. There are so many better environments but sadly they've been suffocated by the MSDE movement. There is simply too much overhead in dealing with the Windows API. One page of Python code can replace 100 pages of C code. If you want to write software, now you know Glade and Python, there would be no stopping you!

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

Moderators: snowgoer540
Time to create page: 0.418 seconds
Powered by Kunena Forum