Event structure to detect the element operated in a cluster

Hi,
i have a cluster with #60 booleans in it with all different labels (1...60).
i have created a event (for whole cluster, not added individual 60 elements) in event structure to find the label of the element.
when i try to fetch the label.text, i am able to get only the cluster label not the element.
please give suggestions,, so that i wil be able to extract the individual label in a cluster.
Thanks in advance
phani
phani srikanth

... and if you don't want to deal with all these references and prperety nodes inside the event structure, you could do as follows. same difference.
...and if the cluster is of mixed datatype, wire the output of search array to a case structure and act according to the changed element.
Personally, you might want to use an array of boolean instead, simplifying the code even more.
LabVIEW Champion . Do more with less code and in less time .
Attachments:
BooleanInCluster.png ‏11 KB

Similar Messages

  • Event structure to detect value change of a control within a cluster in an array

    I have 1D array that contains a cluster. The cluster contains a numeric and a boolean control.
    If the user starts to edit the numeric control value i would like to call one subVI, and if the boolean control value is changed, call a different subVI.
    The array control on the front panel allows the user to edit a number of the array elements. 
    I would like to use an event structure to detect a value change in the cluster. When editing the Events, in the Event Sources panel i get the option to select only the array, not the cluster within the array or the controls within the cluster. Can the Event structure be opened up to show controls within clusters and arrays?
    The solution i am using is to detect a mouse up event on the array and then use property nodes to  determine if the key focus is on the numeric, and  a case structure to determine which subVI to call. This works, but is there a better (simpler) way?
    Thanks, Blue.

    Thanks for the responses guys.
    The tricky bit was that i wanted the numeric control values to flag they were going to be edited, so i could call a subVI, before their values were changed by the user. This is done by using the key focus property node, - i need to detect changes on the fly rather than post the event.  Probably didn't make this clear enough in my original post. 
    The array is of variable size depending on if the user decides to insert or delete elements. The user also has the option to click and edit the array without having to do to much scrolling through the array index, as the FP shows several elements at a time. The Event Structure does a good job of automatically determining which element in the array is being edited, and returning those values to the property nodes. Turned out simpler than i thought it might be at one point!
    Cheers, Blue. 
    Message Edited by BlueTwo on 01-15-2009 06:52 AM
    Attachments:
    evstrct1.jpg ‏63 KB

  • Firing events from a Menu using Event Structure - all in the same Event Window?

    I have an ap where I have three menus, and several selections from
    those three menus. I'm trying to keep everything within the Event
    Structure, but it seems that ALL of the events fired from the Menu must
    be contained within one "frame" of the Event Structure, that being the
    Menu Selection (user) Event. In other words, if I have 16 events that
    can be fired from the menu, do I have to put them ALL in this one event
    frame?
    I can't seem to use a T/F indicator within the Menu Selection (user)
    Event to access another Event. For example, within the Menu Selection
    (user) Event, I placed a boolean named X and can turn it on with a menu
    selection. Now, make a new Event Structure to look for X Value Change -
    doesn't work.
    Message Edited by Broken Arrow on 11-30-2005 10:24 AM
    Richard

    I use one event, Menu Selection (user). to trap all of my menu events.  Use Item Path and / or Item Tag to figure out what menu item was selected then branch code based on selection.  Wtih Booleans and menus you need to update the state of the boolean on the menu by setting it True or False.  It doesn't automatically toggle like you would expect.
    Matt
    Matthew Fitzsimons
    Certified LabVIEW Architect
    LabVIEW 6.1 ... 2013, LVOOP, GOOP, TestStand, DAQ, and Vison
    Attachments:
    menuSelect.JPG ‏45 KB

  • Parallel Structure Part 2 - The Frankenstructure

    After deciding to post an idea for a "parallel" structure, a search revealed the idea for a Parallel Execution Structure has already been proposed by gvholland here. 
    I gave my kudos to this idea because I believe it would be very useful.  In order to make a parallel structure even more useful, I propose adding some features that would make it more convenient for those of us who might use it in code that must execute in parallel for performance and functional reasons.  It has been commented on the other thread that parallel code should be placed in subVI's, and I concur with this view.  However, there are instances where this is either inconvenient or impracticable.  Consider the following example:
    An application needing to perform simultaneous PID control on 32 channels must execute in parallel (only 8 channels shown for clarity):
    Now quadruple the number channels in this scheme, and you can have a pretty big diagram with lots of wires.  Also consider the routine task of initializing that “clustosaurus”  or “classosaurus” as in this example:
    We've all probably tried the scheme wherein we put a case structure inside a FOR loop and wired the iteration terminal to the case selector, as in these examples:
    That's clean and easy, and allows the user to create instances of the reentrant VI by duplicating cases.  But that architecture forces the vi's or code to execute sequentially.  The new parallel FOR loop can boost performance of these techniques, and create parallelism.  But I would like a basic parallel structure that cleanly handles some routine tasks by adding some useful I/O nodes, ala the InPlace Element Structure.
    I propose the following structure, or something similar:
    This structure is drawn here with some proposed I/O nodes and tunnels.  This is by no means the complete set of I/O that might exist, but rather a starting point.
    Cluster unbundle/bundle node:
    This node accepts only “brown” clusters, or clusters of Booleans.  The elements are passed to each frame in corresponding index order, element 0 to frame 0, and so on.  Once added to the structure, a single unbundle/bundle terminal pair appears in each frame. Much like a bundle function that has its center terminal wired, the bundle terminals may be left unwired.  The values of unwired elements remain unchanged.  Any cluster wired to this node must have the same number of elements as the parallel structure has frames.  If not, the wire is broken.
    Array index/replace node:
    This node auto indexes an incoming array and provides a replace array element node on the right.  Note there is no index value IO as with the IPE, since the parallel structure auto indexes the array and distributes/replaces the elements across the frames.  If an array has less elements than the number frames at run time, the node returns default data for the undefined elements, exactly as an index array function does, but the structure returns a warning or error (I can’t decide which).  The output array would always have the same number of elements as the structure has frames, or the same number of input (can't decide which) .  The replace element node on the right must be wired in every frame, just as a replace array element structure must have all of its exposed elements wired.
    Cluster unbundle/bundle by name node:
    This node is tricky, but I decided to take a stab at it anyway.  The node is created and visible on both sides of the structure.  However, unlike the IPE, the unbundle/bundle terminals on either side can be of different sizes and element selections, and can optionally be unused on either side, or both sides, within the individual frames.  Unused terminals appear with the same symbol as the center terminal of a bundle function, as shown in the proposal drawing.  If an element is selected for bundling within a frame, then it is unavailable for bundling in all other frames.
    Indexing and non-indexing tunnels:
    Non-indexing tunnels function somewhat like they do on a sequence structure.  Input tunnels provide data to all frames, non-indexing output tunnels may only be wired in one frame.  Unlike sequences, however, the data arriving at output tunnels would be free to flow out of the structure immediately, which will seem weird, and violates the "whole structure must complete" convention.  But remember, this is a parallel structure.  Like sparks shooting off the bolts in the monster's neck while it's alive, it's gonna be be weird by default.
    Indexing tunnels are different.  Like the auto-indexing node, auto-indexing input tunnels distribute the array elements across the frames.  If the array size is smaller than the number of frames, the frames either execute with default data, or the undefined frames don’t execute, and the structure returns an error or warning (help me define this).  Auto-indexing output tunnels behave like output tunnels from case structures; either all frames must be wired, or the tunnel must be configured to use default data if unwired.  Unlike the non-indexing output tunnel, data from this tunnel is not available until all frames have completed execution.
    Error I/O Nodes:
    There are error inputs/outputs for the structure as a whole, and for each individual frame.  The structure error IO is situated in the lower left and right corners, naturally.  The frame input and output terminals can both be optionally hidden or exposed in each frame, and also slide independently of each other up and down the left and right sides of each frame in which they are exposed.  The structure distributes the incoming error among the exposed frame error input terminals, and merges the frame output error values to the structure output terminal, along with any messages generated by the structure itself.
    So what do you do with this “Frankenstructure”?  Well, here are a couple of the aforementioned examples rewired using this hypothetical beast:
    Of course there could be other cool things, like a CPU core selector for the frames, etc.  Just let your imagination, (or nightmare, depending on how you see it) run wild!

    @JackDunaway  Sorry the example is not more clear, but the additional frames contain all the reference initializations in the 'clustosaurus example pic', and there should be 0..7 frames instead of 9 frames total.  As for why the parameters are not arrayed, I just wanted to show an example of how the structure could operate on a cluster, and because the original example pic used clusters.  They might very well be arrayed.  If they were, an indexing tunnel could be used.  It's true you could use a parallel FOR loop for the PID example, but you would have to nest a case structure to hold the multiple instances of the reentrant PID vi.  I don't like this solution, and believe LabVIEW should have a Parallel Exeuction Structure dedicated to the task.
    @Jim Kring  You are correct.  It is a lot like the parallel FOR loop, but I believe it is (or would be) much more powerful.  Please reconsider the descriptions of the I/O terminals, which borrow some of their functionality from the InPlace Element structure.  The parallel loop structure cannot operate on most iteration dependent data (data passed from one iteration to the next in a shift register), because it cannot guarantee the order of exectution of the parallel iterations.  Neither would this or any other parallel structure, but the I/O terminals, particulary the cluster unbundle/bundle by name, would help manage the code going in and out, and allow the parallel frames to operate on the same data structure in memory.  How would you use a parallel loop structure to update the elements of an incoming cluster? Also, you have to nest a CASE structure in the parallel for loop if you want different code at different parallel iterations, a messy solution in my opinion. This proposed structure overcomes some of these problems with the specifically designed I/O terminals I have outlined.  I admit they may be far fetched, but I wanted to make a start and maybe spark a discusion. A parallel programming language without a dedicated parallel execution strucure seems incomplete to me.  I don't think a modified FOR loop quite makes it.
    Thank you both for commenting on this idea.  As two well respected developers in the community, I value your input.

  • How can I stop an event structure detecting keydown events until the vi has initialised?

    My application has a sequence structure with 3 frames. First one initialises some front pane objects and controls, the second communicates with an external device via a serial port to a start condition and waits for this to complete by polling the device. The third contains the event structure which reads the device when the spacebar is pressed. The problem is that any pressing of the spacebar when the application is in the first 2 frames of the secquence structure is stored and executed as soon as the third frame becomes active. I have tried using dynamic Event registration but to no avail. Am I doing something wrong? can the keyboard be disabled until the second frame complete
    s?

    I usually avoid sequence structures in favor of driving execution order through data dependency (error clusters are great for that). However, since you've already got one, you coul try to add another frame right before your event structure. In that frame, place another event structure that can trap that stray keyboard event. Put a tiny timeout value on it so it doesn't appear to "pause" your VI's response. That event structure will catch any bogus key presses that happen during initialization.
    Having said all that, I still think the behavior is not proper. The event should not be handled if it happened before your VI gets to the event structure. For now, you can try that workaround.
    Daniel L. Press
    PrimeTest Corp.
    www.primetest.com

  • Event structure will hang if i click the button fast

    i trying to debug the program, and i realise that the event structure will hang the program is if i click the button that event structure detecting fast,
    it will hang and stopped there...
    is this a bug or what?
    even i place a time delay in it also no use...
    the event is mouse down for button

    Hi AxE,
    I apologize for the oversight. Please find the attached VIs (now converted to LV 7.0). Apart from changing the "mouse down" event to "value change", I have also changed the mechanical action of booleans to "latch when pressed" . This would change the value of the button only during the duration it is pressed. As soon as it is released, the value of the button will revert back to its default value('false' in our case) so we dont need to change the value of the button inside the event case.
    Windows.cpp error in Line 2978 has indeed been reported to National Instruments. The LabVIEW R&D team is investigating the error.
    Regards,
    Ankita A.
    National Instruments
    Attachments:
    AxE's_TDS_420A_Application_Test.vi ‏155 KB
    CallWF.vi ‏20 KB
    RecordWindow.vi ‏182 KB

  • How can i use the same front panel graph in more than one events in an event structure?

    i want to display the signals from my sensorDAQ in a graph.but i have more than one event in the event structure to acquire the signal and display it in the graph.the first event is to acquire the threshold signals and its displayed in the graph as a feedback.after the first event is executed, i will call the second event,where the further signals are acuired and compared with the threshold signals from the event 1.my question is how can i use the same front panel control in more than two events in the event structure?please answer me i'm stuck.
    Solved!
    Go to Solution.

    Hi,
    I have attached here an example of doing the same using shift registers and local variables. Take a look. Shift register is always a better option than local variables.
    Regards,
    Nitzz
    (Give kudos to good answers, Mark it as a solution if your problem is Solved) 
    Attachments:
    Graph and shift registers.vi ‏12 KB
    graph and local variables.vi ‏12 KB

  • Can I have multiple event structures with the same event cases?

    Hello, 
    I'm doing an application that reproduces the front panel of the HP6675A power supply. To achieve this, I have done a state machine with different states
    (initialize, measures, voltage, current, ocp, ov, store, recall, etc). In each state, should have an event structure that catches the events of the buttons, like for example: if the current state is the Voltage mode and the user press the current button the next state will be the Current mode. For this in each state of the state machine should be the same event structure with the same events.
    My problem is that the Vi doesn't work properly when I have multiple event structures with the same event cases. There are some possibily to do this, and how? Or is impossible to have multiple events? I have been reading some posts, but I don't find solutions. 
    Any help is appreciated.
    Thank you very much.
    Solved!
    Go to Solution.

    natasftw wrote:
    Or as others mentioned, make two parallel loops.  In one loop, have your state machine.  In the other, have just the Event Handler.  Pass the events from the handler to the state machine by way of queues.
    A proper state machine will not need the second loop.  The "Wait For Event" or "Idle" state (whatever you want to call it) is all you really need in order to catch the user button presses.  The setup is almost there.  Maybe add a shift register to keep track of which state to go to in the case of a timeout on the Event Structure.
    There are only two ways to tell somebody thanks: Kudos and Marked Solutions
    Unofficial Forum Rules and Guidelines

  • How can we change the name of dynamic events selector label in Event Structure

    When retriving references to Control that are contained in a cluster. The default name that
    appear in the Event Structure is: : Mouse down.
    I have found a workaround to correct the problem. But I would apreciate a more convinient way to do this.
    This is the workaround I found to change the names in the Event Structure
    I cast the References using a Reference constant and I change the label of
    that constant.
    See the VI for more detail. It is well commented.
    Is there any way to change the name of a dynamic event without doing the
    cast trick?
    Attachments:
    DynEventStructureName.vi ‏44 KB

    I agree!
    I can't top this approach.
    Ben
    Ben Rayner
    I am currently active on.. MainStream Preppers
    Rayner's Ridge is under construction

  • Is there a way to add an event to the event queue handled by the event structure?

    I am using an event structure to control the flow of a program. In one case I want to change the state of a switch and then have the event structure catch this exception and handle it. It works if the user toggles the switch, but doesn't seem to when it is done programmatically. Any suggestions.

    Hello,
    LabView User's manual says:
    "Use Events for Direct User Interaction Only
    Events wait only for direct user interaction on the front panel. Events do not work if you use VI Server, global variables, local variables, and so on to change VI or front panel objects programmatically."
    However, you can have a look in Example Code, there's some applications generating events programmatically, maybe that helps you. (Search for event structure in support).
    Hope that helps,
    SBC

  • Where is the Event Structure?

    I am sure this is a stupid question but....
    I just upgraded from LabView 6.0 to 6.1. I opened a new vi all excited to try out the new event structure, but I can not find it. It is not in my functions>structures palette. Is there something I am missing?

    It seems to me that national instruments was kind enough to provide you with a new splash screen for the four or five hundred you probably had to shell out to get the upgrade.
    I'm pretty displeased with the way ni presented that info, since the event structure was really the only reason to upgrade, oh wait that and the "handy" auto selector tool. Which all they should have done is actually explained that if you use tab and spacebar you can switch between the four and two (respectively) most popular tools for either the block diagram or the front panel. For that information is infinitely more useful than the tool, and infinitely less annoying (meaning it actually does what you want it to).

  • How to control the tab control using event structure?

    Hi,
    I am using tab control and event structure in the program.
    When i run the application event is not happening for the active page.
    When user switches from active page to the other page then event is taking place for all pages
    So, how to get the event trigger for the active page when the application is started
    For more clarification i am attaching the code "Test Control Tab using Event Structure.vi"
    Attachments:
    Test Control Tab using Event Structure.vi ‏52 KB

    You have a basic misunderstanding of dataflow. Maybe you should start with some tutorials or study some of the examples that ship with LabVIEW.
    The event structure belongs inside the while loop, and not vice versa. RIght now, the event structure only runs exactly once and never again.
    If the stop is pressed first, the VI will stop. Game over.
    If the tab control is changed (from any state to any other state!), the inner loop will spin forever as fast as the CPU allows, either executing one or the other case. It just reads the tab terminal to decide which case to execute. Changing tab never triggers any events. The VI is trapped inside the event until stop is pressed to stop the VI.
    you were closer to a reasonable program in the other thread:
    http://forums.ni.com/ni/board/message?board.id=170&view=by_date_ascending&message.id=287905
    Have you tried execution highlighting? Maybe things would become more clear of you do.
    LabVIEW Champion . Do more with less code and in less time .

  • Are user events valid before the event structure executes?

    If I create and register for a user event and immediately generate that event before my event structure has seen the registration refnum, is the event still guaranteed to be seen by the structure? That is, are events queued up? It works but I am wondering if I can rely on it. I am very sure that I can but I am creating some production code and want to be assured that I am not just taking advantage of a bug.
    A picture is worth a thousand words.
    =====================
    LabVIEW 2012
    Solved!
    Go to Solution.

    Generally, Felix's explanation is correct and the queue exists from the moment the register node executes, so the answer is that you can rely on this.
    You should, however, be aware that when playing with dynamic registration you can experience some unexpected side effects, as you can see, for example, in this LAVA thread - http://lavag.org/topic/13607-dynamic-event-reregistration/
    Another example would be this - http://lavag.org/topic/13970-unexpected-event-structure-non-timeout-behavior/page__view__findpost__p...
    Or what happens if you split the registration refnum to more than one event structure (hint - NEVER do that).
    Try to take over the world!

  • Unexpected effect of Lock Front Panel in Event Structure

    I have been using LV intensely for only a short time, although I have dabbled with it many times since its first appearance. The "problem" that I have had may well be the intended behaviour, but it just seems unintuitive to me. I'm writing a small application to take measurements from a USB instrument. I have already written a basic driver for the instrument, which the application calls, and the driver is working as expected. In the application, the user can configure various settings and then click an Execute button to transfer them to the instrument. The click event is handled in an event structure along with other events. Since some of the instrument operations take an appreciable time, the first action that occurs in the click event case is to disable the Execute button using a property node so that further clicks are ignored until the operation completes, at which time the button is re-enabled.
    When disabled, the Execute button is grayed out as expected and clicking it has no visual effect. However, it seems that clicks made during the disabled period are still queued and acted upon when the button is re-enabled, causing the operation to be repeated.
    It is the solution I have found that seems unintuitive to me. The Lock Front Panel check box was checked (by default) for the click event, and I assumed that this would be the correct setting. However, unchecking the Lock check box actually makes everything worked as expected. Click events occurring during the disabled period are now ignored or discarded. I'm not suggesting that this is a bug, but I'm interested to learn why it happens, if anyone can explain. I have attached a picture of a simplified version of the event case.
    Attachments:
    Sample.png ‏7 KB

    I would say what you see is expected behavior, even though it's a bit complicated.
    The "Lock front panel until the event case for this event completes" option will only defer clicks and other things generating events until the current event handler completes. So this means that the click is placed in a queue and only evaluated once the event is finished. At this time, the button is no longer disabled, so an event is generated.
    When the "Lock front panel until the event case for this event completes" is not checked, the click is immediately evaluated, but it's happening on a disabled control, so it does not generate an event.
    From the LV help:
    By default, when an event enters a queue, LabVIEW locks the front panel that contains the object that generated that event. LabVIEW keeps the front panel locked until all Event structures finish handling the event. While the front panel is locked, LabVIEW does not process front panel activity but places those interactions in a buffer and handles them when the front panel is unlocked.
    Note If an event case that locks the front panel takes a significant amount of time to execute, consider using the Set Busy function or displaying a dialog box to notify the user that the front panel is locked.

  • Local variable event structure

    Hi,
    I am using an array control and event structure for detecting changes in the array value.
    At first,I have performed changes in the array(during runtime) and the event structure detected it.
    The next step was adding a parallel while loop in which I am writing to the control array(using local variable).
    During the runtime the layout of the array indeed changed,but the event structure didn't detect it.
    I have attached 2 figures :1)The loop of the event structure 2)the parallel loop.
    Is it possible working in such way?
    How can I make the event structure detect changes the software performed in the control array?
    Thanks,
    Leonid
    Solved!
    Go to Solution.
    Attachments:
    event.PNG ‏43 KB
    update.PNG ‏34 KB

    This is a long discussion about "red flags"
    Norbert
    CEO: What exactly is stopping us from doing this?
    Expert: Geometry
    Marketing Manager: Just ignore it.

Maybe you are looking for