What's new
What's new

Macro Programming Fundamentals

Good morning all. It's cool to see this thread still up and going since a year or so ago when I last checked this forum.

I am starting to get into challenging macros (for me at least) and looking to set up a system of organization, standardization, and program structures.


Might I ask about your usage of local variables?

I know about passing arguments from main to macro and their utility for intermediate calculations.
Am I losing functionality of locals if I consider them "throw away" and only for passing initial arguments from main to macro.
I heard they are volatile and need to be thoroughly understood before using them. I acutely understand the levels of memory and how that updates locals.

Tony in the beginning of this awesome thread said he doesn't use them at all. Do more of you all share that sentiment?

I wish I could have asked better questions but I don't even really know what to ask.



As of now, basically, I only intend to use them as 'user input variables'. They will be passed from main to macro, then reassigned as commons. From there, the commons will travel to wherever the rabbit hole leads. Then during and after calculations/operations/rabbit holes, the commons will be used to set globals, which I envision myself using for the most pertinent information. Dunno.. does that sound dumb, inefficient? I have both Sinha and Smid Macro books but I just dont see the big picture application of local variables and probably much much more.

If you know something specific I need to read/study, I will.
Sincere thanks. SML
 
Might I ask about your usage of local variables?

I know about passing arguments from main to macro and their utility for intermediate calculations.
Am I losing functionality of locals if I consider them "throw away" and only for passing initial arguments from main to macro.
I heard they are volatile and need to be thoroughly understood before using them. I acutely understand the levels of memory and how that updates locals.

Tony in the beginning of this awesome thread said he doesn't use them at all. Do more of you all share that sentiment?

I wish I could have asked better questions but I don't even really know what to ask.

As of now, basically, I only intend to use them as 'user input variables'. They will be passed from main to macro, then reassigned as commons. From there, the commons will travel to wherever the rabbit hole leads. Then during and after calculations/operations/rabbit holes, the commons will be used to set globals, which I envision myself using for the most pertinent information. Dunno.. does that sound dumb, inefficient? I have both Sinha and Smid Macro books but I just dont see the big picture application of local variables and probably much much more.
Hello SML,
Its poor form to use Global (Common) Scoped variables when only Local variables are required. Only 500 series and above Common Variables are non-volatile, so you have the same issue with 100 series Common Variables with regards them being volatile. You need to be sure when using 500 series, non-volatile variables, that they're not being used in other Macro Programs. If you change the value in one program, it changes the value in all other Macro programs using the same Macro, and the value sticks.

The only valid reason to be allocating the value passed to a Local Variable in a Macro, to a Common Variable, is if its an advantage for other programs to use the variable without it being passed.

Regards,

Bill
 
Hello Bill,

Thank you for the insight. It is appreciated.

The reason you mentioned regarding local variable to common variable reassignment is what I was hoping would in fact work and make organizational sense. So that's good hear. thx

As far as the #100's common and #500+ common are concerned: It seems, after reading your response, that my hope of usage might be too ambitious or even too error prone.

I am trying to find a safe and effective solution to have the permanent common variables take on a standardized meaning such that, ie, #500=rough stock diameter, #501= current calculated SFM, #509= calculated IPT. Those are just examples. (I think more likely i would assign a #100 level variable to SFM)

Should I even being trying to attach a repeatable meaning to the variables or does every macro have to be structured to be totally independent from one another?

Last question:

If every program I write uses only variables I assign and those variables all branch out based on unique 'user input' (local variables), is there a danger?

In other words, even if 5 macros share #509, only one macro is running at a time and although it updates #509 in the other macros stored in control, the other main programs will, when called, i naively hope, redefine #509 using the relevant program's calculations and relevant user input??
 
I would not use the common (#500 ranges) variables as you have described. Yes, if you always define them for each program you write, they will work and not be a danger. This will work on your current machine probably.

However, since you are thinking about a bigger picture you need to consider future machines maybe. If you get a machine with probing or tool setting functions those often use the some of the #500 range common variables for storing probe calibration values, tool setter location, and some of the #100 range common variables for intermediate computation results, etc. Now your personal "standardized" macros using common variables could conflict with the storage of values used by those automation features.
 
Vancbiker,

That's a great point. That's even more foresight for future applications than I had yet to think about.
Hmm...........

Alright VanC, what about this.....: Starting with standardized variable meanings as a way to help facilitate more intuitive programming. Then, if programs are required outside my current conditions, simply mass replace the now unavailable variables with unoccupied variables per unique situation??
 
Without knowing your bigger picture, I don't know why you are considering using common variables rather than local.

#1= rough stock diameter, #2= current calculated SFM, #3= calculated IPT, works just as well as #500=rough stock diameter, #501= current calculated SFM, #509= calculated IPT unless multiple macro programs need those variable values and they need to persist through a reset or power off.
 
Yeah, exactly. I do plan on transferring information to different 'sub-macros' within the main macro and need shared variable capabilities.
I personally haven't thought of a reason why I would need them to persist after power up as the programs will (well I hope) be all inclusive and recalculate themselves.
 
Yeah, exactly. I do plan on transferring information to different 'sub-macros' within the main macro and need shared variable capabilities.
I personally haven't thought of a reason why I would need them to persist after power up as the programs will (well I hope) be all inclusive and recalculate themselves.

If you did want them to be retained, do you have extended macro variables? meaning those above #530. up to #999 depending on the option (Fanuc). That helps a bit, you could have #600's for certain stuff, #700's for other certain stuff, etc.

In addition, there is a parameter to make the control retain #100-#199 even when you hit reset or turn off the control. Just in case you want it.

As mentioned by Vancbiker and Angelw, for the majority of things, you shouldn't need that, and it is good form to have variables clear when they are only there for calculations in a given program and only use the nonvolatile ones for stuff you NEED to store. but I fall habit to using 500+'s myself, so...
 
Thanks Dan the keeper of beats.

I want to start with good habits, so if clearing intermediate calculative variables is good form, then that's what I will do. Just trying to figure out an easy and proper way to gather information only once and have the program take care of the rest.

Like now im wondering what to do if there is more user input required than space for locals. Ie, if 39 values must be assigned but only 26 local variables exist. Dunno, reading and working on it as we speak.

Thanks again.
 
For the purpose of passing variables to the macro, L, O, N, G and P cannot be used. Thus, only 21 values can be passed.
However, if you use Argument Specification II, 33 values can be passed through the macro call.
 
Thanks Dan the keeper of beats.

I want to start with good habits, so if clearing intermediate calculative variables is good form, then that's what I will do. Just trying to figure out an easy and proper way to gather information only once and have the program take care of the rest.

Like now im wondering what to do if there is more user input required than space for locals. Ie, if 39 values must be assigned but only 26 local variables exist. Dunno, reading and working on it as we speak.

Thanks again.

But I don't think you'll need THAT many.

If you intend to use locals calling them up as letters, ie G65P9999 A1 B2 C3 D4, sure, you're limited (to 21 using a-z, or 33 using ijk1 through ijk10).

But if you're using them to do math, and you need more than 33, but you don't need to -keep- them all, just re-use them

#1=[#1*3]
 
Hi.
Is it possible to change the tool change macro on a yasnac i80 to activate tool length compensation. working on Mazaks before i miss this feature.

regards
Kent
 
If you did want them to be retained, do you have extended macro variables? meaning those above #530. up to #999 depending on the option (Fanuc). That helps a bit, you could have #600's for certain stuff, #700's for other certain stuff, etc.

In addition, there is a parameter to make the control retain #100-#199 even when you hit reset or turn off the control. Just in case you want it.

As mentioned by Vancbiker and Angelw, for the majority of things, you shouldn't need that, and it is good form to have variables clear when they are only there for calculations in a given program and only use the nonvolatile ones for stuff you NEED to store. but I fall habit to using 500+'s myself, so...


In response, I work with many machines in a large department of a manufacturing plant. We manufacture 1 basic type of part with many different variations. I have done just what the SmlG54 wants to do and standardized the assignment of the #500-#999 variables as much as practical. #500 = Probing variables, #600 = part specific input information, #700 = calculations, #800 = adjustments (corrections), spindle speeds, feed rates and tool variables, #900 = option bits, keep bits and misc. This was standard across all machine types and controls (Fanuc, Mazak, Brother, Siemens (R for Siemens instead of #)). Everyone knew, for example, that #700 was rough OD clearance point. Made no difference if it was a lathe or a mill (all of our parts are round).

The key is that there is a sub program called that writes all of the pertinent variable information for each part type. This is the part information file and it is what is loaded when a part is to be ran and is called each cycle. There is no programming at the machine. In my case, this eliminates the issue warned above of having a variable stay set that may be inadvertently used in another program. That cannot happen in my case.

Each of our machines performs specific operations, unlike a job shop. The first machine is always going to do this, that and that and maybe this and this. But that is all it will ever do. It always runs the same main program. So a subprogram is developed that inputs all of the relevant data to the calculation program.
i.e.
06000 (MAIN PROGRAM)
(CALL PART SPECIFIC SUB)
(CALL INPUT CHECK SUB)
(CALL CALCULATION SUB)
......

In program 7000, there is only 1 line, a sub that calls the actual data input sub routine. This is so the operator only has to change 1 number when changing over from one part to the next - they change which part data sub is called in the subroutine call of O7000.

All 1000 series programs contain the part specific data and reside in the control.

When a new part is required, you simply make a new 1000 series program with all the pertinent data input.

This is very different that what would be required for a machine shop doing 5 different types of parts in a day. Different end of the spectrum.
 
Hi all.
I have this macro to milling a square part with cutter comp(G41/G42). Step down is 1mm, size of square is 50mm with 30mm height.
Every time tool reach the end of the cycle it'll retract to start position (X60 Y60) and then follows the shape again.
Now I wonder if anyone know of a macro to helically step down the cutting process and remove the retracts?

Code:
G91 G28 Z0 ;
G90 G54 X0 Y0 M3 S1200 ;
G43 Z100 H1 ;
G0 G40 X60 Y60;
#1=0 ;
#2=-30 ;
N1 G1 Z#1 F2000 ;
G41 D10 X50 F1200 ;
Y-50 ;
X-50 ;
Y50 ;
X60 ;
G0 G40 Y60 ;
#1=#1-1 ;
IF [#1 GE #2] GOTO 1 ;
G91 G28 Z0 ;
M5 ;
M30 ;
 
Hi all.
I have this macro to milling a square part with cutter comp(G41/G42). Step down is 1mm, size of square is 50mm with 30mm height.
Every time tool reach the end of the cycle it'll retract to start position (X60 Y60) and then follows the shape again.
Now I wonder if anyone know of a macro to helically step down the cutting process and remove the retracts?

Code:
G91 G28 Z0 ;
G90 G54 X0 Y0 M3 S1200 ;
G43 Z100 H1 ;
G0 G40 X60 Y60;
#1=0 ;
#2=-30 ;
N1 G1 Z#1 F2000 ;
G41 D10 X50 F1200 ;
Y-50 ;
X-50 ;
Y50 ;
X60 ;
G0 G40 Y60 ;
#1=#1-1 ;
IF [#1 GE #2] GOTO 1 ;
G91 G28 Z0 ;
M5 ;
M30 ;
Hello Alir3za,
The following will work for you. If you really want a helical in-feed, I can show you how to do that. The feed rates you have seem way too high.

Regards,

Bill

G91 G28 Z0.0 ;
G90 G00 G54 X0.0 Y0.0 M3 S1200 ;
G43 Z100.0 H1 ;
G40 G00 X60.0 Y60.0;
#1 = 0 ; (Z START)
#2 = -1.0 (DOC)
#3 = -30.0 ; (FINISHED Z COORDINATE)
#4 = #1 + 1 (RETRACT PLANE)
G01 Z#4 F2000 ;
WHILE [#1 GT #3] DO1
#1 = #1 + #2 (SET NEW DOC)
IF [#1 LT #3] TH #1 = #3 (ENSURE NO OVER CUT IN Z)
G01 Z#1 F100 (FEED TO DEPTH OF NEW DOC)
G41 G01 X50.0 D10 F1200 ;
G01 Y-50.0 ;
G01 X-50.0 ;
G01 Y50.0 ;
G01 X60.0 ;
G40 G01 Y60.0 ;
END1
G00 Z#4
G91 G28 Z0.0 ;
M5 ;
M30 ;
 
Last edited:
Hello Alir3za,
The following will work for you. If you really want a helical in-feed, I can show you how to do that. The feed rates you have seem way too high.

Regards,

Bill
Thank you angelw for the replay.
I tried your marco but it wasn't helical moves and after each step down machine retracted to start position and took another step until the end of program so result was the same as macro I did write in my previous post.
 
Thank you angelw for the replay.
I tried your marco but it wasn't helical moves and after each step down machine retracted to start position and took another step until the end of program so result was the same as macro I did write in my previous post.

Hello Alir3za,
Do you mean that you want move down to the next DOC as you navigate the square form? If so, you need to specify whether want to move the DOC, in your example -1.0mm, along the first face only, or all faces, resulting in a 4.0mm DOC by the time the cutter reaches the last corner.



Regards,

Bill
 








 
Back
Top