Opining VI problem

[crossrulz]

---

@RavensFan wrote:

because the VI is looking for those VI's in "C:\LabVIEW Hacker" which is a very oddly named directory, plus the fact it is in the root drive, to have be the intended install directory.

---

The screenshot in the original post is looking for a VI in <vi.lib>\LabVIEW Hacker, which I am fairly certain is where it is supposed to be.

[altenbach]

I assume you are using LabVIEW 2013 32bit. Are you?

Have you looked at this FAQ entry? Certain features require at least LabVIEW 2014.

[Mustafasei]

Yes I'm using 2013.

so what I suppose to do now?

[altenbach]

You already said that you are using 2013. The question is if you are trying to do something with

• Arduino/chipkit (supported on 2013) or...
• beaglebone/raspberry (not supported in 2013, requires 2014).

What hardware are you trying to use and what hardware is the target for your example programs?

[RavensFan]

---

@crossrulz wrote:

---

@RavensFan wrote:

because the VI is looking for those VI's in "C:\LabVIEW Hacker" which is a very oddly named directory, plus the fact it is in the root drive, to have be the intended install directory.

---

The screenshot in the original post is looking for a VI in <vi.lib>\LabVIEW Hacker, which I am fairly certain is where it is supposed to be.

---

Your right about VI.lib.  I saw the colon at the beginning and to me that always signals the root of the drive.  I still think "LabVIEW Hacker" is a very odd name for a professional toolkit.

The OP claims to have installed it in the correct default location.  Apparently that location is not the same one that the VI is looking for.  So the all the other commentary still applies in that the VI can't find the code where it is looking for it.

Perhaps the version and the LV 13 vs. LV 14 that Altenbach is talking about is the reason.  But if so, I think he'd be having issues trying to open an LV 14 VI within LV 13, before it even gets to the point that it can't find the VI.lib library.

[altenbach]

Obviously, we don't have enough information. Maybe the project got down converted for him.

In any case, there is a dedicated forum on that other site, so this discussion should continue over there.

[Mustafasei]

By the way this message repated many times and open the directory in my computer and when its open I always I select the same VI which I have downloaded it from iternet till it finshed but rarely I can find the VI is fully compelte inside mostlly i found it as shown

please see this screen video record which i uploaded it on drop box and advise me

https://www.dropbox.com/s/1as07olpqh6pzm6/ScreenCapture_11-10-2016%206.45.42%20PM.wmv?dl=0

Thank you for all your support

[RavensFan]

The problem is LabVIEW is searching for those subVI's that make up the driver and searching in that LabVIEW Hacker path.  When it can't find it, you wind up pointing it to your Fire Alarm.VI and doing that a bunch of times.  So all of those subVI instances are being replaced with fire alarm.VI and you wind up with a whole bunch of broken wires because Fire Alarm.vi is not a replacement for those missing driver VI's.

You should be going to find the actual driver subVI's.  They are in some other directory, so that means you have to go browsing for them, which is what I was telling you to do back in message #5.

[Mustafasei]

i didnt understan what shall i have to do in replay #5

[altenbach]

I still think all this should be discussed over here instead.

You still have not said if you use LabVIEW 32bit or 64bit. From the vi.lib path seen in the video, you are either using 32bit LabVIEW on a 32bit OS or 64bit LabVIEW on a 64bit OS. More typical is 32bit LabVIEW on a 64bit OS.