02-25-2016 01:09 PM
Hardware-
Software
Code attached, but at it's basics, I have 3 DAQmx tasks. 2 analog and 1 digital. Each are setup to Log (only) to 3 seperate TDMS files (couldn't figured out how to stream to a single file). Everything is fine until I try a long run and then try to stop the digital task. I get the error below.
Adding a giant wait (10s) resolves this problem. My guess is that the stream writing isn't finished when I try to close the task and it tries to close out the file. In all of these cases, DAQmx claims that it is finished with the task.
Error -201309 occurred at DAQmx Stop Task.vi:3590004
Possible reason(s):
Unable to write to disk. Ensure that the file is accessible. If the problem persists, try logging to a different file.
Property: Logging.FilePath
Requested Value: D:\temp_20160225_135243_digital.tdms
Task Name: Slot3 Digital
So I'm a little baffled as to why this is happening and can't seem to find a way to find out if whatever is tying up the disk is finished.
Thanks in advance.
Solved! Go to Solution.
02-25-2016 01:26 PM
Oh, I should mention that I replaced the hard drive with a samsung pro ssd.
It's been working perfectly, so I can't imagine it being a problem, but it's worth mentioning.
02-26-2016 11:15 AM
Hi JW-JnJ,
I was not able to view the code you posted since you did not inlcide the sub-VI's and controls you use in the code. Could you zip up the whole project with all dependent sub-VI's and controls in it so I can view how you have everything set up.
Thanks,
hfar2
02-26-2016 12:58 PM - edited 02-26-2016 12:59 PM
Sorry, i tend to avoid attaching all of my code if possible.
The VI in question is Simple Capture.vi and I'm seeing this when running for a 5 second capture without plotting enabled.
(as a note, this seems to work with plotting enabled, but it takes a long time due to the extra memory requirements and low memory in the computer)
02-29-2016 01:42 PM
I believe this may be an issue realted to the max throughput of your device. Based on your code you have the Digital task setup to run at 10MHz so with 5 seconds you would be attempting to log 50 Msamples all at once. If you tried lowering the sample rate for your digital task do you see the same error? Also are the analog and digital tasks input or output?
Based on the error you are receiving it appears there may also be something wrong with the file you are pointing the digital task to log to. Have you tried setting the DAQmx logging option to Create or Replace instead of just Create in case the file you are trying to create already exists?
Best,
hfar2
03-01-2016 07:40 AM
@hfarley2 wrote:I believe this may be an issue realted to the max throughput of your device. Based on your code you have the Digital task setup to run at 10MHz so with 5 seconds you would be attempting to log 50 Msamples all at once. If you tried lowering the sample rate for your digital task do you see the same error? Also are the analog and digital tasks input or output?
Based on the error you are receiving it appears there may also be something wrong with the file you are pointing the digital task to log to. Have you tried setting the DAQmx logging option to Create or Replace instead of just Create in case the file you are trying to create already exists?
Best,
hfar2
By device you mean the PXIe-6358?
All of the channels are analog input. 16 analog on slot 3, 1 digital on slot 3, 16 analog on slot 5.
I tried removing the 6 spare analog channels on Slot 5 and moving the digital signal and trigger to that card. This allows me to go to a higher aquisition time. I'm only erroring at 20 seconds now so my requirements are met at least. I still find this error puzzling.
The file names are generated with a current timestamp down to the second. There is no chance I'm overwriting files or trying to access an existing one. That being said, I tried "Create or Replace" and see the same thing.
04-04-2016 09:12 AM
So, in the interest of not being that guy (What did you see!), I'll post what we found out.
Turns out the bottleneck we had was in the SATA connection. The SSD was more than capable of handling the throughput, but the SATA throughput was not advertised and a lot less (~40MB/s off the top of my head... don't quote me) than the necessary throughput >80MB/s. This caused strange issues with disk access.
A mitigation could have been not using the built in TDMS logging and move to a producer-consumer architecture. I don't have time to test out this theory, but it's a good direction for people that run into this problem.
My particular solution was to move to a PXI Chassis RAID to achieve higher throughput to disk.
Thanks to NI for the help.