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
Highlighted

Brown@KTR wrote:

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. 


That error can arise depending on the order of events. Using this order I don't get an error,

  1. Stop the DAQ task
  2. Unregister the DAQ event
  3. Clear the DAQ Task

Error 1 occurs if you switch 3 and 2. Number 3 depends on your situation; do it before you exit the program. If you are stopping the DAQ, restarting it, etc, in a loop, you may not have to do that; you can just REUSE the current task. You only need to clear the task if you do certain modifications to the task, like removing a channel; then clear it, and start a new task. Hope that makes sense.

 

mcduff

 

PS I cannot answer your questions about the event structure except using data flow. I assume the value on the left side sets it each iteration.

 

EDIT: You can move the unregister events inside the loop, so the order can be enforced, that is what I do. Also keeps the diagram smaller, everything inside the loop.

0 Kudos
Message 11 of 15
(126 Views)
Highlighted

Thanks for the advice. I’ll try to implement unregistering the event(s) inside the loop.

Best regards,
Brown

The more I know...the more I don't know
0 Kudos
Message 12 of 15
(120 Views)
Highlighted

@mcduff wrote:


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


Yep, I see what you're saying. It looks like the rule is "If you register for the event outside the loop, using a new RfE node will modify the old event and will not require a shift register. If you register for a new event inside the event structure, you must use shift registers."

 

events2.png

 

This code doesn't work- you have to switch to shift registers. Oddly enough, it looks like OP's problem could've been solved either way... by adding shift registers OR by removing the unregister. With all of the oddness with how these references work, it's kind of funny that the OP found the ONE configuration where it *wouldn't* work 🙂

 

Regarding what the right hand terminal actually *does*, it appears to me to act as an "unwired" loop element for when you *do* use shift registers. It means you don't have to wire the dynamic registration terminals across ALL of your event structure cases, whereas with a tunnel you either let it go default or wire it everywhere. For example, the following does NOT work:

 

events3.png

 

Basically, if you don't connect the new RfE terminal to *something* it obviously doesn't work, so the output needs to go somewhere. Just connecting it to the right hand terminal does NOT modify the registration; it must go to the left terminal. Thus, you need a shift register. If you use a tunnel, you have to wire it in every case. If you use the right hand dynamic event terminal, you can just wire it where you need it. If you leave it unwired it won't modify anything in the other terminals.

 

At least, this is what I can divine by doing some experiments. I'd love a "deep dive" article from NI on how precisely they intend you to use dynamic event registration, and include things like the potential memory leaks you mentioned.

Message 13 of 15
(91 Views)
Highlighted

@BertMcMahan wrote:


Nice investigative work!

0 Kudos
Message 14 of 15
(87 Views)
Highlighted

...it appears to me to act as an "unwired" loop element for when you *do* use shift registers. It means you don't have to wire the dynamic registration terminals across ALL of your event structure cases, whereas with a tunnel you either let it go default or wire it everywhere...

I came to this same conclusion last night.  Makes sense.  I've never really needed to register for any events inside the Event Structure until now so I've never put much thought into it.  

 

Good discussion!

Best regards,
Brown

The more I know...the more I don't know
0 Kudos
Message 15 of 15
(83 Views)