Okuma Subroutine Call OSP-300

[gcode]

I'm trying to run sub routines on our new Okuma VTM

 

my post is outputting

 

CALL OPL0001   for a sub call... 

 

and naming the sub  "filename".sub

 the control will not even load the main file

 

I tried

CALL 1234 and named the subroutine O1234.SUB

 

but that didn't work either.

 

The Programming manual is as clear as mud on this issue.

can anyone set me straight on this   TIA

 

 

 

 

 

 

[T_MALENA]

shouldn't you be calling your main program something like "main.min" and your sub "sub.ssb"

[T_MALENA]

so for ex. my main program P0001.min has a probe cycle #1 #2 & #3, in the main prog is

 

VZOFZ=638.03(638.014+.002)
CALL OPRB1 DIA=17.55 ZPO=.153 ROT1=2.50 PT=.219
VZOFC=0.

 

 

 

now the probe program is saved as OPRB1.ssb (not necessary to be OPRB, but must be .SSB)  

Note the 1st line is the program call & the program ends in RTS

 

 

OPRB1
VTOFZ[12]=3.406G

0X50.Z6.0
VZOFC=.0
T1212

blah

blah

RTS

 

 

Now bear in mind .SUB can also be used as a sub program call. Slightly different than a .ssb program.   A ssb can be called when its embedded in into another program.  So I have another situation where I have all the probe cycles in the same file called "allprobe"  In there are OPRB1, OPRB2 ...OPRB21 ,  They all start as OPRB1...2...or whatever AND end in RTS.  The CNC control loads the main program & all called ssb programs at the "prog select" button.

 

Hope that makes sense.

[T_MALENA]

I'll pull my book out to be sure, I prefer ssb over sub, I don't use sub hardly ever. 

[The Cathedral]

We never use .SUB, always .SSB

 

Gcode, in the example you gave you said "CALL 1234"

 

It should be "CALL O1234"

 

I don't know if that was a typo or not, so I thought I would point it out.

 

Your sub could technically be named anything you want. What the control looks for is the "O1234" somewhere in a program--any program you have loaded. So even if the post names it "filename.sub" that doesn't matter as long as the beginning of the program is "O1234". Just like what T_MALENA said. We have a hole macro .ssb and inside of it is broken down into hole macros for y-axis, c-axis, face milling, etc; they all are embedded in "HOLEMACROS.SSB" and each one starts with "OHM1" "OHM2" etc. and has to end with RTS.

 

It can also use letters, like "OPROG"

 

It looks like your post will need some tweaking to get it to output the correct sub program names.

[Greg Williams]

The name of the *.sub program has no bearing on this, what matters is the name of the file inside the *.sub

 

Main File

 

CALL OPL0001   for a sub call... 

 

The file name for the sub can be anything, lets say Okumarocks.ssb

 

Insside the ssb we need to have

 

OPL0001

blah

balh

blah

RTS

[gcode]

I got this going OK with the sub inside the main.. which is the preferred solution in this case

 

CALL O1234

blah

blah

CALL O1235

blah

blah

M02 (end of file)

 

O1234

blah

blah

blah

RTS

 

O1235

blah

blah

blah

RTS

 

%

 

My Okuma AE said there cannot be more than 4 characters after the "O" in the Call statement

[Greg Williams]

You can use letters as well if you want CALL OFEED

[jeff]

I got this going OK with the sub inside the main.. which is the preferred solution in this case

 

CALL O1234

blah

blah

CALL O1235

blah

blah

M02 (end of file)

 

O1234

blah

blah

blah

RTS

 

O1235

blah

blah

blah

RTS

 

%

 

My Okuma AE said there cannot be more than 4 characters after the "O" in the Call statement

That's how I've always ran subs in my Okumas

[T_MALENA]

Gcode you got it. also remember the O1234 & O1235 can be in any program. And it can be named anything, up to 16 char. so this can bite you too! if you have O1234 in multiple programs you get some wild parts. that's why I try to keep my probe cycles all in one primary .ssb file. tool macros in one primary file etc.

[oneyankfan1]

I have a situation related to this. 

I have a handful of programs that wont load into the from the fastems due to an buffer issue. I have to run these programs in "b method" as well due to their size. 

I have a Fastems hooked to 2ea. MB 5000H  with osp 300. I want the fastems to deliver the program to the machine as follows:

%

TLFON

CALL O9999

TLFOFF

M02

%

The actual part program (O9999.SSB is what I have it currently named) would be on the control as follows:

%

CALL OPRBE

RUN SOME OF PART

CALL OSETZ

RUN REST OF PART

RTS

%

OPRBE

DO PROBING

RTS

OSETZ

VZOFX[1]= WHATEVER

VZOFY[1]= WHATEVER

VZOFZ[1]= WHATEVER

VZOFB[1]= WHATEVER

AND MORE PROBING

RTS

But I keep getting an alarm when the fastems is trying to load the program.

Do i need to register O9999.ssb? 

Do I need to name it O9999.sub?

It looks right to me as it sits but maybe Im missing something.

Thanks.

[jeff]

7 hours ago, oneyankfan1 said:

The actual part program (O9999.SSB is what I have it currently named) would be on the control as follows:

 

Is the O9999.ssb in the MD1 directory?

Can't it be named O9999.MIN?  

[Brad Lisle]

Here are a few rules to using sub programs.

1. Only allowed four alpha or numerical characters after the "O" (ex. "OABCD", O1234, OAB12)
2. To call the sub program from the main program or from another sub program use the following statement: "CALL O1234", or what ever four characters you choose
3. You can have the sub programs located inside of the main program files, typically at the end of the file after the M02 or M30. This is my preferred method if the sub program only pertains to this one program.
4. If you choose to have an external file, there are four types .ssb, .sub, .msb and .lib
   • if .ssb the file MUST reside in the root MD1 directory
   • if .sub the file may be located in a folder, but you MUST select the folder that the sub program is in at the time of selecting the main program. In the program select screen you will see a list on the left for programs and just to the right of that is another list but for sub programs. this is where you need to open the folder with the sub programs. If you have multiple sub program files, all of them need to be in the same folder and if you are just going to leave everything in the root MD! directory then might as well use .ssb method
   • if .msb the file MUST reside in the C:\OSP-P\MSB and instead of using a single O for the sub program number you MUST use "OO" followed by three alpha or numerical characters. This file is loaded auto magically when the OSP control boots. If you choose to load a sub program here it will require a system reboot. I would only suggest using this method for a sub program you use on multiple parts. For example I have an engraving macro that I would load there.
   • if .lib the file MUST reside in the root MD1 directory and be registered as a library file to a specified G or M code. This is an option on lathes, but standard on mills. This allows the use of a G or M code instead of "CALL O____"

Hope this helps clarify, Cheers,

Brad

[oneyankfan1]

On 5/26/2017 at 2:13 PM, jeff said:

Is the O9999.ssb in the MD1 directory?

Can't it be named O9999.MIN?  

It can but it wont call the program like that. My apps guy said it had to be .ssb or .sub he wasnt sure which. I had time to try .ssb but havent had spindle time to try the other one.

[oneyankfan1]

On 5/27/2017 at 1:50 AM, Brad Lisle said:

Here are a few rules to using sub programs.

1. Only allowed four alpha or numerical characters after the "O" (ex. "OABCD", O1234, OAB12)
2. To call the sub program from the main program or from another sub program use the following statement: "CALL O1234", or what ever four characters you choose
3. You can have the sub programs located inside of the main program files, typically at the end of the file after the M02 or M30. This is my preferred method if the sub program only pertains to this one program.
4. If you choose to have an external file, there are four types .ssb, .sub, .msb and .lib
   • if .ssb the file MUST reside in the root MD1 directory
   • if .sub the file may be located in a folder, but you MUST select the folder that the sub program is in at the time of selecting the main program. In the program select screen you will see a list on the left for programs and just to the right of that is another list but for sub programs. this is where you need to open the folder with the sub programs. If you have multiple sub program files, all of them need to be in the same folder and if you are just going to leave everything in the root MD! directory then might as well use .ssb method
   • if .msb the file MUST reside in the C:\OSP-P\MSB and instead of using a single O for the sub program number you MUST use "OO" followed by three alpha or numerical characters. This file is loaded auto magically when the OSP control boots. If you choose to load a sub program here it will require a system reboot. I would only suggest using this method for a sub program you use on multiple parts. For example I have an engraving macro that I would load there.
   • if .lib the file MUST reside in the root MD1 directory and be registered as a library file to a specified G or M code. This is an option on lathes, but standard on mills. This allows the use of a G or M code instead of "CALL O____"

Hope this helps clarify, Cheers,

Brad

Thanks all. 

[YoDoug®]

Even when in large mode your sub programs cannot be larger than the buffer (2Mb). If you want to have the fastems load large programs you need them to be .MIN files. 

[Maclaw]

On ‎2017‎-‎05‎-‎27 at 8:50 AM, Brad Lisle said:

Here are a few rules to using sub programs.

1. Only allowed four alpha or numerical characters after the "O" (ex. "OABCD", O1234, OAB12)
2. To call the sub program from the main program or from another sub program use the following statement: "CALL O1234", or what ever four characters you choose
3. You can have the sub programs located inside of the main program files, typically at the end of the file after the M02 or M30. This is my preferred method if the sub program only pertains to this one program.
4. If you choose to have an external file, there are four types .ssb, .sub, .msb and .lib
   • if .ssb the file MUST reside in the root MD1 directory
   • if .sub the file may be located in a folder, but you MUST select the folder that the sub program is in at the time of selecting the main program. In the program select screen you will see a list on the left for programs and just to the right of that is another list but for sub programs. this is where you need to open the folder with the sub programs. If you have multiple sub program files, all of them need to be in the same folder and if you are just going to leave everything in the root MD! directory then might as well use .ssb method
   • if .msb the file MUST reside in the C:\OSP-P\MSB and instead of using a single O for the sub program number you MUST use "OO" followed by three alpha or numerical characters. This file is loaded auto magically when the OSP control boots. If you choose to load a sub program here it will require a system reboot. I would only suggest using this method for a sub program you use on multiple parts. For example I have an engraving macro that I would load there.
   • if .lib the file MUST reside in the root MD1 directory and be registered as a library file to a specified G or M code. This is an option on lathes, but standard on mills. This allows the use of a G or M code instead of "CALL O____"

Hope this helps clarify, Cheers,

Brad

Hi Brad,

I want to use the ".sub" method. Why cant I select MULTIPLE (not just one) subprogram file? Do You know a way of achieving this??? Because what's the use of having a main .min program calling just one subprogram .sub file? I prefer using the .sub method because I dont want to trash my root MD1 directory.

I want to use my machine to do 4 pallets of different parts in one run. I will post out 4 part programs and want to have a 4 line main .min prog to control which subs to execute. I dont want to do megabytes of copy paste stuff to put it in one file because it's annoying, a lot of work and may also be dangerous if you leave something out.... Beside - this week I will do 4 parts at a time on 4 fixtures/pallets, next week I will do another (different) 4 parts. All I would need to do is post out the 4 progs for the new parts into subs and do minor (or none) editing to my main prog and fire of the production with no windows copy/paste BS and merging large files into one and all that headache....

Thanks in advace for your help.

[Mr. M]

You would be better served using a schedule program if I am understanding you correctly. Four .MIN part programs and one schedule. 

(ALL.SDF)

PSELECT   A1.MIN,,,Q1

PSELECT   A2.MIN,,,Q1

PSELECT   A3.MIN,,,Q1

PSELECT   A4.MIN,,,Q1

END

[Maclaw]

Thanks Mr. M,

But unfortunately when I use scheduled progs the machine doesnt display the program flow... And this is an issue in my company. It's against our internal safety procedures - how can an operator run a program "in blind"??? This is some kind of absurd....!! Anyway - thanks very much for your interest in this subject Mr. M. I guess for now I will go with the ".ssb" method from the root of MD1, as Brad described above - already backed up all files from that directory in case I or someone else deletes anything important from there. Thanks again Brad for your post.

 

It's amazing how this machine is "safe". You cant even use an edgefinder at 400 RPM with the doors open (max RPM=50).... But when you run a scheduled prog it wants you to do it "blind" - aint that clever Folks? BRAVO!!! :-) The Guy who came up with this clever idea should go to Swedem for a Noble "anti-common sense" prize! I mean - dont these darn MTBs  listen to the machinists anymore these days??? Why?. Good thing I also have HAAS machines which are made for machinists and can be operated in a normal manner still maintaining RESONABLE safety issues. They say Haas this, Haas that, but.... oohh man... to move axes (while spindle is stopped) in this Okuma, it would be good to have 4 hands and a checklist procedure like airline pilots - so many buttons and key switches you must press to achieve this. Going this way, in a few years you wont be able to touch this machine while working on it... This is crazy!!!

It's so darn sad they screwed these "little" things up so much - in - at the end of the day -  a resonably fast and rigid machine which must say the okuma is. It's just sad. But when working on a daily basis these "little" things just make you go mad.... aaahhhhh!!!

Anyway - sorry for the sorrow words but I just had to say it

However I will still try the ".sub" method in free time (if it's possible at all). Anyway when I come up with something will let you all know.

Take care Folks :-)

[YoDoug®]

4 hours ago, Maclaw said:

 

But unfortunately when I use scheduled progs the machine doesnt display the program flow... And this is an issue in my company. It's against our internal safety procedures - how can an operator run a program "in blind"??? This is some kind of absurd....!!

When you are in a schedule program there is a soft key that allows you to toggle between display of running program, schedule program, or sub program. You don't have to run blind. 

[mkd]

my old 7000 will scroll through all the scheduled programs. It's pretty slick.

[Mr. M]

14 hours ago, Maclaw said:

Thanks Mr. M,

But unfortunately when I use scheduled progs the machine doesnt display the program flow... And this is an issue in my company. It's against our internal safety procedures - how can an operator run a program "in blind"??? This is some kind of absurd....!! Anyway - thanks very much for your interest in this subject Mr. M. I guess for now I will go with the ".ssb" method from the root of MD1, as Brad described above - already backed up all files from that directory in case I or someone else deletes anything important from there. Thanks again Brad for your post.

 

It's amazing how this machine is "safe". You cant even use an edgefinder at 400 RPM with the doors open (max RPM=50).... But when you run a scheduled prog it wants you to do it "blind" - aint that clever Folks? BRAVO!!! :-) The Guy who came up with this clever idea should go to Swedem for a Noble "anti-common sense" prize! I mean - dont these darn MTBs  listen to the machinists anymore these days??? Why?. Good thing I also have HAAS machines which are made for machinists and can be operated in a normal manner still maintaining RESONABLE safety issues. They say Haas this, Haas that, but.... oohh man... to move axes (while spindle is stopped) in this Okuma, it would be good to have 4 hands and a checklist procedure like airline pilots - so many buttons and key switches you must press to achieve this. Going this way, in a few years you wont be able to touch this machine while working on it... This is crazy!!!

It's so darn sad they screwed these "little" things up so much - in - at the end of the day -  a resonably fast and rigid machine which must say the okuma is. It's just sad. But when working on a daily basis these "little" things just make you go mad.... aaahhhhh!!!

Anyway - sorry for the sorrow words but I just had to say it

However I will still try the ".sub" method in free time (if it's possible at all). Anyway when I come up with something will let you all know.

Take care Folks :-)

What machine and control do you have? As Doug says, it is just a softkey to switch. I've used schedule programs on multiple generations of Okuma controls and never had to do it blind.

[Brad Lisle]

Sorry for the long hiatus and the late reply. As YoDoug and Mr. M summed it up, it sounds like for what you are trying to do a schedule program would suit your needs the best. Unlike your Haas, Okuma was smart enough to not make you turn main programs into sub programs just to run multiple files/parts. You can change the display to show the program running fairly easily, I'm sure your frustration is simply due to the lack of training, I assure you the control is far superior and capable than a Haas or even a Fanuc for that matter. What control do you have and we might be able to help a little further.