how to merge event structures?

[bmishoe]

I have a VI scripting program that reads a text file of registers and outputs an event structure.  It works great because it creates all the controls and indicators that I need associated with the register set along with the backend code (i.e. the event structure).

After I generate all this code, I copy/paste it into the main VI I am developing.  It all works fine.  The only issue is that there are 100 separate register text files.  This means I am left with 100 separate event structures.  Although this works, it takes up a lot of space and I would prefer to combine them.  However, each event structure has anywhere from 15-75 entries, so to manually do this is not an option.

Is there any way to selectively merge event structures automatically?

I guess I could write a labview scripting routine that would get a reference to the event structures in the VI and then merge it...but part of the problem there is that there are a handful of event structures I wish to keep separate just because they aren't associated with the register set I mentioned.

[RavensFan]

It may be possible to script the merger of the event structures.  But that seems like it would be a lot of work.

I wonder do you truly need to merge 100 different event structures.  From what you are saying it sounds like you have 100 times 15-75 (let's say 50), so that'd would be ~5000 events. When you have that much going on, if you should be looking at how to scale the code better.  Rather than having 100 different event cases that sound like they are all doing the same thing, but to different items, you should have one event case that is registered for all the different objects.

Perhaps set it up so that you have dynamically registered events or user events, that way you can programmatically handle the hundreds of controls and how the event structure responds to them.

[bmishoe]

Yes, there are probably a couple thousand different controls the user could click on.  They are sorted across probably 40 tabs that follow a nested structure.  Each register has up to 16 bits, and the user can control the value of each bit.  So an event structure for a given 16 bit register might have as it's first case, bit0, bit1, bit2...bit15: Value Change so that that event structure code executes if any of those bits change.

Repeat that for each register in the block.

Repeat that for each block in the FPGA...

[bmishoe]

Each 16 bit register obviously has it's own address, so I'm not sure how I could scale it any smaller than that.  In other words, I can't make it any more generic than to say, all the bits associated with address x are part of this event structure entry.  And that's what I'm doing...it's just that there are a lot of addresses and therefore a lot of event structure entries.

[GerdW]

Hi bmishoe,

---

So an event structure for a given 16 bit register might have as it's first case, bit0, bit1, bit2...bit15: Value Change

---

That sounds like you should use arrays/clusters more often… 😄

[RavensFan]

One event case can act on multiple controls.  To know which control is the one that generated the event, you use the CtlRef Node on the inner left side of the event case.

But I would still consider using some sort of dynamic event registration.  I think that would be the most flexible.

[bmishoe]

Interesting...can you point me to an example of the CtrlRef node being used?

[GerdW]

Hi bmishoe,

using Ctrl references is quite easy:

One event for different boolean controls. You can distinguish them by their label…

[bmishoe]

hmmm...I must be missing something...how is that different than what I'm doing?

 

[RavensFan]

You are doing something in combination with all controls if any given one of them change.  That is just fine if that is what you need to do.

What Gerd shows is how to do something with a specific control when that control changes.  And that one event case is handling 4 different controls.  The alternative to this is having 4 different cases, 1 registered to each control, and each case only being able to handle that one specific control.  You wind up having nearly 4 times the code doing essentially the same thing.

In your image, it looks like all of your booleans are related.  I would put them all in a cluster.  Then you can have the event case registered for the value change of the cluster rather than registered for each and every control that is related.

Now if you have a second cluster that needs to be handled in the same manner, you can do what Gerd shows.  Have the event case registered for the value change of the two clusters (rather than 2 times the number of controls that you currently have).  Then use the Control Ref to determine which control fired the event, use the New Value node to get the values and send them to the subVI.

Actually I see the relationship between your  booleans is just for binary values.  Instead of having all the math, true/false to 1:0 conversions, and the addition, your control should be a boolean array.  Then you can use the boolean array to number function to get the numeric value directly.  Then you'd have  basically 1/16th the code you already have.