LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Issue Registering for "Every N Samples Acquired into Buffer" Event Dynamically

Solved!
Go to solution

LabVIEWers

 

I've been troubleshooting this "Every N Samples Acquired into Buffer Event" registration for two days now and I thought that it's time to get some help.  I have used this technique many times but I've always registered outside of the Event Structure (like in the third image).  I found this post from mcduff --> mcduff DAQmx Event Post, which I thought would do the trick but it's not working in my case.  Maybe it's because I have other events to register as well. 

 

I can't upload the VIs but I can make a dummy VI if that would help.  I'm hoping that somebody will be able to spot something... 

 

Code Not WorkingCode Not Working

 

This is the code that is in the Register SubVI above (similar to the mcduff post). When I probe the output refnum I get a value other than 0 but I assume that it's not the correct refnum or an invalid refnum.  When I unregister for this event (when I stop the module) I get error 1055, which points to an invalid ref...

 

Inside the Register SubVIInside the Register SubVI

 

If I wire the task into the Register Events node like below everything works properly.  I could simply use this technique but I'd like to understand why the other method doesn't work.  

Code WorkingCode Working

 

 

 

Best regards,
Brown

The more I know...the more I don't know
0 Kudos
Message 1 of 15
(3,081 Views)
Solution
Accepted by Brown@KTR

Just guessing here:

 

In your loop that works, you register outside the loop for the event and everything works. No need to register inside the "State Machine" unless the task changes.

 

One issue that may be your problem. You are registering for the DAQ and starting your DAQ task in the same frame; I guessing that from your icons. But you have no shift register for the cluster holding the event data, I think it is lost after the frame executes. Change that input to a shift register and try.

 

mcduff

Message 2 of 15
(3,037 Views)

I don't think you need to unregister for the previous event; you can just wire it into the Register for Events function to modify it. (I was all geared up to link to my old post where I had this issue, then I noticed you'd already linked it lol).

 

In my code I didn't Unregister then Reregister, I just modified the Registration by wiring in the dummy refnum into Register for Events. Can you try that and see if it works?

 

Edit: I would highly recommend creating a "minimum viable reproduction" VI/set of VI's to try to isolate the problem, plus then others can try it as well. Just drop your subVI contents into the main VI. It won't be as small as your actual code but it'll put everything in one place and be easier to probe for anyone debugging.

0 Kudos
Message 3 of 15
(3,022 Views)

@BertMcMahan wrote:

I don't think you need to unregister for the previous event; you can just wire it into the Register for Events function to modify it. (I was all geared up to link to my old post where I had this issue, then I noticed you'd already linked it lol).

 

In my code I didn't Unregister then Reregister, I just modified the Registration by wiring in the dummy refnum into Register for Events. Can you try that and see if it works?

 

Edit: I would highly recommend creating a "minimum viable reproduction" VI/set of VI's to try to isolate the problem, plus then others can try it as well. Just drop your subVI contents into the main VI. It won't be as small as your actual code but it'll put everything in one place and be easier to probe for anyone debugging.


Look at the cluster holding the Event registration data; it needs a shift register.

 

Unregistering is good for avoiding reference leaks. 

 

mcduff

0 Kudos
Message 4 of 15
(3,016 Views)

@mcduff wrote:


Look at the cluster holding the Event registration data; it needs a shift register.

 


I didn't think you had to wire that back up to a shift register... I usually do, but there's some mystery around it from what I've read:

 

https://forums.ni.com/t5/LabVIEW/Unregistering-Dynamic-Events/td-p/3651894

 

If that fixes OP's problem then I'd love to know, as it'll help me demystify the dynamic registration terminals.

 

 

Unregistering is good for avoiding reference leaks. 

 


I thought that wiring with the previous registration let you modify the reference, not drop the old and create a new one. Is it creating a new one (thus memory leaks) or modifying the old one (thus no leaks)?

 

Edit: From the RfE help:

"If you wire the top left input of the Register For Events function, the function modifies the existing registration information associated with that refnum instead of registering the event again."

 

Seems like you wouldn't get memory leaks then if I'm reading this right.

Message 5 of 15
(3,007 Views)

OK one more post, I did some experiments and you do not need a shift register for dynamic event terminals:

 

Event structure weirdness.png

 

It appears they act more like references, and if left unwired still work fine. Connecting RfE to the right dynamic terminal doesn't change behavior, nor does looping the dynamic terminal through a shift register. Even if you leave the righthand terminal unwired AND loop it with a shift register it still behaves as expected. I also tried Unregistering for the events and creating a new Event Registration and it still worked fine, so I still don't know exactly what's wrong with OP's code.

Message 6 of 15
(2,998 Views)

@BertMcMahan wrote:

@mcduff wrote:


Look at the cluster holding the Event registration data; it needs a shift register.

 


I didn't think you had to wire that back up to a shift register... I usually do, but there's some mystery around it from what I've read:

 

https://forums.ni.com/t5/LabVIEW/Unregistering-Dynamic-Events/td-p/3651894

 

If that fixes OP's problem then I'd love to know, as it'll help me demystify the dynamic registration terminals.

 

 

Unregistering is good for avoiding reference leaks. 

 


I thought that wiring with the previous registration let you modify the reference, not drop the old and create a new one. Is it creating a new one (thus memory leaks) or modifying the old one (thus no leaks)?

 

Edit: From the RfE help:

"If you wire the top left input of the Register For Events function, the function modifies the existing registration information associated with that refnum instead of registering the event again."

 

Seems like you wouldn't get memory leaks then if I'm reading this right.


I recall, but am not sure, seeing some reference leaks when using DETT some version ago. Not sure if this has changed in newer versions, but typically I rather be safe than sorry. Unregistering does not seem like a CPU killer.

 

I'll go with what Ben says..

So no need to wire anything to it unless we want to change the way the event structure operates.

Ben

 

I would try a shift register, though even a future post of yours will prove me wrong. 🙂

 

mcduff

Message 7 of 15
(2,992 Views)

@BertMcMahan wrote:

OK one more post, I did some experiments and you do not need a shift register for dynamic event terminals:

 

Event structure weirdness.png

 

It appears they act more like references, and if left unwired still work fine. Connecting RfE to the right dynamic terminal doesn't change behavior, nor does looping the dynamic terminal through a shift register. Even if you leave the righthand terminal unwired AND loop it with a shift register it still behaves as expected. I also tried Unregistering for the events and creating a new Event Registration and it still worked fine, so I still don't know exactly what's wrong with OP's code.


More Weirdness.

 

Just tried with a DAQmx Event, can't post the code sorry. When I replaced my shift register with a node, I got an error. Below did not work on LabVIEW 2020. When the node in the red circle is a shift register, it works.

 

Snap38.png

 

 

0 Kudos
Message 8 of 15
(2,985 Views)

@BertMcMahan wrote:

OK one more post, I did some experiments and you do not need a shift register for dynamic event terminals:

 

Event structure weirdness.png

 

It appears they act more like references, and if left unwired still work fine. Connecting RfE to the right dynamic terminal doesn't change behavior, nor does looping the dynamic terminal through a shift register. Even if you leave the righthand terminal unwired AND loop it with a shift register it still behaves as expected. I also tried Unregistering for the events and creating a new Event Registration and it still worked fine, so I still don't know exactly what's wrong with OP's code.


In your example, the refnum NEVER changes, stick on probe on it before and after the while loop. This is why you don't need a shift register. Make the following modification to your program,

 

Snip.png

 

This is more similar to the OP's original query. Try it with and without a shift register, see what happens.

 

mcduff

Message 9 of 15
(2,983 Views)

Woah...a lot of action on this one since I last looked at it.  

 

Indeed, mcduff is correct.  All I needed was to add the shift register.  Thank you very much.  I thought that the dynamic terminal on the right side of the event structure allowed for "registering" an event inside the event structure.  I didn't realize that you need to bring it back to the dynamic terminal on the left hand side of the event structure.  Is this what's actually happening? When do you use the dynamic event terminal on the right hand side?

 

If you wouldn't mind, I also have a question about unregistering for this DAQ Event.  I've noticed that I get Error 1 if I actually register with a real task inside the event structure or I'll get error 1055 if I don't register with a real task because the ref is invalid (from the constant that defines the datatype).  My question: Is there any point to unregistering this event because I'll always be clearing the task that I registered in the message handling loop before I get to the unregister VI...so I assume that this makes the event ref invalid regardless.  I guess I'm asking more for good coding practice. 

 

Solved - THANK YOU mcduff!Solved - THANK YOU mcduff!  

Best regards,
Brown

The more I know...the more I don't know
0 Kudos
Message 10 of 15
(2,975 Views)