Best way to trigger industrial camera in exact positions while robot movement?

    I have robot with camera attached to robot endeffector. Camera can accept 24v external triggers to grab images. Cameras line input is connected one of the terminals of Beckhoff EL2809 module, this output is linked to robot output signal. A task requires robot to move from point to point with LIN movement (~3210mm long path) triggering camera output every 30mm. During program robot makes 3 movements by 3210 mm so total impulse count must be 321. Triggering logic is located in sps.sub and works in a following way:

    Code
    LOOP
X_CURRENT = $POS_ACT_MES.X
IF SCAN THEN
    CHECK_X = Start_Pos.X + (Scan_Index*Scan_Offset);scan offset=30
    IF (X_CURRENT >= CHECK_X)THEN
        PULSE (TAKE_PHOTO, TRUE, 0.005)
        Scan_Index = Scan_Index + 1
    ENDIF
ENDIF
ENDLOOP

    Everything works perfectly until robot's speed is set to higher then 1m/s. The higher is speed the more triggers are missed (interesting effect - at 1.9m/s robot generated less impulses then at 2m/s):

    Robot speed0.30.50.70.911.11.31.51.71.92
    Impulses received3213213213213213062231601268793
    Required impulse frequency Hz (calculated)1016.623.33033.336.643.35056.663.366.6


    1) What can be a cause for this effect? SPS.sub cycle time? EL2809 D-Ouput module operation speed (datasheet states that module switching time: typ. TON: 60 µs, typ. TOFF: 300 µs)?

    2) Are there better way to do the task without adding additional software packages to kuka?
    3) What additional package can help to overcome the "speed" problem? KUKA RSI may be?

    Edited once, last by Daniil1994 (October 14, 2021 at 10:06 AM).

    The robot runs on a 12ms internal clock cycle with scheduled multitasking. This comes out to a frequency of about 83Hz. One side effect of this is that you probably can't fire a pulse with a duration less than 12ms. Another is that $POS_ACT_MES only updates every 12ms.

    A short SPS loop can repeat multiple times in a single ~2ms "slice" of the 12ms "pie," but for ~10ms out of 12, the SPS is suspended. And since an I/O refresh only happens once every 12ms cycle, once the Pulse command fires, it'll take 12ms before the next I/O refresh that can shut the signal back off.

    Going by those numbers, it would seem that you should still have headroom up to ~41Hz (remember, you need at least one refresh cycle of signal-off time between signal-on times), but 36Hz is close enough that I'm not too surprised -- there's probably some subtleties that are eating up some more of the cycle.

    RSI might help, if you used IPO_FAST mode (4ms cycle). I've never tried pulsing outputs that fast with RSI, though.

    Another approach might be to try Interrupts, instead of the SPS. That would be trickier to code, but Interrupts are supposed to be hardware-level interrupts that act with microsecond response times, IIRC.

    Yet another idea: Create your program with points 30mm apart, and put a TRIGGER on each point to pulse the output. Or, what might work better: if you can get your camera to trigger on both rising and falling edges, just have the Trigger invert the output, instead of trying to rely on a PULSE time between two points.

Advertising from our partners