[ozzie34231]

I too was having the problem referred to in the G-code export thread.
I did as suggested and it works, or I guess it does; I got output.
My problem is that there are two wild G0 moves. Here is the beginning and end of the post:
%
:11 (STEMFIRST.TAP)
/G28 U0. W0.
M01
N01 ( T01 )
G28 U0.
T0101
G0 X150. Z200.
G97 S1200 M3
G0 X0.709 Z0.042 M8
(---------------------)
(TR-CONTOUR-T1A - TURN)
(---------------------)


G1 X0.528 Z-0.168
Z-0.227
X0.646
G0 Z0.01
G0 X190. Z200.
M30
%
I've gone over all the info I put in and am at a loss to understand how these very large numbers got there.
HELP PLEASE !
Additionally I thought I was setting up for feeds to be in inches per rev., but I don't see a G95. Should there be one?
I'm running Mach 3.
Thanks,
Ozzie

[Brakeman Bob]

First run a trace. If you open the GPP file somewhere near the top will be a line (if its not there put it below the variable declaration in @initpost)

; trace "all ": 5

remove the semi-colon, save the file and then post the program. The output you get is what the CAM is putting out in terms of variables so if you scan down for your rogue lines you will see what routine is calling it; my guess it is either an @line or @rapid and you are returning to the start point set in Tool Settings 9but I may be wrong). Then you need to build the logic to handle the output toget the code you want.

Likewise, if you want your post to have dual unit functionality there need to be logic in the GPP to detect what units are being used in the CAM and then call the G95 or G94 accordingly. Some users prefer to have separate post processors for imperial and metric; it comes down to personal choice.

If you need more, study the GPP help pages in SolidCAM or download the GPP manual from the SolidCAM website.

Good luck

[ozzie34231]

Thanks Bob,
I've been reading the GPP manual.
The moves should be a result of the dflt_start, dflt_end numbers in the Mac file, but they are not! (I think)
The manual also says, "This value can be changed inside SolidCAM through the Part Options field." But i can find no such Part options field. The entries referred to are apparently in the TOOL options area. However I set all these to "1", and still get these strange coordinates.
When I look in the Mac file the dflt_start, dflt_end entries there are six numbers,
"dflt_start = 75.0000 0.0000 150.0000, 7.8740 0.0000 7.8740
dflt_end = 75.0000 0.0000 150.0000, 7.8740 0.0000 7.8740"
I don't understand this at all, can you help there?
I'm very new to this GPP thing.
I must re-read the remainder of your post and try to understand it more.
Many thanks,
Ozzie

[ozzie34231]

Hi again BOB,
or anyone with some help
I read your post several times and played with the "trace" thing. Unfortunately I can't get much to match up with the code I see and the supposed source.
If I understand what I see the first wild number is a result of a tool change position, (though why it would be after the tool number call, I don't know), But the position doesn't match any numbers that I can find anywhere; Mac file, tool parameters, etc. The second the dflt_end, but again no match to anything!????

In the "trace" I see letters after the numbers as in the following cut:
>
@rapid_move ==> xpos:0.323F ypos:-0.124F zpos:0.010T
..>
>
> G0 Z0.01
@tool_path_info ==>
>
@end_of_job ==> no parameters
>
@end_program ==> xpos:1.000T ypos:0.000T zpos:1.000T
..> last_line:0
>
> G0 X190. Z200.
> M30
@end_of_file ==> no parameters
> %

F's and T's, can you explain?

I suspect there are some variations between the high G-code numbers in Fanuc and Mach 3. Where can I find the Fanuc G-code defs.?

Thanks,
Ozzie

[ozzie34231]

I found the G-codes, there is no difference.
The trace says mm/rev but I see no G95.

Ozzie

[Brakeman Bob]

OK, the F's & T's are easy; it means has the value changed from the last position. "T" = changed and "F" = remains the same. You can use this functionality in two ways, first with square brackets, eg [xpos] which means the post does not out put that value if it has not changed. The second way is the "change(var)" command used thus

if change(zpos) eq true
do something
else
do something else
endif

This is very useful functionality.

Secondly, Part Options are user created options that reside in the MAC file. You can put anything you like here and one possible use would be a logical variable called METRIC which if True issues the G code for metric and if False issues the code for Imperial. To output G95, it would be a simple matter of

if feed_unit eq 'mm/rev' (not sure about the quotes)
{'G95'}
else
{'G94'}
endif

This will output a G95 or G94 in the middle of a line.

Thirdly, it looks like your wild number are being generated in @end_program in the GPP file, so look there to see what variable is being called to give the X & Z positions. My guess is that it is set in either the turning defaults in the MAC file or in the work co-ordinate setting page of CAM settings.

I notice that this is a turning post - turning in FANUC is not my strong point (five axis milling in Heidenhain is much more my thing) so please treat my codes with scepticism.

[ozzie34231]

Hi Bob,
Thanks so much and please don't give up on me. We're making big progress.
The two wild lines are a result of tool change and end of program in the .GPP.
I changed the entries to reasonable coordinates and they come through in the code. So far okay.
There is still much I'd like to know. In the MAC file there are default start, default end and default tool change coordinates, but the GPP seems to ignore these and use coordinates within it's own file. I thought the GPP is supposed to read from the MAC and post accordingly.?? And although there are places in the solidcam operation to enter coordinates for tool change, these seem to be ignored.
Below are parts of the .tap created with trace and the relevant part of the .GPP.
Note that the trace quotes the coordinates I entered in the operation, X1 Z1 but then prints those from the GPP!???
I haven't messed with the G95 yet, I'll get to that next.
I keep reading, (trying to read), the GPP manual I downloaded from Solidcam, but it assumes too much for my level of ignorance. I see things in the Mac and GPP that I don't understand and use the search utility in the manual with zero results. At some point a light will appear, maybe.

From TRACE of .TAP
@tool_path_info ==>
>
@end_of_job ==> no parameters
>
@end_program ==> xpos:1.000T ypos:0.000T zpos:1.000T
..> last_line:0
>
> G0 X190. Z200.
> M30
@end_of_file ==> no parameters
> %
--------------------------------------------------
From .GPP

@end_program
xpos=xtool
zpos=ztool
if save_spin_unit <> rpm
gcode = 97
{nb ' G'gcode}
endif


; if stopper ne 0
; {nb ,'G0 X3. Z2.'}
; if tool_stop lt 10
; {nb,'T0'tool_stop,'0',tool_stop}
; else
; {nb,'T'tool_stop,tool_stop}
; endif
; {nb,'M5'}
; {nb,'M9'}
; {nb,'G0 X0. Z'stopper}
; {nb,'M11'}
; {nb,'M00'}
; endif

{nb,'G0 X3. Z2.'}
; if acpalot ne 0
; {nb, 'M99'}
; else
{nb, 'M30'}
; endif
endp

Can you explain what's going on?
What does "stopper" mean?
What is Ne 0?

I don't understand the sequence of the early commands:
%
:11 (STEM 1.TAP)
/G28 U0. W0.
M01
N01 ( T01 )
G28 U0.
T0101
G0 X3. Z2.
G97 S1200 M3
G0 X0.709 Z0.042 M8
(---------------------)
(TR-CONTOUR-T1A - TURN)
(---------------------)
G99 G97

The code issues an M1, I assume so the tool can be changed, but then the move to the tool change position comes after the T call and the M pause???

Anyway, I'm getting there. I've never played with post processors before, I just edited if things were wrong, but that's not very satisfactory when you want to go back and make a minor changes in the design and re-post; the edits must be done again. So this time I'm determined to make it post right. It could take this old brain a while to get it though.
Regards and Thanks,
Ozzie

[ozzie34231]

Well, maybe I lost my mentor? But Bob put me on the track.
I've struggled through to achieve most of what I wanted.
The post now goes to my tool change position, defined in the GPP. Then the tool change, then a G95, and the code. All correct for me and Mach 3.
At the end it goes to the same change position, issues a G94, (for safety), and ends the program.
I can work with that!
This first test is with only one operation, now I'll go to multiple operations to see if all is well.
There are still "words" in the Gpp I don't understand, and if I did I might improve the scheme even more.
"!", "stopper", "Ne", "acpolot", the numbers after the variables definitions, all are a mystery so far. The GPP manual doesn't help with these!
If anyone out there,,,,,,,,,
Ozzie

[Brakeman Bob]

Hi Ozzie,

No, you haven't lost your mentor - I didn't get chance to post on Friday and this morninging I've been busy (I have a rule not to check the forum at weekends). I am glad that you have got towards where you want to be.

OK, starting from your latest post and working backwards. The words in the GPP that you don't understand are probably the leftovers from someone else's efforts, either an internal variable defined in @init_post or a PART or JOB OPTION defined in the MAC file. What they do only the original creator can confirm (unless they are well described by comments).

It looks to me as if your post is configured for producing sub-routines or sub-programs (known as PROC's in SolidCAM speak). I am no lathe driver, but I do know that this makes for complicated a post-processor. The variable "acpalot" looks like a counter or boolean to trigger the M99 (as in sub program) or M30 (for program end).

Ozzie, learning GPP is daunting but it isn't that bad, perhaps about the same as learning VBA for MS Office macro programming except the documentation isn't as good. I got into GPP by first studying the MAC & GPP files in conjunction with the GPP manual, looking up every blessed thing I didn't understand. Then I studied the GPP again to work out the logic of what was happening. Finally I had a play with the GPP, creating sub routines (anything that starts with "@") and checking the output code.

To my mind, the heart of pst processor writing goes like this

(1) Decide what code you want. Usually these are the lines before and after the actual cutting (including the first rapid move) as it is here that you need to specify how a tool change is handled, how the speed & feed is defined, the format of a canned cycle such as drilling, when do you want coolant turned on and off etc.

(2) Then you define the rules by which these events are handled. For instance, are all jobs to use MM/REV or just the turning ones, leaving drilling to use MM/MIN.

(3) Then you devise the logic in GPP to implement these rules and test it.

(4 )Finally, you keep repeating steps (2) to (4) until you get it right. Developing a "bomb-proof" post takes many iterations but in the end you get something that produces code that you never have to manually edit and, by, is that satisfying.

Starting whit a post that produces nearly what you want is a double-edged sword; the good thing is most of it is already there, the downside is you have to wade through another guy's logic and sometimes you mend one thing and break three others.

Good luck

[ozzie34231]

Glad to hear from you Bob.
Along with your help of pointing the way, the method of learning that you describe is what I've used, reading, looking up, trying.
What I started with was/is the standard "Fanucot" Mac and GPP so there should not be another's work there.
I have no programing ability and only want to learn enough to "make it work".
I consider myself a hobby machinist, though I do make some stuff for sale. I might add that I'm old
The post I'm getting now looks good to me; solves all the places I would have hand edited in the past.
I removed all the "machine coordinate" moves.
I get G95 and G94 appropriately.
The end of program moves and close are what I like.
It sounds simple but it took me many hours. I'm more confident that if I find I need other changes, I can do it.
I'll leave it for now, happy to know that you are here to help if I need it in the future.
Thanks,
Ozzie
Here's one of the things I make www.gatsbyflytyingvise.com

[Excelmachine]

Off topic, but Very nice vise Ozzie.