Jump to content
OMRON Forums

Timings for calls into PCommServer.exe


Recommended Posts

I have inherited a system comprising GeoBrick(6 internal drives)+GeoDrive controlled by a custom PC HMI written in .NET. In a nutshell, the host PC receives packets of data every 1ms, processes the data and sends a position command to the PMAC every 10ms(or thereabouts) via a binary rotary buffer.

In pseudo code the system is essentially doing the following:


If Mode=RUN then

PmacDPRAsciiStrToRotEx(“position commands for 6 motors”)


If Mode=RUN or Mode=IDLE then

PmacGetResponseEx(“Get some P variables and the value of PR”)




I have done some careful timing measurements of the above 2 calls into the PcommServer.exe. (the measurements were made over 1000 iterations) :


PmacGetResponseEx : mean:4.1ms, max:12ms, min:1.9ms


PmacDPRAsciiStrToRotEx : mean:3.5ms, max:9.6ms, min:3.2ms

PmacGetResponseEx : mean:6.7ms, max:10.4ms, min:4.1ms


For this application minimising the latency is important to achieve as near “real time” as possible. To do this the number of packets in the buffer is carefully controlled and kept as small as possible. The system is generally stable but suffers ‘jitter’ in the data rate and buffer underruns occasionally. It seems clear from the timings that the system is close to the edge in terms of packet rate since the 2 main calls take up the entire 10ms.

I have tried using ‘on demand’ DPRam calls to get the status but the time for these calls was 3-4ms so not a great improvement.

The PC is a modern fast machine but I am aware that .NET may be introducing an unnecessary overhead.

So, are these timings as expected? If .NET is the problem what improvement could I expect from a non .NET implementation? Or is it something else?

Thanks in advance,


Link to comment
Share on other sites

  • Replies 0
  • Created
  • Last Reply

Top Posters In This Topic

Popular Days

Top Posters In This Topic

This topic is now closed to further replies.

  • Create New...