We are having overhead issues with the new 53220A counter that need to be resolved. Looking at the attached driver project, I've attached the old and new driver (LV2011).
Looking at the 5322x driver, you will see in the Open Counter.vi and Read Counter.vi that there are disable structures around the old code where we have attempted to replicate the same reads with the new counter. With the new code as is, we are seeing a delay that was not there previously.
The way we were doing it before, we initialized and ran the counter continuously, and read a fixed time of counts with the Read Counter.vi. I'm trying to replicate this with the new driver.
Can someone please look this over and see if this is the correct way to initialize the counter to read continuously in totalizing mode (with fixed arm time)? What may we do to regain our overall performance?
Looking at the 5322x driver, you will see in the Open Counter.vi and Read Counter.vi that there are disable structures around the old code where we have attempted to replicate the same reads with the new counter. With the new code as is, we are seeing a delay that was not there previously.
The way we were doing it before, we initialized and ran the counter continuously, and read a fixed time of counts with the Read Counter.vi. I'm trying to replicate this with the new driver.
Can someone please look this over and see if this is the correct way to initialize the counter to read continuously in totalizing mode (with fixed arm time)? What may we do to regain our overall performance?
Attached is a continuous totalizing example using the 532xxA in its standard mode (not 531xxA compatibilty mode). It uses the counter's continuous totalizing function rather than INITiate:CONTinous and periodically queries the continous count. The program uses VISA as provided by LabView - no additional driver is needed.
Attachments
I've seen this example before, unfortunately. It does not show how to initiate a totalizing count with a fixed amount of time and acquire samples continuously as we were doing in the Read Counter.vi in the attachment above (first post) for the 53132A code.
The delay that we're seeing is most likely caused from the way we're trying to implement the new 53220A code in Read Counter.vi, as the external code that called these two drivers has not changed. I'm sure it's just a misunderstanding of how to use the new 53220A in our application.
Attachments