Is this move kosher?

[GHernandez]

I have a ring structure wired outside the loop and a shift register and a local variable for the ring structure. I am not sure if this ok move.

[GHernandez]

Please take into consideration this will be implemented on a pda too. This is made in lv 8.0, i don't have access to 7.1

[Khalid]

Does the PDA support Event Structure?  And what about Property Nodes (RingText.Text)?  If yes, that would make this trivial. 

-Khalid

[tst]

I haven't seen the beta version of PDA 8.0 and my 8 eval expired, so I can't look at the VI, but from what you said, and based on previous experience with the PDA module, the answer would seem to be yes. Shift registers exist; the event structure exists (it supports value change events, and by now probably mouse down events for all controls); it used to have "property VIs" instead of nodes, but that was now replaced and since one of those VIs allowed you to control a ring's strings, I assume you can still do that. So, again, based on the description, the answer is probably yes.

[Glennaebad]

"GHernandez" <x@no.email> wrote in message
news:1133831445073-296265@exchange.ni.com...
> I have a ring structure wired outside the loop and a shift register and
> a local variable for the ring structure. I am not sure if this ok move.
>
>

Only if it has been passed by the chief Rabbi.

Glen

[altenbach]

Yes, an event structure would probably be better.

A few comments on your code:

1. Your loop definitely needs a wait statement. It is an UI loop thus does not need to spin more than a few times a second. Place a 100ms wait in the big empty case, else the loop spins as fast as possible, gobbling up all available CPU.
2. It is not clear why you invert the output of the "equal" operation, just use "not equal" or swap the cases.
3. There is no need for any local variables. Use the ring terminal inside the loop and initialize the shift register with some "impossible" value (e.g. -1 or 9999), this ensures that the display is updated to the correct value on the first iteration. In your code, you would not be able to select "a" if "a" is already the ring value. Since they are equal, the string does not get updated and remains blank.
4. It is usually much easier to use "stop if true". Now you only need a single TRUE constant, everything else can be set to "use default if unwired".

Attached modified VI shows some of the ideas.

[GHernandez]

What you did was very compact.  But i don't think the Labview PDA module supports property nodes.  Also, i plan to turn on specific parts of hardware on, depending on what was selected via the ring menu.  I will also forgot to slow the loop down, i will do immediately. thank you for the help.

[altenbach]

Sorry, I am not familiar with the PDA module. Still, instead of the property node, you could create a diagram constant with the same content. It would still eliminate the stacked cases and would make the diagram easier to debug and maintain. 😉

If you later need to add another entry to the ring, you only need to change the array constant instead of adding another case, entering the condition, and wiring it up ;). Note also that if you select on the text instead of the index, you no longer need to count the cases to see which one is "quit".

Modify as needed. 😄

[tst]

I haven't seen Altenbach's solution either, but I will refer you again to the "property VIs" in the Application Control palette. One of them allows you to set the strings in a ring, just like the Strings[] property node. You can only see these VIs when you have selected the PDA as your target.

[GHernandez]

What i decided to do was to intialize the shift register to -1 and got rid of the local variable, and check if the value of the the menu ring has changed,if it has, then execute the command, if it is still the same, then don't execure the command. I am currently developing the application in LV8.0, but awaiting the LV 8.0 PDA module. I was led to believe by an NI engineer that it should be out mid december.