11-29-2019 05:03 PM
I am writing a small DAQmx routine that needs to be toggleable on and off by the user. I'm using user events to talk to the loop, so I'm planning on using DAQmx events to pull data from the buffer when it has enough data in it.
When I start the VI, I register for an event of Every N Sample Acquired into Buffer. Since there's no task at this point, I use an empty task constant. In my "Start acquiring" message, I generate the task with the right channel info, then replace the Event Registration with the correct one, so it should fire when it's ready.
Unfortunately, my initial Register for Events function is throwing an Access Violation. I've attached the minimum code needed to get this to run.
I tried this same code on LV2016 32 bit and LV2018 32 bit, same problem.
I'm running DAQmx version 19.5, which appears to be the latest one.
Can anyone run this snippet and let me know if it works for them? If this method of event registration doesn't work the way I think it does I can work around it, but to hard-crash LabVIEW makes it feel more like a bug than anything else. I'll try forcing DAQmx to reinstall, but I'm hoping someone can try this on a separate system and see if it crashes there too.
Thanks for any help and hope you guys had a good Thanksgiving 🙂
Solved! Go to Solution.
11-29-2019 06:00 PM
I get the same access violation error as you.
I often do the same thing you are attempting in a slightly different way without any problems.
See below. (The first picture occurs outside the event structure. The second picture occurs inside the event structure.)
mcduff
11-30-2019 04:17 AM
While registering an event for a session that dies not exist doesn’t make any sense (such an event never can occur as it it has no valid source), I agree that this should not crash LabVIEW. So I would definitely report it.
For now something like what is proposed should work. You only. (ab)use the register event to get the correct refnum type and need to reregister the event anyhow after every time you created the real task again. A refnum constant fulfills that purpose perfectly.
12-02-2019 10:43 AM
Thanks for trying out the code- that's going to save me a ton of time trying to figure out if my DAQmx installation is corrupted or not.
@rolfk, yes there will be no events generated on that dummy task, I just needed it to be aware that an event of that type would be coming later on.
I'll report this to NI and will switch to using a constant. Thanks again for trying this out.
12-02-2019 06:29 PM
Well I may have spoke too soon. I'm still getting access violation errors, but now they happen when I try to register for the new event. Have you had to do anything special in your "dummy event" constant? It's like it's looking up the "old" event, causing the access violation again.
12-02-2019 06:45 PM
(Sorry for a ton of posts here)
So I attempted mcduff's workaround and I somehow still get the access violation, but only when I register for the new event. Try this sample program- hit Start after you run it and let me know if you get an access violation. This is based on the "Continuous voltage with events" sample code, but with the event registration happening manually.
(Yes, the task starts before the registration, but I doubt that would have anything to do with it, and it SHOULD just throw a buffer overflow error if the buffer fills up. This will be correct in the actual project, this is just to isolate the bug.)
12-02-2019 07:03 PM
I got the access violation in LabVIEW2018, DAQmx, version 18.x, not sure, not in front of that computer.
Attached is a 2018 VI and 2019 snippet.
This is what I do to get it to work, note if something major changed in DAQmx 19.5, then all of my programs are hosed, because I do this all the time. Also note I don't have a DAQ here to test.
All should be in a while loop state machine.
mcduff
12-02-2019 07:09 PM
Just saw your vi, you are almost there. You steps are in the wrong order.
Here's an abbreviated list of States I use in a JKI state machine to do what you want to do.
DAQ: Stop
DAQ: ClearTask
DAQ: StartNewTask
DAQ: SetChannels
DAQ: SetClock
DAQ: UnRegister
DAQ: RegisterEvents
DAQ: Start
mcduff
12-03-2019 12:09 PM - edited 12-03-2019 12:14 PM
@BertMcMahan wrote:
(Yes, the task starts before the registration, but I doubt that would have anything to do with it, and it SHOULD just throw a buffer overflow error if the buffer fills up. This will be correct in the actual project, this is just to isolate the bug.)
Whelp, guess that's what I get for assuming. I was aware my Start was before the registration, which I assumed would just mean the buffer started filling before the event was registered, so I ran the risk of the buffer overflowing. (That's just in my simplified code, not the real stuff). Apparently you cannot start a task, then register it. You must register it first, then start the task, otherwise you will get a hard crash in the dev environment. I still assume this is a bug- if I can't do this operation it should throw an error, not crash the development environment 🙂 I'll work with NI to get that filed as a bug report, but for the time being I'm all set, and both my test code and the real thing are working.
So I've finally nailed it down. I don't know *why* this is the case, but it works.
This code works:
If I move the Start Task to before the loop, it will hard crash LabVIEW:
I haven't poked enough at it to understand if it's because of the original Dummy event or not. Unregistering the dummy event doesn't seem to have anything to do with it, though if there was a real event there I would obviously need to unregister it. The particular version of code I used to snap the images just didn't have it in there as I was taking stuff in and out to try to isolate what the heck was causing the issue.
Bonus points if someone can tell me how the "Source" terminal for the event structure got detached from the border. I can move it around the entire Event structure.
12-03-2019 12:45 PM
One thing I/(users) like to do is, is change the Logging Mode.
If you are going to no logging to log and read or vice-versa, then no need to unregister, reregister task, just stop the task, change logging mode, then restart the same task.
If you change the logging mode to "log only" then you need to unregister the task since log only doesn't display data.
mcduff
PS Search the forums for the event bug, I've seen it before here.