RobotStudio event

Call a RAPID function using FPSDK

Options
Hello,

I would like to know if it's possible to call directly a RAPID function using FPSDK.

I need to call the DefAccFrame RAPID function and what I do today : I have a system module with a PROC routine which calls DefAccFrame function. In the module, I declare some LOCAL VAR that I use for the arguments and the result of DefAccFrame.
To call the PROC routine, I use the method CallServiceRoutine of the Task Class, but for this, I need to press the Enabling device of the FlexPendant, what I want to prevent (I don't have motion in my PROC).
And also, I would like to prevent from declaring LOCAL VAR for arguments and result.

Is there a solution?

Thank you!

Herv?.


Comments

  • RussD
    Options

    If the program is stopped, you can move the program pointer to a different routine, but this might be a lot of work to implement.

    An alternative might be to call it from a TRAP routine connected to a signal, then use your FPSDK app to allow the user to toggle the I/O signal.

    RussD2008-7-28 22:21:56
    Russell Drown
  • carlosmtz2000
    Options

    Hi Herve,

    If the robot is in manual, you must have the enabling device. Can you have this code in a background task?

     

    Carlos Martinez
    ABB
  • Herve
    Options
    Hello RussD and carlosmtz2000,



    [QUOTE=RussD]

    If the program is stopped, you can move the program
    pointer to a different routine, but this might be a lot of work to
    implement.

    [/QUOTE]

    Effectively, the program of the motion task is stopped. I allready tried to move the program pointer and restore it after, but I am in manual mode and I need to press the enabling device. So it's not very smart.

    [QUOTE=RussD]

    An alternative might be to call it from a TRAP routine connected to
    a signal, then use your FPSDK app to allow the user to toggle the I/O
    signal.

    [/QUOTE]

    I think I'm going to use a TRAP routine, but connected to a PERS variable (using IPers), and I will put it in our background task. But we already have a lot of interrupts due to our process and I would have preferred not to add another one. So I think, I will use START/RESTART/STOP/QTOP events to activate/disactivate my new interrupt when I need.

    Thanks,
    Herv?.