LabVIEW
Channel Wires on RT systems, duplicate VI error
I am using a Tag Channel on an RT system and then serving the data to a client. However every time I "build" the source package for the RT system I get an error about duplicate VI names. This seems to be an issue with the implementation of Channel Wires on RT systems.
LabVIEW prevented a file name collision during the build. Duplicate file names cannot be copied to the same destination. You can rename files as part of the build process to avoid name conflicts.
The following files were moved to a unique location:
C:\Users\sth\Documents\LabVIEW Data\2017(32-bit)\ExtraVILib\ChannelInstances\Tag-a[.](dbl)\Initialize.vi
There is only one tag channel of a 1D array of doubles. This channel has only one writer in the main program and only one reader in a sub VI. So why does the build think that there are two Initialize calls and that they are different VIs? The Initialize is in the class definition.
LV 2017SP1. RT system is a cRIO-9039 RT linux. Is this a bug in the implementation on RT systems?
Bob,
I figured I would get a response from you or AQ!
I guess that I didn't mention that the channel works quite well on the RT system. It just gives me this notice every time I build the Source Package. If I click "OK" and tell it to go ahead and create the unique named VI then it does and is happy.
Interesting about your experience with 2016 > (2017 | 2018). I haven't tried anything advanced with 2018 other than basic functionality. Since channel wires were a bit experimental in 2016 and needed a bunch of specific patches I was hoping for a robust implementation in 2017. I understand the frustration of simple test cases all working but real complicated life failing! I was thinking of moving my whole project to 2018 and testing but still working on edge cases in the current system.
-Scott
@drjdpowell wrote:
@sthThat's not an error; it's just a warning. "Initialize" is a common vi name, and another library you have must also have an "Initialize.vi". The build tries to flatten out directory hierarchy, but can't have VIs of the same name in the same folder, so gives that warning. I use LVOOP dynamic dispatch and get uncounted numbers of those warnings from all the same-named VIs. The fact that they are in different libraries/classes doesn't mater to the builder; all files in one folder must have unique names.
I thought the whole idea behind moving from LLBs to lvlibs was to prevent name collision. (Actually there is more reason, but it was a bigly reason). The build does create "Tag-a[.](dbl).lvlib" on the RT target which should have the mangled name for the tag initialization code which I assume is one of the culprits. However if I search my Project for "Initialize" I only find that one instance inside the Tag for a 1D array of doubles lvlib. I can't find another one to conflict. I think it may be that somehow it thinks it is loading it twice and conflicting with itself? Assuming the tag creation and naming scripts that generate the LV classes on the fly are correct there should not be a conflict.
I agree Initialize.vi is a common name and should be avoided other than inside a name mangled LV library. But maybe it is just OCD in my trying to remove this error but it signifies something is behaving in a not well understood way. Since I am opening references and need to find VIs by path I did ask that the hierarchy be flattened, BUT that is the default I believe and even if the files have different paths you can't open two VIs of the same name.
Bob, this makes sense and I was aware of the first time each developer creates/opens a channel a whole bunch of code in the developers default LV directory. Sometimes I have had to delete that and let it be recreated as patches come out for the Channel creation code. I think I have groked most of the weirdness in channels. I have seen the channel code created by channel type and data type.
I don't quite understand how to "name" a channel. This is a new one to me, though I have been playing with channels since they came out as a hidden feature. Each channel is defined by the "Channel" (stream, tag, messenger, etc) and the data type (in this case 1D array of doubles). So how do I put a "name" in there to distinguish the different channels? Or should I need two since the same code can be instantiated for two different channels of the same type and data. Are you suggesting creating a special strict type def for the data and using that in the creation of the channel? Is the name in the channel library "a" in the case above? I haven't seen that in an editable property.
In this case I have only 1 channel and thus only using one lvlib of the type and data shown above. "Tag-a[.](dbl)", there is only one channel instance in the folder tree on the host development system. HOWEVER, I do pass the channel to a subVI were it is read and thus the Initialize.vi has as its callers, both other VIs in the library AND the subVI. Is it possible that the SubVI and the library call the Initialize.vi and thus have a collision? If I created the FP control for the channel incorrectly, I could delete and recreate the FP item and maybe resolve this?
create channel writer (creates channel code including links to Initialize.vi).
create channel reader
select channel reader and "Create SubVI", this will create a new link to Initialize.vi???
According to "Find this VIs callers" for Initialize.vi, the callers are all internal to the lvlib except for one call directly by that tag reading subVI.
My guess is that there is an issue with the channel creation code and it ends up with two calls to the same initialize but doesn't know it. I guess it is a bit OCD to try to get rid of this error that doesn't seem to affect the operation of my code but there may be an underlying issue that does need to be addressed in how channels are used or the code to create them.
(See how this gets off of general forum interest quickly and into internal details that can be discussed easily with champions) Congrats to new champion Bob!
-Scott
"I'm all booked up on weird today"
-Capt. Dylan Hung
But multiple Initialize.vi built by scripts (or the same script) is the one that is throwing the error. If it is a red herring then the RT deploy function is being fooled by it! I can't find any other Initialize.vi in the entire project since it only has one channel. There may be something in another lvlib that I can search, but I looked and failed to find it. The project "search" function also only returns one Initialize.vi instance in the project. So it is not common to a bunch of libraries in this case.
It still shows the error on building but this afternoon it does not show that the Initialize.vi is called by more than one VI. Not sure what changed, I made no changes to the code other than rebuilding and reconnecting to the target.
It would be nice if the error message gave a hint as to what it renamed the VI to on the target to avoid the conflict.
I can have more tests on Tuesday, I am connecting through VNC to my work desktop and then running a virtual windows machine to connect to the RT system. It makes things a bit slow and hard to read.
OK, so it took me a little more time (took time to have a cup of tea). Actually, I tried exactly what I described, it failed miserably (because I used a Tag Channel -- here's the Test with a Stream Channel, instead).
So here are three parallel loops generating numbers 1-10, 11-20, and 21-30. They pass their values using a Stream Channel into a sub-VI that (Read Stream, Increment, Write Stream). There's only one of these (I could have cloned it, but figured this would be more of a test), and then pass the Stream out to a Receiver that outputs the 10 values. Guess what? We get 1..10, 11..20, 21..30.
Bob Schor
