Interrupt

    For manuals, check the Manuals&Software sub-forum.


    As to Interrupts, they are a means of forcing an event to execute when a certain trigger condition occurs, regardless of what else the robot might be doing at the time.
    This can have many uses. One of the most common uses is for search motions. For example, in some MIG-welding applications, the parts are not always put in front of the robot the same way every time. Using Interrupts, a motion can be programmed where the robot starts in a safe location and moves along a path where the welding wire tip should hit the edge of the part. When this contact occurs, the Interrupt fires and calls a sub-program that halts the robot's motion (in order to avoid collision), and records the location in space where the contact occurred. This position is then used to shift the welding path to match the location of the part.

    Search path application example with touch sense probe:


    REAL POS_ACTX in $config.dat



    DEF SEARCH_MAIN ( )
    INTERRUPT DECL 18 WHEN $IN[TOUCHPROBE_IN]==TRUE DO SUB () ;declare interrupt


    $ADVANCE=0 ;Disable advanced pointer


    INTERRUPT ON 18 ;interrupt enable


    searchmotion ( ) ;search path routine


    PTP BACK V%100 CONT ; backward path command when triggered interrupt



    END



    DEF SEARCH_MOTION ( )


    LIN 0.5 CONT ;search path linear or point to point


    HALT ; if path reached end position (e.g input not triggered) program stopped.
    END




    DEF SUB ( )


    INTERRUPT OFF ; disable interrupt
    POS_ACTX=$POS_ACT.X ; POS_ACTX value equalizing active position x value. May be use shifting base data. (POS_ACT.X change to BASE_DATA[1].X)
    BRAKE F ; Brake command
    WAIT 0.0 SEC
    RESUME ; Resume program


    END



    LIN motion executing in searchmotion ( ), INTERRUPT request listening. This cause INTERRUPT ON 18 command. When triggered interrupt with touchprobe_in=TRUE, LIN motion stopped and pointer going to SUB ( ) routine, POS_ACTX variable equalize with active position X value.


    This application maybe use palletizing or gripping metal sheet stack.

    Also you can use INTERRUPT for next cycle. If you have 2 or more station, this method will be useful


    example : robot is working on first table and the worker send signal for second table is ready. If you don't have plc or other equipment you can understand the second table is ready with interrupt method and after finish the job on first table, robot will go to other table.



    GLOBAL INTERRUPT DECL 10 WHEN $IN[1] == TRUE DO NEXTCYCLE1()
    GLOBAL INTERRUPT DECL 11 WHEN $IN[2] == TRUE DO NEXTCYCLE2()


    LOOP


    IF CYCLETABLE1 == TRUE THEN
    INTERRUPT OFF 10; if operator send signal again robot will not go to same table again, for safety
    INTERRUPT ON 11
    table1()
    ENDIF


    IF CYCLETABLE2 == TRUE THEN
    INTERRUPT OFF 11
    INTERRUPT ON 10
    table2()
    ENDIF


    ENDLOOP




    DEF NEXTCYCLE1()


    CYCLETABLE1 = TRUE


    END


    DEF NEXTCYCLE2()


    CYCLETABLE2 = TRUE


    END

    All things are difficult before they are easy. <br />Thomas Fuller


    www.hitegro.com

    This is a very helpful example so I thought I would dig it back up. I am attempting to do something similar, but my sensor is analog. I do have RSI, but lets not go there quite yet(unless you think it is really beneficial...it is new to me so I haven't touched it). So I am wondering how to trigger an interrupt with an analog signal. One thing that comes to mind is a submit routine that determines when the signal exceeds a threshold. But that already starts to sound like something better done with RSI. I am wondering if there is another way; for example, I have seen a post whereby using the fast measurement inputs you can store the $pos_int value with very high accuracy, much faster than even the 4ms RSI in fast mode(the manual says 250us). I can always slow down, so this isn't critical, but the submit update is probably much worse than 4ms, so I would lean to RSI in that case. So much of the RSI manual is on path correction, and nothing about interrupts. But I am assuming it is fairly easy to trigger an input(and therefore an interrpt) via an RSI object.


    Thoughts?



    RSI is really for doing constant realtime motion control with sensor inputs. So if you wanted you robot to decelerate smoothly with the analog output of your sensor until it reached 0 speed at exactly the right distance, you would want to use RSI. But if all you need is a simple interrupt-style stop, RSI isn't necessary.


    Probably the simplest way is to use a CYCFLAG. I'm pretty sure you can put a "variable>value" check into a CYCFLAG. If that works, you can use the CYCFLAG as the trigger of the interrupt.


    SPS cycle depends on the length of the SPS program and how cleanly its coded. You can test for this using a $TIMER in the SPS and logging how long it takes an SPS loop to execute. A short SPS can loop dozens of times in less than 4ms. A long SPS loop might require multiple 4ms machine cycles to execute one full loop.

    thanks, I will try that....agreed I will probably switch to rsi longtime(paid for it, might as well use it!). Didn't know about using the cyclical flags that way, and that is a good point about sps as well...this would be a fairly simple program so probably pretty fast. In the way I am using the sensor, it will be a step function, jumping past a threshold. So I am not sure a guided motion would work quite like that....so for now I will try the interrupt. Of course, RSI is amazingly flexible, so I am sure I can set it to trigger an input(therefore interrupt) based on a threshold as well, as opposed to using a poscorr module. The new rsivisual(though I have only opened it) looks really nice...

    Actually, I noticed while looking through the krl reference that the "event" for and interrupt can be a comparison and/or a logic statement. So I may not need a cyc flag afterall. But is there an advantage I am not aware of? I have never needed to declare a cyclical flag or use one, and tbh I am having trouble finding a manual that explains the syntax for declaring them. Regardless I assume I have to use the ANIN ON command to turn on cyclic monitoring of the input before declaring the interrupt. This may be the primary source of latency as well as it states this is only read every 12ms. Ultimately that may be fine, it just sounds slow considering using a discrete input in combination with the fast measurement inputs offers much lower delay(on paper at least).

    12ms? On a KRC4? My understanding was that the KRC4 did everything on a 4ms cycle now -- 12ms was the internal cycle for the KRC2s.


    I could have sworn that interrupts couldn't use logical statements in their declarations -- that's why I started using CYCFLAGs in the first place. Maybe it's a new KSS 8.x thing? Have to look into that.


    ANIN ON is not necessary to monitor an analog input. Er... well, it shouldn't be. My experience in this area is all in KRC2s -- as long as you had the signal configured properly in IOSYS, it was always available. Or, you could simply declare the fieldbus inputs that the analog input is transmitted over as a standard SIGNAL declaration and treat is as an unsigned INT value. This "digilog" approach often works better for me.

    all good points, the issue is I have the kss8.1 manual, and the krl reference from 5.5. If anyone has an updated KRL reference, that would be great. In the KSS 8.1 manual though, it still says 12 ms cyclical reading; could of course be a typo, I have found them before. I will test this today on the controller and see what it says(at least for syntax errors)

    That would be good to know. It's possible that not every element of the system is updating faster. But I was told that the KRC4 would be able to use RSI more effectively than the KRC2 b/c the system would refresh 3x faster, and RSI (when not using XML over ethernet) uses the same I/O as the rest of the robot.

    Just to clear it up. KRC4 still has an interpolation cycle time of 12ms. But there is a new interface called "Fast Sensor Interface" running at 4ms allowing the sensors to run and apply corrections at a faster interval. If this fast mode is already supported by RSI I do not know for sure.


    Fubini

    Is that the same as the fast measurement inputs? I know RSI has the fast mode.. currently I am still trying to do this without RSI, if only to compare once I do it with RSI. I managed to clear up all my syntax last night, took a while. Apparently to use comparisons in an interrupt declaration they MUST be declared in dat files, not in the src header. Cyclical flags were no good, as they have to be digital, not analog(that is to say, you can't set a cyclical flag equal to a comparison involving an analog, or runtime signal. bummer.)


    I don't actually have the sensor installed, so I can't report on how well it works yet.

    Ah, yes, the "Runtime data" error. Interrupts only want to use non-volatile variables, which makes sense, given how they can carry across modules.


    The $CYCFLAG wouldn't perform an analog comparison? That's... Hm. I've checked my archives, and I have working code that performs numerical comparisons in CYCFLAGs, like:

    Code
    $CYCFLAG[1] = (InputWord > 5)

    for example. I don't have any examples with $ANIN, but I do with other REAL and INT system variables. And any $ANIN should just be another REAL variable (limited between -1.0 and +1.0) as far as the system is concerned.

Advertising from our partners