What's new
What's new

Macro Programming Fundamentals

With regards to turning, using TNR Comp by the Control can be troublesome when small segment moves are concerned in any concave feature of a profile and it wouldn't be that much more of a task for the author to include the calculations for the Tool Nose Radius of the tool and a Macro Variable for the TNR to be edited by the user, or to read an Offset Registry where the user can enter the TNR value. It would also be good practice by the author to include error trapping to ensure a TNR was not entered above a maximum value.

I practically never use TNR Comp at the control of a lathe, as its not all that difficult to calculate the true position of the tool based on the TNR used and size adjustment of the diameter of a turned part is generally irrespective of the TNR of the Tool. With a Mill Control, Tool Radius Compensation is the only way to size a feature that is machined using some type of End Mill, either by compensation by the control, or by including the compensation for the Cutter Radius in the Code. The same issues can exist when the profile generated by a User Macro program is made up of small moves and my comment relating to this issue with a lathe apply also with the Mill program.

Regards,
'
Bill
Thanks for your answer.
 
Does anyone have a COMPLETE list of Macro/System Variables for Haas Mills (NGC)? Have seen quite a few used on their YouTube that are not in the Programming Manual and looking to see what else there is available.
 
Have you downloaded the latest mill manual? They've added some more in there, such as the #50,000+ vars
Tool Type, Material, Offset Point, Estimated RPM, etc. looks like all tool data.

Is there something particular you were interested in?
 
Have you downloaded the latest mill manual? They've added some more in there, such as the #50,000+ vars
Tool Type, Material, Offset Point, Estimated RPM, etc. looks like all tool data.

Is there something particular you were interested in?

Specifically looking to see if there is a way to actuate the thru spindle air purge that blasts air thru the spindle during a tool change. I know it’s connected to the TRP though so may only run during the tool release mechanically, without a switch/solenoid.
 
Specifically looking to see if there is a way to actuate the thru spindle air purge that blasts air thru the spindle during a tool change. I know it’s connected to the TRP though so may only run during the tool release mechanically, without a switch/solenoid.
You can turn relays on and off with M59P# on M69P#
Find the output number. Search purge in diagnostics, i/o

purge.jpg

Looks like 38.
M59P38 turns it on
M69P38 turns it off
Works on mine in MDI.
Didn't attempt to do anything else while on, however. I don't know the in's and out's of the whole system or how the 'thru air' is designed to work.. so attempt at your own risk.
 
I took this photo with a potato, and searched AIR instead of PURGE. I’ll monitor these during tool change/etc and see what flips. Seems like this air purge is always on, and turns off with E-Stop / Idle time. Will investigate a bit more but man, this is a huge help thank you!
 

Attachments

  • IMG_5158.jpeg
    IMG_5158.jpeg
    6 MB · Views: 10
Last edited:
This question applies to a lot of things but for example, when you use spiral interpolation to mill a conical bore for example, using G02.1, no matter the degree of depth per rotation, the movement will be smooth and not sluggish.
However when using a macro for doing the same thing, using small values per linear movement, the movement will be sluggish and slow if low enough.

I'm wondering, what is the difference between a built in feature in the control such as this, and a macro? Why is the calculation faster? Does the control essentially calculate or look ahead the entire shape before it executes it whereas a macro does continous calculations while running the program?
 
This question applies to a lot of things but for example, when you use spiral interpolation to mill a conical bore for example, using G02.1, no matter the degree of depth per rotation, the movement will be smooth and not sluggish.
However when using a macro for doing the same thing, using small values per linear movement, the movement will be sluggish and slow if low enough.

I'm wondering, what is the difference between a built in feature in the control such as this, and a macro? Why is the calculation faster? Does the control essentially calculate or look ahead the entire shape before it executes it whereas a macro does continous calculations while running the program?
Machine Controls don't use Macros to generate the tool path of functions such as Circular, Linear, or Spiral interpolation. A trajectory is calculated and the Servo Motors controlled to closely follow that trajectory.

When using a User Macro program to mimic these functions, small Linear Moves are calculated and each Linear move has a Start and Finish and therefore, Acceleration and Deceleration at the start and end respectively. If the length of the Linear Move is small enough, there is insufficient length for the axes to accelerate to the specified Feed rate before having to Decelerate. The Look Ahead and AI features can only do so much and if there is considerable change in direction between each Linear Move, the overall Feed Rate will suffer.

Regards,

Bill.
 
Machine Controls don't use Macros to generate the tool path of functions such as Circular, Linear, or Spiral interpolation. A trajectory is calculated and the Servo Motors controlled to closely follow that trajectory.

When using a User Macro program to mimic these functions, small Linear Moves are calculated and each Linear move has a Start and Finish and therefore, Acceleration and Deceleration at the start and end respectively. If the length of the Linear Move is small enough, there is insufficient length for the axes to accelerate to the specified Feed rate before having to Decelerate. The Look Ahead and AI features can only do so much and if there is considerable change in direction between each Linear Move, the overall Feed Rate will suffer.

Regards,

Bill.
Hello Bill,

But how is the tool path generated in the control then? How does it work and why can't we just mimic these functions with macros? Essentially I don't know how it fundamentally works.

And, with a spiral function in particular, the radius would be changing constantly, and so the machine then does this move with spiral arcs essentially and not linear moves otherwise it would be slow. And so if the machine is capable of such arcs we should be able to program it with a macro. Maybe it would be possible with more advanced calculations.
 
Hello Bill,

But how is the tool path generated in the control then? How does it work and why can't we just mimic these functions with macros? Essentially I don't know how it fundamentally works.

And, with a spiral function in particular, the radius would be changing constantly, and so the machine then does this move with spiral arcs essentially and not linear moves otherwise it would be slow. And so if the machine is capable of such arcs we should be able to program it with a macro. Maybe it would be possible with more advanced calculations.
Motion Control Systems have a Motion Control Trajectory Generator as part of the system. In your example, you're wanting to mimic a control feature that the control is not optioned with. The approach of most using User Macro to mimic, say a helical path, or conical path would be to do so using short linear segments. The smaller these segments, the smoother and closer to the required shape will be the result. However, for each linear move, there will be a trajectory generated with a start and end and the associated Acceleration/ Deceleration incurred with each move. Smarts in the control can smooth this out to an extent, but there are no free lunches. The Trajectory Generator can't be accessed by the User Macro application. All that can be done with it is to calculate a point to go to, then the Control Makes it happen via the Motion Control System, which includes the Trajectory Generator.

In a test I did some years ago, with AI turned off I programmed:
1. a 1000mm move at 1000mm/minute Feed Rate. As expected, it took one minute to complete.
2. a 1000mm move at 1000mm/minute Feed Rate made up of 10,000 x 0.1mm linear, incremental moves. As expected, this took many minutes to complete the same actual distance.

With AI turned on, the above two tests were repeated and again as I expected, both tests took one minute to complete. In addition to the above two tests carried out with AI turned on, I carried out the following test.

3. a 1000mm move at 1000mm/minute Feed Rate made up of 10,000 x 0.1mm linear, incremental moves, dithering alternatively in the plus and minus direction. As expected, this took many minutes to complete the same actual distance. The reason why is that was a maximum change in direction for each move and therefore, there was no opportunity for the Acceleration/Deceleration to be optimized for each move. Like the piston in an internal combustion engine, the axis must come to a complete stop when the direction is changed.

If the control you're using to run the Macro Program on has AI or other profound Look Ahead function, it can be used in conjunction with the moves calculated by the Macro Program to enhance the overall motion performance. Mostly the next move is calculated Just In Time and therefore, there will also be overhead caused by the calculations being carried out by the Macro Program.

Regards,

Bill
 
Motion Control Systems have a Motion Control Trajectory Generator as part of the system. In your example, you're wanting to mimic a control feature that the control is not optioned with. The approach of most using User Macro to mimic, say a helical path, or conical path would be to do so using short linear segments. The smaller these segments, the smoother and closer to the required shape will be the result. However, for each linear move, there will be a trajectory generated with a start and end and the associated Acceleration/ Deceleration incurred with each move. Smarts in the control can smooth this out to an extent, but there are no free lunches. The Trajectory Generator can't be accessed by the User Macro application. All that can be done with it is to calculate a point to go to, then the Control Makes it happen via the Motion Control System, which includes the Trajectory Generator.

In a test I did some years ago, with AI turned off I programmed:
1. a 1000mm move at 1000mm/minute Feed Rate. As expected, it took one minute to complete.
2. a 1000mm move at 1000mm/minute Feed Rate made up of 10,000 x 0.1mm linear, incremental moves. As expected, this took many minutes to complete the same actual distance.

With AI turned on, the above two tests were repeated and again as I expected, both tests took one minute to complete. In addition to the above two tests carried out with AI turned on, I carried out the following test.

3. a 1000mm move at 1000mm/minute Feed Rate made up of 10,000 x 0.1mm linear, incremental moves, dithering alternatively in the plus and minus direction. As expected, this took many minutes to complete the same actual distance. The reason why is that was a maximum change in direction for each move and therefore, there was no opportunity for the Acceleration/Deceleration to be optimized for each move. Like the piston in an internal combustion engine, the axis must come to a complete stop when the direction is changed.

If the control you're using to run the Macro Program on has AI or other profound Look Ahead function, it can be used in conjunction with the moves calculated by the Macro Program to enhance the overall motion performance. Mostly the next move is calculated Just In Time andi expected therefore, there will also be overhead caused by the calculations being carried out by the Macro Program.

Regards,

Bill
I also experienced this when path segments were too small, though never conducted a detailed experiment like you did. You have given some good information. Thank you.
 
Motion Control Systems have a Motion Control Trajectory Generator as part of the system. In your example, you're wanting to mimic a control feature that the control is not optioned with. The approach of most using User Macro to mimic, say a helical path, or conical path would be to do so using short linear segments. The smaller these segments, the smoother and closer to the required shape will be the result. However, for each linear move, there will be a trajectory generated with a start and end and the associated Acceleration/ Deceleration incurred with each move. Smarts in the control can smooth this out to an extent, but there are no free lunches. The Trajectory Generator can't be accessed by the User Macro application. All that can be done with it is to calculate a point to go to, then the Control Makes it happen via the Motion Control System, which includes the Trajectory Generator.

In a test I did some years ago, with AI turned off I programmed:
1. a 1000mm move at 1000mm/minute Feed Rate. As expected, it took one minute to complete.
2. a 1000mm move at 1000mm/minute Feed Rate made up of 10,000 x 0.1mm linear, incremental moves. As expected, this took many minutes to complete the same actual distance.

With AI turned on, the above two tests were repeated and again as I expected, both tests took one minute to complete. In addition to the above two tests carried out with AI turned on, I carried out the following test.

3. a 1000mm move at 1000mm/minute Feed Rate made up of 10,000 x 0.1mm linear, incremental moves, dithering alternatively in the plus and minus direction. As expected, this took many minutes to complete the same actual distance. The reason why is that was a maximum change in direction for each move and therefore, there was no opportunity for the Acceleration/Deceleration to be optimized for each move. Like the piston in an internal combustion engine, the axis must come to a complete stop when the direction is changed.

If the control you're using to run the Macro Program on has AI or other profound Look Ahead function, it can be used in conjunction with the moves calculated by the Macro Program to enhance the overall motion performance. Mostly the next move is calculated Just In Time and therefore, there will also be overhead caused by the calculations being carried out by the Macro Program.

Regards,

Bill
Thank you for the explanation!
 
Can we achieve eccentric shaft turning on 2 axis cnc lathe through Macro programming. I am just new to it and having my company OM-TECH in which I am manufacturing various types of shaft and bushes.
 
Can we achieve eccentric shaft turning on 2 axis cnc lathe through Macro programming. I am just new to it and having my company OM-TECH in which I am manufacturing various types of shaft and bushes.
Yes to some extent if the eccentric diameter doesn't have to be very accurate in shape. Also polygons are possible (inaccurate shapes as well). The key to those is in G32 threading cycle. I have done the polygon turning macro and it works on my 2-axis Mori Seiki from 1987.
 
I came here to ask if anyone knows if it's illegal to make a chip breaking threading macro that mocks Sandvik's optithreading to some extent but a simpler one? (Either just for personal use or sharing online for free?) I could practice some more macro programming with that. Would be Using G32 for that as well.
 
Also since it's stated that the standard canned cycles are just built in macros. I have a hard time figuring out how to achieve the functionality of a G71 rough turning cycle for example. If someone knows how that works it would be enlightening. I have the type II G71 on my machine of course so it's not about that
 








 
Back
Top