forcing vi execution

[labview_beginner]

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

[Ray.R]

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.

R

[altenbach]

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?

[labview_beginner]

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.

[Kevin_S]

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

Kevin S.

Applications Engineer

National Instruments

[labview_beginner]

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.

[Jeremy_B]

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.

[labview_beginner]

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

[Kevin_S]

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