LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

vi cannot write to a shortcut or hard link folder?

Details

Alienware M51 Laptop

Windows 10 Enterprise

TestStand 2021 SP1

Labview 2022 Q3

 

I have vi's that use ActiveX Invoke Node calls to Excel to read and write files.

I have a bunch of TestStand/Labview projects with hundreds of vi's and sequence files that I have inherited, all of them are intended to install their root folders in c:\.

 

Now the problem.

Because these all are in c:\ and the vi calls are hardcoded to c:\<folder>\... I have the projects all in my projects folder and hard link the project home folder to c:\<folder>.

The projects keep all test results and calibration forms in the home folder.

OK, so far, this works fine for vi's calling each other and teststand operations.

BUT

Any vi that is writing a file in those folders, doesn't.  The files don't get written and there are no errors thrown when that happens. 

This also happens with folders that are shortcuts to other network locations.

 

I have Googled this and searched the forums to no avail.  Am I the only person that does this?   My boot drive is only 500GB (we all got laptops), so I can't keep a dozen large test projects in c:\, I keep the projects on the 😧 drive which is a lot larger.  Am I going to have to clone projects to c:\ and copy them back when changing projects to get around this?

 

Any hints appreciated!

 

be well,

DLC

0 Kudos
Message 1 of 10
(499 Views)

Have you tried to run TestStand/LabVIEW as admin?

 

George Zou
0 Kudos
Message 2 of 10
(432 Views)

Have you tried to run TestStand/LabVIEW as admin?

 

George Zou
 
I am running as admin, both in my development and in my deployed workstations.  Both are admin logins.
 
be well,
DLC
0 Kudos
Message 3 of 10
(428 Views)

@DLMC wrote:

I have vi's that use ActiveX Invoke Node calls to Excel to read and write files.

 


Does this mean you just pass file paths along to Excel (via ActiveX) to do the reads and writes?

 

If so, and this is the part that fails, there may not be much that can be done about it.  If Excel isn't doing what you tell it to, all you can do is double-check the inputs/outputs of the function calls you send to it.  Once LabVIEW sends a path to Excel it is no longer in the hands of LabVIEW.

0 Kudos
Message 4 of 10
(412 Views)

Does this mean you just pass file paths along to Excel (via ActiveX) to do the reads and writes?

 

If so, and this is the part that fails, there may not be much that can be done about it. If Excel isn't doing what you tell it to, all you can do is double-check the inputs/outputs of the function calls you send to it. Once LabVIEW sends a path to Excel it is no longer in the hands of LabVIEW.

 

Excel has no problems reading and writing to hard links or shortcut folder when I am using the apps directly.  When using the "Invoke Node" to ActiveX objects to do this, the files are not created.  Note, the file locations are using the linked path, not the direct path.

So D:\projects\MyTest\TestFiles

is linked to

C:\MyTest\TestFiles

 

The vi opens the template file in (linked) C:\MyTest\Labview\SupportFiles

Updates it with the necessary details (Dash board shows the Excel app "doing things") and writes the test results to C:\MyTest\TestFiles\test.pdf.

 

But nothing is written there.

 

I see the same behavior on the deployed test station when writing log files to a linked network folder.  This is another instance of the issue, they are not related other than in their behavior.  In this latter case test results are written from TestStand as log files and html files.  But this only works if the folder is a local disk folder, not when a folder is linked to a network drive location.

 

No errors or events are generated either in Labview nor the OS to say that something went wrong.  Just nothing happens.  I strongly suspect the issue is with writes and not reads because the Excel edit routines would barf if they could not find the key sections that were edited.

 

The well-known "saveAs" issue is not what is happening here, that problem always generates a hung application.  I have done the open/edit/saveas PDF directly in Excel, and it worked.

 

be well,

DLC

 

be well,

0 Kudos
Message 5 of 10
(401 Views)

@DLMC wrote:

Have you tried to run TestStand/LabVIEW as admin?

 

George Zou
 
I am running as admin, both in my development and in my deployed workstations.  Both are admin logins.
 
be well,
DLC

When you start LabVIEW, even if your account has an admin login, you are often not running it as administrator.  Run it the way, you normally would, then check according to this link:

https://www.majorgeeks.com/content/page/process_running_as_administrator.html

 

Most of the time, LabVIEW is not actually running as administrator.  If you're not running it with a right-click to "Run as administrator", you probably are not.

Kyle97330_0-1725396058441.png

Try that just to see if it works.

0 Kudos
Message 6 of 10
(388 Views)

When you start LabVIEW, even if your account has an admin login, you are often not running it as administrator.  Run it the way, you normally would, then check according to this link:

https://www.majorgeeks.com/content/page/process_running_as_administrator.html

 

Most of the time, LabVIEW is not actually running as administrator.  If you're not running it with a right-click to "Run as administrator", you probably are not.

DLMC_0-1725397457048.png

 

Try that just to see if it works.

 

I will try that.  Labview is being called from TestStand.  Will TestStand pass on the "administrator" priv when it calls up Labview vi's?

 

** I tried it, nothing changed.  Still did not write the files.  I will keep pecking away.  FYI, I set the vi's to use a local file folder that was not part of the project, and that did work.  So, I suppose I have a workaround for development that I have to remember to change back.  But that does not fix the other part of the existing programs which will not write to a network folder.

**

 

 

When I start TestStand, I get this login popup, which I keep as administrator.  Does that mean the same thing as "run as administrator?

DLMC_0-1725397686507.png

 

be well,

DLC

 

0 Kudos
Message 7 of 10
(379 Views)

If that prompt is a UAC prompt from Windows, then maybe. But if it is not then highly unlikely that it is the same thing as "Run As Administrator".

Have to you tried making a test VI that just reads and write files to desired directory? If not, then please try and see if you get any error message.

I prefer setting administrator privileges option once in for all for my LabVIEW code that needs to run as admin to read/write files. 

Example:

Xonmyth_1-1725400322141.png

 

 

0 Kudos
Message 8 of 10
(365 Views)

All,

 

Thanks for the pointers, I learned a lot. 

However, not what was going on here.

It turned out that there was a unreported file missing error buried two more vi levels below where I was looking.

After I corrected that (an incorrect path) everything worked for my development system.

 

The problem on my old Windows 7, LV2010, TS4.2 system still exists.  I will deal with that later, and maybe never if I ever get these systems migrated to a new LV/TS on Windows 10 project completed...

 

be well,

DLC

Message 9 of 10
(297 Views)

Hi DLC,

 


@DLMC wrote:

When I start TestStand, I get this login popup, which I keep as administrator.  Does that mean the same thing as "run as administrator?

DLMC_0-1725397686507.png


No.

This is the TestStand-internal account management…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 10 of 10
(277 Views)