Yet another iteration of nothing
Random header image... Refresh for more!

Posts from — January 2016

KmotionCNC Conditional Logic

The GCode Interpreter included with KmotionCNC is more bare-bones than the extended on in LinuxCNC, and some people were discussing how to work-around this perceived lack. I found a link on CNCZone that outlined a method (albeit on Mach3) of performing conditionals (as Mach3 also does not support the higher-functions in LinuxCNC). At one point, Tom Kerekes also weighed in:

Comment#1:

The same approach should work with KMotionCNC as with Mach3.  Both support variable numeric subroutine labels. With Mach3 the Interpreter should work the same regardless of what motion plugin is performing the motion. KMotionCNC also supports a Variable loop count (L word) which includes zero calls.  To me that is a simpler form of conditional. See the example: SubroutineWithConditionals.ngc I’m not sure why Eon feels that the Loop Count must be less than 100.  Any value up to ~2 billion should be allowed

The reason for the bold statement is apparently Mach3 (which Dynomotion has a plug-in to interface to) claims a limit of 99 iterations Limit on Loops. Others state there is no such limit to Kmotion, and using the Gcode window in Kmotion, I have easily proven this. Instantly I can have huge loops amounts (tested to 20 Million). Another claims to use M47, which in MACH3 repeats program from first line. This Mcode does not exist by default in Kmotion.

 

Comment#2:

KMotionCNC doesn’t support if/while statements.  You can conditionally call subroutines and repeat subroutines.

Comment#3:

Regarding KMotionCNC Subroutines: unfortunately calls to other files are not supported. The subroutine must be within the same file.

Comment #4:

If you don’t like using a subroutine with an infinite loop count you should be able to add an action to M30 to automatically re-cycle start.
Configure the M30 (stop rewind) with an additional action to execute:

#include “KMotionDef.h”
#define TMP 10
#include “KflopToKMotionCNCFunctions.c”

main()
{
while (JOB_ACTIVE) ;  // wait until GCode Finishes
DoPC(PC_COMM_EXECUTE);  // Cycle Start again
}

The source code for the Interpreter is there if you wish to add a new command.

This last statement is something I spent some time looking for: where exactly is the defined commands.  More on that later.

I have copied below the example Tom cited: SubroutineWithConditionals (Github link)

 

G20
#100 = 5

(examples of logical operations)
(result is 1 if condition is true)
(result is 0 if condition is false)

#101 = [#100 >  5]
#102 = [#100 >= 5]
#103 = [#100 <  5]
#104 = [#100 <= 5]
#105 = [#100 =  5]
#106 = [#100 <> 5]

(subroutine call can be looped a number of times)
(the L or Q word may be used to specify the count)
(if neither L or Q is specified a count of 1 is used)
(if the count is 0 the subroutine will not be called at all)

M98 P1 L3  (example using L to specify the loop count)
M98 P1 Q3  (example using Q to specify the loop count)

M98 P1 L#100  (example using a variable loop count)

M98 P1 L[5 > 4]  (example using a conditional as a loop count)
M2

O1
#200 = [#200+1]
M99

Although this was new to me (using a third party CAM package, I rarely do more than tweak the resulting G-code; I know, but too many other priorities), but apparently the question was not new. May 2014 Post CNCZone:

Is there a G code supported that will allow a line jump? An M99 P12 will jump to line 12 for example on a Fanuc and some others . I have also seen GOTO used in the G code.

Response:

KMotionCNC supports Jumps to Subroutines which is similar to a Jump if you simply never return. M98 Pxxx can be used to Jump to the GCode Line with the Label: Oxxx The Jump can be conditional as well by specifying a Subroutine Loop Count of either 0 or 1. See the included example SubroutineWithConditionals.ngc

A further example refining the code was given

Still a bit clumsy but here is a way to eliminate your list of repeated conditional subroutine calls by using a looped surbroutine:

 

#100=1
#101=1
M98 P2 L100 (Do up to 100 tools)
G10L2P9X0Y0Z0
#100=0
#101=0
(MSG,Tool Setting Complete)
M2

O2 (Sub to conditionally call another sub)
M98 P1 L[#101=1]
M99

O1
(Change Tool)
M6 T#100
(Set Fixture Offset)
G59.3
(Set Height Offset & Save XY Offset to G59.3)
M101
(Go Home)
G00 G53 G90 Z0.
G00 G53 G90 X0. Y0.
(Send Message and pause)
(MSG,Change to next Tool!)
(Pause)
M00 (Uncheck "Block Delete" To End)
/#101=0
/M99
G00 G59.3 G90 X0. Y0.
#100=[#100 + 1]
M00 (Move Z to desired Offset Height)
M99

And more: Aug 2015 – Yahoo GroupsKflopWebNC Sub Programs

 


Now, on to finding the place to modify the interpreter

I found where the G-Code words are referenced to internal numbered functions (Definitions are in rs274ngc.h), but not where the internal functions are defined. As an example: #define G_93   930. Great. Now where is 930… According to Windows Search, that term only occurs in the aforementioned file (searched the entire directory). RS274ngc.cpp DOES have an occurrance of 300 in it as well, so looking through it.

They are not in either of the above header or program file. I have found DMRS274 Interpreter file in the KMotion Dot Net directories (all C#).

At this point, I surfaced and did a Google search for adding a custom G-code into the linuxCNC compiler. Since that, Mach3 and Kmotion all are derived from the same source, I could find some hints that way.

Stand Alone Interpreter for LinuxCNC

The interpreter is really just a library of related functions that work together to read RS274 files and output canonical commands, it does not
have a main() function(...) nor does it have a "user interface". 

Well. That was helpful. Off to RS274NGC_3.pdf – 2000.

1.3.1 How it Runs

When the Interpreter starts up, before accepting any input, it sets up a world model that includes data about itself, parameter data, and data about the machining center being controlled (including data about the tools in the tool carousel of the machine).

Once initialized, the Interpreter runs using a two-step process: 1. Get a line of RS274/NGC code and read it into memory, building an internal representation of the meaning of the entire line. We will call this stage “reading.” 2. Change internal state and/or call one or more canonical machining functions (see Section 4) in order to do what the line says to do. We will call this “executing” the line.

So, as far as I can see, I might have been right to look in the canonical section, despite not seeing anything before (it is to be included in RS274ngc.h). Well, that was somewhat useful; most of the items in there state references to external code… Let us search keyword: DWELL. It appears in several places, and corresponds to a GCode.

Well.

That showed me enough to convince me that I was correct; there is no one file with definitions for each Gcode; it is spread all over the place.

Aha.

Appendix D. Interpreter Software

D.1 Interpreter Interfaces

The Interpreter has four interfaces, as shown in Figure 9. These are all function call interfaces. The direction of function calling is indicated by arrows. The flow of information in the reverse direction from the arrows differs in the different interfaces. The Interpreter-do-it functions tell the Interpreter to do something, such as read a line of NC code or execute the line last read. These functions all return an integer status code as described in Appendix A.1. The functions themselves are described in Appendix D.4. They are declared in rs274ngc.hh and defined in rs274ngc_pre.cc. The names of these functions all begin with “rs274ngc_”.

So, off to look at _pre. Annnd there is no file in Kmotion labeled that. Reading through NGC…

The file may be pre-preprocessed

into "pre.cc" by "prepre" (a lex-based pre-processor). All

fifteen executables may be compiled from the pre.cc file.

Fair enough; was not pre-processed. Well, back to Google:

Also, after asking a few questions on the developer”s list, I found out that the EMC2 version of the interpreter is encapsulated in a C++ class. Not too long ago, all the functions in the rs274ngc intepreter were named rs274ngc_functionxxx(), but Paul Corner was kind enough to drop the “rs274ngc_” prefix from all the sources, which was a great first step towards generalizing the interpreter function call interface. Here”s how to find out what interpreter functions are being called: 1. The rs274ngc interpreter in EMC2 (and presumably any future
interpreter) encapsulates its functions into a C++ class named Interp.

Well…

January 5, 2016   Comments Off on KmotionCNC Conditional Logic

Brief History of G-Code, Numerical Control, and G-Code Complilers

G-Code (more precisely G and M Code, more formally, RS-274D or other names) is a programming code that dates back circa 1950, and was originally developed to control mechanical machining operations using paper tape.

It shows.

The last ratified standard was in 1980, and the last open source variant in 2000 (RS274NGC_3.pdf – 2000). Most manufacturers extend it in their own directions, making incompatible changes to others doing the same thing. The standardized code has no ability to do any of the commonly done flow control (loops)or logic operations (if, then, else, and, nor). Outrageous, says someone coming from a computing background.

When one examines in detail the actual history, intended operations and uses of these machines, a different picture emerges.

Simple Machines have existed for thousands of years, with compound or complex machines for hundreds, and each generally performed simple, repeated tasks. For example: windmills were used to grind grains to flour continuously, the Archimedes screw was used to lift water. More complex machines, such as the lathe, exist to rotate items, removing material from their diameters. In most cases, the machining progression is a straightforward, beginning-to-end process. 

To illustrate, here is a sample process to produce a wooden candlestick from a raw work-piece on a lathe. It can be broken down into single, discrete steps:

  • load the work-piece into the lathe
  • start the lathe (bow, pedal, water, steam, electricity or other motive power)
  • turn the work-piece cylindrical with a tool
  • carve away material to form the general intended shape
  • carve decorative features if desired
  • drill a hole for the candle
  • stop the lathe
  • unload the machined work-piece

In the above example, there is very little need for any advanced flow control or logic. The workflow is a straightforward progression of isolated steps performed in a procedural manner.

Historically, someone would perform all those steps by hand, and doing so quickly with minimal mistakes became a production bottleneck when industries switched from cottage level craftsmanship to mass production. After all, a Master woodworker can only turn out so many finished pieces in a day. Adding more people and more lathes would speed up production, but costs also rise, since more Master level woodworkers are needed, as is more machines. It is an oversimplification, but it can be said the focus changed to more production at less cost. 

As technology progressed, what used to take a Master level worker with a handheld gouge and pedal powered rotary motion to produce could now be manufactured in a single cycle by an unskilled person placing a work-piece blank into a lathe equipped with multiple cutting knives on a bar and triggering the entire series of operations with a single motion, drastically decreasing machining time. Factories in the 20th century had rows of such machines, each doing a single set of operations on the work-piece, and once completing its process, transferred the work-piece to the next machine to do the following operations. In the generally more complex metalworking world, ways were found of reproducing the actions of the master worker via mechanical means (cams, levers and gears shaped to replicate the same actions). Now that same Master level worker could oversee gangs of lesser skilled personnel overseeing the mechanically automated machines.

Manufacturing continued to move from skilled worker to assembly line worker to automation.

This was acceptable for industry for a time, but setting up each machine mechanically to do only one job and then changing the job performed required expensive and time consuming changes to the mechanisms. A logical extension of the technique was to make a single machine capable of performing the actions of several other machines. Enter the world of Numerical Control (NC); the precursor to Computer Numerical Control.

Machines were constructed that could have their work patterns altered by a punched paper tape, which was fed into a reader, which in turn controlled the machine operation. As technology progressed, the paper tape was replaced with magnetic media, but the basic operations required to produced the same candlestick really did not change; the same operations had to occur, in the same order; only the timeframe for the production of the product had shifted from hours to seconds. The production of G-Code reflected that process; the produced code had little need of more than the ability to loop operations and utilize subroutines. Typical operations were:

  • re-iterate a cutting/drilling/boring/milling procedure until final depth was reached
  • utilize a preexisting movements (subroutine) when a particular point in the main program was reached (move the machine to a specific spot, trigger the drilling subroutine, move to another spot, trigger the drilling routine again)

Very procedural programming.

Enter the 21st century, with vertical machining centers capable of self-feeding in work stock, performing lathe and mill operations simultaneously while interfacing to external automation systems, and now operational complexity has outstripped the original purposes.

Machine control manufactures extended the standard G-Code to include storage variables, more so-called canned cycles, goto, if-then-else flow control, AND,OR,NOR logic, and even so-called conversational programming (select operation, select size, select depth, select direction, speeds and feeds, push go; the machine generates the G-Code), all to the goal of increasing production, decreasing cycle time, improving cost-effectiveness.

But what if you have none of those features built in to the controller? Enter G-Code Compilers.

General purpose computer programming languages have long since needed flow control and conditional operations, and it is entirely possible to interface the two. An example from my own research is using C language to handle the flow and conditionals, and have it produce executable G-Code for each case. Here is an example from the web; someone made a compiler that converts logical arguments in C to LinuxCNC compatible G-Code:

CGCC Gcode CompilerFeatures and Examples

// Constants
const float X_Holes = 10;
const float Y_Holes = 10;
// Loop
for (float y = 0; y < Y_Holes; y++) {
for (float x = 0; x < X_Holes; x++) {
if (x != y) {
G00 Z1
G00 X[x] Y[y]
G01 Z0 F1
G00 Z1
}
}}
The above code is as follows:
– Want to drill a grid of 100 holes in a 10 x 10 inch grid
– the code is repeated 100 times with different X and Y coordinates.
– The code has to skip a line of holes down the diagonal where X equals Y

The person states that LinuxCNC CAN produce this workflow through the added-on O-codes (extension of the original RS-274D standard) but it is hard to produce good programs quickly. The result is a program that takes C language syntax incorporating G-Code and produces LinuxCNC compatible Gcode.

Others have similar needs:

GCME – G-Code Meta Compiler

January 5, 2016   Comments Off on Brief History of G-Code, Numerical Control, and G-Code Complilers

Dynomotion KFLOP and KSTEP running from Raspberry Pi using patched version for Linux of KMotionCNC

Who might be interested in this.

Anyone that would like to operate their KFlop controlled machine from their phone, tablets or anything with a web browser.

Github Repository of the patched system

GitHub Parhansson

YouTube Link of Operational System

January 5, 2016   Comments Off on Dynomotion KFLOP and KSTEP running from Raspberry Pi using patched version for Linux of KMotionCNC