Trouble mixing DAQmx Events and User Events

[CoastalMaineBird]

LV2013

I've never used DAQmx Events before, and I'm having trouble using an EVENT structure that can accept both regular USER events, and DAQmx Events.

How do you get them all registered?

See this JING: http://www.screencast.com/t/GOyKTvYfugU

The opening frame shows the basic structure I'm using: the EVENTS vi produces a cluster of four user events.

I can register using this cluster, or the individuals, and everything is fine.

However, I want it to ALSO accept a DAQmx event (every N samples scanned into buffer), and I can't get it to register BOTH.

The "AI manager" produces both a TASK out, and it registers an event with the EVERY N SAMPLES, set to "1", and brings out the refnum.

At 0:06, I try to wire the AI Refnum into the REFNUM INPUT of the REGISTER EVENTS node, but that node CHANGES to look just like the register node that's already in the AI MGR vi.  Why?

The cluster of events coming out of the ETHERCAT EVENTS vi is still accepted into the EVERY N SAMPLES input - why?

0:25 - as soon as I try to wire the "N" value here, it complains about the cluster connection - why?

0:39 - If I undo all that and wire the TASK into a second input of the REGISTER EVENTS, it is accepted - why?

0:50 - There is no option to choose the EVERY N SAMPLES (or task done or other events) - all I see is the four events from the cluster - why?

1:27 - if I create a second REGISTER EVENTS node, I can wire it to the REGISTER EVENTS node that's already in the AI MGR vi.

1:48 - I can wire that 2nd REGISTER EVENTS node to the event structure and choose the event.  Great. But the original USER events are lost.

1:59 - If I wire from the DAQmx events node to the USER events node, the USER events node changes personality into a DAQmx node. why?

2:19 - If i wire in the other order, the DAQmx node changes personality into a USER node - why?

The bottom line is: how do I get the EVENTS structure to have cases for all the USER events AND ALSO a DAQ Mx event?

[CoastalMaineBird]

Hmmm.  This combination SEEMS to work (at least it compiles without error and offers the appropriate options in the event cases).

But the second event input to the REGISTER EVENTS, offers a SAMPLE INTERVAL input that is irrelevant and unneeded, but I can't get rid of it.  The REMOVE ELEMENT option is grayed out from the menu.

Furthermore, that second SAMPLE INTERVAL is required (if I don't wire it, it complains of an error).  But it can't possibly pertain to those user events.

I suppose I'll try this and see if it actually works.

[CoastalMaineBird]

Well, it compiles, but it doesn't work.  In fact it kills the part that DOES work.

I found that if you start with the regular events, then add the TASK to the node (not the other way round), you can configure the node properly .

See this JING: http://www.screencast.com/t/6LAXLS2F0cEK

The first part shows that it generates and receives events with just the CLUSTER registered (as before).

Then I add the TASK, choose the event I want to add and try again.

NO events come thru. 

[JÞB]

Just out of curiosity....What shows in the event inspection window?  (2013 feature)

[GregFreeman]

Why do you have the same event reg refnum wired into two event structures (just based on your photo, didn't look at the Jing)? That can cause major issues at runtime. Also, you can bundle dynamic event reg refnums into a cluster, and wire that cluster into the event structure. This is great because if you use a single dynamic event reg refnum for multiple events, your wire is strictly typed and will break in certain situations if you change your events. WIth the cluster method, you can avoid this. 

[CoastalMaineBird]

What shows in the event inspection window? 

Nothing. Absolutely nothing.

[CoastalMaineBird]

Why do you have the same event reg refnum wired into two event structures (just based on your photo, didn't look at the Jing)?

--- Just for the pic.  Just to show that both Event cases had the proper input terminals available.

[GregFreeman]

Man, you're quick. I'll have a look at the Jing.

[CoastalMaineBird]

Hmmm.  I can't explain the weird behavior in the JING just yet, but I did find a problem.

I found it by starting from scratch, copying an example.

When registering events for a task, you MUST do the registration BEFORE THE TASK IS STARTED.

In my code above, the task is already started.  Trying to register events on a running task is futile.

So that is part of my problem.

[CoastalMaineBird]

Man, you're quick.

You misspelled "Man, you have no life.".

😉