First time making a Macro Program

[EyeEmTrash]

Most of those variables are useless because they are going to be hard coded into your main program.

I was just going to make a few main programs for different ODs and just call the same sub program. What would you suggest?

 

[EyeEmTrash]

So I plan on making a bunch of different main programs and call the same subprogram (attached). Is there a better way that wouldn't be so complicated for a newbie like me? Also if you wouldn't mind looking over and let me know what you think. I have proofread it around 5 times and good thing I did. Quite a few mistakes, wouldn't be surprised if there's more hiding in there. Also, this isn't a complicated part. You will notice some things and wonder why I am doing it that way. For example, the first line of OD thread numbers might be off, I haven't checked the old program yet. The top drilling. I don't use true rapid into the parts because it leaves a bad finish on the long and thin parts. I created my own rapid. Or why, I need to know my drill od for tool safety ;D ;D. I plan on trying longer DOC on drill now that it is easier to change. I couldn't use drilling canned cycle because they ruined some parts on the rapid in. So I would have had to rewrite the code for a different DOC.

I care more about how fast I go then my job does. They just want good parts. Any advice is appreciated though.

 

[EyeEmTrash]

Most of those variables are useless because they are going to be hard coded into your main program.

If I understand what you are saying, my argument back would be those variables remain constant. If you look at the program I attached, I use variables #150-160 to manipulate the hard coded variables. Hoping it works

 

[Booze Daily]

If those variables remain constant then put them in the code. Do you plan on rough turning each part with a different tool?
No? Then use T1010 in your sub.
Do you plan on rapiding to a different approach point every time you spot drill?
No? Then hard code it in the sub.

That's what I'm getting at. Less variables, less chance for a mistake.

 

[EyeEmTrash]

If those variables remain constant then put them in the code. Do you plan on rough turning each part with a different tool?
No? Then use T1010 in your sub.
Do you plan on rapiding to a different approach point every time you spot drill?
No? Then hard code it in the sub.

That's what I'm getting at. Less variables, less chance for a mistake.

I understand. I guess I just want the variables at the top so I don't have to go digging through the code every time I need to change it.

 

[Jatrox]

BD is just saying some of the variables in the sub can possibly be replaced with hard code.

Check for missing brackets:
#154=#154-#119(DRILLING COORDINATE)
#155=#154+#119+.005("RAPID FEED" COORDINATE)

 

[Booze Daily]

I understand. I guess I just want the variables at the top so I don't have to go digging through the code every time I need to change it.

So you do need to change which tool you're using to rough turn. OK, use a variable.
You need to change the depth of each facing pass depending on which particular part number you're running? OK, use a variable.

Why not just use a G72 facing cycle and hard code your DOC in there?
Same with G71 for turning.

 

[EyeEmTrash]

So you do need to change which tool you're using to rough turn. OK, use a variable.
You need to change the depth of each facing pass depending on which particular part number you're running? OK, use a variable.

Why not just use a G72 facing cycle and hard code your DOC in there?
Same with G71 for turning.

The turning isnt that complicated. A lot of the parts dont have to be turned down much. And I never used a facing canned cycle before.

 

[EyeEmTrash]

Ok so the last programs I uploaded had quite a few mistakes. I had some time to read and reread a few times to make sure everything is copacetic. I think it looks good enough for a dry run. I will be adjusting it to some of your suggestions but I am still learning as I go so I would like to just get a working program first. If anyone notices anything please point it out.

Also, I was worried that if I had to rerun a certain tool, that the parameters might get lost in the sauce. So I decided to make a few subprograms for each tool just in case. I was going to ask if this was necessary. As I type this, I realize that I could do it a little different using m01s and different goto codes instead.

 

[Jatrox]

Ok so the last programs I uploaded had quite a few mistakes. I had some time to read and reread a few times to make sure everything is copacetic. I think it looks good enough for a dry run. I will be adjusting it to some of your suggestions but I am still learning as I go so I would like to just get a working program first. If anyone notices anything please point it out.

Also, I was worried that if I had to rerun a certain tool, that the parameters might get lost in the sauce. So I decided to make a few subprograms for each tool just in case. I was going to ask if this was necessary. As I type this, I realize that I could do it a little different using m01s and different goto codes instead.

Yes that can be cleaned up a lot but if this gets you started go with it. As you go through it things will make more sense and you'll see what you can/need to do.

 

[angelw]

If I understand what you are saying, my argument back would be those variables remain constant. If you look at the program I attached, I use variables #150-160 to manipulate the hard coded variables.

One issue that may bite you is in fact that you're manipulating the Variables that you have set in the Main Program, in the various Subprograms. The Variables you're using are Common Variables, meaning that all programs that use these Variables are subject to the change to the variable made in another program. The change of #150 in the following #150=[#150-#106], for example, will be seen by all programs using #150.

One of the first rules of Software Programming and Macro Programming is a form of Software Programming, is that you only use Global Variables where they are absolutely necessary. If a Local Variable can be used, then use it.

I'm not sure of the case with later model Yasnac Controls, but older models, Common Variables would have to be used to register the values of the Variables; Local Variables can't be used in the Main Program. But with Haas, Fanuc and many other controls, that isn't the case. Because of the number of Variables you're defining in the Main Program, there aren't enough Local Variables, therefore, if you deem that all the Variables are required, then Common Variables will have to be used. However, you need to get into the GOOD habit of using Local Variables in your Subprograms. Any changes to Local Variables in any Sub or Macro Program (there is a difference between the two types of programs), won't affect the same Local Variables in any other Sub or Macro Program. The only time you may want to change the value of a Common Variable is when another Sub or Macro program (more for a Subprogram than a Macro Program) may be being called from within a Sub or Macro Program. Even in this situation, rather than Call a Subprogram, the values of a Local Variable used in one Subprogram or Macro Program can be passed as an argument to another Macro Program (not to a Subprogram)

Regards,

Bill

 

[EyeEmTrash]

One issue that may bite you is in fact that you're manipulating the Variables that you have set in the Main Program, in the various Subprograms. The Variables you're using are Common Variables, meaning that all programs that use these Variables are subject to the change to the variable made in another program. The change of #150 in the following #150=[#150-#106], for example, will be seen by all programs using #150.

One of the first rules of Software Programming and Macro Programming is a form of Software Programming, is that you only use Global Variables where they are absolutely necessary. If a Local Variable can be used, then use it.

I'm not sure of the case with later model Yasnac Controls, but older models, Common Variables would have to be used to register the values of the Variables; Local Variables can't be used in the Main Program. But with Haas, Fanuc and many other controls, that isn't the case. Because of the number of Variables you're defining in the Main Program, there aren't enough Local Variables, therefore, if you deem that all the Variables are required, then Common Variables will have to be used. However, you need to get into the GOOD habit of using Local Variables in your Subprograms. Any changes to Local Variables in any Sub or Macro Program (there is a difference between the two types of programs), won't affect the same Local Variables in any other Sub or Macro Program. The only time you may want to change the value of a Common Variable is when another Sub or Macro program (more for a Subprogram than a Macro Program) may be being called from within a Sub or Macro Program. Even in this situation, rather than Call a Subprogram, the values of a Local Variable used in one Subprogram or Macro Program can be passed as an argument to another Macro Program (not to a Subprogram)

Regards,

Bill

Yes I will have to look into it more. As of now, this will be the only Macro program I make so I am guessing it will be ok for now? But I will definitely look into it. I will read and then reread your comment and then research. It takes me a bit to fully understand things.

 

[EyeEmTrash]

One issue that may bite you is in fact that you're manipulating the Variables that you have set in the Main Program, in the various Subprograms. The Variables you're using are Common Variables, meaning that all programs that use these Variables are subject to the change to the variable made in another program. The change of #150 in the following #150=[#150-#106], for example, will be seen by all programs using #150.

One of the first rules of Software Programming and Macro Programming is a form of Software Programming, is that you only use Global Variables where they are absolutely necessary. If a Local Variable can be used, then use it.

I'm not sure of the case with later model Yasnac Controls, but older models, Common Variables would have to be used to register the values of the Variables; Local Variables can't be used in the Main Program. But with Haas, Fanuc and many other controls, that isn't the case. Because of the number of Variables you're defining in the Main Program, there aren't enough Local Variables, therefore, if you deem that all the Variables are required, then Common Variables will have to be used. However, you need to get into the GOOD habit of using Local Variables in your Subprograms. Any changes to Local Variables in any Sub or Macro Program (there is a difference between the two types of programs), won't affect the same Local Variables in any other Sub or Macro Program. The only time you may want to change the value of a Common Variable is when another Sub or Macro program (more for a Subprogram than a Macro Program) may be being called from within a Sub or Macro Program. Even in this situation, rather than Call a Subprogram, the values of a Local Variable used in one Subprogram or Macro Program can be passed as an argument to another Macro Program (not to a Subprogram)

Regards,

Bill

Ok so I get changing it to other variables and I will do that. Say for example I do #150=#150-#106, it will be stored in the machines. In theory if in another program I used #150=2.5, then wouldn’t It reset to be 2.5?

 

[sinha]

Common variables are "common" to the same program, including its subprogram and macros.
It doesn't pass on to another program (assuming 6001#6 = 0). There are "permanent common variables" for that purpose.

 

[angelw]

Ok so I get changing it to other variables and I will do that. Say for example I do #150=#150-#106, it will be stored in the machines. In theory if in another program I used #150=2.5, then wouldn’t It reset to be 2.5?

Yes, its how Sinha explains. But from what I've read of this Thread, it's your intention to set the Variables at the top of the Main Program, then call numerous Subprograms from within the Main Program, all of which will use at least some of the Variables set at the Top of the Main Program. Because the Variables aren't reset to their required Values between the call of the Various Subprograms, any change made to any of the Variables you set at the Top of the Main Program, will be used by the Subprograms called subsequent to the changes made.

Normally M30 at the end of the Main Program will be linked to the Reset Signal and unless their characteristics are changed via parameter setting, the100 Series Macro Variables will be reset to Vacant (Null), when either the Reset Button is pressed, or via the Reset Link of M30. When the Main Program is run again, the Variables at the Top of the Program will be set to their specified values.

There are two types of Common Variables, volatile and nonvolatile. The Volatile versions is reset to vacant when Reset is executed, or when the power to the control is cycled. The Nonvolatile version retains their value, when Reset is executed and even when the power to the control is cycled. For the purpose of your program, it's irrelevant as to whether the Common Variables are reset to Vacant at the end of the Main Program, or not, for they will have the correct values allocated to them when the Main Program starts.

The important thing is that, as you add further Subprograms to your project, any Common Variable that is used by all, or a number of the Subprograms, is not modified within any of the Subprograms unless the scope of your project is for subsequent Subprograms to the change, to use the changed values.

Regards,

Bill

 

[sinha]

OP may like to read my books, Probing on CNC Machines and Macro Programming Fundamentals, for a quick introduction to macro programming.

The probing book will be available for free download from tomorrow, for five days.
Download link: https://www.amazon.com/dp/B08Q5QGGRY

The other book can be downloaded for free in the following week.