Jump to content
OMRON Forums

POSIX queues


Recommended Posts

Hello all,


I am facing an issue using the POSIX queue libraries (mqueue.h).

My goal is to make the different capp to exchange data with the rtiplc (basically for errors managment).


I have made a simple test today. On one hand, I created a queue in a capp (using mq_open) and send some data in it (mq_send). On the other hand, I openned this very same queue (through the same name) in the rtiplc.c and tried to read the sent messages (mq_receive).


It appeared that the sending process (the capp) filled up the message queue until the mq_maxmsg is reached. Indeed, I observed that the receiving process (the rtiplc) did not receive anything.


In fact, I observed that the two opened queues are DIFFERENT. I made a second test opening two queues with different names in the capp and the rtiplc. The one opened through the rtiplc is seable in the /dev/mqueue Linux file system. The other one is not visible in this interface.


I suppose that there is a wrapper around the POSIX mq_open call in the capp but not in the rtiplc. Is it expected ?!


For information, I have just tried with the SYSTEM V IPC queue library (msgget) and the data exchange is perfectly working. However, I'm wondering if this is the right solution, as I might expect a lot of switches between the primary and secondary modes...


Thank you in advance for replying !

Link to comment
Share on other sites

  • Replies 4
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images



I am not familiar with those function calls, but the usual recommended way of sharing memory between real-time routines (such as RTICPLC) and background C Programs or Script programs is using the shared memory structures:








These can be accessed in C through the "pushm" pointer from gplib.h.

Link to comment
Share on other sites

Hi Charles, thank you for replying.


We have used the pushm for handling the error management so far. However this strategy suffers from many drawbacks that are all corrected by the Linux queue system.


First of all, the shared memory is not synchronised. It happens that a process read a shared memory which is being written by another process. I have made some test showing it and this is very critic !


Furthermore it is complicated to transmit many data. Imagine your different processes write structures inside the shared memory at the same time. How do you manage the data priority and order? What rules will you give to your reader process ? All these questions find answers with Linux queues. Besides, I'm already using them for passing data from capps to other capps.


Now I want to do the same between the capps and the rtiplc but I can't make it work. It seems that the cplc files cannot access the Xenomai API. Is it expected?


Thanks again !

Link to comment
Share on other sites

In order to complete my previous post, I used the System V queue functions in rtiplc.c and could observed the mode switches (see the attachement).


If I activate the functions (msgsend, msgrecv), the mode switch number increase at the rti frequency. If I deactivate them, the increasing stops.


I am kind of stuck... The rti does not have any access to the Xenomai API (preventing the use of the POSIX functions) and the System V functions makes the rti to switch a lot. Thus, I have absolutely no synchronized mechanism to safely exchange between capp and rti processes (do I have ?).


By curiosity, I tested the DeltaTau send() and getsends() functions inside the rti and they did not make it switch. What is their underlying mechanism ? Would it be possible to use it for data exchange between the capp and rti processes ?


Link to comment
Share on other sites

Yes, unfortunately background programs do not have access to kernel-space volatile memory (i.e. Background C Programs vs. RTICPLCs or User Servo/Phase/CaptCompISR).


Would it be possible for you to use semaphores to regulate the reading and writing of user shared memory? Here's a guide for POSIX semaphores:




Please note also that there is a feature involving the Sys.Lock[] structures that are accessible both through C and Script, which provides a semaphore-like data locking feature available throughout all PPMAC programs. See pages 594 - 595 of the PPMAC Software Reference Manual for more details.


I am surprised send() getsends() does not cause a mode switch. If it is working for you, that may be a way to exchange the data between programs, although I personally have not used them for that.

Link to comment
Share on other sites

This topic is now closed to further replies.

  • Create New...