build executable bug?

[JT]

Hello, NI

Is it true that there is a bug in the default selection of board id's on
motion board vi's in LV7.0?

IE. My program wouldn't run as an executable because zero's were being
pased to all the motion board id's.

My technique for creating board id's was to right click the terminal and
select either "constant" or "control."

When I actually went to create an executable, it compiled but when I ran
it, it kept generating errors for "illegal board id".

After bringing in an expert labview consultant, he found that all type
definitions of my bd id controls had to be changed. It took him several
hours to figure that out. And several more hours to fix them all.

From what I can see, this is a LV bug and needs a patch from NI.

I would adv
ise anywone new to labview to try compiling your programs to
executables to see if you also have this problem. Cost me about 10-12
hours with the consultant to fix my program.

The symptom is, the vi runs fine in design mode under labview development
environment but generates "illegal bd id" errors when ran as an executable.
This will happen with the first motion vi that uses a board id. Using
LV7.0 and 7344 motion boards under windows 2000. The consultant found
something documented on the ni website describing the error and the fix and
he mentioned that it also addressed LV7.1.

My question really is, "is this true and does NI intend to fix the bug?"

Thanks,

JT

[rolfk]

JT wrote:
> Hello, NI
>
> Is it true that there is a bug in the default selection of board id's on
> motion board vi's in LV7.0?
>
> IE. My program wouldn't run as an executable because zero's were being
> pased to all the motion board id's.
>
> My technique for creating board id's was to right click the terminal and
> select either "constant" or "control."
>
> When I actually went to create an executable, it compiled but when I ran
> it, it kept generating errors for "illegal board id".
>
> After bringing in an expert labview consultant, he found that all type
> definitions of my bd id controls had to be changed. It took him several
> hours to figure that out. And several more hours to fix them all.
>
> From what I can see, this is a LV bug and need
s a patch from NI.
>
> I would advise anywone new to labview to try compiling your programs to
> executables to see if you also have this problem. Cost me about 10-12
> hours with the consultant to fix my program.

The problem is that the LabVIEW application builder tries to disconnect
any and all typedefs when creating an executable to make the application
smaller. But this disconnection makes the controls loose their default
data and default back to default default data.

The solution is to add an INI file setting
"BldApp.RemovePolyVIsandTypedefs=FALSE"
to your LabVIEW.INI file.

This is most probably fixed in 7.1 but I didn't check it yet.

Rolf Kalbermatter

[Philip_Courtois]

Hi JT and Rolf,

This feature is now optional in LabVIEW 7.1. Instead of adding the string to the INI file, you can select your option in Application Builder (see attached TypeDefOption.jpg).

Best regards,
Philip C.
National Instruments

[rolfk]

Philip C. wrote:

> Hi JT and Rolf,
>
> This feature is now optional in LabVIEW 7.1. Instead of adding the
> string to the INI file, you can select your option in Application
> Builder (see attached TypeDefOption.jpg).

Neat. But what I meant is if the bug that automatically diconnected
typedefs by this option loose their default data, has been fixed. I will
probably have to try it one of these days.
Well, if it hasn't been fixed I see actually no reason to even make that
option available in the Application Builder, so I really hope the best.

Rolf Kalbermatter

[JT]

Thanks very much for both your replies. Could have saved me a lot of
time if I had known this before.

I have one other question that's been plagueing me:
It seems that LV remembers where you copy backups for your VI's and then
tries to use the backup copies the next time you open the top VI's
instead of pulling them from the original directories.

ie. Without LV running at all, I copy all my files and directories to a
directory called "BU...." where "...." is the name of the original
directory. When I later open a top VI (one that calls most of the
other VI's), instead of pulling the VI's from my original directory, it
calls the VI's from "BU...." directory instead. It's as if LV tracks
what windows explorer is doing. The undesirable effect is that at first
I wasn't aware of this. I would edit a VI and hit "save" and it was
putting it in the back up directory instead of the original directory.
Later when I think I am backing up newly edited VI's from the original
directory to the Back up directory, I was actually overwriting the newly
edited VI's with the unedited old VI's. Is there a way to turn this
action off too? This is also something I think that is highly
undesirable as no other programming language I know of tracks the
windows explorer actions in this way (ie. replacing subroutines from
other directories that you never told LV to do).

Thanks very much for both your help.

JT.


RolfK wrote in
news:41141556@newsgroups.:

> Philip C. wrote:
>
>> Hi JT and Rolf,
>>
>> This feature is now optional in LabVIEW 7.1. Instead of adding the
>> string to the INI file, you can select your option in Application
>> Builder (see attached TypeDefOption.jpg).
>
> Neat. But what I meant is if the bug that automatically diconnected
> typedefs by this option loose their default data, has been fixed. I
> will probably have to try it one of these days.
> Well, if it hasn't been fixed I see actually no reason to even make
> that option available in the Application Builder, so I really hope the
> best.
>
> Rolf Kalbermatter

[rolfk]

JT wrote:

> I have one other question that's been plagueing me:
> It seems that LV remembers where you copy backups for your VI's and then
> tries to use the backup copies the next time you open the top VI's
> instead of pulling them from the original directories.

Well, LabVIEW remembers subVIs as follows: If the subVI is on the same
volume as the caller, then LabVIEW stores the relative path from the
caller VI to the subVI in the caller.
This means that if you copy an entire hierarchy of VIs to some other
place, LabVIEW will pick up the subVIs from the new place as well if
they were in the directory hierarchy you copied.
If the subVI is on another volume than the caller, LabVIEW will store
the absolute path to the subVI in the caller.

Now there is one thing which can mess up your calling hierarchy and that
is LabVIEWs search order. Basically when LabVIEW needs a subVI, the
first thing it will do before even looking at the path where that subVI
is supposed to be located, it will check if a VI with the same name is
already in memory. If so it will relink to that VI instead of the one on
disk if its location is different and when you close the main VI you
will get a dialog prompting you to save the changes in memory which will
include relinkings to other VIs. If the needed subVI is not in memory
LabVIEW will try to load it from where it was last stored (relative to
the caller if on the same volume and absolute if on a different volume).
If the VI can't be found LabVIEW will go and search its search paths.

They are default (you can change that in the Options including the order
of them) as follows:

1) The directory where the Top Level VI of the current hierarchy is located.
2) The directory where it already found other VIs before when searching.
This can be automatically or pointed to it by you in a previous search
VI dialog.
3) In the vi.lib directory and its subdirectories.
3) In the user.lib directory and its subdirectories.
4) in the instr.lib directory and its subdirectories.

If LabVIEW still can't the VI it will prompt you for the VI in a file
dialog and the path you select there will be added to the list of paths
searched in step 2) above.

Rolf Kalbermatter