LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Channel Wires (Old Dog, New Tricks)

Solved!
Go to solution

When your Customer opens the Project and loads any VI that involves a Channel, LabVIEW 2018 will "see" the Channel and will attempt to create the appropriate ChannelInstances code via LabVIEW Scripting in the user's My Documents/LabVIEW Data/2018 (32-bit)/ExtraVILib/ChannelInstances.  That's how it is supposed to work.

 

That sounds OK, but I care more about how it ACTUALLY works, which is different.

I have a working project with a working channel.

I close LV

I move the specific CHANNEL INSTANCE folder out of the CHANNELINSTANCES folder (hide it, as if the customer didn't have it).

I start LV and load the project and load the main VI:

I get this:

Error2.PNG

 

It can't find it. If I let it go and cancel all the FINDs, the VI opens up broken, with missing VIs.

 

That makes it useless for the way I want to use it.  If there's a better way, I'm listening.

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


LinkedIn

Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 11 of 16
(1,669 Views)

Did you also move the lvlib file for the channel?

0 Kudos
Message 12 of 16
(1,578 Views)

Oops, I'm sorry that I dropped the ball on this topic, only realized it when a new question popped up.

 

As I understand it, there are three basic ways to distribute code to a remote site (such as to a customer):

  1. Distribute Source code.  Requires the Remote Site to have an appropriate LabVIEW installation to be able to compile and run the code.
  2. Distribute an Executable.  Requires the Remote Site to have an appropriate LabVIEW Run Time Engine, but does not require any "source" information.
  3. Distribute an Installer.  I'm less experienced with this method, but my understanding is this is the "moral equivalent" of distributing an Executable and an "installer" for the RTE (and perhaps a few other pieces).

I've used Method 2, but in most cases, the PC at the Remote Site had, in fact, LabVIEW installed (in case I needed to log in and make a "patch" or fix a bug "feature" we didn't expect).  The Executable was stored in Public Folders, so anyone who logged into the PC could run the code (there was a shortcut to the Executable on the Public Desktop, so they only needed to double-click it), but the Source Code (including my LabVIEW Data folder) remained in my "private" Documents folder, to which the Executable did not have access.

 

I've done the equivalent of Method 1, which also works (for me).  Example -- I want to "install" a Project that uses Channel Wires on a new PC that already has LabVIEW.  I log in, use Subversion to Check-Out the Project, open it, load the Main VI, and wait for the Channel Wires to build.  On some occasions (and on some versions of LabVIEW), things get complicated and LabVIEW hangs during the Channel Wire configuration (or so I surmise).  The "fix" is to "load slowly" -- instead of loading the Main, I load a bunch of sub-VIs, starting low on the hierarchy and working my way up until I've loaded the Top Level VI.  I actually wrote a "Load by Hierarchy" routine once when a particular largish Project (with quite a few Channnel Wires, mostly Messenger Channels) got cranky.

 

One "feature" I'd like to see have another option would be to allow the Channel Instances to be saved with the Project, as I often re-use Names used for Channels across Projects (e.g. M-State) that have a Project-specific Definition, resulting in a "clash" when I open the second Project that uses this name.  My "fix" is to simply find the Channel Instances folder and delete it, then reload the Project and let it rebuild all of the Project code (takes at most 20-30 seconds, once), but if I could save this code with the Project, the Clash should not occur.

 

Bob Schor

0 Kudos
Message 13 of 16
(1,558 Views)

Good timing...

So Bob, you seem to be the local expert on channel wires,  how do you handle multiple developers with projects that use channel wires? I issue I am having is that when a different developer opens a project, the dirty-bit (re-save) is set on the parent vi. I only noticed this issue when I was issued a new laptop and when I updated my local copy of the project, it wanted to be re-saved.. making my think I forgot something on my old laptop! Turned out to be the channel wires. I could not find any "official" documentation on this topic.

I would also like an option " to allow the Channel Instances to be saved with the Project" Is there an idea that I can vote for?

NOTE: I have not had any issues generate the channel wires... yet.

---------------------------------------------
Former Certified LabVIEW Developer (CLD)
0 Kudos
Message 14 of 16
(1,549 Views)

I recall a discussion with the Channel Wire developers about the location of the ExtraVILib files.  Let me see if I can't find this before I propose an option of putting ChannelInstances inside the Project instead of inside the User's LabVIEW Data folder.

 

Bob Schor

0 Kudos
Message 15 of 16
(1,521 Views)

In the case of source code distribution or multi-developer situation, would separating the compiled code from source code help? IE would the original vi's that contain channel wire still want to be re-save if the channel wire code is regenerated?

---------------------------------------------
Former Certified LabVIEW Developer (CLD)
0 Kudos
Message 16 of 16
(1,475 Views)