LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Generate user events by name?

Solved!
Go to solution

Hi,

 

When I generate a user event the event name is equal to the label of the input data type. Example: the user event name will be "Tray closed"

1984_0-1694528259735.png

The events are bundled into a cluster.

 

Just for the example sake lets say I need to create 1000 user events. Its quite easy to create a cluster with 1000 event refnum and name them correctly so the event structures registering to these event will know the event name and datatype.

 

The problem is creating the 1000 user event refnums. I couldnt find a way except to copy the create user event node 1000 times and rename the boolean. Like this:

 

1984_1-1694528565050.png

Assuming that the datatype is always boolean and I have a list of event names is there a way create the events in a for loop?

 

Thanks.

 

0 Kudos
Message 1 of 14
(1,546 Views)

You can make 1 event that has a cluster with a string and the type.

 

Even better replace the string with an enum type def.

 

Optionally (not an improvement per se) replace the Boolean with a variant. nOw you can send anything.

 

Alternatively, you can make a container (a map would work nicely) with the strings and user event references.

 

Upside of keeping the map vs 1 event, is that you can register for individual events (efficient).

Downside of keeping the map vs 1 event, is that you have to register for individual events (more code).

0 Kudos
Message 2 of 14
(1,542 Views)

@1984 wrote:

Assuming that the datatype is always boolean and I have a list of event names is there a way create the events in a for loop?


You could try to script this.

 

I don't think it will be as convenient as you'd think.

 

Anything more than 2 you want to use arrays and loops, not copies.

0 Kudos
Message 3 of 14
(1,533 Views)

I tried to abstract my question, but it seems its worth going into the details. 

 

The scenario is that I have about 30 digital input lines. So far the architecture developed by others works in a way that each module which needs to know the value change of the digital inputs polls the value of the inputs and takes an action if a change is detected. So these VIs are not event based.

 

I'd like to at least experiment with making these VIs event based by creating all these user events, polling the values in one module and generate an event if a value change occured. The rest of the modules will register for the events and act on those. By this - I hope - I will end up having one VI which continously polls the values which is more efficient and the rest of VIs become easier to debug.

 

I can create 30 user events easily manually, my question was rather out of curiosity. I could handle the problem as you suggested with a cluster or a map, but that means there is really one event triggered many times and in the rest of the VIs I'll capture that singular event gazillion times. Besides that I need a decision making routine in all these VIs to see if that VI is at all interested in the content of that event.

 

To simplify: one VI may only need to know about DI_1 and another one needs only DI_2. With my approach I can unbundle my cluster and register only to the event(s) the given VI needs. With a map/cluster solution all VIs need to register for the same event and within the event structure I need to select if I'm interested in content of the actual event. Given that I have (only) 30 digital lines this would be very inconvenient as every VI need to use any of the events will receive tons of events what they are not interested in. So at the end I think I end up something really hard to debug because of the constant influx of the events.

 

I hope now my original intent makes more sense. Also wondering what are the other sensible ways to handle the scenario. I think events would be nice, but sure that others solved this in different ways as well. 

0 Kudos
Message 4 of 14
(1,469 Views)
Solution
Accepted by topic author 1984

@1984 wrote:

I hope now my original intent makes more sense. Also wondering what are the other sensible ways to handle the scenario. I think events would be nice, but sure that others solved this in different ways as well. 


It confirms how I read your initial question.

 

The answer is the same.

 

You'll have to either

+ throw everything in one event, and then you'll get all events and filter them based on the data, or

+ manually create the events

 

Of course you can mix...

 

The only thing manually created events give you is the name of the event in the event structure.

 

If you make a map of events, with the name as a string, you can dynamically register for only the desired events. If the event also has an ID (string\enum) you can register n times for individual events, or 1 time for n events. In the event structure, you'll get only individual events you register for, and than use the id to filter. This is more or less required, as the event name isn't useful.

 

You can actually make a bin of events, and amend the name of the registered event with a cluster (if there's >1 element):

wiebeCARYA_0-1694592223379.png

 

This is cumbersome though. If you put the code in a subVI, you'll often not get updates, and it can get quite confusing. 

Message 5 of 14
(1,453 Views)
0 Kudos
Message 6 of 14
(1,411 Views)

You could do this by creating an array of user events, one per Digital Input or whatever, and "naming" them with an enum that you use as an indexer for the array of events.

 

Proof of concept:

Kyle97330_0-1694623840955.png

 

If you run this you will see that one loop each fires for DI 0 and 2, both loops fire for DI3, and none fire for DI1.

 

All events do have to share one case inside of the event handler, but it's trivial to just pass the enum into a case structure and put the code for each separate digital input in that structure, which is then named for each value change that it cares about, and should never fire for any digital changes that particular subVI doesn't care about.

Message 7 of 14
(1,398 Views)

@Kyle97330 wrote:

You could do this by creating an array of user events, one per Digital Input or whatever, and "naming" them with an enum that you use as an indexer for the array of events.

 

Proof of concept:

Kyle97330_0-1694623840955.png

 

If you run this you will see that one loop each fires for DI 0 and 2, both loops fire for DI3, and none fire for DI1.

 

All events do have to share one case inside of the event handler, but it's trivial to just pass the enum into a case structure and put the code for each separate digital input in that structure, which is then named for each value change that it cares about, and should never fire for any digital changes that particular subVI doesn't care about.


That will get slower and slower when you add events.

 

There are going to be a few hundred. It might add up. Of course, you could use a map just like you've used an array. It will still get slower and slower, but at log(O) in stead of (O).

 

You'd also have to distribute all user events to all event structures, while for previous solutions only the registration needs the specific user event . No problem if it's all contained in a class of course, but it might be restrictive.

 

You are limited to an array of Boolean user events. If you ever want to add another data type, you won't be able to build the array.

 

You'll not have the name of the event in your event structure... But that's (practically) not achievable at all anyway.

0 Kudos
Message 8 of 14
(1,346 Views)


You can actually make a bin of events, and amend the name of the registered event with a cluster (if there's >1 element):

wiebeCARYA_0-1694592223379.png

 

This is cumbersome though. If you put the code in a subVI, you'll often not get updates, and it can get quite confusing. 


While this is not a 100% solution to my problem it still helped me a lot to simplify the task so it is definitely worth to be marked as the solution.

 

See my implementation on the snippet below. Yes, the cluster has to be generated manually but that hell lot easier to do than to copy the create user event part of the code. Also if once I'll really need 1000 events then scripting the generation of the cluster is also a lot easier than generating a VI with 1000 VIs.

 

Thanks!

 

event generation.png

 

Message 9 of 14
(1,330 Views)

It seems it can be automated even further:

 

event generation2.png

Message 10 of 14
(1,319 Views)