Many won't let you do this. My dell for instance is one that won't, and it happens to be that it can't be done as the dedicated graphics has to port through the integrated to get out. But things seem to run ok, so I'm not worried at the moment. If I had known this, I wouldn't have chosen this model, but it is compact and good for the road, so I'm not complaining.

No head spinning required.... I haven't done much with the anything built in the last 30 years, but with Heidenhain, my experience is "If it can't be that simple, it just is." If I were to buy a 5ax machine today, I think HH would be very high on the list. My priority would be to favor the control options over many other things. But I guess at the end of the day it would depend on what that machine was needed for. All of the control builders have gotten pretty good over the last decade. It's mostly the machine tool builders making things difficult and holding back progress on standardization.

Upon further reading the post was really about both, so no need to disregard. Someday, I'd love to get my hands on three or four different machines all with different control makes, but similar kinematics and do some of these things and document methods on how to accomplish tasks like these with the simplest methods possible. We lack means of translation from platform to platform.

I'm not sure this is true on a mazak control. In my experience, G54.2 on a mazak is more functional that it is on a Fanuc, much closer to Fanuc G54.4.

I'm with Aaron. For me it came much easier by changing it. When I tried to explain this to a coworker he looked at me like I had a third eye. I guess it's just preference and or how we are wired. I own one. Haven't used it in years... I'm far too lazy to have both hands engaged in work activities. I find my left hand is usually engaged in pulling my hair out, bringing coffee to my face, or propping my head up against my armrest whilst watching YouTube.

Not sure why this didn't come up yet, it depends on the post! IIRC, the generic post has logic to shift the origin to the T/C planes for when they don't match the origin of the WCS. This can become useful when using G68.2 or other local coordinate system methods. I have only played with it, and have never really ever "used" this functionality, but it could be very useful when creating programs that have "local features", and possibly for situations where one might want to build subs.

Welp! Ummm sir Haas machines would not have a fanuc control. They have a Haas control! Close for most, but definitely not the same thing. ron, that would be fine drilling the outside of a cylinder. But I believe the application he is referring to is drilling a bolt circle axial to the cylinder. Think avoiding the center of a wheel hub while drilling from the front side.

You will probably have to do it with each hole as individual ops and add a contour move at high feed rate between each one. Otherwise you will have to create a macro that would do it for you. If you have multiaxis mc license, you might be able to use that to drive different behavior, but I doubt it will be as effective or straighforward. I am assuming this is on a fanuc control?

Might want to look into some sort of workshifts either g52, g54-g55, or heaven forbid going back to using G92's. Everything should be programmed in absolute. Plain, flipping a contour program from inc to abs, will be disastrous.

Ron, how much ram do you have on your machine there. That is showing 111,260! Are you really running 128GB of ram now?

Would happen to have it set to 4-axis in the toolpath dialog?

I bet he defined his machine in Inch.... Don't you have to do it in metric for collision detection to work properly?

No noticeable issue with bitlocker, other than if you power on and walk away it will shut your computer down after it times out. Makes you go crazy thinking you already turned it on and are having to do it again.

I miss spoke, it's not tooling per say, it's the workholding. Which happens to be tool holders most of the time... Hence why i misspoke. Believe me they aren't that far out of whack...

Way before my time, this decision was made.... I'm just helping this plant out, being that it is one of our own, I have to be careful what I propose... Hence why I am asking for some guidance.

Our programs currently use Cycle 7 Datum Shift, I wonder if the Vericut just doesn't respect things properly, and or if the lack of plane function or M128 would be the reason. They may, but I don't have access to any of the Hermle docs. Thanks for the advise so far. I will look into what things would look like if I were to use the PLANE functions to get the functionality we need.

I believe I understand how the PLANE functions work, but it is possible for me to shift the entire program using them. Also how or can you shift the coordinate system to a new local coordinate system? Such as you can with G68.2 on a Fanuc. I have Vericut, but I have no idea what functions our digital machines support or don't support. The machines are Hermle C600U and C30U. I don't think it is out of the realm of possibility that both types of machines could use identical programs as well.... I say that because currently our programs posted between them are only different by coordinate shifts, otherwise structure and syntax are 100% the same.

I'm not sure I am being clear with what I am looking to do. I want to eliminate a time sucking task our programmers have to do all the time due to tooling maintenance. They are constantly reposting jobs with a different tooling gage/line, which suffice to say is nothing more than a shift value in the post. The post has values associated with the machines rotary offsets, as well as the distance from the rotary center to the center of rotation and then spits out the program accordingly. I'd like to eliminate that activity of reposting jobs if the fixture length change is say less than .25". I have no problem redefining the method of which the parts programs are constructed using the post as they are output with macros, and looping for repeated features. I'd like for the operator to just edit a header line variable of the fixture length and the program would run, likely verified by probing and limits set in a sub or internal label call. Hence removing the need for the jobs to make two trips through the programming office unless they need a serious change.

Anyone know the details of doing Dynamic Work Offsets, or TCP/WSEC like behavior on a Heidenhain TNC530i control for mainly planar work? Also would be nice to program in part coordinates, instead of from rotary center. The books are clear as mud, and offer zero examples or explanation of such activity. I'm not interested in a post for this at this time, but may be in the future.

Another way to look at this is, that customization is healthy as long as it reduces the amount of work you need to do to get work out the door.

I might be able to help.... See pm's shortly. Might work. Otherwise, make a toolpath, cut it off and using the stl as stock and resave it...

Our company uses NX internally. But with what we do it makes sense. Lots of CAD/CAM automation, loads of it in fact. Externally, I and a select few others do things for our customers using Mastercam, NX, and Esprit, on an as needed basis. So far I have only help customers with Mastercam.... One of the other guys has been doing projects in NX for a few customers that have it. I used Featurecam about ten years ago, and wish never to touch that god awful software again. As mentioned, you have zero control, none, zip, zilch.

Probably not like you are thinking... Speaking of which, can you describe with a little more detail what you are trying to do on the machine. Maybe that would be easier for us to help come up with a solution.

I need to get a hold of our CAD/CAM coordinator and get the installer and license updates to check out V9.... Haven't had to use it yet for a customer, but would anyone say that it's got some performance upgrades above V8.22? Worth pushing to get updated anyway?

Careful saying this..... Soon as you speak in absolutes lightning will strike and it won't be true anymore... Many times that you wouldn't actually do this. But as default behavior on a table/table machine, sure, no hurt as long as you have the option to suppress it or use another method on the fly via misc ints/reals. No need to get the tool out of there and then get back in if you don't need to.