RMQ problems?

DanS

Hello,

I've tried working with the RMQ/IPC stuff in the past with some success.  In the past I would have to write a random queue name down to the controller to work.  I didn't remember why, until I got back to it.  Below is a rapid procedure that will send messages to a PC.  After an I-start I connect to the controller via my PC application and it receive messages perfectly.  If I stop the PC application and restart it this rapid procedure will no longer send messages.  It appears that the instructions execute without error, but no messages come through on the PC side.

PROC RmqNameTest()

VAR rmqslot slot;

VAR rmqmessage pcMsg;

VAR rmqheader pcHeader;

VAR num pcNum;

VAR string sendData := "test";

RMQEmptyQueue;

RMQFindSlot slot, "PC_Q";

RMQSendMessage slot, sendData;

RMQSendWait slot, sendData, pcMsg, pcNumTimeout:=10;

ENDPROC

The PC code look something like this (I didn't include the listener):

if (!_ctrl.Ipc.Exists("PC_Q"))

{

     _RmqWccQueue = _ctrl.Ipc.CreateQueue("
PC_Q ", 15, Ipc.IPC_MAXMSGSIZE);

}

else

{

     _RmqWccQueue = _ctrl.Ipc.GetQueue("
PC_Q ");

}

...so anytime the GetQueue is called no messages will come through.  Any advice?

John Wiberg

Hi Dan,

 

Have you seen this topic?

 

If that topic doesn't answer your question then I'll see if I can get someone better than me to answer.

DanS

Thanks for the quick response.  I did read this post and wrote an application based on this a long time ago, but I was hoping for a way around having to send a unique queue name every time my RAB application connects.  In a situation where I have multiple RAB applications talking to a single controller it becomes a chore to manage queue names in RAPID.

Any chance this behavior could be made to work?  It seems like the GetQueue() method could be removed from the API since it isn't really of any use in its current state.

Thanks again for the quick response.

DanS

One problem that was mentioned in the other post was about how to clean up all the dead queues that are continually being created by a RAB application.  What is the recommended way of doing this?

Erik Hellström

I had similar problems when using IPC and solved it by doing the following:

1. Check if the queue exists.
2. If it exists - delete the queue.
3. Create a new queue with the same name.

Yes, I know, it's ugly and most likely not the way the IPC system was intented to be used. But it works for me. 

John Wiberg

Asked a colleague about this topic and he sent me this:

[code]                    if (tCurrentCommand == ThreadCommand.Start)
                    {
                        // Start send message to rapid
                        // Kill current read thread until a new queue is created
                        KillReadThread();

                        // Delete current created queue
                        if (m_myQueue != null)
                        {
                            m_controller.Ipc.DeleteQueue(m_myQueue.QueueId);
                            m_myQueue = null;
                        }
                        // Get a new unique queue name
                        string queuename = System.Guid.NewGuid().ToString();
                        m_myQueue = m_controller.Ipc.CreateQueue(queuename, 5, Ipc.IPC_MAXMSGSIZE);

                        // Start the read thread so it reads data from the controller
                        // on the new created queue
                        StartReadThread();

                        // Start send data
                        tCurrentCommand = ThreadCommand.Run;
                    }[/code]

Apparently some old test case they used in the 'olden' days.

 

Don't know enough on the topic to know if that helps?

DanS

Alright so I'll continue using GUIDs everytime I reconnect.

Now...I have a new issue that is terribly intermittent.  I've got a multimove system and suddenly the RMQ will stop working for one of the tasks.  I can't explain why, simply that it is working fine one second and then faults on the next message.  The PC application continues to talk to the other tasks just fine.  Once an error occurs it will consistently fail.

I'm using the RMQSendWait instruction with RMQ configured as interrupt mode (I'm also using a trap to receive things asynchronously).  The waittime is 10 seconds.  The PC application will receive the message correctly, but when it tries to send the response I get a "Operation/request timed out on controller" exception.  This error will persist on all subsequent steps.

Are there any recommendations on how to avoid this?

Thanks

DanS

I think I may have found something....thought I'd pass it along for everyone to see.  The problem described ("No response from controller") occurs when I'm sending messages too frequently.  I'm since added a 200ms delay between message writes to the robot controller and added a lock to prevent different threads from accessing the message queue simultaneously.

Laro88

The RMQ buffer is quite small in the robot controller. I had a similar problem that caused the buffer to fill, and then there was nothing to do except for a hard reset of the controller.