WMassey

Well it kind of hard to tell what you are doing wrong if you don't include a working VI fragment that demonstrates the problem. The only thing wrong I can see from the screenshot you included is that there is no way to terminate the external loops and no way to recycle the event structure once you activate it the first time. Perhaps the pair of them is what is causing the behavior you are seeing. One click of the Terminate takes you out of the event structure (and is discarded) but doesn't stop the external loops and a second click of the Terminate then stops everything immediately because it is not discarded. See the attached VI for an example of something like I think you are trying to accomplish that seems to work. Download File:post-2800-1134513509.zip

Well, if the four external loops are strictly timer driven (no events) and if there is no priority associated with one over another then you may not need to worry about a race condition. A race condition is where you are expecting things to happen in a certain order but because of unexpected circumstances or very closely timed actions, something occasionally happens a bit out of order. If you don't ever care if one action just barely sneaks in and happens before some other action on an occasional basis then you don't need to worry about a race condition. Yes, the dequeue element (or preview queue element) function can have a timeout specified and will set a flag if a timeout occurs. One other thing that may help you to decide how you want to handle your GUI is the frequency that you need to read various controls and write to various indicators. Actually the reading of all the controls should be handled by an event structure (with a short timeout event of its own) that would be integral to your state machine. If all your indicators are to be all updated together then that may be a good reason from grouping all the updates in one or more contiguous states (more complex updates may deserve their own states). If on the other hand some of the indicators only need to be updated infrequently then that may be a good reason to handle the updates just whenever the associated data actually changes. You mentioned graphs. If you want the data displayed on all of them to grow together then update them all at once. If you want the data displayed to grow at a rate that makes sense for the individual data streams, update them independently as needed.

Just some random quick thoughts... Are the four subVIs at the bottom driven by strictly by timers or by events? Does one have priority over another? Is there any race condition you need to watch out for? Have you thought about incorporating them directly into the idle state of the DECIDE structure so that there didn't need to be communication between them and DECIDE? If you do choose to go with queues, you don't need the DECIDE structure to loop - just make it hang on a queue read operation. As far as the control interface goes, it depends on its complexity and what you are trying to do. Go with whichever method is simpler and easier to understand. If there is no reason to use the data outside the DECIDE structure then definitely go with the shift registers.

I have used the Excel Toolkit to write both data and header information to a spreadsheet. It felt weird to use the ActiveX methods to transfer data to Excel for its use but in the end it all sure did work well. An example is in this discussion.

No you did not miss the point and I have also done what you have suggested at various times. I guess I'm like you in that having the control lurking there just to provide a typdef does bother my delicate sensibilities - it's not exactly a valid reason not to do it; I just wish there was some other option like the one I suggested previously. And, FWIW, when I do something like this I now drop all the controls and indicators which I want to hide into a tab control which just has one page/tab and then hide the tab control. I label the tab control "Hidden controls & Indicators" and place the terminal in a prominent location on the block diagram. It makes it very easy to view/hide/find the hidden front-panel stuff.

Ah, but that assumes you have a named wire of the right type to use in the first place. I realized that I missed this capability when I found that I needed (but didn't have) a named wire from the output of an Initialize Array node which had a fairly large typdef'd cluster wire/value as its input. Yes, I could do what you suggest and make an array constant using the typdef, give it a name and use that, but then it would have been a rather large blemish on the block diagram just to get the name. I also know that it is possible to hide large block-diagram constants within tiny single-frame sequence structures but that is, in my opinion, ugly too. It too is possible to hide large block-diagram constants within a one-output subVI dedicated to just holding the constant (indicator) on its front panel, but that always struck me as something of a waste of a subVI call. I just wish that there were a better way which is why I spoke out here.

As things work now, many wires (data paths) have a name associated with them. It may be derived from a control label or a constant label or a VI terminal. This is useful if a group of wires having unique names are wired to a bundle node** since it later allows the cluster data to be accessed using an unbundle-by-name node. If however, a wire does not have a name because it has passed through something like an Initialize Array node or if it has a duplicate name then this bundle to unbundle-by-name option will no longer work. It would be very useful to be able to set (or reset) the name associated with a data path either by directly modifying the properties of the wire (right click option?) or by the insertion of a (tiny) naming node into the wire that would take a name as an argument and change the name of any type of data path that passed through it. ** While it would be possible to use a bundle-by-name node instead, that assumes that the cluster definition already exists. Creating (and later maintaining) the initial definition of the cluster can be, in some cases, more trouble than the job warrants (e.g. temporary data passing through a state machine).

While I have not actually run it in anything more than its tutorial mode, this looks like it might have some promise in building animated demonstrations: http://www.debugmode.com/wink/ ( and I miss the spell checker too! )

As you may have suspected by the lack of any answers (especially positive answers), I don't believe you can do this. In the case of text rings, you can create a front panel control with the text you want and drag it from there onto the block diagram and get a constant that shows the text strings but this doesn't work with the pict ring. Not even if it is strictly type def'd. You could add this to the wish-list forum but I don't suspect it'll happen anytime soon. If you really want pictures on your block diagram you could always drop a case structure onto the diagram, drop individual pictures into different cases and wire it up to an ENUM (or Text-ring) constant that provided the real control for both whatever needed the constant and the case structure. Unfortunately, changing the ENUM constant wouldn't cause a change of the displayed case while in edit mode - that would have to be done manually or with execution highlighting on. Clunky at best.

You are using the 'event structure' and its 'double click' event aren't you? It may not matter but are you talking about an ordinary listbox or a multicolumn listbox? How do you have the 'selection mode' of the listbox setup? Which value are you trying to capture? The double-click event of the event structure does not directly return the value of a listbox control. It will however return the number of the row that is double clicked. Is it possible some other part of your code is also acting on or updating the same listbox control and is responding to a parallel event (or just doing a periodic update)?

Thanks for the reply. I took a look and tinkered with it a bit but have set it aside for now. I was trying to figure out if I could manually construct an IMAQ image datastream but have given it up for the moment.

Using nothing more then the two outputs from the flatten-to-string node, is it possible to determine both the structure and data contained there-in of an arbitrary data stream input into the node? Are there any examples of this?

FWIW, here is a fairly nice, free MD5 checksum program with a Windows (rather than a command-line) interface. I have not downloaded LV 8.0 and tried it against the download (heck, I've got three unopened boxes of it in my office here) but I would hope that all MD5 programs give the same checksum.

Thanks! I've turned it in to NI to see what they have to say. And thanks for the convenient workaround! I had not found that. Just a quick followup... NI has confirmed that this is a bug in 7.1 but 8.0 is OK.

I have an I32 vertical slider control (attached) which has non-sequential values running from -2 to 8 but lacking a value for zero. The control produces the correct values and, if you ignore the placement of the slider on the scale, looks right. But the slider itself, in most cases, never aligns properly with the scale. The slider does not move in even increments from value to value. I suspect this might be a bug. Can anyone else confirm this behavior on their system? Does it work properly in version 8? Download File:post-2800-1131986537.vi

Son-of-a-gun, you are right! That's exactly what I needed. Thanks!

Actually that is what I am using and in this respect a multicolumn listbox and an ordinary listbox behave exactly the same -- you select a line and the entire line is highlighted by a color that is apparently dictated by a system-wide setting. It was that specific color I was hoping to change in one particular case. It's not going to happen.

Ahh. I feared as much. I was hoping to be able to change just one listbox out of several to make it stand out but if it is a windows-wide setting then that won't work. Thanks for the reply though!

For a listbox control/indicator is it possible to specify the color used to highlight the selected item(s)?

You could do something like this: expanding on the code within the no-error case and also in the for loop.

Go to the on-line labview help and enter "customize" and select "controls". More info is here as well. You cannot do what you want with a ring value. You can do it with an ENUM. You could open the TypDef'd .CTL and right-click the ring control/indicator and select Replace --> ENUM followed by an "apply changes" (in the file menu) and it would then do what you want -- assuming it did not mess up other areas of the program that used the typdef.

In the case of IMAQ at least, you can get a small subset of the Vision tools installed with the IMAQ drivers and they would seem to share the same path, even though the Vision toolkit is not installed. Thanks though.

I decided that a bit of a followup was in order here based on something I just discovered. According to this NI page, if you install the NI-IMAQ drivers you will also get a few IMAQ VIs including "IMAQ WriteFile.vi" which will write TIFF files. I'm still not sure what you do about reading them but it now looks like you can at least write TIFF files without having the Vision toolkit installed.

I need to put together a simple RS-170 image display vi for a target machine that does not and will not have the IMAQ Vision toolkit installed. My development machine does have the toolkit. I wish I could "turn off" the toolkit temporarily on the development machine so that I didn't have any question about which library VI's did or did not belong to the toolkit.

Within LabVIEW: Help --> Find Examples --> Browse --> Fundamentals --> File Input and Output --> Write to Text File.vi You really should make a better effort to find the answer on your own before asking for help here