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
