[Home]AdditionalGCodeFunctionality

LinuxCNCKnowledgeBase | RecentChanges | PageIndex | Preferences | LinuxCNC.org

Difference (from prior major revision) (minor diff, author diff)

Changed: 49c49
See: SubroutineSample for some code that uses this.
See: SubroutineSample for some code that uses this. For a fairly complex example see JMKsFusee.

Changed: 222c222
17.11 Tolerance setting for are endpoints, mm
17.11 Tolerance setting for arc endpoints, mm

Changed: 224c224
18.12 Tolerance setting for concavity, inside corners, cutter compensation.
17.12 Tolerance setting for concavity, inside corners, cutter compensation.

Introduction And History

For quite a long time we have wanted additiona features added to the NIST RS274.NGC interpreter. Keith Rumley spoke of some of his modifications at the first fest in Detroit. That fest was named EMC-Monday. In general the issues include

Several of these issues were addressed in code submitted to the emc branch at SourceForge about the same time it was decided to move development to the emc2 branch. Further stress was added by forks that produced different code for emc2 interpreter than were used for the emc changes. These two divergent systems require that we now merge these systems by hand.

Once the merge is completed, it is essential that the new interpreter be tested extensively to satisfy all that it is good. The good pronouncement will be made by the EMC board as soon as test procedures have been established and results confirmed.

Summary of Actions

A branch will be setup in the emc2 module that will allow ken, keith, and others to work out source for the new interpreter. The following is a brief discussion on IRC that led up to this.

Ken Lerman Stuff

Additonal interpreter functions that are needed:

See: SubroutineSample for some code that uses this. For a fairly complex example see JMKsFusee.

I, Kenneth Lerman, the originator of this page have NO G code experience. I'm a programmer and compiler designer who does have some idea of what I'd like. Feel free to change this stuff so that it makes sense for this environment. Some thoughts:

In the examples below, things in italics are my comments.
Onnnnn sub declare the beginning of a subroutine
the subroutine body goes here
Onnnnn endsub end of subroutine declaration - the nnnnn must match the nnnnn in the sub line

Onnnnn while [expression] begin loop do it while [expression] is true
the body of the loop goes here
Onnnnn endwhile end of loop - the nnnnn must match the nnnnn in the while

Onnnnn if [expression] conditionally execute the body if [expression] is true
the body of the conditional goes here
Onnnnn else if the "if" wasn't true, the else part will execute
the body of the else goes here
Onnnnn endif end of conditional - the nnnnn must match the nnnnn in the if

Onnnnn if [expression]
body
Onnnnn elseif [expression] acts like an else followed by an if
body
Onnnnn endif

Onnnnn do
this body is executed at least once
Onnnnn while [expression]

Onnnnn call [arg1] [arg2]... call the subroutine with the declaration nnnnn. Optional arg1, arg2,... (up to arg30) will be passed in parameters 1 to 30 in the context of the called subroutine. On return from the subroutine the original values of those parameters will be restored. The args are full expressions that are evaluated in the calling context. Subroutines may call other subroutines (even recursively) with a maximum nesting level of ten.

Onnnnn return return from the containing subroutine
Onnnnn break break out of the while with label Onnnnn -- this will skip down until the matchining endwhile, and may break out of multiple nested whiles.
Onnnnn continue skip down to the end of the while with label Onnnnn. If it was a do...while, the while will be evaluated and the loop repeated if appropriate. If it was a while...endwhile, the endwhile will execute which takes control back to the matching while.

Some notes:

I believe these definitions should provide a lot of functionality at very low implementation cost. Comments, suggestions, etc are always welcome.

Keith Rumley Stuff

The following email describes what Keith is thinking about a migration of their work to the EMC2 branch. Some lines are quoted from an earlier post.

I was typing this out to reply on list, but since I'm not on IRC, and wouldn't be able to make it tomorrow, anyway, perhaps the following would be useful as a starting point.

>> The real problem is that the interpreter that Ken is talking >> about is in emc not emc2 nor BDI. This is an issue that we

Back in May I did a test compile with the EMC1 interpreter plugged into EMC2.

It took about a few hours, but was easier than I expected. (Wholesale replacement of the EMC2 RS274NGC/ with EMC1 rs274ngc_new/. Replacement of emctask/emctask.cc emctask/emc_canon.cc and emctask/canon_pre.cc, update to emc.cc and emc.hh as below.)

>> will need to resolve in the next few days. Perhaps this >> weekend, during the IRC on Sunday (hint >> hint) we can study enough of it out to work out the steps >> need to make this possible.

For an actual merge, my understanding is that the following would need to be addressed:

1. Agreement on what to migrate Then,

2. Move features to separate files for given functions/commands and update the related function calls and error messages. The AND/OR/IS/ISNT and /*AA*/ etc stuff would need cleaned out of the EMC1 code. rs274ngc.hh has a fair amount of change, as well.

3. Harmonize emc.ini files

4. Harmonize the emctask/ files emctask.cc, emccanon.cc, and canon_pre.cc with their EMC2 equivalents. This primarily involves changes to features being migrated. (expanded ini-file variable passing to the interpreter)

5. Harmonize the emcnml/ files emc.cc and emc.hh Reference interpreter-determined array sizes to rs274ngc.hh, instead of hard-coding them.
emc.hh:
...
#include "rs274ngc.hh"
...
#define EMC_TASK_ACTIVE_G_CODES RS274NGC_ACTIVE_G_CODES;
#define EMC_TASK_ACTIVE_M_CODES RS274NGC_ACTIVE_M_CODES;
#define EMC_TASK_ACTIVE_SETTINGS RS274NGC_ACTIVE_SETTINGS;
...
emc.cc:
...
void EMC_TASK_STAT::update(CMS *cms)
...
cms->update(activeGCodes,EMC_TASK_ACTIVE_G_CODES);

cms->update(activeMCodes,EMC_TASK_ACTIVE_M_CODES);
cms->update(activeSettings,EMC_TASK_ACTIVE_SETTINGS);

6. Documenting the features/changes

Having worked a lot with the interpreter, I'm interested in how this issue develops, and would like to help if I can. I'm at my limits for time is the other issue.

If you and the folks on IRC Sunday can come up with a list, I could perhaps incrementally work away at it.

Regards,

Keith


Attached is a review of the EMC1 interpreter changes, between mine and those KL has made.

1. G92 bugs cleared up (after M02, abort, affected commands G92 aware)

2. G92 P<1-9> modifier (lets the coordinate systems be set directly to value given, vs using G10 L2 and entering desired position in absolute coordinates to get the same thing )

3. G92 is modal, and mode is retained in the active code display. Lets you know it's on/off/stored.

4. G54-G59.3 commands turn off and save G92 offsets. A switch may be set in the ini file to keep them in effect.

5. Subroutines and conditional evaluation commands added.

6. User M code implementation expanded and cleaned up. Two examples are in emc/programs/M101, M102.c

7. Multiple user M codes, and M62-M65's may be on one line. M62-M65 get priority.

8. User m-codes are executed in the order they appear on the line.

  (within the groups M62-M65, and then the general user m code group.) 
  Incidentally general user m-codes execute last of any m-codes on a line.

9. M62-M65 throw an error if they get invalid values. (negative values)

10. Error checking for P/Q values back in place, and user M code handling for them.

11. MS-DOS format files are allowed.

12. Semi-colons may be used for comments

13. An incremental retract peck-drilling cycle added, G83.1.

14. MDI command error checks now displayed.

15. Bug fix for pseudo random motion when a command issued from MDI before previous motion was complete.

16. New files (including same file) may be (re)opened without having to run or 'verify' them first.

17. Ini file control of a number of interpreter options, some previously compile-time only.

 17.1 Allow files without '%' and 'M02/M30' file delimiters

 17.2 Skip comment reading. Speeds up g-code parsing if you've lots of comments

 17.3 Keep current coordinate system in effect after M02/M30

 17.4 Coordinate system to use as default after M02/M30

 17.5 Keep G92 axis offsets after M02/M30

 17.6 Keep G92 axis offsets after G59-G59.3 (old default behavior, obviates P2 modifier)

 17.7 G83 rapid down distance above bottom of hole

 17.8 G83.1 rapid retract increment

 17.9 Tolerance setting for what is considered logically equal in expressions  

 17.10 Tolerance setting for arc endpoints, inch

 17.11 Tolerance setting for arc endpoints, mm

 17.12 Tolerance setting for concavity, inside corners, cutter compensation.


LinuxCNCKnowledgeBase | RecentChanges | PageIndex | Preferences | LinuxCNC.org
This page is read-only. Follow the BasicSteps to edit pages. | View other revisions
Last edited January 2, 2009 10:56 pm by KimKirwan (diff)
Search:
Published under a Creative Commons License