Mellroth

You should use a WHILE loop instead (actually a DO_WHILE) The FOR loop is to be used when you know how many iterations you need, it can't be stopped until all iterations have completed. /J

QUOTE(chrisdavis @ Mar 4 2007, 02:22 PM) Good point, I forgot about that :thumbup: /J

QUOTE(Ami @ Mar 4 2007, 08:07 AM) Hi, think of inlining as replacing the subVI call, with the BD of the Sub VI itself. The benefit by using inlining is that you get rid of the overhead associated with a SubVI call (typically in the us range), e.g. a loop containing special calculations, will benefit by using inlining, since you then remove the overhead in each loop iteration. The higher the loop count the more you gain. An exe, however, still keeps the subVI hierarchy, and therefore still suffer from this overhead. If you are using VI-server calls to a VI, then be careful not to break this if you inline your code. /J

My experience with LabVIEW 8.2 is that the run time behaviour seems to be very stable, but the editing is not, e.g. I have got numerous crashes trying to get a "Bundle by name" node from the palettes. The palette freezes and in the end LabVIEW crashes. Regarding load speed, I feel that having LV 7.1.1, LV8 and LV8.2 on the same machine tends to result in longer load time fo any of the LabVIEW versions (but you hardly notice this for LV8 ). Tomi: do you experience these issues for all LabVIEW projects or only projects involving LVOOP? /J QUOTE(Tomi Maila @ Mar 3 2007, 05:28 PM)

QUOTE(tcplomp @ Mar 3 2007, 05:04 PM) I'm guessing BridgeVIEW /J

QUOTE(alnaimi @ Mar 3 2007, 04:36 PM) I'm sorry if I offended you, but the Guidelines are quite clear about this QUOTE Don't abuse the PM (Personal Message System)Please don't PM people on these forums for LabVIEW assistance. Especially after you've already posted your question on the Forums. It is a personal choice for someone to respond to a question on the Forums. A PM is Personal (hence the name). Would you go around town knocking on the doors of people you don't know asking for LV help? No, so why would you do the same on the internet? Most of the time, a PM triggers an email notification to the recipient which can be even more annoying. Please think twice before sending a PM. If the person has not responded to your question on the Forums then what makes you think they will respond in person? I think your chances of getting a response from thousands of readers is better than just a response from one.... 'nuf said. There might also be other users facing the same problem as you, and if you use the PM system instead of the forums the knowledge will not be made public. Anyway, I'm pleased to hear that you did get some help. /J

QUOTE(tcplomp @ Mar 3 2007, 02:53 PM) Or maybe its part of the error handling, to get an download error I mean /J

Hi alnaimi, at least two members have allready told you that it is not polite to PM members directly, use the forums instead. When someone has the time and knowledge to help, they probably will. I must say that receiving a PM with a question, doesn't make me want to help you. Good luck with your project, and again please DON'T PM members with your questions. /J QUOTE(tcplomp @ Feb 28 2007, 04:18 PM) QUOTE(crelf @ Feb 28 2007, 04:58 PM) alnaimi: do NOT PM LAVA memebers with unsolicited technical questions - it is very poor form.

QUOTE(Aristos Queue @ Mar 3 2007, 02:54 AM) I get an error when I follow that link QUOTE We could not find the file specified has it been removed? /J

QUOTE(alnaimi @ Mar 2 2007, 04:00 PM) I don't know what you mean by "anyone can view it". If you mean that after you have set a password you can still view the block diagram then this is normal. To check if your password has taken effect, either close your VI and open again, or go to the menu Tools->Options->Environment and Clear Password cache. /J

Here is the same thing as Albert gave you, but using "Spreadsheet string to array" to do the conversion. http://forums.lavag.org/index.php?act=attach&type=post&id=5060 /J

Thanks for all your comments. I'm not arguing that it should be possible to add two absolute times, what I'm trying to say is that I would like the TimeStamp data type be able to contain relative values as well. Then the addition/subtraction nodes would make sense. Why should the TS be limited to absolute times, when this internally is in fact only a relative time (but displayed as absolute time)? The choice of relative/absolute time could be made by the user (like for floating point values), when the value is displayed. QUOTE(Jim Kring @ Feb 23 2007, 10:49 PM) I haven't been there yet, but I'm planning a visit really soon Another point is that the TimeStamp (TS) data type is not a floating point value (as far as I understand it), but rather a more accurate representation. The TS can thus represent any point in time with the same accuracy. A floating point value can not do this, since a higher integer value (seconds), means less accuracy for the fractional part. Anyway, from all the comments I conclude that this is not a bug. I will now enter the 5th dimension, and see how the arithmetics work... /J

Hi, I don't know if this classifies as a bug or not, but I find it very annoying that simple arithmetics (lika add, subtract etc.) does not work with the Timestamp datatype. At least not returning a TimeStamp datatype in the result. What do you say; is it a bug, a requested feature...or is it just me /J

QUOTE(Eugen Graf @ Feb 23 2007, 07:20 PM) If you are converting back to LV7.1 from a LabVIEW 8 project, I would consider making a VI tree to display all Top level methods anyhow, since the project view didn't exist back then. Have a nice weekend! /J

QUOTE(Eugen Graf @ Feb 23 2007, 05:51 PM) I'm not sure what you mean, but you can select your top VI and save that for a previous version. All linked VIs (except those in vi.lib) will also be saved for previous. Is this what you need? /J

QUOTE(Eugen Graf @ Feb 22 2007, 03:28 PM) If you want to change the byte order in a DBL (e.g. to Little Endian byte order), you can always typecast to an array of U8. For Little Endian, just reverse this array and typecast back to DBL http://lavag.org/old_files/monthly_02_2007/post-5958-1172161029.png' target="_blank"> /J

QUOTE(tcplomp @ Feb 22 2007, 07:30 AM) Or just drag the updated VI to the "type specifier VI Refnum". You might also have to right click on the "call by reference node", and select "adapt to type" (or something similar), to get the node working correctly. /J

QUOTE(Jeff Plotzke @ Feb 20 2007, 12:38 AM) Good catch Jeff! When I want to keep the FrontPanel, I usually uncheck the "Allow user to close window" option, this worked at least in LabVIEW 8. I really wish there was a separate VI option, to select if the FP should be removed in a build. /J

QUOTE(Tomi Maila @ Feb 17 2007, 07:41 PM) I don't really work with LVOOP yet, but I really think private items should stay private. If I define something to be private, its because I would like to make sure that a end-user doesn't use this item (shouldn't even be aware of that the private items exist). If the end-user can not access the internal/private parts of the system, then they can be changed without affecting the end-user at all. Allowing the user to break this "rule", would probably lead to situations where the higher levels in your program needs to be recompiled (or be broken), even though it is only an internal part of a subclass that has changed. /J

QUOTE(rolfk @ Feb 16 2007, 01:29 PM) Rolf, I think that a path key in LabVIEW 7.1.1 was given in platform specific format, have this changed in LabVIEW 8.2 (I'm at home and can not check)? In my opinion the Path data type should display paths in the format specific for the platform that hosts your application. In a cRIO project you are developing on Windows, but deploying to a cRIO, so the question is how a cRIO on a VxWorks platform should handle paths? Either display paths Windows style and accept windows paths in the ini-files, or always use VxWorks path style? Have a nice weekend /J

QUOTE(gsussman @ Feb 15 2007, 05:50 PM) I too experienced this, on VxWorks it seems like the paths should be given as /c/calibration/test instead of c:\calibration\test. A bug? I don't think so, since this is a platform different than Windows and paths are platform dependant (Mac, Linux etc.). I do, however, agree that it is inconvenient to have different paths separators for different cRIO platforms. /J

QUOTE(aka @ Feb 15 2007, 12:01 PM) Hi, I don't know if the "Snd Read Wave File.vi" existed in LabVIEW 6i, but if it does then it can read a wave file and output sound data together with sound format info. Look in the palettes, and if you don't find it, have a look in "vi.lib\sound\lvsound.llb\Snd Read Wave File.vi" If you just need to read the sound info, go into this VI and take out the parts where sound info is extracted. Put this in a VI of your own that only reads enough characters to extract the wav-header (~36 characters). Hope this helps /J

QUOTE(PJM_labview @ Feb 13 2007, 05:40 PM) I've verified that this is very strange, and I would classify this as a bug since there are no other way to know whether the TDMS refnum is valid or not. When "Not A Number/Path/Refnum?" doesn't work you would expect that there was a special method to get the status of this special refnum. /J PS. To clarify; my comment in the other thread was only regarding the ordinary file I/O refnums, I'm sorry I forgot to mention that I verified the TDMS refnum problem in the original thread.

QUOTE(dannyt @ Feb 13 2007, 01:19 PM) Can you tell us a bit more what kind of expressions you want to match? Is it always a character sequence followed by numbers etc.? If it is then you could check out the "Match First String" primitive. QUOTE Compares each string in string array with the beginning of string until it encounters a match. /J

QUOTE(PJM_labview @ Feb 12 2007, 11:09 PM) Hi PJM, can you explain what you mean when you say that it does not work on file refnums? I just tried to wire a file refnum to "Not A Number/Path/Refnum" primitive, and I do get a correct indication of the reference status? /J