Problem with post for ex-trak, really stuck!

[cygnus x-1]

Hi Cygnus,
I just went hunting for the conversational post that you mentioned and I'm not sure which one it is. Can you give me the name of it when you get back from your holiday? Thanks!

It's called "eztrak conversional.cps". I haven't tested it but there are a few things I've noticed so far.

1) Canned cycles are not implemented yet; only lines and arcs. This is actually about all you would need for the 2 axis version, except for the drill cycle command. With a manual Z the only thing the drill cycle does is move to position and wait for the operator to hit start when finished. With 3 axis I imagine there could be more drill cycles but I really don't know.

2) The default file extension for the NC file is ".nc" whereas the control is looking for ".pgm". I think it will open any filename but I don't know if it's smart enough to figure out what type the program is. Will need to test this.

3) The conversational commands appear to allow larger than 180 degree arcs if the 'centerpoint' option is specified instead of 'radius'. One thing that occurs to me though is that internally the control may break arcs at the quadrants when using the conversational language. I remember that the display shows gcode commands even when the conversational language is used, so it's doing some sort of translation. If it is breaking arcs at the quadrants then that may explain why the gcode post isn't working if it doesn't break the arcs. Again, will need to do some testing.


Otherwise the code generated by the conversational post looks correct. Hopefully I should be able to try some things out when I get back on Monday.


C|

[mr_servo]

I have an EZ Trak post working most of the time, but I use the R word instead of I and J for circular moves.

It has one nasty habit. If the start point or end point are along the X or Y axis, HSMWorks will not explicitly repeat the coordinate after the G02/G03.

Example:

N214G1X-0.1397Y-7.5178
N216G2Y-7.2385R0.1975

will generate an error, while

N214G1X-0.1397Y-7.5178
N216G2X-0.1397Y-7.2385R0.1975

is fine.

I don't want to manually edit any more code. Any ideas on how to force the output of X and Y coordinates after the G2/G3?

Edit:

After a little more digging, xOutput.reset() and yOutput.reset() will cause those coordinates to be explicitly restated. I'm happy to share my ez trak post after a little testing. I wouldn't want to crash somebody's machine.

In particular I found it best to disable the canned drill cycles. The sign conventions are a little funky on the EZ trak, and they might just cause a drill bit to end up in the table.

[TheCamMan]

instead of listing each axis by its self you can also use

forceXYZ();


Nice work mr_servo

[mr_servo]

I tested my post today and found an issue with arcs in the YZ plane.

Here is some test code to test arcs in all three major planes:

Code:
N100G90
N102T1M26
N104S2000
N106G54
N108G0X1.Y-0.5625
N110Z1.
N112G19G3Y0.4375Z0.R1.F20.
N114G17G3X0.Y1.4375R1.
N116X-1.4375Y0.R1.4375F40.
N118X0.Y-1.4375R1.4375
N120X1.4375Y0.R1.4375
N122X0.Y1.4375R1.4375
N124X-1.Y0.4375R1.
N126G19G2Y-0.5625Z1.R1.
N128G17
N130G0X-0.5625Y-1.
N132Z1.
N134G18G2X0.4375Z0.R1.F20.
N136G17G3X1.4375Y0.R1.
N138X0.Y1.4375R1.4375F40.
N140X-1.4375Y0.R1.4375
N142X0.Y-1.4375R1.4375
N144X1.4375Y0.R1.4375
N146X0.4375Y1.R1.
N148G18G3X-0.5625Z1.R1.
N150G17
N152M26
N154M30

Line 112 and 126 end up cutting a 270 degree arc (starting and ending on the correct points though) instead of a 90 degree arc. The simulated output on the EZ Trak screen is correct, however. Changing the sign of R has no effect. The arcs in the XY and ZX planes work fine.

I thought I had this post thing figured out, but this one has me stuck. Ideas? Are there any other conventions besides the sign of R for specifying the short arc rather than the long arc? Anybody have a G code manual for EZ Trak? My manual only shows the conversational programming.

Also, post is attached.

[TheCamMan]

One thought comes to mind. it could be that your YZ plane normal's could be backwards. just as a test try editing the program and swap the G2 and G3. if that works the you can do a if plane = in the post. if you need a hand with the syntax let me know.

[cygnus x-1]

I tested my post today and found an issue with arcs in the YZ plane.

Here is some test code to test arcs in all three major planes:

Code:
N100G90
N102T1M26
N104S2000
N106G54
N108G0X1.Y-0.5625
N110Z1.
N112G19G3Y0.4375Z0.R1.F20.
N114G17G3X0.Y1.4375R1.
N116X-1.4375Y0.R1.4375F40.
N118X0.Y-1.4375R1.4375
N120X1.4375Y0.R1.4375
N122X0.Y1.4375R1.4375
N124X-1.Y0.4375R1.
N126G19G2Y-0.5625Z1.R1.
N128G17
N130G0X-0.5625Y-1.
N132Z1.
N134G18G2X0.4375Z0.R1.F20.
N136G17G3X1.4375Y0.R1.
N138X0.Y1.4375R1.4375F40.
N140X-1.4375Y0.R1.4375
N142X0.Y-1.4375R1.4375
N144X1.4375Y0.R1.4375
N146X0.4375Y1.R1.
N148G18G3X-0.5625Z1.R1.
N150G17
N152M26
N154M30

Line 112 and 126 end up cutting a 270 degree arc (starting and ending on the correct points though) instead of a 90 degree arc. The simulated output on the EZ Trak screen is correct, however. Changing the sign of R has no effect. The arcs in the XY and ZX planes work fine.

I thought I had this post thing figured out, but this one has me stuck. Ideas? Are there any other conventions besides the sign of R for specifying the short arc rather than the long arc? Anybody have a G code manual for EZ Trak? My manual only shows the conversational programming.

Also, post is attached.

I tried the above code on my 2-axis, and didn't get very good results. For one thing G54 is not supported at all and it errors out. M26 sends the table all the way to the ends of travel. Line 112 made it do a really huge radius arc in the XY plane and I stopped it right before it hit the limits. At that point I gave up and decided I should probably just go with the conversational post for now. This control doesn't seem to like g-code very much, and with only X and Y axes there isn't much value in all the extra stuff that g-code supports. The conversational post has some issues too but they appear to be pretty minor so far.

I'll be watching for any progress though.

C|

[mr_servo]

On a 3 axis EZ Trak, M26 is go to clearance point. That clearance point is settable, and I use it for tool changes. It might be different on a 2 axis, or your clearance point may just be set at the end of the travel.

[cygnus x-1]

On a 3 axis EZ Trak, M26 is go to clearance point. That clearance point is settable, and I use it for tool changes. It might be different on a 2 axis, or your clearance point may just be set at the end of the travel.

I figured it was some kind of homing command but I have no g-code reference for the 'trak. Makes it much harder.

C|

[mr_servo]

For the life of me, I could not get the EZ Trak to cut an arc properly using the radius word in the YZ plane. I gave up and went back to arc centers.

Here is my modified post, believed to be working. Please test with caution. It uses I,J,K addressing for arcs. It appears the EZ Trak wants absolute arc centers for I, J, and K.

The EZ Trak supports helical interpolation, by the way. It's got more brains than I thought.

For the 2 axis folks, you might try commenting out line 472, which will remove the workshift offset.

[druga]

Hello!
I have a postprocessor for Haidenhein 530i CNC machine
Please if someone knows how to optimize post-processor axes for change and as simple can then modify the + and -

"A and C or B year or year head table"


Thanks

[druga]

This is my post-processor