topic Re: forcing vi execution in LabVIEW

forcing vi execution

labview_beginner — Wed, 02 Jul 2008 23:06:54 GMT

I have a VI (Move_PDFs.VI) which I call within my application to move some PDF files from source location to target location.

Along the application execution, the user sets the target directory which is updated to a global variable. My source directory is fixed for each execution and is also stored as a global variable.

In the VI (Move_PDFs.VI) I basically get the source folder, get teh list of all the PDFs that have been created during the application execution, and then move those files to the user input target directly. If I run this VI as a stand alone (using the run button on the tool bar) it works fine. It moves all the files. But if I include it in the main application, even though it is called, it is not executed. By this I mean that the simple messge box in the VI is invoked during the execution of the main application, but the PDFs are not moved. The "list folder" and "move" vi's are not even called. Can somebody help me understand why this is happening? How can I force this VI to execute in the main application?

Thanks in advance.

Re: forcing vi execution

altenbach — Wed, 02 Jul 2008 23:15:33 GMT

How do you call the subVI? It would be much easier for us if you could attach your code.

Re: forcing vi execution

labview_beginner — Wed, 02 Jul 2008 23:37:39 GMT

apologies for teh b&w images. i was in a hurry and forgot to dump the color images.

first image shows how the VI (move_PDF) is called in the main application.

The second image shows the details of move_pdfs.vi

Like I mentioned in my prevoius post, if I include a simple message box in the move_pdfs vi, then there is a pop up which means Labview does go through the vi.

But if I probe the filenames array or any other element inside the vi, i think "list folder" or "move" commands are not being executed.

Thanks in advance.

Re: forcing vi execution

altenbach — Wed, 02 Jul 2008 23:52:36 GMT

Keep the diagram window of the subVI open and enable execution highlighting. Anything interesting?

On a sidenote, there are a few weird things that don't look right. It would be better if you could attach the VIs intead of pictures.

In the subVI:

The upper shift register has no function, because the data stays the same. Inexing into an array with [i] connected to the index terminal is the same as autoindexing at the loop boundary. (delete the upper shift register, "index array", and "array size" and wire the array across an autoindexing tunnel.
The lower shift register seems disconnected on the left, so what is its purpose?
I would very strongly recommend to operate with paths instead of strings.

Maybe once the code is cleaned up a bit, it is easier to tell where the problem is.

Re: forcing vi execution

Ray.R — Thu, 03 Jul 2008 02:13:40 GMT

Is it just me or are the images in black & white?

Re: forcing vi execution

labview_beginner — Thu, 03 Jul 2008 03:20:34 GMT

Thanks for the feedback. It is very annoying that the VI executes perfectly everytime I run my appliction with "move_PDFs" vi in "highlight execution" mode. If I turn the mode off, then the VI does not even go through "list folder" and "move" commands. I also cleaned up the vi and am attaching it with this post.

Help would be appreciated.

I forgot to add that after the main application exits with "move_PDFs" not executing correctly, if I just hit the "run" button on front panel of the "move_PDFs" vi it moves all the PDFs to the correct location perfectly.

Thanks,

Message Edited by labview_beginner on 07-02-2008 10:20 PM

Re: forcing vi execution

Dennis_Knutson — Thu, 03 Jul 2008 03:53:50 GMT

When you turn on execution highlighting and something works, that's a pretty sure indicator that you have a race condition and race conditions are caused by use of global and local variables. From what you have shown, using a global to set the final destination is just silly. You could easily pass the value directly. Do you know if the main is even setting the path correctly? Your problem is in the main and you did not attach that.

And, as already mentioned, you should be working directly with paths - not strings. Just use the Build Path function to add a file name to a path.

Re: forcing vi execution

altenbach — Thu, 03 Jul 2008 04:38:16 GMT

Unzip the attached zip file into its own hierarchy (don't run from within the zip file!).

It contains a folder with:

PathsGlobal.vi: The global for the paths (I would not do it like that, just duplicating your scenario here)

CallMover.vi: The toplevel VI that lets you move pdf file between two folders ("from" and "to")

Move_PDFsMOD.vi: The subVI tha does the moving (bascally your's, but cleaned up!)

Folder "From": containing three empty and fake pdf files.

Folder "to": that where me move the files.

Just open and run "CallMover.vi". It will show the pdf filed in the two folders.

Now select the direction with the enum and press "move" Everything seems to work.

I agree with Dennis that you have a race condition somewhere in the calling VI.

Message Edited by altenbach on 07-02-2008 09:38 PM

Re: forcing vi execution

labview_beginner — Thu, 03 Jul 2008 05:28:20 GMT

In the two images that I have sent, the first image shows part of the main application.

i have a flat structure: the first frame is where the PDFs are created. The second frame is where I force the global variable to be updated. And the third frame is where I call the move PDFs.

I thought this would be logical, and it seems that labview does move through them sequentially. just that it does not call the move_PDFs explicitly.

I wil try to shy away from globals and will send the path into the VI as input. And will update tomorrow on how things go.

Thanks for all the help.

Re: forcing vi execution

altenbach — Thu, 03 Jul 2008 05:42:16 GMT

We really need all your VIs. Could it be that writePDF keeps the file open and thus they cannot be moved, for example?

What does the error ouputs say in the subVI?

You really should wire the errors and connect them to terminal so the error is propagated to the calling VI.

Re: forcing vi execution

labview_beginner — Thu, 03 Jul 2008 05:59:22 GMT

There are no errors in any sub VIs. I have checked and re-checked.

Re: forcing vi execution

Ray.R — Thu, 03 Jul 2008 12:28:12 GMT

How can you say that there are no errors when you have not wired the error cluster to all functions within your vi's? Looking at your image, there are many items that are not wired to the error cluster. One of which deals with the file.

Re: forcing vi execution

altenbach — Thu, 03 Jul 2008 15:27:39 GMT

The "list" files will NOT give you an error if it cannot find any matching files, because that is a valid result. 🙂

If the file list is empty, the FOR loop will be skipped and you don't get an error from the move primitive either.

One horrible flaw in your code that can lead to errors is the fact that you list the file from a location that is hardwired into the VI, while later you try to move the list of files from a location that you get from a global variable (Default_PDF_Location). Maybe you can do an "equal" on the two and see if they differ when the code is running in your vvarious scenarios.

Have you tried my example?

Re: forcing vi execution

labview_beginner — Thu, 03 Jul 2008 20:46:45 GMT

Thanks for the great pointers and yes I tried your example.

I think I know where is issue is - I am using PDFCreator to print Excel into PDFs in the subVI Write_PDFs. Then I call the Move_PDFs. But I think there is a certain time required to print the Excel sheet to PDF and the Move_PDF is being called even before the PDFCreator is done writing the PDFs. Hence the "List Folder" function does not find any PDFs in the folder and hence the For loop is not executed.

Any suggestions how I should tackle this issue? Once way is to check the folder before exiting the Write_PDFs subVI that there actually is a PDF file in the folder - which means PDFCreator has finished writing the file. Are there other more elegant ways to do this?

Thanks.

Re: forcing vi execution

Kevin_S — Mon, 07 Jul 2008 23:20:52 GMT

That's the first thing that comes to mind - continually poll to see when the file exists.

Kevin S.

Applications Engineer

National Instruments

Re: forcing vi execution

labview_beginner — Mon, 14 Jul 2008 17:28:11 GMT

I just randomly assigned a 2 second delay before the move_PDFs will execute and everything works fine. In worse case I would live with a 2 sec delay but was wondering of the best way to do this. There could be 1 or 2 or 4 or 8 PDF files which could be written to the folder before the move_PDFs should be executed. So I will have to keep polling the folder and counting the # of PDFs before I can execute the move_PDFs subVI. I am wondering whether this logic would take the same amount of time (~2 sec) to execute and would I be wasting unnecessary time writing the code without making it more efficient. With 2 sec delay I have tested that all 8 files are in the folder (worse case) before move PDFs is executed.

Thanks.

Re: forcing vi execution

Jeremy_B — Tue, 15 Jul 2008 16:15:42 GMT

You might run in to problems if your PDF creation takes longer than two seconds. Like Kevin_S said, polling is probably the best and easiest way. You might want to have a timeout in your polling loop in case your PDF creation were to fail.

Re: forcing vi execution

labview_beginner — Thu, 17 Jul 2008 22:26:58 GMT

Ok!

I keep bugging everybody but I have still not been able to elegantly tackle the issue of race condition between PDFCreator actually printing the PDF and a subVI "movePDFs" trying to move these printed PDFs to another location.

I tried to use following two methods:

1) keep polling the folder where PDFCreator is writing the PDFs. The moment I have 'n' (known number) files in the folder, come out of the while loop and then execute subVI "movePDFs" ---- i think if i can implement this correctly, will be the most elegant solution. But it seems that there is a time lag between a the last PDF showing up in the folder and the PDFCreator actually finishing printing the last PDF. So movePDFs is still invoked a tad bit earlier than I would like it to be.

2) looked up a "folder size" functionality in the the forums and found one which will give me the total size of the folder.

Make sure there are 'n' PDF files in the folder

Then I check for a ballpark size (to be greater than a certain number of bytes) of the folder

the invoke movePDFS.

In this case too I am facing the same issue. The folder size funtion is being called before PDFcreator actually finishes printing the last file.

Any hints on how to check whether PDFCreator has actually finished printing?

Thanks.

Message Edited by labview_beginner on 07-17-2008 05:26 PM

Re: forcing vi execution

Kevin_S — Fri, 18 Jul 2008 18:18:33 GMT

I assume that you're using ActiveX from inside LabVIEW in order to use the PDFCreator. Another option that you might have would be to monitor the print job number. There's a specific property that you can select from the property node titled "cCountOfPrintjobs". I would imagine that you could monitor this number until the number of jobs returns to zero. Until then, you know printing is still under way.

One idea to investigate,
Kevin S.
Applications Engineer
National Instruments