What's new
What's new

Macro Programming Fundamentals

Fanuc 30i question again -
In a sub program, is it possible to determine the calling program number? In the below example, within program 3, is it possible to determine which top level is running? either 1 or 2?

O0001
M98P3

O0002
M98P3
 
Store #4115 in some common variable just before calling the subprogram, and read it inside the subprogram.
#4115 contains the currently-executing program number (main or sub or macro)
 
Store #4115 in some common variable just before calling the subprogram, and read it inside the subprogram.
#4115 contains the currently-executing program number (main or sub or macro)

Thanks Sinha, that is a possible solution.

In this case I'm wondering if I can do this without editing those calling programs (1, 2, etc as there are too many), but only the called program (3)... if possible.
 
I suspect that the correct Variable to use may be #2. The reason for this thinking is that the Error Trap results refer to the "B" axis and your Call Block "G190 BXXX" is passing an Argument to Local Variable #2 (B) in the Macro.


Regards,

Bill
The program runs as is with no alarms. It just doesn’t index. I agree I’m missing values in the tables but where and what is the question. I have the value for distance traveled in X = degrees of rotation, I just don’t know where or what number to enter it on in the tables.
 
The program runs as is with no alarms. It just doesn’t index. I agree I’m missing values in the tables but where and what is the question. I have the value for distance traveled in X = degrees of rotation, I just don’t know where or what number to enter it on in the tables.
The following two Blocks are wrong and I would have thought they would generate an error, for there is no Variable that is defined with just the #.

IF[#LT0]GOTO102
IF[#GE360.]GOTO103

As I mentioned in my previous Post, 2# would very likely be the correct variable, as the Variable in the two Conditional Blocks are checking to see that the Variable is within the range of 0 to 360. Logically, these values would be degrees as a "B" argument is being passed (passed to Local Variable #2 in the Macro) and if the Conditional Statement tests True, an Error Message is displayed that relates to the "B" axis. Accordingly, everything points to the Variable number being #2.

#100 in the following Block is not defined anywhere in the Macro. It could be that it should be a four digit number specifying an I/O. As it is, if its being set in another program and the set value is "1", your Macro Program will read the Variable because #100 is a Common Variable and branch past the Indexing Code of your program. If its not being set in another program, its value will always be Null and therefore, superfluous in the Macro Program.

My guess is that it should have another digit and define a Variable in the range #1000 to #1015 to be read as a signal bit by your Macro Program. That would make the most sense.

IF[#100EQ1.]GOTO008

Your best approach will be to step through the program in Single Block and look up the value of the Variables used in the Conditional Blocks before they are executed, This way you will see exactly what the program is doing and why no index.

Regards,

Bill
 
Last edited:
Thanks Sinha, that is a possible solution.

In this case I'm wondering if I can do this without editing those calling programs (1, 2, etc as there are too many), but only the called program (3)... if possible.
Not possible on model C and earlier versions. Have not checked the system-variable list in model D.
 
The following two Blocks are wrong and I would have thought they would generate an error, for there is no Variable that is defined with just the #.

IF[#LT0]GOTO102
IF[#GE360.]GOTO103

As I mentioned in my previous Post, 2# would very likely be the correct variable, as the Variable in the two Conditional Blocks are checking to see that the Variable is within the range of 0 to 360. Logically, these values would be degrees as a "B" argument is being passed (passed to Local Variable #2 in the Macro) and if the Conditional Statement tests True, an Error Message is displayed that relates to the "B" axis. Accordingly, everything points to the Variable number being #2.

#100 in the following Block is not defined anywhere in the Macro. It could be that it should be a four digit number specifying an I/O. As it is, if its being set in another program and the set value is "1", your Macro Program will read the Variable because #100 is a Common Variable and branch past the Indexing Code of your program. If its not being set in another program, its value will always be Null and therefore, superfluous in the Macro Program.

My guess is that it should have another digit and define a Variable in the range #1000 to #1015 to be read as a signal bit by your Macro Program. That would make the most sense.

IF[#100EQ1.]GOTO008

Your best approach will be to step through the program in Single Block and look up the value of the Variables used in the Conditional Blocks before they are executed, This way you will see exactly what the program is doing and why no index.

Regards,

Bill
Yes you are correct about #2.
 
The following two Blocks are wrong and I would have thought they would generate an error, for there is no Variable that is defined with just the #.

IF[#LT0]GOTO102
IF[#GE360.]GOTO103

As I mentioned in my previous Post, 2# would very likely be the correct variable, as the Variable in the two Conditional Blocks are checking to see that the Variable is within the range of 0 to 360. Logically, these values would be degrees as a "B" argument is being passed (passed to Local Variable #2 in the Macro) and if the Conditional Statement tests True, an Error Message is displayed that relates to the "B" axis. Accordingly, everything points to the Variable number being #2.

#100 in the following Block is not defined anywhere in the Macro. It could be that it should be a four digit number specifying an I/O. As it is, if its being set in another program and the set value is "1", your Macro Program will read the Variable because #100 is a Common Variable and branch past the Indexing Code of your program. If its not being set in another program, its value will always be Null and therefore, superfluous in the Macro Program.

My guess is that it should have another digit and define a Variable in the range #1000 to #1015 to be read as a signal bit by your Macro Program. That would make the most sense.

IF[#100EQ1.]GOTO008

Your best approach will be to step through the program in Single Block and look up the value of the Variables used in the Conditional Blocks before they are executed, This way you will see exactly what the program is doing and why no index.

Regards,

Bill
When I single block through the program it goes straight through to the end with the pallet unlock and lock commands and ends the program.
 
Are you saying you are not seeing the macro program 9010 when you single block thru it? Or it simply skips a bunch of stuff (either by a true IF-GOTO, or some other error)?

On a fanuc control, there is a parameter to allow you to single block thru macro statements such as #100=1. There is also a parameter to allow you to view the contents of m-code called 9000 programs as they are executed. I would expect similar to be true for your yasnac control. but I have never used one so I can't help you.
 
I can see the program, in single block it runs to the end, unlocks and locks the pallet and ends the program. No alarms, but it thinks its rotated based on the data it stores in variable #550.
 
That would depend on what is already stored in #550. If its the same as the Index Angle that is passed to the Macro, then the Program will fall through to the end.

Post a copy of your current program so we can see if their are still errors in it. Every time I look at the first program you Posted, I find more errors.

If you're really executing the program in Single Block, then you should be able to determine why its not indexing. Unless a parameter bit and a System Variable are set accordingly, Macro Statements won't be executed in Single Block. For example, lets say that there are twenty, consecutive Macro Statements in a program; notwithstanding that Single Block has been turned on, without the correct setting of the parameter bit and System Variable, one press of the Cycle Start Button at the first Block of twenty Macro Statements will have all twenty Blocks execute as if one Block only.

Another way to force each Macro Statement to execute Block by Block in Single Block, without the need to set the parameter bit and System Variable, is to add a blank line between each Macro Statement, that is, just an End Of Block.

It looks like the following is the Block that makes the Index occur
G53X#32
therefore, put an M00 in a Block immediately before it and run the Program. If all the ducks are aligned to make an Index, the program will stop at the M00. At that point, look up the value of #32 in the Variable Register to determine if an Index should occur or not. In Single Block, if your program has made it to the M00, then the next Block should have an index occur.

Regards,

Bill
 
Last edited:
Awesome information, thank you!!!! I'll give this a try this afternoon. Thank you again, and I'll see if I can post the program without making any typo's.
 
If I may suggest a half-assed thing to try if you don't receive the whole program when you click send -- If it simply isn't sending the last several lines of code to the PC, or not sending the first few lines of code, insert a bunch of blank lines at the front or end of the program. If it is simply dropping the first or last few lines, it will only drop blank lines.

Obviously if there's a setting that can change it, great. I might also suggest whatever hardware you're using to receive (such as rs232-usb adapter) might be the culprit, too. But give the above a shot.
 
I get the whole program, it just drops or leaves out some of the characters, when I make changes to get the characters it leaves out or changes the information on that line or lines, I've changed cables, software, hardware and settings, added lines, added spaces, removed lines and spaces. Tried it at night, tried it in the morning and afternoon, even waited for full moon to try it. I believe its a case of old meets new, and there's not much I can do about it.
 
Screen shots of the program
 

Attachments

  • IMG_2023.JPG
    IMG_2023.JPG
    530.5 KB · Views: 10
  • IMG_2024.JPG
    IMG_2024.JPG
    663.6 KB · Views: 10
  • IMG_2025.JPG
    IMG_2025.JPG
    560 KB · Views: 7
  • IMG_2026.JPG
    IMG_2026.JPG
    682.3 KB · Views: 6
  • IMG_2027.JPG
    IMG_2027.JPG
    608.2 KB · Views: 7
  • IMG_2028.JPG
    IMG_2028.JPG
    544.1 KB · Views: 7
  • IMG_2029.JPG
    IMG_2029.JPG
    647.3 KB · Views: 5
  • IMG_2030.JPG
    IMG_2030.JPG
    281.1 KB · Views: 5
  • IMG_2031.JPG
    IMG_2031.JPG
    330.2 KB · Views: 9
Screen shots aren't going to do it. Its difficult enough trying to help you with a program listing that has multiple errors, whether they're from your typos, or a program that is just full of errors, than having to construct a program out of screen shots.

I'm sure I'll be able to sort your issue out, but a good copy of the program you're using will be required.

Regards,

Bill
 








 
Back
Top