RMQ/IPC and Multimove?

DanS

Hello,

 

I have a multimove controller with three tasks:  Hearbeat, T_ROB1, T_ROB2.

 

Heartbeat,  RMQ Type=Remote, RMQ Mode=Synchronous (Queue name RMQ_Heartbeat)

T_ROB1,      RMQ Type=Remote, RMQ Mode=Interrupt (Queue name RMQ_T_ROB1)

T_ROB2,      RMQ Type=Remote, RMQ Mode=Interrupt (Queue name RMQ_T_ROB2)

 

I am trying to send messages from a PC app to the Heartbeat queue, but I am having difficulty.  When sending to RMQ_Heartbeat, T_ROB1 seems to get the messages:  "RMQ_T_ROB1 received a RMQ message that couldn't be handled".  As soon as I turn off the RMQ in T_ROB1 and T_ROB2 (RMQ Type=None) the messages get through to the Heartbeat task.

 

Has anyone else seen this?

 

Thanks,

Dan

DanS

I also tried turning off just T_ROB1.   I get the same "Message discarded" error, but now the messages meant for RMQ_Heartbeat are being received by RMQ_T_ROB2.

RussD

There seems to be a problem with having more than 5 total message queues configured between the robot and client application. Can anybody confirm that this is a known limit, i cannot find it documented anywhere.

Laro88

Are you by any chance filling your queue? I have had some problems with too much IO going on.
My experience is that on the PC side you need to be quick to process the messages.

I think I initially was running with 4 inbound and 4 outbound queues, but the software on the PC side started to look ugly so I have reduces it to the T_ROB1 (in and out queue) and a "heartbeat" queue which is handling all the background IO ( heartbeat, external mech. hw. through DeviceNET io etc.)

Laro882010-02-23 10:12:10

carlosmtz2000

Hi Dan ... a chance to have a backup and a short program test?

 

Thanks

DanS

I ended up heading in a different direction.  I removed the heartbeat task and am now using RMQ-interupt style messages to traps on the robot side to send down the PC queue identifiers.  I am running into a strange problem where the PC app hangs with little indication of what went wrong.

 

The ChangeListeningState thread is started:

 

_listenerThread = new Thread(new ThreadStart(_mq.ChangeListeningState));

_listenerThread.Start();

 

This little guy runs and the line shown in red trys to receive a message place on robot 1's pc queue by robot 1:

 

public void ChangeListeningState()

{

  //this is the listener thread that processes incoming requests from the robot

  //it just runs until the user presses the "Stop Listening" button

  IpcReturnType ret;

  string msg = string.Empty;

  string response = string.Empty;

  int timeout = 5000;

  while (true)

  {

  IpcMessage dataReceiveMessage = new IpcMessage();

  //Check for msg in the PC data queue

  ret = _pcDataQueue.Receive(timeout, dataReceiveMessage);

  Thread.Sleep(100);

  dataReceiveMessage = null;

  }

}

 

If I comment out this line (shown in red) it's just a thread that does nothing and the application doesn't like to hang. If I keep this line in it still refuses to hang, UNTIL I send a message (or several messages) from the robot.

 

On occasion I get an debugger error directly after attempting to send a message from the robot: "'System.ExecutionEngineException' occurred in Unknown Module."  I'm running Windows 7 64-bit...if that makes a difference.

 

Any ideas?

 

 

 

DanS2010-02-27 23:30:12

carlosmtz2000

Hi,

 

Could you try this code? This contains some exception handle to understans what it coudl be the problem.

 

Besides this, do you have the simple RAPID code?... Thanks

 

private static void ServerStart()<?: prefix = o ns = "urn:schemas-microsoft-com:office:office" />

{

    IpcMessage message;

    IpcReturnType ret;

    UTF8Encoding bdata = new UTF8Encoding();

    int timeOut = 50;

 

    try

    {

while (_ipcLocal != null)

{

    message = new IpcMessage(Ipc.MaxMessageSize);

 

    ret = _ipcLocal.Receive(timeOut, message);

 

    if (ret == IpcReturnType.OK)

    {

//convert msg data to string   

string data = bdata.GetString(message.Data, 0, message.Size);

 

    }  

}

    }

    catch (ThreadAbortException)

    {

// expected exception when disposing the last client

    }

    catch (Exception e)

    {

MessageBox.Show(e.ToString());

    }

}

 

 

 

 

 

DanS

I will do as you suggest...in the meantime here is the trap I've been running on the robot side to test the pc app.  DataQueueGUID is sent down in another trap when the PC app connected.

 

Thank you for the help!

 

Dan

 

 

RAPID code:

TRAP RMQ_Debug1
   ErrWriteW, "RMQ_Debug1", "";
   RMQFindSlot pcClient, DataQueueGUID;
   RMQSendMessage pcClient, Rec;
ENDTRAP

 

DanS

Carlos,

 

I've tried the code that you posted.  If I have the line:
string data = bdata.GetString(message.Data, 0, message.Size);

I get the exception:

A first chance exception of type 'System.ArgumentOutOfRangeException' occurred in mscorlib.dll
Index and count must refer to a location within the buffer.

 

I would guess this code should work the same between our two machines...could there be any diffferences with the way I'm initializing the IpcQueue(?):

_pcDataQueue = this._ctrl.Ipc.CreateQueue(guidString, 100, Ipc.IPC_MAXMSGSIZE);
If I remove this line I get the same behavior as before (App will hang without throwing any exceptions).

carlosmtz2000

The good news is that you are getting a message, but something it is wrong. I have not tested Windows7.

 

Try these parameters:  _ipcObj.CreateQueue("MyName", 8, Ipc.MaxMessageSize);

 

- A shorter name for the Queue

- A smaller capacity of the queue.

 

Do you have a more complete RAPID module to test?

 

Thanks ...

DanS

FYI...I did just test on Windows XP 32bit system with same issue.

DanS

Well Carlos,

 

I was able to get things working by starting fresh with a console application.  I am still unsure why the form application was not able to work, but don't spending any more time chasing anything on my behalf.

 

Thank you much,

Dan

DanS

Has anyone seen any issues connecting to two VCs with RMQ (both on the same computer) from a single PC application?

Niklas Skoglund

Hi,

 

the Send and Recieve methods of IPCQueue shall be called from an MTA thread.

This has been documented in the PC SDK 5.13 release.

 

When trying this myself I had problems to recieve messages when I simply called receieve from the GUI thread. When I created a new Thread and set apartment state to MTA, it worked fine.

 

Use Thread.SetApartmentState to set it to MTA before starting the thread execution.

 

I hope this can help you.