Rob and Ron, just so I'm clear, are you using the Dynamic 2 option (G54.2) on the Matrix control, or the Dynamic 1?

Thank you Ron! I suspected as much. John

Rob, you mentioned that the XY still neeeds to be pretty close to the C/L. Why do you say this? This is something that I have suspected to be the case, but it definetly NOT what we are doing right now. John

Thanks for your thoughts. I hear what you are saying, but I think we may not be on the same wavelength here. I have probably complicated the issue. I am new to Mazak so I don't know how your integrex compares with the Vari-axis' dynamic offsetting. But I can say that one does not need multiple work offsets with our dynamic offsetting. The idea is that the all the operator has to do is set the XYZ at a given origin point and the machine calculates the distance to trunion/table C/L and it runs as if it WERE programmed from C/L. It does a very good job of this. However we are currently experiencing some accuracy problems that may be due to that huge machine settling a bit. Mazak is supposed to be coming in soon to re-check it. Because of this, we have been using a kind of hybrid program that includes both dynamic and regular work offsetting (for critical feature fine tuning). It is here where the post is creating some issues since we are not programmed from table C/L's. But when we are using ONLY dynamic offsetting we only have one work offset just as if we were programming from C/L. Sorry for the confusion. John

Yes I have always programmed from C/L myself. But I am the new guy here at this company and the decision was already made that dynamic offsetting would be more operator friendly in that you do not have to program from C/L. It does work and I don't really see that it is limiting the capabilities of the machine if the dynamic is working properly. We are still working things out since the machine is pretty new.

Many times I wish it had that feature. The closest thing is to activate the EA Manager at the bottom of the attributes box. This will allow you to define different attributes to always be on the same level and same color. Not exactly what you are asking for, but it can be useful. John

sorry, I replied to the wrong topic. I am new at this. Here is what i wrote: Thanks. I assume you ar talking about Bruce from Mouldcam. I saw in a search that he has a Veri-Axis 630. We have a 730. I have the post pretty much dialed in as far as Dynamic comp on and off. I have even included the offset variables in them to eliminate the scary z moves in on and off. I just don't know how to force the post to make the c-axis move after an A-axis move. It wants to stay at the last C-axis move and calculate the XY output at that location. That is fine if you are programming from c/l of rotation. But we are not and in this case dynamic is not on. John

see Dynamic Comp thread

Thanks. I assume you ar talking about Bruce from Mouldcam. I saw in a search that he has a Veri-Axis 630. We have a 730. I have the post pretty much dialed in as far as Dynamic comp on and off. I have even included the offset variables in them to eliminate the scary z moves in on and off. I just don't know how to force the post to make the c-axis move after an A-axis move. It wants to stay at the last C-axis move and calculate the XY output at that location. That is fine if you are programming from c/l of rotation. But we are not and in this case dynamic is not on. John

Thanks for the welcome. Ours is a vari-axis and uses dynamic offsetting. Does your integrex use that?

We currently are not programming from c/l of axis rotation because we are trying Mazak's dynamic offsetting feature on our new 5-axis. This feature is not without problems and we are currently using kind of a hybrid system of programming, i.e.: some operations in dynamic while others using standard work offsets. One problem I cannot seem to overcome is this: at a null toolchange I need to force the primary© axis to the toolplane view rather than remaining at the last C-axis position and having the .psb file calculate the new XY position. I have done this at actual toolchanges by using the protretinc postblock command in pretract, but this doesn't address the issue at null toolchanges. I might be able to figure this out if I had a list of pre-defined 5-axis post variables and a description of their functions. Any thoughts? John