Leaderboard

Windows update ran last night while I was running an experiment, and restarted the computer while LabVIEW was running. If you run overnight experiments with LabVIEW, you may want to consider this. I found some instructions for how to disable automatic restart on XP http://www.aviransplace.com/2004/12/18/tip-disable-auto-restart-in-windows-update/ Here's the skinny: Windows XP Pro users can tell Windows never to restart the computer automatically. In order to do that follow these steps. In the Start Menu go to Run type “ gpedit.msc ” and press Enter Now a Group Policy editor will open. In this window navigate to: Computer Configuration -> Administrative Template -> Windows Components -> Windows Update Double click on No auto-restart for scheduled Automatic Updates installations In the settings window Choose Enabled and click OK Close Group Policy Editor Hope this helps someone else! Or if there are other/better suggestions for keeping Windows Update at bay, I'd love to hear them. Pat

The Full details here. LabVIEW 2009 f2 Patch Details

You can also pull the network plug out while your running tests

Any time you get into the habit of taking on someone else's work load the entire company takes on that habit. And bad habits are hard to break. You'll end up being resentful and having too much to do. I would take a bullet for most of my coworkers, but I refuse to cover for anyone who is lazy or takes advantage of the team.

It could also mean you have a different decimal sign ('.' vs ','). use %.; in the start of your formatter to specify a dot as the decimal sign. Ton

Well. There are a few ways. If the message string is always in a fixed order and fixed length and messages are not concatenated, you can use the "Scan From String" which will give you the results straight away in the format you require. If its not, then you can use the "Spreadsheet String To Array" to break up the string at the delimiters then convert to whatever formats you like.

Daklu, the style of my writing below is fairly terse and occassionally EMPHATIC. I've done this to emphasize key points that I think you've missed in How Things Work. Some customers in the past have felt I'm insulting them writing this way, but it is the only way I know through the limited text medium to highlight the key points. My only other option is to post just the key bits and leave out a lot of the exposition, but that doesn't seem to be as helpful when communicating. So, please, don't think I'm calling you dumb or being disdainful. I'm trying to teach. The problem is that you're almost right. Customers who are completely off-base are easier to teach because they need the whole lesson. Here, I'm just trying to call out key points, but presenting them in their full context to make sure it's clear what fits where. Throughout the post, refer to the graphic at the end of the post as it may clarify what I'm talking about. Dalku wrote: No. If there is, that's a bug that needs to be reported to NI ASAP. Think about what you just asked for... ignore the DVR part for a moment. You just asked for a PARENT object to invoke a CHILD class method. That cannot ever happen. You cannot pass a parent object directly to a function that takes a child object. The parent object in question IS NOT a child -- the parent object does not have the child's private data, nor does it have all the methods that may have been defined on the child class. For this reason, LV will break the wire if you try to wire a parent wire to a child terminal -- the wire is broken because there are zero situations in which this can successfully execute. You CAN pass a child object to a parent terminal. That is because a child IS an instance of the parent -- it has all the necessary data and methods defined to act as a parent object. What you can do is take a child wire, up cast it to a parent wire and make a Parent DVR out of that. Alternatively, you could take a child wire, make a Child DVR wire, and then upcast that to a Parent DVR wire... these two processes produce the idenitical result: a parent DVR that contains child data. Upcast and downcast DO NOT create new objects EXCEPT when they return an error. The point of a cast is to say, "I have an existing object. Please check that it is this type and approve it to go downstream if it passes this test." You use this only when you need to do something for a specific type of object and you do not have the ability to edit the parent and child classes in order to add the appropriate dynamic dispatch VIs to both. Preserve Run-time Class (PRTC) is the same thing. "Allow this object to pass downstream if it passes this test, otherwise create a new object that does pass the test." The test in this case is "Does the object in have the same TYPE AT RUN TIME as the OBJECT (not the wire) on the target object input?" If the left object is the same or a child class of the center object then there is no error. You will ALMOST NEVER WIRE PRTC WITH A CONSTANT FOR THE CENTER TERMINAL. I would say "never" because I can't think of any useful cases, but maybe someone has something out there. If you are wiring the center terminal of PRTC with a constant, something is wrong in your code. You use the PRTC to assert that the left object, which comes from some mystical source, is the right type to fulfill run-time type requirements of dynamic dispatch VIs, automatic downcast static VIs, and the Lock/Unlock of Data Value References. In all three of these cases, there is some input (either the input FPTerm or the left side of the Inplace Elt Struct) that must be passed across to the output (either the output FPTerm or the right side of the Inplace Elt Struct) WITHOUT PASSING THROUGH ANY FUNCTION THAT CHANGES THE OBJECT'S TYPE. You're free to change the object's value, but not its type. Sometimes you pass the object to functions where LV cannot prove that the type is maintained. Easy example -- pass the object into a Global VI and then read the Global VI. You'd never do this, of course, but it demonstrates the problem. LV cannot know that the object you read from the global is the same object you wrote in -- some other VI elsewhere might have written to the global in parallel. But you, as the programmer, know that there are no other writes to the global VI, so you use the PRTC to assert "this is going to be the right object type." You wire the original input (as described above) to the center terminal, and the output of the global to the left terminal, and pass the result to the original output terminal (as described above). Does that make sense?

Don't get me wrong, I try to make the majority of my posts helpful (not like this one). I think the voting posts up and increasing rep thing hasn't caught on in LAVA yet though as it's pretty new. Until it does catch on, a post count at least shows you're not hiding in the shadows and you participate in the LAVA community. I still find it a bit intimidating to post a reply in the same thread as someone who has over 4000 posts, especially if they reply and increase their font size and encapsulate in exclamation points, hypothetically speaking of course. Maybe some of the mystery will fade at the LAVA BBQ though...