Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: bucky898 on November 24, 2009, 04:13:11 PM
-
I have a program with the line "M98 P2 L2". It should call subroutine O2, two times. However, it calls the subroutine 4 times. Has anyone every seen this? I originally had "M98 P2 L12" - I stopped the program after the subroutine was called 17 times. I then changed the L word to L2 to see what would happen and now it calls 4 times. I upgraded to the latest stable version, R3.042.032, but no change in behavior. I am running Win XP and the machine is an IH CNC mill. Here's the whole program:
G0 Z5
G0 x-24 y9.24
g0 z0
M98 P2 L2
g0 z5
M30
(O1 - drill bolt hole)
O1
F50
G0 Z1
G1 Z-24
G0 Z5
M99
(O2 - cut out clear area for bolt head, x- y+)
O2
F100
g91
g1 z-1
g90
G0 x-24 y9.24
g1 x-9.24
g1 y24
g1 x-14.24
g1 y14.24
g1 x-24
g1 y19.24
g1 x-19.24
g1 y24
g1 x-21
g1 y21
g1 x-24
g0 y9.24
m99
-
Hi Bucky
It's rearing the (O2 - cut out clear area for bolt head, x- y+) as if it was another O2 put a ";" as below or delete the line
;(O2 - cut out clear area for bolt head, x- y+)
There are some other issues with the M98 routine and it needs to be looked at.
Chip
-
Hi, All
Hera's an example of issues, I think Only One of these "O30"es should be Used by the "M98 P30 L1" routine or Recognized by the G-code Loader/Interpreter.
Mach3 Ver. R3.042.032
G80 G90
N10 M98 P30 L1
G01 Z0
M30
%
'O30 (CUT'S THIS FORTH "WHY")
G01 Z-.25 F20
G01 X1
G01 Y-1
G01 X0
G01 Y0
M99
(O30) (CUT'S THIS THIRD "WHY")
G01 Z-.25 F20
G01 X-1
G01 Y1
G01 X0
G01 Y0
M99
O30 (CUT'S THIS SECOND "OK")
G01 Z-.25 F20
G01 X-1
G01 Y-1
G01 X0
G01 Y0
M99
O0030 (CUT'S THIS FIRST "WHY")
G01 Z-.25 F20
G01 X1
G01 Y1
G01 X0
G01 Y0
M99
%
Any Thought's, Chip
-
Hi, All
I did see in the manual that the "%" or "\\" and "()" should be used for Comment's and such.
In the End Shouldn't some of these be rejected or load of a file be halted as an Error.
10.5.5 Comments and Messages
A line that starts with the percent character, %, is treated as a comment and not interpreted
in any way.
Printable characters and white space inside parentheses is a comment. A left parenthesis
always starts a comment. The comment ends at the first right parenthesis found thereafter.
Once a left parenthesis is placed on a line, a matching right parenthesis must appear before
the end of the line. Comments may not be nested; it is an error if a left parenthesis is found
after the start of a comment and before the end of the comment. Here is an example of a line
containing a comment: G80 M5 (stop motion)
An alternative form of comment is to use the two characters // The remainder of the line
is treated as a comment
Comments do not cause the machining system to do anything.
A comment that is included in parenthesese, contains a message if MSG, appears after the
left parenthesis and before any other printing characters. Variants of MSG, which include
white space and lower case characters are allowed. Note that the comma which is required.
The rest of the characters before the right parenthesis are considered to be a message to the
operator. Messages are displayed on screen in the "Error" intelligent label.
Thanks, Chip
-
Just a guess....The "O" line can NOT have an "N" word and line # in front of it. It may also mean that there must be NOTHING in front of it as well.
Not any character of any kind.
Maybe ?
Russ
-
Hi, Russ
I Agree, Except the second one has no character in front of it and the others are commonly used to comment out or hide Text, Hears a better file to look at.
If theirs an N## it doesn't run it at All.
G80 G90
M98 P30 L1
G01 Z0
M30
%
;O30 (CUT'S THIS FIFTH "WHY")
G01 Z-.5 F20
G01 X-1
G01 Y-1
G01 X0
G01 Y0
M99
\\ O30 (Doesn't CUT'S THIS "OK" and skips the G code to the m99 also when run)
G01 Z-.25 F20
G01 X-1
G01 Y-1
G01 X0
G01 Y0
M99
% O30 (Doesn't CUT'S THIS "OK" and skips the G code to the m99 also when run)
G01 Z-.25 F20
G01 X-1
G01 Y-1
G01 X0
G01 Y0
M99
'O30 (CUT'S THIS FORTH "WHY")
G01 Z-.25 F20
G01 X1
G01 Y-1
G01 X0
G01 Y0
M99
(O30) (CUT'S THIS THIRD "WHY")
G01 Z-.25 F20
G01 X-1
G01 Y1
G01 X0
G01 Y0
M99
O0030 (CUT'S THIS SECOND "WHY")
G01 Z-.25 F20
G01 X1
G01 Y1
G01 X0
G01 Y0
M99
O30 (CUT'S THIS FIRST "OK" This is the only one that should be executed)
G01 Z-.25 F20
G01 X-1
G01 Y-1
G01 X0
G01 Y0
M99
%
Thanks, Chip
-
Russ's comment is valid, but the other stuff, well only Brian would know or can fix.
Your posting puts it into perspective. My question would be "How do you know that specific problems
reported are not lost and will be taken care of over time?
Maybe we should create a "PROBLEMS LIST" viewable by all but can only be added to by moderators.
This way memory of problems would not fade.
RICH
-
> It's rearing the (O2 - cut out clear area for bolt head, x- y+) as if it was another O2 put a ";" as below or delete the line
> ;(O2 - cut out clear area for bolt head, x- y+)
Thanks, Chip. Removing the parenthesized line does fix the problem, but of course a comment line *should* be completely ignored by the parser. Are there other known problems in the way comments are handled?
-
Hi,Chip
For some reason it seems to depend on whether there is a space between the comment designator and the O30.
Here’s what I get, (referencing your sample code):
CO30 CUTS
C O30 NO CUT
%O30 CUTS
% O30 NO CUT
;O30 CUTS
; O30 NO CUT
And even:
NO30 CUTS
N O30 NO CUT
But there are exceptions as:
//O30 NO CUT
// O30 NO CUT
\\O30 NO CUT
\\ O30 NO CUT
I would think that leading zeros are OK and should be allowed as in the O0030.
For what it’s worth.
Al
-
This will all become somewhat moot shortly, when Mach3 V4 comes out - It will use a completely new and different G-code parser, and will accept *only* () for comments.
Regards,
Ray L.
-
Hi, ALL
Thanks for the comments, All in All if we don't post questions and concerns and try to help others, Nothing would ever get fixed.
Hears a question I asked Brian on the yahoo site.
Re: M98 or G-code Loader/Interpreter "Question"
Hi, Brian
One more Look, It's missing the leading numbers values in Two of the "O" lines.
G80 G90
M98 P30 L1
G01 Z0
M30
%
O0300 (Doesn't CUT'S THIS "OK" G code Interpreter is seeing the extra trailing
caricter "0")
G01 Z-.25 F20
G01 X1
G01 Y-1
G01 X0
G01 Y0
M99
O030 (CUT'S THIS THIRD "WHY" Should be rejected, G code Interpreter is missing
the leading "0")
G01 Z-.25 F20
G01 X-1
G01 Y1
G01 X0
G01 Y0
M99
O0030 (CUT'S THIS SECOND "WHY" Should be rejected, G code Interpreter is missing
the leading "0"es)
G01 Z-.25 F20
G01 X1
G01 Y1
G01 X0
G01 Y0
M99
O30 (CUT'S THIS FIRST "OK" This is the only one that should be executed)
G01 Z-.25 F20
G01 X-1
G01 Y-1
G01 X0
G01 Y0
M99
%
Are these rejected in the "New Versions" ?
Just Hunting Bug's, Chip
-
You should not expect the G-code interpreter to distinguish between "30", "030", "0030", "0000000030", etc. The argument to G98 is simply a numeric value, and all of those evaluate to "30", so *should* be seen as identical to the interpreter. If you write code *expecting* the interpret to distinguisjh between those, you *will* have problems, as that behavior will be very much dependant on the specific interpreter, and will likely vary from machine to machine. If the interpreter DID distinguish between those, I would consider that a bug in the interpreter.
Regards,
Ray L.
-
This will all become somewhat moot shortly, when Mach3 V4 comes out - It will use a completely new and different G-code parser, and will accept *only* () for comments.
Regards,
Ray L.
Hi Ray,
True, but until Rev 4 is released, we must live with what we have now and need to understand its idiosyncrasies.
Al
-
Hi, Ray
I guess it's to much to expect a few String's in a G code interpreter or a few more Error warnings, I still have my caveman outfit, Didn't think it would be that big-a deal and don't remember so many issues in earlier versions of Mach3.
Thanks, Chip
-
Hi, Ray
I guess it's to much to expect a few String's in a G code interpreter or a few more Error warnings, I still have my caveman outfit, Didn't think it would be that big-a deal and don't remember so many issues in earlier versions of Mach3.
Thanks, Chip
Part of the problem with Mach3 is it's tried to be all things to all people, and in some cases, did not follow standards, or followed multiple standards. I think this is one of the latter. The G-code parser has also become rather tangled over the years, making it difficult to maintain, and probably a bit quirky, as you're seeing. For V4, Brian is using a completely new parser that will be much easier to maintain and extend if necessary, and he is following a very well documented and published syntax, so there will be NO ambiguity. It will also be thoroughly tested by a true expert. In terms of consistency and reliability, it should be a big step up.
Regards,
Ray L.