Logic question and Tool Change subprogram

    I have a KRC2 ed05 with an ATC spindle, and I use Pointloader to run large programs.

    My end goal is to write a functional tool change so each program will have the robot get a tool, run the toolpath, then return the tool and go to home position.

    Pointloader can run a subprogram like "ChangeTool(a,b)", so I think I'll just write two subs; one to get a tool, one to return it.

    The groundwork question: Why is it common to run a subprogram to turn an I/O on or off?

    (e.g. SpindleOff to turn off a digital I/O, instead of $OUT123=FALSE)

    Is it just cleaner theory or does it work with interrupts better or something?

    I followed another thread to stop my spindle if $PRO_ACT goes false in SPS, maybe the subprogram method will let me restart the program (and spindle) if I need to stop it. At the moment, I'm forced to restart the toolpath from the beginning.

    I appreciate any insight!

  • Go to Best Answer
    Quote from kbekkala

    My end goal is to write a functional tool change so each program will have the robot get a tool, run the toolpath, then return the tool and go to home position.

    it would be better in terms of cycle time if tool is not returned until different tool is requested.

    Quote from kbekkala

    The groundwork question: Why is it common to run a subprogram to turn an I/O on or off?

    (e.g. SpindleOff to turn off a digital I/O, instead of $OUT123=FALSE)

    Is it just cleaner theory or does it work with interrupts better or something?

    it is plausible that SpiddleOff is a signal (digital I/O). and $OUT123 could be a signal too but i suppose you meant to write $OUT[123].

    there is no performance difference but using signals has significant benefits:

    programs are more readable. Can you guess the function of $OUT[1837] on someone elses robot?

    can be easily adapted to different IO range when needed to work around other code (usually existing and not portable)

    in case of an IO failure, one can easily remap SpiddleOff from wrong or busted $OUT[123] to another one (assuming there is a free and functional output available ... anywhere). this means change in ONE place rather than tedious scanning of potentially dozens or maybe hundreds of files and making change in each in every place. clearly, simply remapping a signal in one place is sooo much faster and safer. one can move one wire, change one signal and be up and running in one minute. compare that with finding many places where the output is uses. and it is not just places where output value is set. in my experience most people get into trouble when trying to modify complex expressions or one of many changes may become bad due to a typo. if you ever had to change something in 80 places and things are no longer good, how long will it take to recheck all the places, open/close every fold etc.?

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

    To add to what panic mode wrote, having a function for performing some IO is nice because sometimes the system changes and now instead of just setting some output, you also have to check some inputs every time the output is set. E.g. when moving a cylinder, check if/wait until it reaches end. Or maybe just add some wait time. It's a very simple change if you have that as a function.

    • Best Answer

    A subprogram is more modular, and can be modified or swapped without altering the path program. For your spindle, maybe you want your SpindleStart() subprogram to:

    1. Check the spindle state
    2. set the RPM output to the spindle
    3. Turn on the spindle-start output
    4. wait for the spindle to reach RPM
    5. perform error checking, user messages, retry functions if the wait takes too long

    A simple little subprogram like that can easily go to 100 lines of code, if you start adding messages, error handling, "smart" options like automatically branching bases on which type of gripper is mounted, etc.

    If you have lots of large path programs, and make a change to your tool, you can just make changes to the StartSpindle() and StopSpindle() subprograms, and not need to re-generate all your complex path programs with new I/O.

    It also saves memory. Even for a tool with just an on/off command, using a subprogram can save you a few lines of code at every start/stop event in the path program. If your multi-thousand-point path program has a hundred start/stop events, then a small subprogram can save you a few hundred lines of code. And with very large CNC-type programs, reducing line count can be important to avoid hitting the memory limits of the robot.

    In your specific case, you want to stop the spindle when the program stops, but also want to resume. So instead of just setting $OUT[whatever] True in your program, create a Global Boolean, bSpindleState, and control that from your path program (or your start/stop subprogram). Then, in the SPS, $OUT[whatever] = bSpindleState AND $PRO_ACT will turn the spindle off when the robot stops, and back on when the robot starts running again.

    Of course, giving the signal an actual name, like SIGNAL O_SpindleRun $OUT[whatever] and using O_SpindleRun instead of the $OUT is always better.

    Or, you could get fancier and use Interrupts. The way the robot's built-in templates use IR_STOPM is a good example. In fact, KUKA tech packages that have stop/recover functionality use IR_STOPM to shut the tool off when the program is interrupted, and perform recovery. You might, say, create a SpindleStart() subprogram that turns on the output, but also waits for the spindle to achieve RPM before continuing. SpindleStart() could be called from your path program, but also from the recovery section of IR_STOPM. Of course, your SpindleStop() subprogram would need to be called from the "stop" section of IR_STOPM.

    Great feedback, thank you guys. I'll aim for the subprogram method.

    The reason for loading/unloading tools was that I'm not sure about editing a global variable for the "current tool number". I thought the PointLoader plugin can't use/edit global variables, but looking again it states

    "No local or global subprograms may be defined in the CAD/CAM file."

    and OrangeApps support said I could call any subprogram if it's already saved in the R1 folder, so I'd expect a similar thing with global variables.

    I love this code, Skyfire: in the SPS, $OUT[whatever] = bSpindleState AND $PRO_ACT, thanks for the tip!

    I'm not the cleanest or fastest coder but I'll try to update this thread with my sub soon.

    I have a tool change that is close, but doesn't recognize a global variable how I want it to. If anybody can take a look I'd appreciate it.

    Basically, my CAM program calls SetTool(1) to fetch Tool #1.

    It checks what tool it currently has, a global INT CurrentTool.

    If CurrentTool is different than called, here it returns Tool X and fetches Tool 1.

    Lastly, CurrentTool =fetched tool.

    the problem is that the INT CurrentTool is not being updated via the subprogram. I set it to 2, ran a test program that called SetTool(1), but it skipped the Tool 2 return (the CurrentTool switch) and went straight to fetching Tool 1.

    Apologies for all the Folds, I don't know how to collapse them.

    Quote from kbekkala

    CurrentTool is defined in the user section of config.dat to make it global, hopefully that was the right place for it?

    I don't need to declare it locally for it to activate, do i?

    No, that should be fine.

    Your ENDIF should be all the way at the bottom. Otherwise, the program will try to run the Pick motion for the tool it already has.

    If you single-step, it skips over the IF/ENDIF? Odd. I would create a new Global INT for testing, and have NewVariable=GetTool at the top of SetTool(). That way, you can use the VarCor to check the value of GetTool and CurrentTool as you single-step through the program.

    Got it now, I wasn't actually updating the CurrentTool value in the variable monitor.

    Thanks for the tip Skyefire, I moved the Endif to the end and it appears to be functioning correctly (with some position corrections as well).

    Is it good practice to set the ANOUT (spindle rpm) and $TOOL=TOOL_DATA[n] inside this SetTool( ) subprogram as well?

    Quote from kbekkala

    Is it good practice to set the ANOUT (spindle rpm) and $TOOL=TOOL_DATA[n] inside this SetTool( ) subprogram as well?

    The former, maybe not, the latter, yes.

    For $TOOL, keep in mind that any any Inline Form programmed point (like those you have in SetTool() ) automatically rewrite $TOOL (and $BASE, and $ACT_TOOL and $ACT_BASE) to whatever is set in the ILF menus. IIRC, your CNC programs are all "raw" KRL, without any ILFs, so if you set $TOOL at the end of SetTool(), it should be fine. Just keep in mind that any ILF move command will rewrite $TOOL, so if you have, for example, a ILF-programmed "move to maintenance" position, $TOOL will be wrong unless you directly re-write it.

    The ANOUT... mmm. I suppose if you control the spindle On/Off outputs inside the CNC program, that might work. But if you want to change speeds during the CNC program, then setting ANOUT at the end of SetTool() is probably pointless. I've also encountered certain motor controllers that didn't like getting speed values until after the Start signal was sent (usually ones that needed a careful ramp-up from 0RPM), but it doesn't sound like you have that problem.

    That makes sense for the $TOOL setting, you're correct that my code is raw KRL, and we only machine the one material on this robot (nice not to have to worry about changing RPM!). I just want to build some kind of guarantee that CurrentTool will match $TOOL. Maybe another SWITCH at the very end, where each case just assigns $TOOL.

    I haven't been able to get ANOUT to set correctly yet (I think there's a factor somewhere in there), so that program's on pause right now. My VFD just takes a 0-10v signal as a percent of its max speed, and a separate RUN signal.. The problem I want to avoid there is that I have 3 tools, T1 can only spin *at maximum* ANOUT=3.0, the others spin at ANOUT=4.0.

    Hm. How is your ANOUT configured in IOSYS.INI, and how are you trying to set it from the program?

    Analog-output modules come in different resolutions (8bit, 12bit, 14bit, so on). When mapping one in IOSYS.INI, it's possible to map it to the KUKA $ANOUT, or to a digital "word" or "group output." I tend to prefer the digital method, personally. With digital mapping, you have direct raw control at the bit level. The $ANOUT adds a layer of abstraction. $ANOUTs can only be set from 0.0 to 1.0 (think 0% to 100%), or a bipolar module can support -1.0 to +1.0. If the IOSYS mapping is correct, setting $ANOUT to 0.1 on a module with maximum 10V output will cause a physical 1V, 0.5=5V, and so on.

    At the digital level, an 8-bit module that ranges 0-10V (no negative voltage) would have 255 ('B11111111') =10V, 127=5V, and so on. For modules with higher bit resolutions, those values obviously change. But setting $ANOUT to 0.5 should generate a digital value of 127 (or close, there's some rounding error) out to the module.

    One advantage to the digital mapping is that you can plug a voltmeter into the analog output, and test what each bit does (00000001, 00000010, and so on). Each single-bit change should double the output voltage. For multi-byte modules, if you see a huge voltage change when you jump from the highest bit of the low byte to the first bit of the high byte (say, from 255 to 512), you may have the two bytes "swapped" -- there's an option for that in the IOSYS Analog settings, or you can swap the two bytes in IOSYS for digital mapping.

    Here's the IOSYS line:

    [DEVNET]

    ; This is where I/O at DeviceNet is assigned.

    ;

    ;INB1=13,0,x1 ; $IN[9-16] (1 byte = 8 bits)

    ANOUT1=13,0,16,3 ; $ANALOG OUT [1-2]

    OUTB26=13,4,x1 ; $OUT[209-216]

    I was attempting to set a global variable, something like

    SIGNAL SpindleRPM $ANOUT[1]  

    and the SetTool() program would also cover the spindle speed.

    I don't think I tried setting the variable to less than 1, and that would make sense why it's always at the maximum. Thats got to be a big slice of my problem, anyway.

    Edit: Got it, it was just the X10 factor that was fooling me!

    Edited once, last by kbekkala (December 26, 2022 at 8:03 PM).

    with analog signals it is a bit different... one still has to use ANOUT On and ANOUT OFF commands.

    for example in $CONFIG.DAT

    Code
    DECL REAL SpindleRPM = 0.0
SIGNAL aoSpindleRPM $ANOUT[1]

    then in your program add something like

    Code
    ANOUT ON aoSpindleRPM = 1.0*SpindleRPM -0.1 DELAY 0.5
;....
ANOUT OFF  aoSpindleRPM 

    note that ANOUT ON expects the factors in that format. You can change the factor values and omit optional parameters but you cannot omit the asterisk even if the scale factor is 1.0 because that is part of the syntax.

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

Advertising from our partners