Hello,
Glad the last resopnse was helpful, and sorry you don't have the event structure to build with 😞
Anyway, to solve the multiple aggressor problem, how about defining a new section for each agressor? You could automate the naming as aggressor1, aggressor2, and so on quite easily. For example, you can hold a count value and use the Number to Decimal String VI to get your count in string form, then concatenate it with the word aggressor. I attached a simple counter VI which will illustrate the count keeping and number to string conversion process (notice the count is a string), as well as the idea noted in the next paragraph.
As far as efficiency is concerned, there is nothing wrong with a state machine architecture - it's great and commonly used! Ironically, I would recommend adding a small piece of code to make your program less efficient - let me explain. You may consider adding is a 0 ms wait statement in the while loop. The reason for this is that such a wait statement, although telling LabVIEW not to actually pause, will offer up the possibility of a thread swap to the OS. Not that such a swap will NOT occur without the statement, but this way you are offering that possibility, which will make the overall fluidity of your system better when the application is running. This is because when you use a state machine architecture to handle user interface events, your code is always requesting processor time (even when the user is doing nothing, the default case is executing!). This is in stark contrast to the behavior of an event structure, which basically allows LabVIEW to sleep until a registered event occurs. Thus, to prevent LabVIEW from being a bit of a processor hog, you can use a wait statement (such as the wait ms function in the time and dialog palette) even with a 0 ms wait time.
Ok, I hope this helps!
Best Regards,
JLS
