What's new
What's new

Macro Programming AB 9 series 260 mill control

rorycollins0

Plastic
Joined
Apr 3, 2020
Hey just wondering if anybody has a solution to this problem im having.

Im trying to adapt my fanuc B macros to work on the AB 9 control.
I frequently run into this issue

Allot of my Fanuc macros have input argument test comparing a local varialbe to #0(null)
and the Allen bradley control does not have a null value concept. all the local and volatile variable reset to 0.0000 on reset/m30/m99/power on.

heres an example of my dilema

Say your macro is g65p8001c54m2

in your macro program you have a line
o8001
IF[#3EQ#0]GOTO997
.
.
GOTO999
N997#3000=1(NO C VALUE PROGRAMMED)
N999M99

ALSO SOME OF MY MACROS RELY ON IGNORING NULL VALUES FOR EXAMPLE
G0X3.Y7.
G65P8084D3.T1.Q20.R.1Z-1.F30.
HENCE #24 & #25 ARE CONSIDERED NULL
O8084
.
.
G0X#24Y#25(IF XY ARGUMENTS WERE NULL NO MOVEMENT WOULD OCCOUR)
(WHILE DO LOOP BLAH BLAH)
END1
G0Z3.
M99

I am a pretty good programmer but i can't wrap my head around an easy solution thats not ridiculously complicated. The allen bradley manual calls it parametric programming and has no example of this in it.

any help or tips would be appreciated.
 
Bump

More stuff the machine is a Toshiba Shiabura BTD-11B boring bar mill.
all the macro programming and g code is identical to Fanuc includeing almost all system variables for modal data, and common and extended common variables.
so it has
#1-#33
#100-#200 volatile at system reboots
#500-#519 non volatile
#520-#999
#1000-#1075 ish system ports and inputs etc
#3000s system timers and macro alarm flags
#4000s modal data
#5000s offsets
#8000s tool offsets
it takes if then statements and all normal Fanuc math logic like ABS[#11] FIX[#1] etc
except... no null values
all variables are either set to a value or 0.0000 no way to be set empty.

Everyone stay safe out there!
Hope you all are getting to do your part in these grim times.
 
If the expected value of the variable is not 0, then something can be done.

I am not aware of your Control, but it is difficult to believe that the concept of Null variable is not there. It might be parameter dependent.
Let Bill comment.
 
Thanks for the reply. It may be possible that the 0.000 are also null unless you actually programmed a 0. in an argument. I will have to play around with that. But even so if that is true I do not understand how that a test like IF[#100EQ0.000]#3000=#3000+1(missing arg. alarm) would be a substitute for checking if a value is null. What if you did program a value as 0.000 that would pass the test, when it may be important to fail that and catch a forgotten input. It's difficult. I want to add probing to the machine but all the fanuc renishaw macros have lots of #0 null refferences in them. unless there is a safe substitute for that input test i don't think the macros would be reliable like they are on fanuc systems.
 
Thanks for the reply. It may be possible that the 0.000 are also null unless you actually programmed a 0. in an argument. I will have to play around with that. But even so if that is true I do not understand how that a test like IF[#100EQ0.000]#3000=#3000+1(missing arg. alarm) would be a substitute for checking if a value is null. What if you did program a value as 0.000 that would pass the test, when it may be important to fail that and catch a forgotten input. It's difficult. I want to add probing to the machine but all the fanuc renishaw macros have lots of #0 null refferences in them. unless there is a safe substitute for that input test i don't think the macros would be reliable like they are on fanuc systems.

Hello Rory,
You are correct in your interpretation of the Variables of this control. There is no Read Only Variable that has a Null, or Empty status, such as #0; this is a basic deficiency of this control.

It's my understanding that the volatile Variables are set to Zero and not Empty on Reset and Cycling of the power to the control. However, if it is the case that 0 is Null, unless explicitly specified, you could dedicate a seldom used Local Variable in place of #0, such as #22 ("V"). In that case, your example Conditional Statement would look something like the following:

IF[#100 EQ #22]TH #3000=#3000+1(MISSING ARGUMENT)

However, I don't believe an un-allocated Variable has an Empty status.

Rather that raise an alarm on the fly, at the specific Conditional Statement, I prefer and its better programming practice to group your Error Trapping for missing arguments at the head of the program and them the result close, or past the end of the program. If you were to raise a generic alarm for all omitted arguments, then you can "OR" them together in the single Conditional Statement as follows:

IF[[#1 EQ #22] OR [#2 EQ #22] OR [#7 EQ #22] OR [#11 EQ #22]]GOTO900

Regards,

Bill
 
Hello Rory,
You are correct in your interpretation of the Variables of this control. There is no Read Only Variable that has a Null, or Empty status, such as #0; this is a basic deficiency of this control.

It's my understanding that the volatile Variables are set to Zero and not Empty on Reset and Cycling of the power to the control. However, if it is the case that 0 is Null, unless explicitly specified, you could dedicate a seldom used Local Variable in place of #0, such as #22 ("V"). In that case, your example Conditional Statement would look something like the following:

IF[#100 EQ #22]TH #3000=#3000+1(MISSING ARGUMENT)

However, I don't believe an un-allocated Variable has an Empty status.

Rather that raise an alarm on the fly, at the specific Conditional Statement, I prefer and its better programming practice to group your Error Trapping for missing arguments at the head of the program and them the result close, or past the end of the program. If you were to raise a generic alarm for all omitted arguments, then you can "OR" them together in the single Conditional Statement as follows:

IF[[#1 EQ #22] OR [#2 EQ #22] OR [#7 EQ #22] OR [#11 EQ #22]]GOTO900

Regards,

Bill

Thanks Bill i really like that suggestion. I think that would be the best option in my case. I would possibly also put in a test to ensure that #22 is eq to 0, gt 0, or lt 0 or something similar to be sure no one ever assigns value to it. I will let you know how it works out. The machine is down now. We tried replacing the lamps in the buttons on the operator panel and it smoked an ic on the input mtb2 board that communicates with the fiber optic i/o ring when we powered it back up. The tech identified the issue and the board is out for repair. Keeping my finger crossed that it's just a fluke and not something major. Should be up by the end of the week if all goes well. With the current covid virus issue the tech said he is having lots of issues with part suppliers. It is quite a large machine and in really good mechanical condition. The real shame is the obsolete allen bradley control. I've done some incredible work with that old girl, I would be sad to see her go.
 
Just to follow up. The board was repaired last week. I have had time to play with it now on new jobs. It does seem to behave as that if a volatile variable is 0.0000 unless written 0. value prior it is considered null and just shown as 0.0000 instead of empty.
It is rather confusing, too bad they did not do it the Fanuc way. Oh well with a bit of tweaking I have gotten my macros to work without changing extensive amounts of the programs.

Thanks for all the help everyone.
 
Even in fanuc, a null variable is equivalent to 0 in arithmetic expressions. In fact, it is equivalent to 0 except in EQ and NE conditional statements.
 
absolutely right, and that is what i did to fix my problem. I just checked if the variables were eq or ne to 0 and it seems to work correctly. I will do some extensive proving of that before i let it run a probe macro willy nilly day in day out. I think ill just use a cheap edge finder in place of the probe for now lol.
 








 
Back
Top