Timings for calls into PCommServer.exe

[PRM]

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”)

Endif

If Mode=RUN or Mode=IDLE then

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

ProcessStatus

Endif

 

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

Mode=IDLE

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

Mode=RUN

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,

Paul