RobotStudio event

IPC, threading

Laro88
Laro88 ✭
in Developer Tools

I Have IPC running on a VC in two tasks ( T_ROB1and TGovernor )

On the PC Side i run a separate thread pr. VC Task to handle IPC comm. However the PC program behaves wierd, crashes randomly, uses all cpu etc.

Is there any special precautions needed when communicating using IPC in a multi threaded setup? I have problems pinpointing the problem further, and the doc. is not specific on multithreading.

Are there any "in depth" material / documentation available on the IPC ( Messaging ) subsystem.

Kind regards
Laro882010-01-07 08:55:38

Comments

  • Laro88
    Laro88 ✭
    After a warm start the RAPID program behaves fine after the first run, but then the IPC messaging stops working. T_ROB1 claims to send the messages but nothing is received on the PC.

    My guess is that either the VC is broken or the PC API is broken.

    When my PC app starts up it scans for existing IPC Queues, finds the 4 queues from before. None of these can be deleted ( have tried ) so the program connects to them, and there are no errors reported.

    However, the Queues are dead silent after the first run.

    It feels like a connection maintenance problem in either the VC or the PC dlls.

    Does anyone have a detailed spec for the IPC messaging sw and a "debugging" guideline? I am asking since I might be breaking some "rule" in my code.

    Kind regards



  • frpa
    frpa ✭
    I have moved this thread to the RAB forum... BR frpa
  • Laro88
    Laro88 ✭
    The problem is that it is not possible to reconnect to the outgoing queues.
    The incoming queue on the controller "RMQ_TROB1" is available to the PC, so a special connection establishment process is necessary.
    Here are the basic steps that works for me.

    1. PC connect to RAPID incoming queue "RMQ_TROB1"
    2. PC create its incoming queue using a guid as a name "af390-32434-ghjf3 bla bla"    Guid.NewGuid() in C#
    3. PC sends the name of its incoming queue to RAPID using the "RMQ_TROB1" queue
    4. RAPID uses the received name to send mesasges to the PC

    Notes.
    1. Remember teardown
    2. Only ONE pc client unless the RAPID code is written to handle multiple connections
    3. Error handling is necessary, queue full / not ready happens from time to time
    4. Fast but limited, the queue responds well, but do not spam it, the queue seems not to process messages in a constant rate.

    I use it for starting and stopping jobs, progress monitoring, status requests, "alive" polling etc.

    Regards

Categories

In this Discussion