tleibner

Dear Admin:

Just a typo in the german translation:

'Friendesliste' - sounds quite nice, but 'list of friends' would better be translated into 'Freundesliste'.

I do appreciate the german version of the forum very much. Thanks for providing it.

Best regards,

Thomas

Download Here:

ftp://ftp.ni.com/support/labview/updates/...bview_8.0.1.exe

Docs:

ftp://ftp.ni.com/support/labview/updates/...adme_8_0_1.html

Again (as with the 8.0 download), I'd love to have a http access to the files. That's because I am stuck behind a proxy with disabled ftp. Pleeeeeease, NI!

Thanks

Thomas

G'day,

at the end of one of those endless wireing sessions I became inspired by a gimmick sold on thinkgeek.com: the TIX clock.

Since software is the instrument, here is my (your?) new desktop clock. Enjoy!

Any improvements are welcome.

/Thomas

Download File:post-3293-1139837395.vi

Jim and Michael,

Give me some time to finalize the DLL and put up a set of LV Vi's and an example database. I'll work on this today and hopefully post it this afternoon.

Chris

G'day,

why not calling the sqlite3.dll directly? e.g.: sqlite.viDownload File:post-3293-1138210594.vi

Get your latest sqlite3.dll form www.sqlite.org. e.g. http://www.sqlite.org/sqlitedll-3_3_2.zip

Thomas

Hi, I currently have LabVIEW 7.1 installed in my lab, but I'd really like to move over to LabVIEW 8.

What are the implications of downloading and running the LV8 download that is being linked in this thread? Ie, do I need to purchase new licenses, or can I re-use my old ones, etc? Thanks.

I used my LV7.1 SSP license number to install LV8. The installer connected to NI to check it and it worked. Despite, NI has now sent me a SSP upgrade containing LV8 cd, handbook, and a new (!) serial number. Until now, I did not install the SSP upgrade with its new number. I admit, I do not fully understand NI's license scheme.

Have fun.

This is a Labview 8 editing bug along the same lines as my previous post. I made it a new topic because it is a different VI attachment. Please read the note on the VI diagram. Thanks for trying it out.

Another nice example of an anaomaly of the LV editor. I can reproduce you finding.

Unexpected, too, if you delete the wire connecting the input tunnel of the TRUE case with the unbundle, signals sig.b. and ref.b remain valid without any data input. Well, the run arrow becomes broken.

Further, deleting any wires from within the Loop structure will not cripple the Unbundle's signal names.

I wonder what would be the LV developer's comment (Greg?).

Thomas

One of the things I wanted to check with Labview 8 is whether or not NI fixed problems in which Unbundle and Bundle By Name can change cluster elements during editing, such as when rewiring, adding structures, or reordering the cluster. I found that in 2 out of 3 situations, Labview 8 did the right thing while Labview 7.1 did not! The one situation I see where a problem still remains is demonstrated by the attached LV8 VI. Please see my note on the diagram. Thanks for trying it.

For many years I've seen problems (although rarely) with using sub-clusters and Unbundle By Name using the dot convention to denote cluster levels. At times, unbundle elements would change with no apparent causal action on my part. Has anyone else noticed that?

I played a little with your bug demo and could reproduce your finding. But to my mind, it seems to be an anomaly with the UnflattenFromString. Do another little experiment:

1. make the case structure to show the True case with 'sig.b' and 'ref.b' signal names.

2. delete the wire to the 'type input' of the UnflattenFromString

The signals names shown at the Unbundle will change to 'b' and 'b'. To proove that crippled signal names were sent by the UnflattenFromString, type strg-z to restore the wire; then delete the wire from the output of the UnflattenFromString to the input tunnel of the case structure. See what I mean?

Thomas

The NI application builder can save a project's build settings to a ".bld" file.

Has anyone here managed to figure out the format of the data contained in that file?

Thanks!

Well, not the file format itself, but there ara two VIs from the appbuilder's llb doing the job to read and to write the *.bld files:

C:\Program Files\National Instruments\LabVIEW 7.1\project\prodisttool.llb\Dist Load Script.vi

C:\Program Files\National Instruments\LabVIEW 7.1\project\prodisttool.llb\Dist Save Script.vi

I did use them once to leave all diagrams within an executable for later debugging.

Thomas

That simple & perfect. I owe you one :beer:

Thanks, Jim.

Thomas

I identfied this piece of code to crash my LV7.1 app when running under 8.0 :headbang:

What it does is to retrieve the VISA resource name (COM1 in this case) from the variant data type as a string.

Any idea how to work around?

Thanks,

Thomas

Download File:post-3293-1129902555.vi

I've updated all the links to Jim's new posted location. It should work now. BTW, I used Firefox default download system and it worked the first time, perfectly. :thumbup:

I've been successful with Firefox, too.

Go to http://labview8.ni.com/evaluation/labview/pc/

Right-click labview_80.exe -> Save it to a location with 500 megs free.

Thanks Jim & Michael!

Thomas

Thanks a lot for pointing me to the README.

Well, unfortunately my first try to get the file via http failed after 250MB (of a 450MB total size)

With ftp I could resume from there - http urges me to start from the beginning.

My apologies, NI admins, for raising the traffic level by reloading the first 250 megs.

X-ing fingers for the 2nd try

Thomas

The file has gone. :headbang: Any other ftp resources available?

Otherwise I'll have to wait for my SSP update in November (yes, that late in Germany..). What a pity.

Thomas