Touch probe (X33) in T1 without programmed motion

    Hi All,


    Controller KRC4, V8.3 B450


    I have a quite specific problem (couldn't find topic with this issue on the forum) regarding touch probe connected to the X33 interface and interrupts. So, what I want to achieve is a calibration feature by moving the robot manually in T1 instead of programming any motion before. The system has to be flexible.
    Basically, the sequence of steps would be like:
    -Define and start interrupt,
    -Move the robot manually in T1 to the point until interrupt is triggered by touch probe,
    -Save joint pos. to the variable,
    -Continue manual movement to another point and repeat sequence.


    My problem is, that if I create my own program, after touching the point with a touch probe, to go inside of the interrupt I have to click play button on the smart pad and I would like to avoid it. Without that, my interrupt function will be never executed. Does anyone ever tried to implement something like this or know how achieve it?

    When you say "move the robot manually in T1," do you mean you are jogging the robot? Or are you running a program? B/c the former presents an extremely difficult scenario.


    You simply can't have an Interrupt unless you're running a program. So if you're jogging the robot, the only program that is active is the SPS.


    You could, perhaps, create a routine in the SPS that would zero out $OV_JOG when the probe made contact, then put up a dialog message on the SP asking for the operator to acknowledge the event, record the point, and "unlock" $OV_JOG. It would be rather hacky, but it might be possible to make it work.

    Quote from SkyeFire


    When you say "move the robot manually in T1," do you mean you are jogging the robot?


    Exactly, I want to trigger interrupt during jogging.


    Quote from SkyeFire


    You could, perhaps, create a routine in the SPS that would zero out $OV_JOG when the probe made contact, then put up a dialog message on the SP asking for the operator to acknowledge the event, record the point, and "unlock" $OV_JOG. It would be rather hacky, but it might be possible to make it work.


    This is kind of solution, the problem is that it will be not triggered by interrupt and timing strictly will depend on the calculations, functions which are running on the SPS.sub. I have a feeling that it will be not precise enough.


    BTW. Is it possible to define and run interrupts in SPS.sub? I've tried but till now I didn't succeed with it.

    Unless your SPS is very complex, it's internal loop time should be much less than the 12ms input-refresh cycle. And proper programming of state machines can do a great deal to control SPS loop time.


    (ah: X33, the Fast Inputs. Okay, that makes a difference. Although enforced slow motion could still compensate).


    Yes, Interrupts can be used in SPS. Your stock SPS includes an example, in fact -- look at Interrupt 91 and how it calls the subroutine RESET_OUT().

    Edited once, last by SkyeFire ().

    Quote from SkyeFire


    Yes, Interrupts can be used in SPS. Your stock SPS includes an example, in fact -- look at Interrupt 91 and how it calls the subroutine RESET_OUT().


    I have a following problem here, when I'm using $MEAS_PULSE[1], the SUBMIT interpreter is not starting due to the "Instruction inadmissible" (Input of active commands (robot motions, program start) is blocked). I tried to trick it with a cyclical flag by doing it in following way (correct me please if I'm wrong here):



    After that, my SUBMIT Interpreter is running properly, but then my $CYCFLAG[1] is not updating their value at all. Am I doing something wrong?

    Quote from mati2007

    I have a following problem here, when I'm using $MEAS_PULSE[1], the SUBMIT interpreter is not starting due to the "Instruction inadmissible" (Input of active commands (robot motions, program start) is blocked). I tried to trick it with a cyclical flag by doing it in following way (correct me please if I'm wrong here):



    After that, my SUBMIT Interpreter is running properly, but then my $CYCFLAG[1] is not updating their value at all. Am I doing something wrong?


    I've figured out that $CYCFLAG[1] = $MEAS_PULSE[1] has to be declared in separate file - this is fine for me. Before calibration process I will simply have to run the program which initialize the process. What is more, I've implemented dialog messages which are asking user for saving the position, also saving the current position as such to the variable works as well. Everything is running on the interrupt declared in sps.sub.


    I have only last (I hope) issue:I cannot stop the robot's jogging movement. When I'm using "$OV_JOG" variable to stop the motion, I'm getting following error: "Variable write-protected in module SPS". Any idea how can I sort it out?

    I'm surprised that the $CYCFLAG assignment had issues in the SPS -- that shouldn't be a problem.


    Motion commands, or commands that would effect motion, cannot be performed from the Level 0 Interpreter (SPS). $OV_PRO is a bit of a "cheat" around this rule, b/c it does not affect the physical path the TCP follows, only the speed. $OV_JOG should be similar, but....


    $OV_JOG is write protected? That's... a problem. I would write a quick test program to see if that limitation also extends to the Level 1 Interpreter. But even if L1 can write to $OV_JOG, that doesn't solve the issue -- anything called from the SPS will be treated as part of the Level 0 Interpreter during runtime.


    Frankly, without accessing $OV_JOG from the SPS, I can't really think of a way to make this work the way you want. The KRC (most robot brands, honestly) simply isn't designed to run programs while being manually jogged -- they're considered two very different operating regimes.


    Is there a reason you can't write a probing program for the operator to run? That would simplify things a great deal.


    $OV_PRO works fine, so it's also surprising for me that $OV_JOG does not. I've checked if the problem exists also in a test program and like you've predicted - it also doesn't work.


    Unfortunately I need it in this way, we have some existing solutions (separate software) where adding this feature would make our lives way easier. The thing is, that we are using let's say 1000 of different parts, completely different with size, position etc. Teaching each time new points would be horrible for user.


    Is there any other way to trick it? Any different hidden commands for stopping the motion? I've checked whole system variables manual 3 times already trying to find anything, but there is nothing what I could use.

    Edited once, last by mati2007 ().

    Could you instead of making jog speed zero, drop the move_enable signal? i am not sure of your set-up. but in theory it could be done. The hard part would be to acknowledge and resume moving.

    Every problem has a solution, that isn't the problem. The problem is the solution.

    Ehhh... there's no way to connect $MOVE_ENABLE directly to a Fast Measurement input. It might be possible to have the $MEAS_PULSE input trigger an Interrupt, that would fire an $OUT that could have a PLC or relay reset $MOVE_ENABLE. But the while the $MEAS_PULSE reaction time is ~125us, and the $OUT should be instantaneous, the time delay on getting the $OUT to an external device, and having that external device open the $MOVE_ENABLE input, would be unknown, but probably something like 20-30ms at minimum.

Advertising from our partners