From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
Changing the Group Name using DAQmx Logging (Error -201311)
Solved!
A colleague recently gave me some code to look over since they were running into an error using DAQmx Logging: "Error -201311 occurred at DAQmx Start Task.vi", "File specified is already opened for output. NI-DAQmx requires exclusive write access."
Searching tells me one cause for this error is that multiple tasks are trying to use the DAQmx Logging functionality, but I'm pretty sure that only the one task ever makes any reference to DAQmx Logging. I've removed local variables and superfluous indicators, and so I now don't think there's anywhere else that has access to the DAQmx Tasks to change these settings.
I've refactored quite a bit of this section of the code, and now I have it down to a state machine that gets upset when it calls the "Logging.TDMS.GroupName" node (in a loop). It errors on the second attempt to log data (the first time it tries to change the group name after logging).
I can't see the functional difference between my colleague's (with my modifications) code, and the following, but this code works as expected, so there's obviously something.
Is there anything I should be particularly careful of/aware of when using the GroupName property like this?
Here I am switching the "Read and Log" and "Off" values, but now in the real code it will instead use "Off" until a button is pressed, then go to "Read and Log", then return to "Off" after the N iterations (so changes occur whilst the setting is "Read and Log", but the task is Stopped).
I tried setting it to "Off" after each iteration before calling the GroupName property, but it didn't seem to make a difference.
As I understand the documentation, this property change (Mode) takes effect only on the next read, so if it is turned off, then on, then DAQmx Read is called, it should be the same as if it was never changed?
You might also have to give DAQmx some time to "close the file" after the task has been stopped. Try adding a wait after the DAQmx Stop.
@mcduff wrote:
Not sure what is causing the error, but it has my experience with the logging properties that order of operation matters. Some properties need to be set before others, otherwise you have an error. Remember, at I think this is the case, a property node executes sequentially, from the top property to the bottom property.
mcduff
Hmm. You're indeed right that a property node will (should - I remember a forum thread in which Active Cursor was a bit lazy updating...) execute from top down.
I'll check the real code more closely and see if mirroring the exact property node layout in the example code here produces a different result. Maybe there's something there (although I think maybe not in this case. Still, worth checking more closely).
@crossrulz, I also wondered about that and put a 100ms wait in, to no effect. Now I'm bothered that I didn't use a longer wait just to be sure - something to redo tomorrow. "More haste, less speed" comes to mind now... do you have a recommended minimum delay?
@mcduff wrote:
@crossrulz wrote:
You might also have to give DAQmx some time to "close the file" after the task has been stopped. Try adding a wait after the DAQmx Stop.
I may be mistaken, which is often true, but according to the code, I believe the OP wants 1 file with multiple groups, new files are not created with each iteration, only a new group is added to the original file.
That's right. I think/guess the suggestion was that by stopping and starting acquisition, it effectively closes and then reopens the same file (and that if there isn't enough delay, maybe it doesn't close from the previous iteration somehow, via not blocking, I don't know...
@mcduff wrote:When I use the logging features, if I choose Log Only then the number of points needs to a multiple of the disk sector size; not sure if things have changed, but I would get an error if I set the logging to Log Only BEFORE setting the number of points, I had to set the number of points first. All of this was done before starting at task.
Good to know. There's a note in one of the help pages about sizing, it sounded like it was for performance gain but not a requirement, but perhaps that's not true. In this case, I'm reading them at the same time, and the documentation made it look (at least to me) that in that case, you can choose whatever size you'd like (at the DAQmx Read node), perhaps in part because by choosing "Log and Read" you already gave up on "performance".
I tried both checking the property node ordering (and reordering a few ways just in case) and adding a 2s wait after the Stop - neither changed the behaviour.
I'm not sure if there's some sort of triggering/retriggering issue - the task is always "done" which seems strange to me given that whether or not it is "done" is a value used to determine how to read samples. Perhaps this is a simulated device vs real PXI system issue, or maybe not.
In any case, I now think it might be faster/simpler/better to just not use the DAQmx Logging functionality and use TDMS nodes directly. I suppose I'll find out if that's a performance problem once I try it...
Bahh... I was assuming the problem was my snippet was too new a version, but I now see, no snippet.
Here's the VI, backsaved to 2016. The real code is running in 2016 64-bit, but I've been testing using 2019 32-bit and an NI-MAX provided simulated PXIe-6358 in "PXI1Slot2".
I'll see about posting some of the actual code, but since it was given to me by someone who was given it by someone who was given it from some other institutions, blah blah blah, I can imagine this might not work out.
Thanks for posting. Just ran this on LabVIEW 2019 64bit with a simulated device. I deleted the counter task, no idea if that has any effect. See below.
This worked for me without errors. See below.
The code seems to work. I am a loss as to what the problem is. Sorry.
mcduff
