jpdrolet

I don't want to get into a philosophical argument either but what you really want is for LLBs to look like directories, feel like directories and behave like directories regarding the OS and other applications... You want them to be no different than directories... In short you want them to be directories...

I am not aware of a SCC application that manipulates and controls files within compressed files (ZIP) (correct me if I am wrong). Shell extensions can be made to hook into Windows Explorer and peek into ZIP files and LLBs and display their content as it would belong the the file hierarchy. However, other applications do not use Explorer hooks to access files, they use the file system API where ZIP files and LLBs are simply plain files. It would be a LOT of trouble (for very little gain) to integrate a LLB as a subfile system in the file system.

NI distributes most of LabVIEW VIs in LLBs. That is what LLBs are useful for: distribution. I myself distribute my applications VIs packed in executables and LLBs but I develop them as VI files. I'm quite sure NI also develops its VIs as files and packed them in LLBs only when a version is ready for distribution (I'm curious how they handle Open/Create/Replace File.vi...)

So you are free to use LLBs but do not expect them to be directories or that further development will be made for LLBs to gain the advantages of using individual files and directories.

Nice tool Michael.

My nitpick :

In _JKI PBD Controller.vi_ the logic to build the path to _JKI PBD gui.vi_ accounting for Dev/Run-Time is not needed.

Simply set the path to the constant _support\JKI PBD gui.vi_

• In Development Environment, when _Open VI Reference_ has a relative VI path, the path is completed relative to the calling VI location (the folder/LLB the VI is in)
  
• In Run-Time, when _Open VI Reference_ is called the internal LLB is first checked for a VI with a name corresponding to _JKI PBD gui.vi_. The actual path is ignored when the VI is found in the internal LLB.
  

In both situations the VI will be found using the relative path _support\JKI PBD gui.vi_

I have a specific VI (reentrant) that I load dynamically (with options = 8). I open a VI reference, set the front panel properties to "Standard", then run the vi with "Wait Until Done" set to FALSE and "Auto dispose Ref" = TRUE. (The VI's default Window options "Show Front Panel When Opened" is set to FALSE. I'm going change it to Hidden after Open Reference when I'm done; I need to see it for now for debug...)

The VI runs in a loop that receives notifiers, reduces some data and plots data to a chart (for debug). The VI stops running when a "Wait On Notification" call returns an error (the Notifier was destroyed in the Data Source VI) or the operator presses a "Quit" boolean.

It's been working for over a week without problems, but now OCCASIONALLY I see the dialog box below when closing the VI. If I place a CD in the tray (drive D:) and click continue, the VI closes. When I try to load the VI again dynamically, LabVIEW crashes.

What could be going on that would cause this? Has anyone seen this before? I've forced a recompile of the VI and all associated VIs. I'm ready to toss the whole VI out and write it from scratch!

I've seen this message but in different context.

Look into your labview.ini file and see if there is any old file path referring to d:\ It may cause LabVIEW to look for the drive d:\

I don't know where these people are getting new computers with parallel ports. Most of the ones I'm getting now don't even have this anymore.

Just buy a Parallel Port card that you plug in the ISA bus...

I tried that just by wiring the output of "Open Application Instance" without anything wired into that function, but this didn't help.

Also, NI replied with this being the issue:

as of LabVIEW 8.20, VIs in an executable can no longer

be programmatically controlled from outside of the executable. In

addition, developers can no longer build LabVIEW executables and use

them as VI libraries. This means that you can no longer rename an

exe to a .llb and gain access to the VI. The reason why this

behavior changed wasn't for this security issue, but for

compatibility with the upcoming Windows Vista.

Meaning that they changed how one can access VI's from inside .exe's.

Are they mixed up? Do I just need to give it a different application reference?

If what they said is true, any opinion on the best way for me to call VI's from an executable on a run-time system? (I deploy to machines that don't have the LabVIEW development system installed). Do I need to place a .llb instead of the .exe on the machine, and call the VI that's inside the .llb with VI server? Or is there a better way to achieve this? The goal is to have a core executable that never has to change that calls VI's dynamically. That way you can deploy new VI's on a run-time system without have to rebuild the entire application.

Thanks!! Jason

The way you used them, executables were no different than LLBs so continue to deploy with LLBs instead of EXEs.

Perl really looks like an explosion in an ASCII factory... (slashdot quote)

Hi,

The Task I'd like to perform seems quite easy, but I didn't manage to do resolve it at whish:

- providing just the path and filename of the pdf-file to system exec.vi, hoping that Win calls acrobat, doesn't work.

- providing the path and filename together with a "call" opens an unwanted command-line window, but works.

Does anyone has any idea how to open a pdf-file with the standard-application that is installed on the computer (in other word: let Win resolve the app that is linked to ".pdf")?

It should work on Win98 to WinXP, the pdf-viewer might (but must not) be acrobat reader, where the pdf-viewer is installed is unknown, if it is acrobat in which version it comes is unknown (so activeX is also not an option). Additional command-line windows are unwanted. LV version 6.1.

Didier

It works with _System Exec.vi_ provided you set the command to

cmd \c "path\to\any\doc.type"

Set Run Minimized to True.

That is the quantum wave equation of the hydrogen atom. And I'm white too... :laugh:

I have not tried the technique but you could try to open TCP connections to NetBIOS ports 139 and 445 of the remote computer to see if it is serving files. If one of the connections open without error then most probably the computer is online for filesharing. You can then close the connection and open the file. When the computer is not online, you have control on the timeout input of _TCP Open Connection_ to set how long is too long to wait.

Alternatively, you could call the file function in a VI spawned in parallel to your main code and if the VI doesn't resume with valid data after some delay (shorter than the network timeout) resume the main code letting the spawned VI running until the file function times out.

Here is the snapshot I was talking about. But yen is correct, you won't be able to get this as text unless you do the string formatting yourself.

For the sake of completeness, in LabVIEW 8.2 and probably 8.0 too, the function _Format into String_ accepts relative time formats such as %<%H:%M:%S>t

Michael!

I think it's time you put your priorities at the right place...

*looks at Barbie Girl video...***

Real G'eeks don't watch retard teenagers videos!

*looks some more videos... (humm nice)*

LAVA founders don't listen Britney Spears (edit:oops! Aqua) music! What an example to set for weakest members?

*watches even more videos...(wow very cool!)*

AAArgh!!! I'm addicted too! Look what you've done!

thanks you for your help.

the problem with the TCP read component is that i am obligated to do a while loop to listen if something is coming.

isn't it more convenience to wait until something is coming??

thanks again

You have to use a loop anyway to gather the next piece of data so what is the problem? Set a large timeout on the Read function so it won't loop wildly. To abort the waiting Read function close the TCP connection and it will stop immediatly with an error.

hello again,

i have an opened TCP connection with a remote server which can send me data randomly in the time (it is a chat server)

so i need to know which local port is used for the connection in order to use the TCP listen component and so for reading data sent by the server.

thank you for your help

(ps: i dont want to use static port to solution this problem, i prefer when labview to choose dynamicaly a unused port , and sorry for my poor english)

Once the tcp connexion is opened, the proper function to use is TCP Read. TCP Listen is used to wait incoming connexions from clients.

When variants are stored to disk, the attributes are lost.

That is not true. There is a field in the flattened variant string that tells how many variant attributes there are, followed by the flattened attributes.

Hi,

maybe a stupid question, but have you tried the openG vi's??

I think

- Cluster to Array of VData (Variant as input)

- Get Cluster Element by name

- Get Cluster Element names

come close to your "other possibility"

good luck.

TNT

(In the past I've once made a logging/debugging vi with a variant input

which filtered out any variant input into a readable string-format)

Definitely you need OpenG Data Tools to manipulate variants. The input will convert to a variant but the output will stay a variant that you will have to convert back to typed data on the calling diagram. On the diagram it will look like that:

This OpenG VI parses the elements from an arbitrary cluster and read their values from an INI file and returns the cluster as a variant.

The caller converts the data back to the type of the cluster.

Is it possible to change the default location of the Instr.lib and User.lib directories ? it sure would be nice to have those on the network so that when i change LV versions all i have to do is point to them. If i could create virtual directories in XP i would do that , but , i dont think i can do that unless i am running a server version.

Dan

You can try the setting "Library Directory" but it also sets the location of vi.lib

To create symbolic link directories I successfully used the tool Junction from Sysinternals.

Hi,

I have a fairly long timer running in a while loop. (10 minutes) At the end of the programs' use, how does one avoid having to wait as much as 10 minutes for the vi to stop? Nicely, of course. :-)

semi-newbie,

Fred

The Wait functions are not interruptible so when you put them in a while loop, the loop will take 10 min to execute. Instead of using a Wait function, create a notifier and use Wait Notification (with timeout) which can be interrupted by sending a notification or destroying the refnum. If the Wait Notification times out with no error, this indicates that the loop can run next iteration. If it doesn't time out (notification received) or output an error (refnum destroyed) the loop can exit.

There is also the VI property FP.State that can be set to Hidden. With a hidden top level window, the executable continues to run.

I'm not sure it can prevent the flicker.

Hi,

I was doing some changes in one of my control when I've receive this error. I've check at NI and there's no indication about this error. Now I can't run my main program anymore.

Do you have any idea of what's wrong?

Thank you,

I guess that your control is corrupted. If it is a typedef, try opening the control file only. If it crashes LabVIEW, use revert to a backup copy or send it to NI, they may be able to fix it.

Is your control HUGE (cluster with hundreds of elements)? That might be the problem

You can take a look at the VI Parse Formula String.vi which analyzes the syntax of a formula string.

However, variables names are limited to a single lowercase letter alone of followed with a single digit. You can use Substitute Variables.vi to map your variable names to legal names. The binary operators OR and AND are not supported either so you have to substitue them with valid operators such as + and *.

For example, map your formula

(VARIABLEA AND VARIABLEC OR VARIABLE B

to

((a) * (c) + (b)

and the check the syntax using Parse Formula String.vi

In fact something like this does exist here. I also thought I would look just for :laugh: at a basic text document in the open office native file format (Open Document Text in this case). And the file is not simple XML. I couldn't read it with a basic text editor. If someone else wants to shed light on how to read an Open Document file in a basic text editor please show us the light. I enjoyed reading an article from ArsTechna about the Open Document format and the recently release Google Spreadsheet which might help to explain why this toolkit doesn't exist yet.

I think it is a compressed set of XML documents. You can decompressed the file to get the XML documents or set an option in OOo to save the files uncompressed.

my program need to control printer and scanner, but i dont know how to do this.

i need help

Thanks

Read the User's Manuals of Printer and Scanner and implement a driver.

Sorry, that is the best help we can offer with the information you provided.

From the Wikipaedia article:

Dot Countries: Canada(English speaking)

Comma Countries: Canada(French Speaking)

:headbang: A confused Canadian in Canada...

I think it is quite elegant. I have used this and it provides you with a lot of flexibility of naming files after the fact, optionally saving files (i.e. deleting the temporary and not creating the file w/ header), and putting in header comments that reflect what happened during a data run. If this is the environment you work under, then it works quite well.

EDIT - I forgot to add that for large files you can write a fixed length blank header as big as you will ever need. A 1k size header on a 10MB file is hardly a drop. Then you can write the true header over the blank one after the fact and resave the file.

I agree with that. Reserve a fixed length header in the file. Files are random access, you can rewrite the header every time is is needed.

Well that is a Cylon. The bad guys from Battlestar Galactica.

I got hooked by this sci-fi series. No technobabble, no alien/widget of the week. It has good drama and character development.

Some will find Cylon Number Six more attractive... but machine/human mating is disgusting...