LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

forcing vi execution

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.
0 Kudos
Message 1 of 19
(3,725 Views)
How do you call the subVI? It would be much easier for us if you could attach your code.
0 Kudos
Message 2 of 19
(3,723 Views)

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.

0 Kudos
Message 3 of 19
(3,720 Views)
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.

0 Kudos
Message 4 of 19
(3,715 Views)
Is it just me or are the images in black & white?
0 Kudos
Message 5 of 19
(3,696 Views)

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
0 Kudos
Message 6 of 19
(3,686 Views)

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.

0 Kudos
Message 7 of 19
(3,676 Views)
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
0 Kudos
Message 8 of 19
(3,670 Views)

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.

0 Kudos
Message 9 of 19
(3,657 Views)
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.
0 Kudos
Message 10 of 19
(3,652 Views)