Jeff Plotzke Posted February 19, 2007 Report Share Posted February 19, 2007 Here's a discovery I made today: If you're using DAQmx Property Nodes in an RT application, they may not work correctly until about 5 seconds after the RT system has been running. In my case, I'm using a PXI RT controller and my application calls the "DevNames" DAQmx System property to return all the devices on the system when it begins. However, after a long search, I've discovered that this node gave back only 1 of my 7 cards on the system when it executed in a deployed startup application. If I put a 5 second wait before this property node, it works fine, returning all the cards. I don't know if this is a "bug" or just that LVRT needs to discover all the cards first, but I wanted to post this in case anyone experiences this problem. Quote Link to comment
crelf Posted February 20, 2007 Report Share Posted February 20, 2007 QUOTE(Jeff Plotzke @ Feb 19 2007, 09:59 AM) I don't know if this is a "bug" or just that LVRT needs to discover all the cards first, but I wanted to post this in case anyone experiences this problem. Sure sounds like a bug to me. Are you sure that the pause is repeatable, or is there something else you can call to see if the system is ready for the property node you're using? Quote Link to comment
Jeff Plotzke Posted February 20, 2007 Author Report Share Posted February 20, 2007 QUOTE(crelf @ Feb 18 2007, 09:59 PM) Sure sounds like a bug to me. Are you sure that the pause is repeatable, or is there something else you can call to see if the system is ready for the property node you're using? OK, I've done more testing, and found the strangest results. Here's a summary: -The 'DevNames' property is the only property I can find that gives different results based on a time delay after booting the RT controller. -The 'DevNames' property only exhibits this behavior when it is in the same property node as 'GlobalChans' and follows 'GlobalChans'. (Not necessarily immediately following, it returns incorrect results even if a property is between 'GlobalChans' and 'DevNames') -If 'DevNames' is alone in a property node, it will return the correct cards without any delay. -If 'DevNames' is preceded by properties other than 'GlobalChans', it will return the correct cards without any delay. -If 'DevNames' is proceded by 'GlobalChans', it will return the correct cards without any delay. In the case that 'GlobalChans' precedes 'DevNames', a wait time before calling the property node will fix the issue. The pause itself is repeatable, at least on the one controller I'm using. I've been doing testing with multiple times with wait times from 0 sec - 20 secs. In any instance where the wait was below 20 seconds all the cards were not returned. I do notice that in the case where all cards are not returned by the property node, the cards that it does return are the ones closest to the controller. I don't know if this is simply coincidence... I'm attaching the VI I've used for testing. I've documented in my disable structure which frames give correct results and which frames give incorrect results. I'll contact NI tomorrow regarding this bug. I'll post again once I get more information. I'll add that if anyone tests my VI with their controller -- This behavior is only seen once you build, deploy, set as startup, reboot, then connect via Remote Front Panel. If you simply execute this code on RT without deploying and rebooting, it will work fine. Quote Link to comment
eaolson Posted February 20, 2007 Report Share Posted February 20, 2007 QUOTE(Jeff Plotzke @ Feb 18 2007, 10:34 PM) I'll add that if anyone tests my VI with their controller -- This behavior is only seen once you build, deploy, set as startup, reboot, then connect via Remote Front Panel. If you simply execute this code on RT without deploying and rebooting, it will work fine. I also found some significant slowdowns on an RT controller when using property nodes immediately after a reboot. In my case, I was using the Task PN to find the devices in a task. I'm not sure if these are related or not; in my case, waiting before calling the PN did not seem to help. http://forums.ni.com/ni/board/message?boar...ssage.id=210246 Quote Link to comment
dthomson Posted February 21, 2007 Report Share Posted February 21, 2007 QUOTE(Jeff Plotzke @ Feb 18 2007, 04:59 PM) Here's a discovery I made today:If you're using DAQmx Property Nodes in an RT application, they may not work correctly until about 5 seconds after the RT system has been running. In my case, I'm using a PXI RT controller and my application calls the "DevNames" DAQmx System property to return all the devices on the system when it begins. However, after a long search, I've discovered that this node gave back only 1 of my 7 cards on the system when it executed in a deployed startup application. If I put a 5 second wait before this property node, it works fine, returning all the cards. I don't know if this is a "bug" or just that LVRT needs to discover all the cards first, but I wanted to post this in case anyone experiences this problem. I had a very similar issue, but on a LV 7.1 W2K machine. Daq calls didn't work reliably if the machine started a LV program automatically at bootup. I found a Dos Sleep command, put it in a batch file to sleep 10 seconds on bootup, and then had the batch file launch the LV program in order to get it to work properly. Never tracked it down fully, and I've never seen the same problem on other W2K machines, even running LV 7.1 programs at bootup. The other similarity is that this program did query the MAX database for devices and channel names, from which it set up its daq tasks internally. My guess was that whatever Max processes run in the background at bootup just hadn't finished up yet. Perhaps some of this code is common to RT and Windows systems. (Or at least the symptoms are common!) Regards, Dave T Quote Link to comment
Jeff Plotzke Posted February 21, 2007 Author Report Share Posted February 21, 2007 Just sending a quick update: I've sent my example VI to NI R&D and they're reviewing it. It's interesting to see that others have seen similar issues on other platforms... I'll post more (and hopefully a CAR#) once I hear back. Quote Link to comment
Ton Plomp Posted February 21, 2007 Report Share Posted February 21, 2007 Me too On a Xp machine, just added a 5 seconds wait at the start of the program. It just means that LabVIEW is loaded faster than DAQmx... Ton Quote Link to comment
Jeff Plotzke Posted February 21, 2007 Author Report Share Posted February 21, 2007 QUOTE(tcplomp @ Feb 20 2007, 11:41 AM) It just means that LabVIEW is loaded faster than DAQmx... I expected that, until seeing that calling 'DevNames' before 'GlobalChans' gives me all correct data, without adding any delay. Perhaps it's just coincidence? Quote Link to comment
Jeff Plotzke Posted March 18, 2007 Author Report Share Posted March 18, 2007 FYI -- NI just responded back. It's been filed with R&D with CAR# 47FHLM99 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.