Speeding up my frequency stability program

[jdamato3]

I am running a Labview VI that tests the resonance frequency stability of fabricated devices via GPIB. Unfortunately, this program is way too slow and it is only iterating each frequency once per second.  If anyone can give me some insight on how to speed up this program, it would be much appreciated. I've attached the VI below.

~jdamato3

[johnsold]

Once per second may not be too far off for reading a counter via GPIB.  I am not familiar with your device.  How fast can it count and return a reading?

How long do you count to get the resolution you want?

Writing one point to the file seems rather inefficient. Why not accumulate several points and then write a block to the file?

Lynn

[altenbach]

I addition to Lynn's comments, here are a few more about your general program structure.

• Your time indicators have the wrong representation. They should be I32. Use quotient&Remainder instead of division to keep things blue.
• Intead of doing all that song and dance to get hours, minutes and seconds from [i], use a plain numeric indicator formatted as relative time (HH:MM:SS)..
• You calculate time from the iteration terminal, which has no meaning because your loop rate is not deterministic. (Is there some timing in the device configuration, perhaps?). (I hope you are not using this to determine the read rate 🐵
• If you can guarantee that a loop iteration can be done in under one second, place a 1000ms wait inside the loop to make things deterministic and the time display meaningful.
• If you cannot do that, take for example a tick count before the loop and one inside the loop. The difference is the elapsed time in milliseconds, updated once per iteration.
• If time is important, it would also be impotant to include it in the log file.
• Why do you use two charts with exactly the same information. Wouldn't one be enough?
• Why do you show an extra numeric indicator for frequency? Delete it and right-click the chart...visible items... digital display. Format and place as desired. (less clutter on the diagram!)
• Shouldn't there be some error handling. (e.g. do you really want to continue logging if the GPIB operation fails?

[jdamato3]

Lynn,

Sorry for taking so long to respond. Independent of LabVIEW, I ran the counter anywhere between a tenth to a hundreth of a second. For our specific application, we have to leave the program running for about 30 hours. 

~jdamato3

[jdamato3]

---

@altenbach wrote:

I addition to Lynn's comments, here are a few more about your general program structure.

• Your time indicators have the wrong representation. They should be I32. Use quotient&Remainder instead of division to keep things blue.
• Intead of doing all that song and dance to get hours, minutes and seconds from [i], use a plain numeric indicator formatted as relative time (HH:MM:SS)..
• You calculate time from the iteration terminal, which has no meaning because your loop rate is not deterministic. (Is there some timing in the device configuration, perhaps?). (I hope you are not using this to determine the read rate 🐵
• If you can guarantee that a loop iteration can be done in under one second, place a 1000ms wait inside the loop to make things deterministic and the time display meaningful.
• If you cannot do that, take for example a tick count before the loop and one inside the loop. The difference is the elapsed time in milliseconds, updated once per iteration.
• If time is important, it would also be impotant to include it in the log file.
• Why do you use two charts with exactly the same information. Wouldn't one be enough?
• Why do you show an extra numeric indicator for frequency? Delete it and right-click the chart...visible items... digital display. Format and place as desired. (less clutter on the diagram!)
• Shouldn't there be some error handling. (e.g. do you really want to continue logging if the GPIB operation fails?

---

Altenbach,

Thank you for all of your help on everything. In the device configurations, the time interval is set to a hundreth of a second, yet the program only counts once/s. I got rid of one chart and added a digital display for frequency. Using quotient remainders, how do you convert that into the proper form of relative time? Speed is my goal, not so much calculating elapsed time. I'm just looking for any possible solution, so I don't have to keep running this for 30 hours to get the proper results.