Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations MintJulep on being selected by the Eng-Tips community for having the most helpful posts in the forums last week. Way to Go!
Postprocessor G68 command 1
- Thread starter Bingos
- Start date
- Thread starter
- #3
The ugpost_base.tcl which is automatically sourced contains matrix operations to get some of the maths done. Within the postprocessor there is procedures called CONVERT_POINT and CONVERT_BACK.
I use my own code to put rotations around a vector in a transformation matrix. That works too.
I use my own code to put rotations around a vector in a transformation matrix. That works too.
- Thread starter
- #5
Thank you for the information.but even can we use the 3d cordinate rotation for the output of G68.is it right method ?
I checked with the convert_back and onvert_point method looks bit complex codeing.
Can you please explain this how to use this.
Thanks in advance
I checked with the convert_back and onvert_point method looks bit complex codeing.
Can you please explain this how to use this.
Thanks in advance
I put an example on my website showing the current output when using standard configuration then fun then download then mazakG68. I used mazak because that is what I am currently working on I suppose you are on fanuc.
I had a go at the PB_CMD_set_csys procedure. It looks like that requires an update. Only if I put type to fanuc then I am able to get output in one occasion. The vector sample is also calling the procedure but bails out in the first couple of sentences. The first bit is to disable G68 I think by the looks of it.
The convert_point and convert_back will not be very useful. You will only need to transform the coordinates in the b-axis. The arcs are converted in linear moves if you opt for vector programming when using the same postprocessor configuration.
In order to get the desired output for vector programming. The PB_CMD_set_csys procedure should be modified in such a way that it does not bail out in the first couple of lines. Then you will need to put a transformation in place in PB_CMD_before_motion that will only act if G68 is active.
The transformation is a simple one axis rotation.
I had a go at the PB_CMD_set_csys procedure. It looks like that requires an update. Only if I put type to fanuc then I am able to get output in one occasion. The vector sample is also calling the procedure but bails out in the first couple of sentences. The first bit is to disable G68 I think by the looks of it.
The convert_point and convert_back will not be very useful. You will only need to transform the coordinates in the b-axis. The arcs are converted in linear moves if you opt for vector programming when using the same postprocessor configuration.
In order to get the desired output for vector programming. The PB_CMD_set_csys procedure should be modified in such a way that it does not bail out in the first couple of lines. Then you will need to put a transformation in place in PB_CMD_before_motion that will only act if G68 is active.
The transformation is a simple one axis rotation.
-
1
- #7
Could it be bailing because of your MCS type? You need to set up a 'Main' MCS, and then a 'Local' MCS with special output set to 'CSYS Rotation' for it to work right. It works, but its a bit tedious to set all those different coordinate systems for each rotated angle. I have a post that handles it automatically if you'd like to use it. I tried to go a step further and actually rotate the mom_csys_matrix, but couldn't get it to reload. In short, the custom command UG provides works in some cases. Just rename it, and put it in the initial move and first move events.
-Derek
-Derek
The mcs type causes it to bail out.
You are right putting the procedure in initial move and first move will make it more useful. Does your pp also solve the issue of circular motions being outputted as linear motions?
There has been a discussion on the subject on the ugs news group but I could not find the answer.
You are right putting the procedure in initial move and first move will make it more useful. Does your pp also solve the issue of circular motions being outputted as linear motions?
There has been a discussion on the subject on the ugs news group but I could not find the answer.
Yes it does..........This is the secret. You need to lie to the post builder and tell it the machine is a table-table machine. That way everything is always in a principle plane. Just make sure that you have the G68 activated for every new B axis rotation. What machine are you making a post for? Ours is a Mazak Integrex e1850V. This was one of the more challenging posts I've made. I gave up long ago on the Local MCS to output the G68 blocks. We just have too many different angles on our parts to have a coordinate system just for one operation. It gets messy when the part changes and you have to check all 30 of your MCS's to make sure they are oriented properly. We've been running this post now for about 2 months without a major hitch so far.
-Derek
-Derek
- Thread starter
- #11
The only enchancement I know of for G68 is in the IS&V. I had reported a problem with how the tool tip gets transformed and rotated. Its fixed now. Other than that, you'll have to work with what UG provides you, or write your own tcl code to handle G68. What excatly is your problem?
-Derek
-Derek
- Thread starter
- #13
Hi Derek
Thanks for the information
I tried as you sujjested earlier to change the machine to table/table, but I did get the result as I need.
This is how I am expecting the code to look after post.
M05
T1008
G361 B-45 D0 (Tool change and Axis rotated by -45 degree)
M302
M45
G28 U0 V0 W0
G97 S5000 M13
G00 C00
G68.1 X8.0 Y0.0 Z-1.0 I0.0 J1.0 K0.0 R45 (Co-ordinate system rotated by 45 degree)
G43 H5 (No B in G68.1)
G00 X0.0 Y0.0 (Make the temp rotated Co-ordinate system as Zero)
Z0.1
G83 Z-1.0 Q2500 R0.0 F0.020
C180
G80
G00Z10
G49
G69.1
G28 U0V0W0
Thanks for the information
I tried as you sujjested earlier to change the machine to table/table, but I did get the result as I need.
This is how I am expecting the code to look after post.
M05
T1008
G361 B-45 D0 (Tool change and Axis rotated by -45 degree)
M302
M45
G28 U0 V0 W0
G97 S5000 M13
G00 C00
G68.1 X8.0 Y0.0 Z-1.0 I0.0 J1.0 K0.0 R45 (Co-ordinate system rotated by 45 degree)
G43 H5 (No B in G68.1)
G00 X0.0 Y0.0 (Make the temp rotated Co-ordinate system as Zero)
Z0.1
G83 Z-1.0 Q2500 R0.0 F0.020
C180
G80
G00Z10
G49
G69.1
G28 U0V0W0
well........you have two choices. Either import the custom command UG provided to handle coordinate system rotation, or, do like I did and lie to the machine and tell it your machine is a table table (to get output in a principle plane), and add G68 blocks, with tcl code, everytime there is a different B val0e. email me at Derek.Karpinski@sfketema.com for more information, or if you want to send me your post, I can take a look at it to modify it to suit your needs.
-Derek
-Derek
- Thread starter
- #15
- Thread starter
- #17
hi guys,
you find each other very well..i fix a Mazak E800-II post.
Our vendor made it, but it has som bugs.
Since i have no pui file, i don't know how it made up.
But it doesn'n use G68..
there were a sipmle problem, in a simple planar operation, where the coords range from x350 to x-350, we hit the travel limits, at X-80. Did you meet this problem?
----
kukelyk
you find each other very well..i fix a Mazak E800-II post.
Our vendor made it, but it has som bugs.
Since i have no pui file, i don't know how it made up.
But it doesn'n use G68..
there were a sipmle problem, in a simple planar operation, where the coords range from x350 to x-350, we hit the travel limits, at X-80. Did you meet this problem?
----
kukelyk
- Status
Similar threads
- Question