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.

I remember seeing this a few years back. There wasn't much more provided beyond a post in the NI Community, which included a paper on the whole thing. I don't think it ever went beyond that.

Back for more homework help? It sounds like you don't have much programming experience, so it's not clear what kind of answer you are expecting beyond what has already been said. The only other thing I will add is to not use this to search an array of floating point values. If you do not understand why that is, I'd suggest starting here: http://stackoverflow.com/questions/1089018/why-cant-decimal-numbers-be-represented-exactly-in-binary

We had first encountered this way back in 2007. It's good to see that MS did not abandon this project.

Your VI appears to be foobar'ed. Have you tried opening a backup?

I posted an example here that you can take a look at.

Ummm... right in the article that you linked to it says: "The file must be named xxx-errors.txt, where xxx is the supplied name" And, in the LabVIEW Help for the page that discusses the custom error codes file it says: 6. When you are done editing the error codes file, click the Save button to save the error codes file in the labviewuser.liberrors directory. You must save the error codes file in the format xxx-errors.txt, where xxx is a name that you supply.

For the windows selection you might be thinking of this: Windows API Function Utilities (32-bit) for LabVIEW

The windows udpate service is called wuauserv on Windows, and actually runs withing the generic svchost process. When Windows is doing its update check you'll see wuauclt.exe running in the list of processes.

Have you tried contacting R&S? Without knowing what files are where where we're sort of blind...

That link is a page explaining the net command. The user already knows what the command does. He's asking what the wcontrol service is, specifically. If I'm not mistaken, the wcontrol service is one of the services for Symantec's Enterprise AntiVirus, having to do with the CCM Server. Whatever that is.