PRM Posted November 30, 2012 Posted November 30, 2012 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
Recommended Posts