LabVIEW Channel Wires

cancel
Showing results for 
Search instead for 
Did you mean: 

Channel Instances in LabVIEW Data

By default, it seems that when LabVIEW generates a channel, the instance of that channel is stored in the LabVIEW Data folder, which is generally defaulted to My Documents. I've just discovered this, and it's caused me a little bit of a headache. I use a repository to transfer my code between workstations, however I have not had to use a different workstation since I began working with channels...until now. As it turns out, the other computer is unable to load the LabVIEW project because it cannot find the specific instances of the channels used. If I selected "Ignore All" when it was searching for the instances, a dialog would pop up for each channel which says something to the effect of "Regenerating channel instance..." However this did not seem to do as it said it was doing, since the project was still missing each channel when I started trying to load the VI's (and it would again try to search/regenerate).

Once I discovered it's because they're stored locally, separate from the project, was I able to fix it by copying the files from the first computer to the same location on the 2nd computer. This works for the majority of the channels, except for one which references a class. The location of the local project directory on the 2nd computer is not the same as the first computer, so the channel instance which uses the class can't find the files, even though they're loaded successfully in the project. I should be able to find a way to get around this eventually, though I haven't yet and am open to suggestions. It's just a conflict that requires I update the Channel Instance with the new class location, however the "Use Selected Item" button is disabled so I'm unsure how to do this smoothly without manually re-creating all the instances which use that class.

Is it necessary that channel instances be saved in LabVIEW Data? It would be extremely helpful if channels could be saved to either a folder specified by the user in project options, or to a folder which is contained within the project library. I know you can change the default location of LabVIEW Data, but this would only work for one project, and could cause problems with other projects. Is this an issue that anyone else has encountered yet? And if so, are there any solutions available?

Thanks,

-Ben

0 Kudos
Message 1 of 10
(11,203 Views)

When I have moved some channel projects or needed to re-create the channel instances.  It has rebuilt them seamlessly.  Even on moving a project with channels cross platform it regenerates correctly.

LabVIEW ChampionLabVIEW Channel Wires

0 Kudos
Message 2 of 10
(10,918 Views)

a) The instances are supposed to be seemlessly regenerated, but there was a bug. Just hit the Ignore All button and let regeneration happens. Regeneration should work just fine, but the project tree doesn't always notice and still shows the missing symbol. If you try to open the instance VIs directly from the project, yes, it'll search and complain, but if you open your VIs that call the instance VIs, your VIs should open just fine. If you close and re-open the project, it should also be just fine. We have a fix for that behavior in LV 2017 and may include it in a future LV 2016 patch.

b)

Main question: "Is it necessary that channel instances be saved in LabVIEW Data?"

That's a more complex question. Answers include "no", "yes", and "kind of". 🙂

As you noted in your answer, the Default Data Directory can be set in Tools >> Options. That allows you to specify a location other than My Documents. So in that sense, the answer to your main question is "no". And it hints at the broader answer...

The "yes" and "kind of" answers are more complex.

When a caller VI calls a user subVI, the caller VI saves a relative (or sometimes absolute when crossing drives) path to the subVI. But when a caller VI calls a vi.lib subVI, the caller VI saves a "pseudopath". For example, "<vilib>\Utility\error.llb\General Error Handler.vi". When we load, that <vilib> tag is interpreted by the loader... that's how you always get the version of the subVI for the version of LabVIEW that you're using.

For instances, we created the <extravilib> tag, and we make it resolve to the MyDocuments directory.

Could we have made it resolve to other places? Yes. Should we? Maybe. 🙂

First of all, let's take care of the case where you're working without a project. When you don't have a project open, we'd be faced with creating the instances in the same directory as the VI that requested the endpoint, and that's a somewhat random location. So in that case, we'd probably just keep using the Default Data directory so that all load-by-themselves VIs would use the same location. So that means that main question gets a "yes" answer... there is at least one case where we would definitely use that directory.

But when there's a project, we could create the rule that the instances are created per-project and placed in a directory next to the project file. That's certainly an option we could have done. We could have still used the <extravilib> tag to resolve and said, "Hey, we're loading under a project, resolve that tag differently."

We avoided that option mostly for performance. Regeneration is slow because scripting is slow. We've done what we can to improve that, but real improvements require more fundamental refactorings (which is in the works but would be in the new platform announced at NIWeek, so still out in the future). If we always load from one location, a given subVI only has to generate once no matter which project it becomes a part of, and multiple subVIs in different projects that all use the same core data type can share the implementation.

There is a secondary reason: versioning. When we resolve <extravilib> currently, we resolve to a directory that is specific to that version/bitness of LabVIEW. That means that if you use LV 2016 and in LV 2017 we improve the channel templates somehow, your instances will regenerate and get the new code. That allows us to patch issues for you, something we thought might be valuable given how new these features are. We could have a separate 2016 and 2017 directory under your project file. That starts to seem like a lot of LV clutter in your directories, but it would work. It might frustrate your source code control systems when LV wipes out files (which we do when a new module [FPGA or RT] installs or uninstalls), but that's deal-with-able.

Long and short -- we could do what you're asking, at a cost. So the answer is "kind of". We discussed it but didn't like the costs. But we're open to changing our minds. Because of the pseudopath system, if we did change it in the future, it wouldn't break any of your code.

Message 3 of 10
(10,918 Views)

Thanks for that explanation, I had considered the lone VI without a project situation, but hadn't taken into account versioning. However, I am still faced with a problem - my channels are not regenerating like they should. I have my project repository on my 2nd computer, and I've opened up the LabVIEW Data folder, and browsed to the 2016 ChannelInstances directory. There are only two folders and two libraries, with 3 text files, the libraries are for "Messenger-str" and "Tag-i64".

When I open the project and select "Ignore All" I see the regeneration boxes come up, however nothing populates the ChannelInstances folder. I double-checked and confirmed that I am currently in the default data directory, it wasn't changed to something other than My Docs. Could the channels be regenerating somewhere other than LabVIEW Data?

0 Kudos
Message 4 of 10
(10,918 Views)

I'm someone who (a) always does multi-VI Projects within the context of a LabVIEW Project, (b) have had problems having a Channel named, say, "Message" defined in more than one Project, but having slightly different definitions, and as a result, (c) have run into "clashes" and problems regenerating Channels.  [I've also advocated for saving the Channel data with the Project, so I enjoyed reading AQ's analysis of the current design decision, which does make sense to me].

What I've found that works (and was suggested during problems I reported during the 2016 Beta) is to simply delete the appropriate ChannelInstances folder in ExtraVILib.  Do this with the Project closed (I usually do it with LabVIEW not running).  Now, when you open your Project using Channels, you will force a rebuild, "from scratch", and everything should now work.  [Of course, when you go to the "competing" Project, you may have to repeat this process ...]

Despite this minor glitch, I remain an enthusiastic Channel user.

Bob Schor

Message 5 of 10
(10,918 Views)

Unfortunately this does not work for me either, it only regenerates the two channels I mentioned above. The only workaround I have at this time is to copy the directory to the new computer, however this is only a partial workaround as it does not solve the problem of the channel being unable to find the class.

0 Kudos
Message 6 of 10
(10,918 Views)

Quick update, I was able to fix the conflict problem by opening the specific instances of the channel VI's (in the LabVIEW Data folder) which used the class and this let me resolve the conflicts.

0 Kudos
Message 7 of 10
(10,918 Views)

> Could the channels be regenerating somewhere other than LabVIEW Data?

Nope.

0 Kudos
Message 8 of 10
(10,918 Views)

What are the transmission data types of the two that don't regenerate?

0 Kudos
Message 9 of 10
(10,918 Views)

Both tag channels associated with my class don't regenerate. There is also an I64 stream with abort (r/w), and a bool tag r/w which don't regen either. It does regenerate the two streams below (confirmed after trying Bob's suggestion of clearing the folder before loading LV).

ChannelInstances Folder - CPU2.PNG

0 Kudos
Message 10 of 10
(10,918 Views)