Mellroth

QUOTE(chrisdavis @ Mar 4 2007, 02:22 PM)

Security is another benefit of inlining. Jim gives a good explanation http://thinkinging.com/2007/02/03/security-at-the-subvi-boundary/' target="_blank">here.

Good point, I forgot about that :thumbup:

/J

QUOTE(Ami @ Mar 4 2007, 08:07 AM)

Hi,

Can anyone please explain to me what are the benefits of "Inlining" a LabVIEW project (I say project because I mean a very big system developed in LabVIEW). I understand from previous posts that it decreases execution time, but does it have any effect on Projects that are being run as a stand alone executable? Because, I would assume that when an exe file is being built, the compiler already makes the execution as efficient as possible, thus probably using the same techniques that one of them is "inlining".

Thanks,

Ami

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)

• Avoid renaming VIs in project, your project may corrupt
  
• If you need to rename, make a backup before you rename
  
• Avoid typedefs, compiler cannot manage complicated typedef references
  
• Compile as often as you can by pressing Ctrl + Shift + Run and then save all
  
• If your project get corrupted
  • Open your project and try to recompile by ctrl+shift+run
    
  • Don't use save all as it may crash your LabVIEW but save all VIs individually
    
  • be patient, to get project working may require may rounds of recompiling and saving and recompiling and saving and...
    
  • If your VIs get missing because you tried to rename them and LabVIEW crashed, edit the project or library XML by hand to change the VI names to actual names
    
  • If nothing helps revert to backup

QUOTE(tcplomp @ Mar 3 2007, 05:04 PM)

BV????? :question:

Ton

I'm guessing BridgeVIEW

/J

QUOTE(alnaimi @ Mar 3 2007, 04:36 PM)

No one forces you to help me and your help is not needed in this case !!! I did recieve PM from many but didnot do what u did!!!!

I'm sorry if I offended you, but the Guidelines are quite clear about this

QUOTE

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)

I think even Stephen has to wait before a CR is approved

Ton

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)

And please don't PM

QUOTE(crelf @ Feb 28 2007, 04:58 PM)

QUOTE(Aristos Queue @ Mar 3 2007, 02:54 AM)

The revised error.llb and commentary was sumitted here:

http://forums.lavag.org/downloads.html&showfile=83#''>http://forums.lavag.org/downloads.html&showfile=83#' target="_blank">http://forums.lavag.org/downloads.html&showfile=83#

I get an error when I follow that link QUOTE

has it been removed?

/J

QUOTE(alnaimi @ Mar 2 2007, 04:00 PM)

i have tried to sceure it by VI properties but I doenot effect , any one can view it??

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)

Adding two relative times is nonsensical: tomorrow + today = huh? (unless you're living in one of alpha's parallel universes)

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)

Thanks, save for previous version in LV includes all depencies automaticaly only if i select a folder in the save dialog. But the VI from ars_stowers is very interesting.

Thanks a lot, Eugen

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)

Is it not posible??? Must I open every VI (of 30) and save they for previous version? What would be if I would have 500 VIs?

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)

Hello, my question is:

how can I realize Flatten To String with little endian byte order for 7.x LabVIEW versions? I tryed Swap Bytes and Type Cast VIs, but it fits only interegr data types and not floating point numbers.

Eugen

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)

Hi Thang,

right click on the specifier, select class -> Browse.... and browse for a file that matches exactly (type defs/names/required states) the dynamic VI

Ton

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)

The Workaround: Uncheck the "Show Front Panel When Called" checkbox. Note that you must then alter your build specification to not remove the front panel of the VI so that you can still connect via Remote Front Panel.

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)

Ton, I suggest you post NI a change request. Don't request the functionality to change because it will not happen. Request change in the user interface of the LabVIEW development environment. Request that LabVIEW allows user to make all referenced private typedefs public for a public typedef. The same should apply for public VIs, the connector pane of which refers to private typedefs. There simply could be a new option "apply same option to all referenced items", where item means typedefs and classes and referenced means what I explained above.

Tomi

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)

INI file paths are always normalized when you use the LabVIEW INI Read/Write Path VIs. And yes the normalized form is basically Unix annotation. Since VxWorks has most likely unix roots I think the actual path string syntax would be correct. One more reason to deal with paths as much as possible using the LabVIEW built in Path data type!

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)

Correct Behavior:

String in: "calibration\"

Path out: "calibration"

Behavior under VxWorks

String in: "calibration\"

Path out: "calibration\" <---- Note the "\" character is still present

Depending on your code, it can cause double backslash characters "\\" to be inserted into your build path functions.

c:\\calibration\\test

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 need to read the duration of a .wav file, or alternatively the size of the file and its sampling frequency.

using Labview 6i (6.0.3).

thanks!

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)

This is a follow up to this thread http://Not-A-Number-Path-Refnum-does-not-work-on-TDMS-file-refnum-t6234.html' target="_blank">Not A Number/Path/Refnum does not work on TDMS file refnum.

Upon sleeping it over, I am still thinking that there is something fishy going on, but before I mess that thread any more than I already did, I am posting this here so people can comment.

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)

ah Labview 8.0 or even better 8.2, I am trying to go in that direction, but you know the old Newtonian law on Software Inertia... a software version bought and paid for should remain in rest until senior management say otherwise

As I said I can implement it in 7.0, I was just hoping somebody would tell me I was wrong and there was a way to match it with one single MatchPattern vi if only i got the pattern right.

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

/J

QUOTE(PJM_labview @ Feb 12 2007, 11:09 PM)

Edit: Well apparently I spoke too fast, this function does not appear to work on file refnum at all (same pb for regular file primitive). This might be the intended behavior. I guess this "Use this function to make sure a reference to an object, such as a VI, application, or control, still resides in system memory and was not closed" should be read as "Use this function to make sure a reference to an object, such as a VI, application, or control (but not file reference), still resides in system memory and was not closed".

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

As others have pointed out your -1003 error is most likely due to missing subVIs.

Hi,

just wanted to point out that you will also get error -1003 if you try to load a dynamic VI, containing FPGA code, using option 0x08 (reentrant run) in the "Open VI Reference". In this case the error is somewhat misleading as the VI is executable, but not with the selected option.

The developer distribution works great, just create a build for the desired target (include vi.lib, instr.lib if needed).

Build, and download the distribution folder to your target and run your dynamic VI.

/J