Profile - Depth Type 3D - G Code

[mattpatt]

Hi Guys,

Got some strange G code output going on, and wondered if anyone can throw light on it.

I'm milling around a profile using 3D depth type. The simulation works fine, but the problem occurs at the G code generation.

If I select to rough only then the code is fine. G90 absolute coordinates and just as I planned.

If I rough and finish in the same op then it's also fine. Same as above (G90).

But, if I select to just finish then the G code goes very strange. The toolpath goes haywire. Parts of the code are in G90 absolute and other parts are in G91 incremental. This would be ok, but it's calling a G91 where it should be a G90. Not always in the right place though.

It's obviously something to do with my .mac & .gpp files as if I use the supplied fanuc.mac and fanuc.gpp files the output is different again. In some cases putting a G90 and G91 on the same line.

Confused!

I fiddled the code (using Cimco Edit) and all's well on the machine, but I can't be doing that all the time.

I'm guessing that I need to print out the gpp tool help manual and take it to bed for bed time reading.

[Brakeman Bob]

Hi Matt,

Take a look in your GPP file and near the top look for a commented out "trace" command. Delete the comment, save the file and post out your code - the output will show what the CAM is putting out and what sub-routine in the post is generating your odd code. My guess is a sub call in either @line or @rapid is causing the problem, but that is only a guess and you really need to examin the debug code.

All the best

Bob

[mattpatt]

Bob,

Well, it's been awhile but I eventually got around to trying to sort this out.

It seems that the @absolute_mode section in the gpp file was a little lacking:

-------------------
gcode = 90

skipline = true
endp
-------------------

Changed it to:

-------------------
gcode = 90
{nb, 'G'gcode, ' '}
skipline = true
endp
-------------------

And now works a treat.

No idea where the missing line went to, but I've simulated both old and new programs back to back and this seems to have solved the issue for now.

Now I must go to back of class and write lines.....

Check gpp file
Check gpp file

etc etc etc.........

[Brakeman Bob]

Now I must go to back of class and write lines.....

Check gpp file
Check gpp file

etc etc etc.........

Hey Matt, that seems a little harsh. Far better to study the manual and plan how you would build a new version of your post from the ground up.

Bob

[mattpatt]

Bob,

You are right of course.

This may sound like a stupid question, but what's the best plan? Up to now I've pretty much skipped through the manual as and when I've had a problem. Mostly I can solve it, or at least see what's going on, but as for writing my own from scratch!

Oh well, I guess it's just a case of getting stuck in and getting on with it.....but any suggestions would be very welcome.

Matt.

[Brakeman Bob]

Matt,

I found writing my own posts one of the most satisfying things I have do regarding CNC. I start by writing a specification - nothing fancy, just a good description of how I wanted the code to look illustrated with examples. Things such as what happens at the beginning of a program, what happens at tool change and what happens between each cut or pass. Remember, the actual cutting bit of code is the most straightforward and the hardest bit is the code around toolchange - it is very easy to send the tool straight through the job if G28 is missing. Think about what happens when and the logic behind it, such as "if I have work work offsets in my CAM program, how do I want the machine to handle the change from one offset to the other?". This is crucial if sometimes Offset 1 is 150mm higher than Offset 2. Think very hard about the different circumstances and plan the logic about that.

I started tweaking SolidCAM posts by completely rewriting the drilling section of my GPP file, first to reflect all the canned cycles on my machines then to provide specialist code such as peck drilling with G00 and G01 (because sometimes our SH400 alarms out if it does too much G83 - go figure) or spiral hole milling. Then I moved on to handling pallet rotation bith a B axis - ah, the delights of @tmatrix! From there it was just a short step to tool changes and vóila, you have a post. Then come the scary stuff when you have to test it, watching like a hawk. Just as you think you have it nailed, some situation you haven't foreseen occurs and your code isn't up to it, so it is back to the GPP file and think again. This happens a lot at the beginning of the development process but you will get there in the end.

Matt, have you done any sort of computer programming? I mean things like BASIC or other computer languages. If you have, then will be familiar with the concept of variables and their types, if you haven't you need to study that bit of the manual in particular. The main uses of the variable types is as follows
NUMERIC : any number that has decimals, so if you want a variable to store an axis position for some reason, this is what you would declare it as.
INTEGER : a whole number. Used when counting something. I used this in my peck drilling cycle to count how many loops (or pecks) a drill had done before exiting the loop and drilling to the final depth.
LOGICAL : a simple yes or no. I use logical (or BOOLEAN) variables for things like "is this the first rapid move? If YES, insert a spindle start"
STRING : anything that is text (and may include numbers). Used for generating comment lines and other things. For example I use string variables for generating comment lines in the program and to create a textfile separate from the program giving a listing of all the tools and the CAM job names

I have gone a bit longer than I meant to, sorry.

Hope this helps.

Bob

[mattpatt]

Bob,

"I have gone a bit longer than I meant to, sorry."

You could have gone on a lot longer and I wouldn't complain Shame you're not here in Thailand, 'cos I'd rack your brains for hours!

At the moment I'm reasonably happy with most things, but there are couple of little quirks that I'd like to change. For example, I still haven't sussed out the G80 generation that isn't happening after 3-d drilling, but since I don't use it a huge amount at this time I just (lazily) keep writing it in manually.

I'm also not sure if I can generate a G2/3 code is the XZ and YZ axis. It would have been jolly handy on the last job I did, which was two R42mm channels, along a block. I used linear technology to semi-finish and finish the part. It came out quite sweet, but the program was all linear moves and nearly 2 million lines to the program! I had a look through the manual, and changed a couple of things in the files but it still put out linear moves and not G2/3. Hmmmm.

Anyway, It looks like my best approach for now is to take it a step at a time and build up to the final (for now) version.

Thanks for offering your advice.

[Brakeman Bob]

For example, I still haven't sussed out the G80 generation that isn't happening after 3-d drilling, but since I don't use it a huge amount at this time I just (lazily) keep writing it in manually.

I'm also not sure if I can generate a G2/3 code is the XZ and YZ axis.

The 3D drilling is a little odd as the G80 call needs to be generated for @drill_point (he says working of memory - it's two years since I did that in my post!). Like you, I hardly ever use 3D drilling - all my holes are on different angular displacements.

You can get SolidCAM to use G18 and G19 and then sung G2 & G3, though I have never used it. I believe you set the plane as YZ or XZ in the co-ordinate system set-up and go on from there. I imaginge that you would set up a separate MAC for these jobs that are using G18 / G19 and then set up you post so that it read the difference and acted accordingly.

We use right anle head tooling here quite a bit, though they are all programmed manually using parametric macros - I'm going to have a play at building a post for this I think.

All the best

Bob