586,036 active members*
3,565 visitors online*
Register for free
Login
IndustryArena Forum > MetalWorking Machines > Okuma > Okuma OSP-100M subprogram call and variables
Results 1 to 4 of 4
  1. #1
    Join Date
    Dec 2013
    Posts
    7

    Okuma OSP-100M subprogram call and variables

    Couple of questions regarding subprograms..
    Let's say i make a program called Main.min. In this program I set a variable.
    Then i call a subprogram. Not a subroutine, as in:
    CALL OSUB1
    [...programming continues...]

    OSUB1
    [...subroutine...]
    RTS
    But a subprogram where i call Sub1.ssb or sub1.sub (What should i use, ssb or sub?).

    -----

    So here are the questions.
    1. I've been doing some trial and error testing with subprograms, as i have noone to teach me. What do i write to call a .ssb or .sub program from the .min? ("Pselect" tested, "call" tested, and only writing the program name tested.)

    2. How is the layout of the subprograms? Is it like subroutines where we end with RTS? How do i jump to a subprog. in the middle of the .min program, then jump back to the same spot in the .min program (Can i define where in the .min i want to return to?)

    3. As i said earlier, a variable was entered in the .min (for example VC1=5), if i then jump to the .ssb/.sub and attempt to alter "VC1" there, will it still see VC1 as 5 in the subprogram?

    -----

    What im trying to achieve here is this:
    In the .min I will always enter 2 variables at the top. (VCPARTS and VCWORK).
    Then i program the machining cycles as usual.
    At the end, instead of either turning the dual-pallet table and end the program, I simply run a subprogram to check if there are still parts remaining to be machined.
    I know i can do this within the .min program quite easily. But just for the fun and training, i want to creat a subprogram for it.

    Example of what i mean:
    VCPARTS=40 (40 parts ordered)
    VCWORK=2 (Number of parts being completed for each machining cycle) (2 parts in the machine.)
    -
    NTOP
    [...program cycle...]
    -
    call (<-?) count.sub
    M30
    Then in the subprogram:

    VCCOUNT=VCCOUNT+VCWORK (VCCOUNT will be manually reset to 0 before running the program)
    IF[VCCOUNT GE VCPARTS]GOTO N2
    M60
    [command that returns to the .min program, but also to NTOP]
    -
    N2
    M60
    [Line that returns to the .min program, and countinues where it left of] (M30)
    Sorry for my very complex way of describing my questions/problems. Im not a native english speaker, nor very familiar with CNC machines (yet).

  2. #2
    Join Date
    Sep 2015
    Posts
    26

    Re: Okuma OSP-100M subprogram call and variables

    I use .ssb because you don't have load it with your program, it will just grab your subprograms. Think of a ssb file as a container eg

    SUB.SSB

    OSUB1
    your code
    RTS

    OSUB2
    your code
    RTS

    You use CALL. It will jump back to the same spot that you left your MIN. Common variables can be read across programs but local variables can't unless you pass it to your subprograms as in "CALL OSUB1 LZI=LZI".
    As far as I know your "IF [VCCOUNT GE VCPARTS] N2 (you don't have to have GOTO, or at least on a 200M and 300M) will have to be in your MIN and you can't have a M30 or M2 in subprograms.
    If you have User Task 3 you can use variable N numbers (GOTO N=VC1) then just have your subprogram set VC1 to "2" or where ever you wanted to go.

  3. #3
    Join Date
    Apr 2006
    Posts
    822

    Re: Okuma OSP-100M subprogram call and variables

    Best way of deciding if your subprogram should be in a .SUB or in a .SSB file is to see if you have a program that is single program use or multi-program use!
    Single program use = .SUB
    Multi-Program use = .SSB

    When I refer to a subprogram as being "Single Program Use" I am referring to a Sub program that will only be used in one program. i.e. it may be a profile shape that is called multiple times.
    This kind of program can also be stored within the same .MIN file as the "main" program.

    A "Multi-Use" subprogram, such as what you are discussing is ideal to be saved into a .SSB file.
    A .SSB file is loaded upon file select, so you do not have to remember to select it along with the .MIN file.

    File format is thus:
    In your main file (the .MIN file) you need this format:

    N1 (COMMENT)
    .
    .
    .
    Program continues...
    .
    .
    .
    N2 CALL OSUB1 <any arguments>
    N3...
    .
    .
    N4 M02 (or M30)

    The above is contained within the file XXXXXX.MIN

    In your file SUBS.SSB you need this format

    COMMENT...
    COMMENT..
    .
    OSUB1
    .
    .YOUR SUBPROGRAM CODE HERE
    .
    RTS
    *
    *
    DESCRIPTION OF SUB2 PROGRAM...
    OSUB2
    .
    .
    .
    RTS
    *
    *
    DESCRIPTION OF SUB3 PROGRAM...
    OSUB3
    .
    .
    .
    RTS

    Note that you can put if comments anywhere you want when they are OUTSIDE of the subprogram code (as you can see the above example.
    I usually separate my subs by a couple of lines using a * character or such.
    Also put in comments describing what the subprogram actually does!

    If you are using a subprogram to describe a profile shape, you can put it in the same file as the Main file thus:
    Start of file
    N1 (PROGRAM STARTS)
    .
    .
    .
    N2 CALL OSUB1
    N3.
    .
    .
    N4 M02
    *
    *
    SUB TO DEFINE PROFILE PATH
    OSUB1
    .
    . PROFILE
    .
    RTS
    End of File

    As stated by rdhoggattjr, when you call a sub program, the program will return to the calling program at the point where it left, and continue on from the next line.
    You cannot define the return point in the calling program, it will return to the line if came from and then continue on from there.
    Your naming convention for "User Defined Variables" is also invalid.
    User defined variables cannot start with the letter "V" as this is reserved for System Variables and you will get an alarm.
    Also from memory, user variables can only be 4 characters long, can contain numbers but must start with a LETTER!
    There are other restrictions such as not using "N" (line numbers!), "O" (Subprogram Names) and others... cannot remember all the exclusions.
    Note that user defined variables only live during program execution.
    i.e. if you set the Order QTY and Run QTY at the start of the program, when the program ends, those variables disappear.
    so if you want to maintain an ongoing QTY machined counter, you need to use a Common Variable to hold the value between program runs.

    I would suggest the following format for your problem.
    Assuming that you are loading new parts through the door of the machine until your Order QTY is completed.
    Filenamed MAIN.MIN
    N1 REQ=40
    N2 WORK=2
    N3.
    .
    .Machining program for required WORK qty...
    .
    N100 CALL OCNT REQ=REQ WORK=WORK
    .
    .
    N200 M02

    File Named Subs.SSB
    SUBPROGRAM USED TO COUNT PARTS MACHINED BEFORE PERFORMING PALLET EXCHANGE
    VC1 USED AS PERMANENT QTY MADE COUNTER
    OCNT
    N1 VC1=VC1+WORK (INCREMENT TOTAL MACHINED COUNTER)
    N2 IF [VC1 GE REQ] GOTO NEND (IF TOTAL QTY MADE IS GREATER THAN OR EQUAL TO REQUIRED QTY THEN JUMP TO RESET CODE)
    N4 GOTO NRTS (JUMP RESET CONDITIONS AS ORDER QTY NOT MET)
    NEND M60 (PALLET CHANGE AS ALL ORDER COMPLETE)
    N6 VC1=0 (RESET TOTAL COUNTER AS ORDER COMPLETE)
    NRTS RTS

    Pretty sure this will do what you want.
    Regards
    Brian.

  4. #4
    Join Date
    Apr 2009
    Posts
    1262

    Re: Okuma OSP-100M subprogram call and variables

    I would use Broby's last example. Common variables such as VC1 will remain even after power off or reset, M02, M30. where Local variables such as VCWORK will be cleared at power off or reset, M02, M30. Your count will thrown off in those cases.

    SSB's will load on power up and be memory resident, so you will want that for shared code between programs. I don't use the SUB that much since you can just put the sub routine after the M02 and keep it in the same file as the .MIN code and avoid having 2 files. (thanks again broby!)

    Another note is that you can use the schedule program to automatically select your program and run it a number of times. This would be an SDF file and would be something like this:

    PSELECT RUN.MIN,,,Q20
    END

    You would then use the schedule program select and it would run 20 times and then stop. It will keep count automatically and will not mess up things like cycle time counters, MacMan, Alarm-C, and tool life counters like a GOTO loop will. Just name the file RUN.SDF and put the aboute 2 lines into it. Then use the Schedule program select rather than the Program select.

    This also gives you the power to run a schedule of programs (thus the name) using something like this:

    PSELECT RUN1.MIN,,,Q20
    PSELECT RUN2.MIN,,,Q5
    PSELECT RUN3.MIN,,,Q12
    END

    It will run 20 of part 1, run 5 of part 2 and then 12 of part 3 with no intervention.

    This is nice when you have memory limitations since it is loading and unloading programs as it runs. This alllows you break programs into sections if your code is large and run them even though program memory may be exceeded.

    Best regards,

Similar Threads

  1. Replies: 7
    Last Post: 01-04-2018, 09:22 PM
  2. external subprogram call
    By Jure_v in forum Fanuc
    Replies: 10
    Last Post: 07-29-2015, 11:31 AM
  3. Okuma MB-56va with OSP-100M controler Help
    By peaceandcalm in forum Okuma
    Replies: 3
    Last Post: 05-16-2015, 10:43 AM
  4. 0TB multiple subprogram call
    By guhl in forum Fanuc
    Replies: 7
    Last Post: 10-29-2011, 09:11 AM
  5. Replies: 7
    Last Post: 06-14-2009, 02:56 PM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •