I am using Veristand 2016 on a PXIe-1078 chassis with a PXIe-8135 controller with a PXIe-6363 MIO card and 5 PXI-e 4330 cards.
All analog input channels in all cards are configured for single point input.
Due to the sampling rate limitation in the 4330 cards described in this KnowledgeBase article https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000PA15SAG, I have set the target rate for the controller to 711Hz.
When I set the Conversion Rate for the 6363 card to "Default", Veristand does not use the proper sampling rate of 711 Hz. When I sample a sine wave generated by an external function generator, it appears that Veristand is using a sampling rate closer to 500Hz.
However, when I set the conversion rate of the 6363 cards to "Maxiumum", it appears to be sampling at the specified rate of 711Hz.Setting the conversion rates of the 4330 cards to maximum or default has no effect.
I am wondering why setting the conversion rate in the 6363 cards affects the controller sampling rate, and how I can be sure that with the 6363 conversion rate set a Maximum, the controller is using the exact sampling rate specified.
Also, when I tested the attached VI in LabVIEW RT, I got slightly different actual sampling rates for the 6363 and 4330 cards. Is this happening is Veristand as well, are the sampling rates of the cards only approximately equal?
Solved! Go to Solution.
Also, I forgot to mention, when I disable the 4330 cards, the 6363 card samples at the correct rate even when its conversion rate is set to default, which is puzzling.
There's likely a bug in VeriStand somewhere that's leading to what you are seeing if the 6363 is actually sampling at 500 Hz when you've specified 711. At a glance, here are my thoughts:
I'd get in contact with Support with log files an a simple representative System Definition corroborating the claim that the 6363 samples much slower than requested to validate that behavior and maybe get a bug report filed.
If you want to independently validate the sample rate on the 6363, ensure you're using DAQ timing and that the 6363 is your master DAQ device. Then, monitor an indicator the for the "Actual Loop Rate" system channel. That number will give you the loop rate of the control loop as reported by the controller. Since the controller is clocked by an interrupt from the master DAQ device - the 6363 - that indicator will show you the sample rate the 6363 is using.
Thank you for your detailed reply.
The 6363 is set as the master DAQ device for the chassis. Following your suggestion, I added an "Actual Loop Rate" indicator. When I run with the Covert Rate for the 6363 set to Maximum, the Actual Loop Rate reads ~711 Hz (it fluctuates from 710.7 to 711Hz). When I run the Convert Rate for the 6363 set to Default, the Actual Loop Rate reads 355.5Hz (half of the 711Hz, also not 500Hz like I thought).
Thank you also for clarifying the possible minor sampling rate discrepancy between the 6363 and 4330 hardware.
I also logged some data from the 6363 as you suggested, and with the Convert Rate set to Default, the sampling rate in the log file (attached as TDMS) is in fact 355.5 Hz.
So it appears that I have to set the Covert Rate for the 6363 to Maximum. While I am curious as to why this is the case, if the number in the Actual Loop Rate Indicator is reliable, then my purpose is served. Can I be sure that this number is right?
Thank you again.
Thanks for the follow-up! That behavior is admittedly very strange; I sent the AE you're working with the log file attached here. He may want a simple reproducing System Definition to explore further, but I'll leave that up to him. Personally, I'd be curious if this is happens with any number of 4330s in the chassis or if five is a magic number.
You can be confident that the loop rate reported by the "Actual Loop Rate" system channel is accurate since it goes through two different layers - DAQ hardware and controller hardware. The ~711 Hz timing signal is created by the master timing device (the 6363) and routed along one of the PXI_Trig lines that VeriStand reserves (either PXI_Trig0 or PXI_Trig1; not sure which your system is using without access to the source but it doesn't ultimately matter) to the controller. The controller registers rising edges of that pulse and notes its internal system time at each rising edge. Note that the timebase used by the DAQ hardware is completely separate from the controller's timing source. The time delta between rising edges - measured by controller time - is what is displayed in the "Actual Loop Rate" system channel. Hopefully that is clear, but let me know if it isn't and I can clarify.
Though it sounds like you have a working system, this is absolutely something that we want to better understand internally. Thanks for your diligence in investigating this!
Your explanation for why the Actual Loop Rate is reliable makes sense. Thank you.
Following your input, I created a minimal System Definition that reveals the problem.
I have one 6363 card (set as the master DAQ device), and one 4330 with 1 channel (AI0) added.
The behavior is interesting.
1. For number of channels in the 6363 < 5, the loop rate is ~711Hz.
2. For number of channels between 5 and 10, the loop rate switches between 355.5Hz and 711Hz.
3. For number of channels > 10, the loop rate is 355.5Hz.
When I set the Convert Rate for the 6363 to Maximum, or when I disable the 4330, the loop rate becomes 711Hz even with > 10 channels.
I am attaching the minimal System Definition (zipped up, so I could upload it).
I will mark this issue as solved because I have a working system now, but I am curious and happy to contribute towards understanding the issue further.
Thanks for attaching the SysDef! I talked to the AE who you spoke to on the phone on Tuesday and he's picking up the hardware to try and reproduce this in-house. Not sure exactly what the timeline there is, but I'll let him take point and communicate out what he finds. I'll stay in the loop as an escalation resource for him; assuming we can reproduce this behavior, there's an almost 100% chance this will eventually make it into R&D's hands.
I'm actively invested in finding a root cause since this behavior is so strange; it'll be interesting to see what we find out.