Other user accounts on computer can't see RT target

[dbrother]

Hi, my research group is using a a cRIO device, and we have a dedicated computer that runs LabVIEW. I have the project's files stored on a public folder (instead of say, my own user account's Documents folder) on a hard drive on the network, with the hope that anyone from the group can login with their own user account and still access and run the files. Although, since I am the only person who programs the cRIO, I was using my user account when the project was created.

Yesterday, we tried starting up the project from another user account, but found that when the project opens, the RT target has the yellow triangle warning icon next to its name, and all the files beneath it are seemingly gone. Logging back into my user, I can once again see the files and there is no warning next to the RT target.

Is there a way to make sure other users can also properly access and run the project?

[rolfk]

In order for a Realtime project to be able to show the proper target there is quite some software necessary to be installed on your computer.

-LabVIEW itself

-LabVIEW Realtime

-Hardware drivers for your device

In the case of a cRIO this is typically the CompactRIO software driver bundle, and if you use a recent RIO device or a special one such as the Industrial Controllers, you also need a specific hardware support package for that device in addition to the standard CompactRIO drivers.

It seems that one of these components installs certain files into user specific disk or registry locations and LabVIEW then can't find it if you login under a different account.

There might be a reason for this but it looks like a bug of the installer that hasn't really been discovered yet, since most users do not develop cRIO projects under different user accounts. 

[dbrother]

Hi Rolf, thanks for your response. That makes a lot of sense.

I'm not sure how to continue now though. Can I report this bug anywhere?

[Bob_Schor]

I'm also developing a Real-Time project on a Shared Computer.  We're "sharing" in a slightly different way (namely using Subversion to let each developer get the "latest version" of the code.

If I understand your situation, you have, instead, put the entire Project in C:\Users\Public\Public Documents.  Here I would expect the entire Project to be available to whomever logs on and goes to the Project folder.  The only "catch" is that some of the Folders that LabVIEW uses are "relative folders" to the User's area (e.g. the Default Data Folder will be in \Users\BS\My Documents\LabVIEW Data, not \Users\Public\Public Documents\LabVIEW Data).

However, if you've posted the entire Project to Public Documents, you should try asking your users to copy the Project (and its supporting files) to their "My Documents" and see if LabVIEW works properly from their accounts.  This also lets them "mess up their own copy" without damaging the "Master" Public copy ...

Still, this is kind of what Version Control was invented to allow ...

Bob Schor

[dbrother]

Hi Bob,

Thank you very much for your response! I really appreciate your suggestions.

Unfortunately, the project is not in "C:\Users\some_user\Public\Public Documents", but rather in an external hard drive N:\group that's accessible via the network. There is no My Documents but this makes me wonder: could I copy over whatever necessary items from my user's Documents into that public folder, and then somehow change where LabVIEW looks for the default folder for that project?

I agree that version control would probably have helped us avoid this. We didn't think of it because I'm the only one actually developing the code (and we're just scientists doing basic research, not programmers, haha...).

[Bob_Schor]

A better solution (I think).  I'm assuming that any user who want to run this code has LabVIEW installed.  Make the Project Folder "Read-Only" (so noone messes it up).  Tell your users to "Copy the Folder into your LabVIEW Data folder, open it, and double-click on the LabVIEW Project (.lvproj) entry to open it in LabVIEW".  If you are currently "developing", you can have several Versions in your "Shared" space ("Code, 16 Sep 21").  This way,, one person (you) controls what's out there, and everyone can access it safely.  [Now you can investigate some form of Version Control -- very, very important for LabVIEW Development and maintaining your Sanity].

Bob Schor

[billko]

---

@Bob_Schor wrote:

A better solution (I think).  I'm assuming that any user who want to run this code has LabVIEW installed.  Make the Project Folder "Read-Only" (so noone messes it up).  Tell your users to "Copy the Folder into your LabVIEW Data folder, open it, and double-click on the LabVIEW Project (.lvproj) entry to open it in LabVIEW".  If you are currently "developing", you can have several Versions in your "Shared" space ("Code, 16 Sep 21").  This way,, one person (you) controls what's out there, and everyone can access it safely.  [Now you can investigate some form of Version Control -- very, very important for LabVIEW Development and maintaining your Sanity].

Bob Schor

---

I am amazed that there are still developers out there that don't use some kind of version control software.  This is the ultimate time machine.  With it, you can take chances going down an innovative programming path, knowing you can always go back to the place you branched from if it turned out to be a dead end.

I have actually flat-out told project managers that I refuse to do any serious coding without some kind of versioning software installed.  I can do some basic setup and stuff, but once I get the point of no return, that's it.  The versioning software goes on pretty quickly after that.

It's like, no seat belt needed to prep in my driveway, but once we're ready to leave the driveway, the seat belt goes on.

[Bob_Schor]

---

@billko wrote: It's like, no seat belt needed to prep in my driveway, but once we're ready to leave the driveway, the seat belt goes on.

---

Wonderful analogy.  My father-in-law used to not wear a seat belt (arguing "What if you get in an accident and can't get out of the car because your seat belt is jammed?"  We cured him (at least while visiting us) by refusing to take him with us to dine with his grandchildren if he didn't "buckle up".  Your analogy of saying "No VCS, no Code Development" gets similar results, I see ...

Bob Schor