Saverio

The stock controls don't have the capability you're looking for. Other options: trap the value change event, and if you see the "rollaround", change the value back. Hide the up/down arrows and place your own buttons on there to increment/decrement the value I am, of course, assuming you're using an event structure.

This is also another cross-post from NI: http://forums.ni.com/t5/LabVIEW/How-to-get-time-stamp/td-p/2136340 At some point along the way it seems the question changed. I lost track jumping back and forth.

This is a cross-post from NI, where the user has received numerous suggestions. Please keep these in mind when providing suggestions/comments.

I have to admit that wasn't all that clear from your response, as you basically said that you thought Shaun's suggestion was sufficient, and he simply said to unbundle the error cluster. Nothing was mentioned about the initializing/closing. Well, at least it's clear now.

The code is designed on the premise that "everything is working". If the VISA resource control is set to the "correct" value, then the code will run without error (barring communication errors). Opening and closing the serial port on each iteration. How is this a good thing? Yes, checking for the error code will stop the loop, but it does not eliminate the fundamental problem with the code that I pointed out. On the NI forums we see this all the time, and we tell those who do this the same exact thing (all the time): initialize before the loop, close after the loop.

Your fundamental problem is that you are opening/closing the serial port in every iteration of the loop. This is a waste of time and resources. The serial port should be opened once, before the loop, and closed once, after the loop. If you're concerned that someone may choose a VISA resource that does not correspond to a serial port, or to the wrong serial port, then you need to check before you start your loop. You don't show the rest of your code, but a simple state machine could be used for your architecture. You'd have an "Init" state where you mess around with controls (as you appear to be doing below the loop), a "open serial" state where you check the port and verify you're connected to the right port, and a "close" state where you close the serial port, and do any cleanup. Additional comment: you can replace the big Concatenate String with a Format Into String function.

Well, that changes things considerably, now doesn't it? It would have helped to have this information up front.

Well, yes, obviously, but is that a concern here? Just because something is possible doesn't mean it's relevant in this case.

Isn't that what you were after? If the subVI is running on its own as a "regular" subVI then its front panel would not be open. When in a subpanel the front panel has to be open, so the subVI can check itself based on whether its front panel is open. The property would still be true when the VI is running on its own, but does that matter in this case?

What about looking at the Front Panel Window's Open property?

Prabhakant, I suspect he probably finished his homework assignment by now.

I don't think your problem has anything to do with LabVIEW. I'd check your system if I were you.

Nobody has mentioned the Wikipedia entry: http://en.wikipedia.org/wiki/CAN_bus, which is the first place I would have gone to get a basic understanding of what CAN is.

Which "rules for floating point comparison" were you referring to? I'm assuming by the inclusion of NaN in parenthesis you're referring to comparing against NaN. However, there is a more general rule: comparing floating point numbers using Equal or Not Equal is almost always a bad idea and will not always work. Thus, if your clusters contain floats, the top two approaches are null and void. Which makes the choice kind of simple.

For shame! Tsk, tsk.... A less polished version of Mellroth's solution was provided in a post all the way back in 2002 in the LabVIEW forums over at NI (I'm sure you know the place ): http://forums.ni.com/t5/LabVIEW/how-can-i-make-a-ring-control-resize-itself-to-display-the-whole/m-p/47562/highlight/true#M30020 All tongue-in-cheek, of course.