Load and save warning on probe

[mooseo]

Hi,

I'm getting a "Dependency loaded from new path" warning every time I try to probe a wire on my block diagram. It's loading "General Error Handler CORE.vi" from an llb from which I'm not expecting it. 

Is there a simple way to break this linkage?  I've looked, but everything I see in this regards works from within Projects. 

Thanks,

mike

[smercurio_fc]

Were you using custom probes at some time? Some strange things happen when custom probes get corrupted. Try moving your custom probes someplace else on your hard disk temporarily to see if that does anything. Be sure to do this when LabVIEW is not running.

[mooseo]

I've never knowingly created a custom probe, although it's entirely possible that I did without knowing what I was doing. How do custom probes get named?

Thanks,

mike

[Vivek_N]

Hello Mike,

For your information, here is a link to our online LabVIEW Help that explains how to create custom probes in LabVIEW 2009: http://zone.ni.com/reference/en-XX/help/371361F-01/lvhowto/creating_custom_probes/ . 

Are you not able to probe any wire? Does this happen in any VI? Which version of LabVIEW do you have? Were you able to do this before? If so, were any software changes made right before this behavior started occuring?

I would appreciate it if you could answer these questions. This information would greatly help us isolate the root of the problem quicker.  

[mooseo]

Hi Vivek,

Thanks for your reply. I seem to have fixed it, though I didn't pinpoint the problem. I started this project by duplicating an llb that was doing something very similar to what I wanted. However, this meant that it recycled a lot of paths. I went through the library and deleted everything that looked like it should just load out of the labview core, and that seems to have fixed it. 

I like to use llbs... I develop my code on a desktop machine with a big monitor, but then deploy it on a laptop connected to my experiments (usually just moving it on a USB drive). I've been saving the entire hierarchy in the llb, thinking this saved me hassles with differences in the directory structures on the different machines. I don't know if this is the right thing to do or not. It's generally worked until this, but it's working now. 

Thanks,

mike

[smercurio_fc]

In general you should not use llbs for storing of your code for development. LLBs have more drawbacks than advantages. They were introduced a long time ago to get around the limitation in Windows filenames back when filenames had to be only 8 characters plus a 3 character extension. Yeah, that long ago. The biggest drawback is that if one VI gets corrupted, the entire LLB is screwed. LLB usage should be limited to deployment scenarios, not development scenarios.

[Ben]

---

smercurio_fc wrote:
In general you should not use llbs ...

 introduced a long time ago to get around the limitation in Windows filenames back when filenames had to be only 8 characters plus a 3 character extension. Yeah, that long ago. ....

---

... and when you try to pull everything out of the llb  with those bogus  names you intruduce a complication that is NOT appreciated at update time...

So saving outside a llb is a good idea so that you know about bougs names when you create them ( I am not implying that I have ever done such a dasterly deed. ).

Ben

[mooseo]

What do people recommend for my situation where I have to frequently move the whole project back and forth between different computers?  Should I use labview projects and then move a whole folder around? 

I've sort of avoided figuring out what projects could do for me because what I was doing seemed to work. But I guess now that it's actually caused me an afternoon of problems, I should make the effort to learn something new.

thanks,

mike

[Ben]

THe simpleset solution is what I use as often as possible.

Thistag cloud for Tree.VI has links to previous discusions.

I maintain a Tree.VI for my app that consist of all top level VIs, dynamic VI, templates etc. This VI never has to run, but I keep it "runnalbe" as a quick check if the integrety of my code. Tree.VI's was the way to go prior to LV 8 and the introduction of the Project.

In the Project you now have the ability to create Source Distributions. Source Distributions pcick up all of the VI's listed and moves them to a new location and fixes up all of the file references so there is now crosslinking to teh old code. I use teh Source Distribution to make sure I have all of my code in one place.

THat works if you keep all fo your code in one folder along with its sub-VIs. If you want to go with a more exotic arrangement where you customize your tool palettes on your development machine and expect it to work the same on anothe machine, then check out the VIPM (VI Pakage Manager)  from JKI.

I hope that helps,

Ben