Prototrak SLX lathe (XYZ Machine tools)

Anonymous

Prototrak SLX lathe (XYZ Machine tools)

Anonymous
Not applicable
I'm trying to get a program to work on my Prototrak SLX lathe.

Over a year ago somebody else on here was trying to do the exact same thing here: https://camforum.autodesk.com/index.php?topic=4934.0

I have made the same progress as they have, manually removing all of the Gcode which generates an error.  Specifically G18,  G50, G53 and G54.  Doing this enables the machine to open the program.

I can look at the tool path and it is fairly obvious that it isn't handling the arcs correctly (it appears the direction, CCW/CW of the arcs comes out the wrong way round).  The part will verify with errors around the operations involving arcs and the result is almost the correct part, without arcs (it appears to create chamfers instead).

It would be really great if I could use HSM Pro to run this lathe as I already have two mills which I control with this program (one of which is 20+ years old).  It would be a sad shame if my brand-spanking-new lathe could only be programmed manually!

Any suggestions on what I should do next? anyone willing to help?

0 Likes
Reply
3,009 Views
17 Replies
Replies (17)

HughesTooling
Consultant
Consultant
Which post are you using. Can you post a small profile and give use the code straight out of the post you're using and a modified version that runs. Have you tried swapping the G02s for G03s and vice versa to make sure that's what's needed.

Mark

Mark Hughes
Owner, Hughes Tooling
Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.

EESignature


0 Likes

Anonymous
Not applicable
Thanks for the suggestion.

I'm using the generic HAAS post processor (haas turning.cps).

The attached images show what's going on (as labelled)

turntest4.cam is the G-code with G18, G50, G53 and G54 removed and all G3's replaced with G2's.  It's still not right.

When I go to verify the part an error message around several events reads "An arc has been encountered that cannot be executed, look at the arc definition and edit the program"


0 Likes

HughesTooling
Consultant
Consultant
For testing just work with the finish profile, disable roughing and have just one finish pass. The problem with the arc could be down to ABS\incremental arc centres, do you know what you machine needs.

Mark

Mark Hughes
Owner, Hughes Tooling
Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.

EESignature


0 Likes

Anonymous
Not applicable
Ok yeah that makes sense I will try again tomorrow morning.

When programming the machine manually in the form of individual events you can use either Inc or Abs.  When a HSM program is loaded it undergoes a conversion into these events.  Normally, an arc will consist of an end point, a direction, and a radius (the start point is dictated by the end point of the previous operation).

When I looked at one of the arc events which threw up the error, the radius was always zero but the other data I assume is correct.  Therein lies the problem I believe.
0 Likes

Anonymous
Not applicable
OK, so, I've made progress.

Working off the Generic Fanuc post.

1. The G02's and G03's need swapping to make the radii the correct orientation.

2. G18, G50, G53, G54 need to be removed (Incidents where another G-code occupies the same line as any of these, only the 'offending' G-code need be removed, not any of the other coordinates).

3. Where a G02 code is generated in the format:

N10 G2 X"arc-end-position" Z"arc-end-position" R"radius value"

should instead be displayed in the following format:

N10 G2 X"arc-end-position" Z"arc-end-position" I"X-incremental offset from arc start point to arc center point" K"Z-incremental offset from arc start point to arc center point"

Does this make sense?

An example of this is as follows:

N25 G2 X15. Z-1.8 R0.8                        N25 G2 X15. Z-1.8 R0.8
N26 G1 Z-11.03                                  N26 G1 Z-11.03
N27 G2 X35. Z-21.8 R10.8  BECOMES:    N27 G2 X35. Z-21.8 I-1.6 K-10.77



0 Likes

Laurens-3DTechDraw
Mentor
Mentor
Ollienor wrote:

OK, so, I've made progress.

Working off the Generic Fanuc post.

1. The G02's and G03's need swapping to make the radii the correct orientation.

2. G18, G50, G53, G54 need to be removed (Incidents where another G-code occupies the same line as any of these, only the 'offending' G-code need be removed, not any of the other coordinates).

3. Where a G02 code is generated in the format:

N10 G2 X"arc-end-position" Z"arc-end-position" R"radius value"

should instead be displayed in the following format:

N10 G2 X"arc-end-position" Z"arc-end-position" I"X-incremental offset from arc start point to arc center point" K"Z-incremental offset from arc start point to arc center point"

Does this make sense?

An example of this is as follows:

N25 G2 X15. Z-1.8 R0.8                        N25 G2 X15. Z-1.8 R0.8
N26 G1 Z-11.03                                  N26 G1 Z-11.03
N27 G2 X35. Z-21.8 R10.8  BECOMES:    N27 G2 X35. Z-21.8 I-1.6 K-10.77


In the user defined properties set useRadius to false.
That will help for the I&K instead or R.

Laurens Wijnschenk
3DTechDraw

AutoDesk CAM user & Post editor.
René for Legend.


0 Likes

Anonymous
Not applicable
Fantastic, making good progress here thanks for the help so far.

I have modified the post processor to output the correct G codes for the radii and tool numbers, as well as removing all of the aforementioned codes it doesn't recognize.

Now, for the I and K values it is giving the absolute value for the arc centers, I need this to be incremental from the start of the arc (i.e. incremental to the previous values for X and Z in the lines above).

Any ideas how to do this?  I am so close to having a working post now.
0 Likes

Anonymous
Not applicable
Actually I'm wrong.

What it was actually doing was scaling the K value by 2.

I don't know why it was doing this but in all cases, the value generated for K was always twice what it should be.

I've simply halved it in the post processor and it appears to be doing the correct thing now.
0 Likes

Laurens-3DTechDraw
Mentor
Mentor
Ollienor wrote:

Fantastic, making good progress here thanks for the help so far.

I have modified the post processor to output the correct G codes for the radii and tool numbers, as well as removing all of the aforementioned codes it doesn't recognize.

Now, for the I and K values it is giving the absolute value for the arc centers, I need this to be incremental from the start of the arc (i.e. incremental to the previous values for X and Z in the lines above).

Any ideas how to do this?  I am so close to having a working post now.


If you modified the fanuc turning post the onCircular does this calculation for the I:

cx - start.x

Which means.
Absolute center point in X minus the start point in X.
Which gives the incremental value from start to centerpoint of the arc.

Laurens Wijnschenk
3DTechDraw

AutoDesk CAM user & Post editor.
René for Legend.


0 Likes

Anonymous
Not applicable
Thanks,

I saw that in the post.  I was just mistaken due to a coincidence in my coordinates making it seem as if it was using abs not inc, but actually what was happening was the z incremental value was twice what it should be.

I don't know why this was the case, I can't see any reason why the K value was twice what it should be but in true mechanical engineer fashion I fixed it with a bodge.

This post is tested for simple linear turning and radii and works.  I haven't looked at anything else e.g. thread cutting.

Thanks for all of your help, much appreciated.

This has proven to be a very useful forum for me!



0 Likes

HughesTooling
Consultant
Consultant
Ollienor wrote:

Thanks,

I saw that in the post.  I was just mistaken due to a coincidence in my coordinates making it seem as if it was using abs not inc, but actually what was happening was the z incremental value was twice what it should be.

I don't know why this was the case, I can't see any reason why the K value was twice what it should be but in true mechanical engineer fashion I fixed it with a bodge.





Could the problem be your machine uses radius programing and the post is for diameter, have you done any tests on the machine to see if you get the correct sizes. I just wonder if you are going to find the diameters come out twice as big.

Mark

Mark Hughes
Owner, Hughes Tooling
Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.

EESignature


0 Likes

Anonymous
Not applicable
I just gave it a try and actually the Z dimensions are all perfect.

The X however all machined about 1mm under size, which is really odd because for example, the G-code instructs to go to X15, but the machine puts the tool at 14.6, the material, after the cut, measures 13.9 and when winding the same tool to touch onto the surface, the readout displays 13.9.  Something very funny going on here!
0 Likes

HughesTooling
Consultant
Consultant
You've not got compensation on G41/42 anywhere.

Mark

One more thought, you are calling the correct tool and tool offset eg T0101 and not something like T0102.

Mark Hughes
Owner, Hughes Tooling
Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.

EESignature


0 Likes

Anonymous
Not applicable
I set the tools up in the tool table on the lathe controller itself, setting them to match the tools chosen in HSM.

When I remove the radius of the tools, setting them to zero, it machines on size.

I assume that the SLX controller is putting an offset in there 'on-the-fly'.

If I look at the events it generates for the G-code it says tool-offset: Center, I wish I knew how to make this import as the correct tool offset.

Bottom line is, I can make it work but it's not ideal since I'll probably be the only one programming this machine via HSM and everyone else will require the tool radii in the tool table.  I know what the problem is but as yet don't know how to fix it.
0 Likes

HughesTooling
Consultant
Consultant
I'm using Fusion so it might be a bit different but in the tool library you can set Tip Centre. And in the op you have options for compensation.


Mark

Mark Hughes
Owner, Hughes Tooling
Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.

EESignature


0 Likes

Laurens-3DTechDraw
Mentor
Mentor
Ollienor wrote:

I set the tools up in the tool table on the lathe controller itself, setting them to match the tools chosen in HSM.

When I remove the radius of the tools, setting them to zero, it machines on size.

I assume that the SLX controller is putting an offset in there 'on-the-fly'.

If I look at the events it generates for the G-code it says tool-offset: Center, I wish I knew how to make this import as the correct tool offset.

Bottom line is, I can make it work but it's not ideal since I'll probably be the only one programming this machine via HSM and everyone else will require the tool radii in the tool table.  I know what the problem is but as yet don't know how to fix it.


How is the tool set-up in Inventor?
I mean the compensation there.

I think you need tip tangent.

Laurens Wijnschenk
3DTechDraw

AutoDesk CAM user & Post editor.
René for Legend.


0 Likes

Anonymous
Not applicable
Thanks for the suggestion.

This option does exist in Inventor and was set to tool tangent, so what was happening was both the machine and HSM were compensating.  I've chosen to use the tip center option on the tool setup in HSM and leave the compensation to the machine itself, that way the tool table remains the same for everybody else who uses the machine and the way I do it doesn't effect anyone else.

I think I have all the little problems ironed out now, though you can be sure if I have any more I'll be back on here!

Thanks for the help guys!  Much appreciated.
0 Likes

Type a product name