LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Access violation when registering for DAQmx Event with empty Task input

Solved!
Go to solution

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.

 

accessviolation.png

 

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 🙂

0 Kudos
Message 1 of 12
(3,532 Views)

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.

  1. Make a constant DAQmx "Dummy Event". I often use a cluster, for some reason it works better when mixed with User Events.
  2. When you have a real task at hand, the register for it inside the loop.

See below. (The first picture occurs outside the event structure. The second picture occurs inside the event structure.)

Snap7.pngSnap8.png

 

mcduff

Message 2 of 12
(3,507 Views)

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.

Rolf Kalbermatter
My Blog
Message 3 of 12
(3,479 Views)

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.

0 Kudos
Message 4 of 12
(3,401 Views)

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.

0 Kudos
Message 5 of 12
(3,383 Views)

(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.)

0 Kudos
Message 6 of 12
(3,378 Views)

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.

 

  1. Right Click the DAQmx Event node and choose create constant.
  2. Put that constant in a cluster, I remember this was key for some reason. Use that cluster for event registration.
  3. Unregister if active.
  4. Register with real task reference, then rebundle.

All should be in a while loop state machine.

 

mcduff

 

snip.png

Message 7 of 12
(3,372 Views)
Solution
Accepted by BertMcMahan

Just saw your vi, you are almost there. You steps are in the wrong order.

  1. Stop Task.
  2. Clear Task if you are not reusing.
  3. Unregister.
  4. Register with the new task.
  5. Start task.

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

Message 8 of 12
(3,371 Views)

@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:

Works.png

 

If I move the Start Task to before the loop, it will hard crash LabVIEW:

 

Crashes.png

 

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.

 

 

Spoiler

 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.

 

0 Kudos
Message 9 of 12
(3,329 Views)

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.

0 Kudos
Message 10 of 12
(3,323 Views)