09-22-2009 02:30 PM
I'm having a problem with an appliction I wrote for the PCI-6229 where I get errors at night. This happens evey night, and while I'm not sure what time of night yet I've added code so that is noted in the error message.
But basically, the program is running all night and all it is doing is reading the analog inputs a couple of times a second and possibly displaying the reading, if the user has that form open. The readings procedure is triggered by a timer in my program, not by anything on the NI board. We run this program all day as well and so far no errors during the day. We've been running the program for several weeks.
The error message is saying that the specified resource is not available. It occrs during a call to DAQmxReadAnalogF64.
The only time I've seen this error is when I try to execute a new task before the previous one has finished. Given this, my feeling is that another program must be accessing the PCI-6229, possibly briefly. We don't have any other programs running, so I'm wonderingif any of the installed National Instruments softwae is doing this. I know that a number of NI programs connect to the Internet when I log on, or so my firewall software tells me, so I think it is possible that it may check in with Ni.com at night, and maybe while it is doing this it checks on the installed hardware. If this is happening, if the NI software is engaging the NI hardware, while my program is asking the same hardware for readings every 200 ms or so, this would be a problem.
1 Am I interpeting the "specified resource not available" error correctly?
2. Does the NI software check in withni.com every night?
3. DOes the NI softwareinitiate any activity with teh PCI-6229 on its own?
Again, the program works fine all day long, but sometime during the night I get the "resource not available" error.
Thanks.
I'll be checking back frequently. We're trying to solve this problem NOW. I think you know what that means. 😉
09-22-2009 03:18 PM
m610,
Any chance your anti-virus is running a scheduled scan/auto update every night?
09-22-2009 03:18 PM
No, NI software does not connect to the Internet when you log on or during the night. There is no checking of NI hardware at any time unless you command it.
Your interpretation of the error is correct but I think you have going to have to look a lot deeper to find the cause.
09-22-2009 04:14 PM
Thanks for the reply. I was pretty sure I was right on the "specified resources" question.
I'm not sure about your ansewer to my other question. I do recall Norton Firewall asking me repeatedly if various ni.... program should be allowed to connect to the Internet. Maybe they are just connecting and not doing anything more, anticipating there being Ethernet-based data acquisition hardware in my system. I just rebuild that system and I'll reinstall the Firewall software to check those messages again.
09-22-2009 04:36 PM
09-22-2009 04:40 PM
Wayne,
How might virus scan software interfere? I supposed it could cause me to miss readings, and that would be acceptable. Nothing is timing-critical.
My code that reads from the PCI-6229 runs in its own thread and I allow only one such thread to run at a time. Before starting it I check to see if one is already running, and if one is, I skip the start of the new thread this time and will try again next time my timer fires.
I could understand getting this error if I have more than on thread running.
When this thread runs it may execute as many as 4 different tasks - a thermocouple input task, analog input, analog output, and digital output. The first two tasks are always performed and the last two per user input, but at night, the user has gone home.
1. Is there any chance that one of these tasks is starting up before the previous one finishes and releases the resource in question?
2. Is there an easy way to see if the resource is free before I hand it another task?
09-22-2009 06:12 PM - edited 09-22-2009 06:13 PM
A thermocouple task is an analog input task and cannot be in different tasks unless you run them sequentially start task 1, run it, close it, start task 2, run it, close it. Is there a reason you can't combine the read of the thermocouples with the other analog channels?
Depending on how your code is written, it is possible that one task is not finished before the other starts and that would explain the error message.
09-22-2009 06:44 PM
I do start, stop, and close each task when I update my readings.
DAQmxStartTask(taskint);
DAQmxWriteAnalogScalarF64(....
DAQmxStopTask(taskint);
Getting analog inputs and thermocouple inputs in separate tasks has more to do with my learning curve and how I tackled one thing at a time. Simple analog-in first, then thermocouples with cold-junction compensation.
09-23-2009 09:00 AM
m610,
I asked about the anti-virus simply because of the timing of the problems. A lot of computers are set so that auto updates and scans are done after hours. It sounds like your code is constantly starting and stopping tasks. Depending on how your code is structured, the a slowdown of your pc could cause problems.
Dennis' suggestion of creating a single analog input task is a very good one.
09-23-2009 10:34 AM - edited 09-23-2009 10:39 AM
Thanks. I had suspected virus scanning for the same reason, but only because it could be a coincidence. Even if the errors correlated with a virus scan I'd want to know how that led to errors so I could build that into my program. Of course, turning off virus scanning is an option.
Last night was the first time in a long time that the error [u]did not[/u] occur. I was actually hoping to see the error and get the time when it occurred so I could look for external possibilities.
The thing is, the program runs all day and it must call these procedures 200,000 times without running into problems. Then, at night....
Edit - I have added the DAQMXTaskIsDone command to my code just before runing my I/O tasks. I check each task to make sure they are done before proceeding. If this works I can at least avoid the error, but I haven't solved this. I hope this function works when the task has never been run. A task that has never run cannot ever be "done".