Channel Wires on RT systems, duplicate VI error

[sth]

You may need more than regenerating the folder.  Since you renamed the type def, it is now disconnected from the instantiation of the channel.  When you create the channel, I assume it creates files tied to that typedef by name of the typedef.  Once you rename the typedef (especially outside of LV) you break that connection and need to recreate the channel endpoints with the new typedef.

I haven't explored strict typedefs and channels, renaming within the project **should** be smart enough to find the channel that references the typedef and fix the reference.

[billko]

---

@sth wrote:

You may need more than regenerating the folder.  Since you renamed the type def, it is now disconnected from the instantiation of the channel.  When you create the channel, I assume it creates files tied to that typedef by name of the typedef.  Once you rename the typedef (especially outside of LV) you break that connection and need to recreate the channel endpoints with the new typedef.

I haven't explored strict typedefs and channels, renaming within the project **should** be smart enough to find the channel that references the typedef and fix the reference.

---

And that's what makes channels so frustrating to me.  I shouldn't have to hunt down all the endpoints just because I changed a typedef.  With a queue, you just change the typedef.  End of story.

That's what I would think, too.  If a VI is in a project, I always open the project and rename it with the right-click rename option.  (I then deal with it in TSVN by using the "repair move" option so SVN understands that I didn't delete the file and create another one.  SVN freaks out when you don't use their renaming tool.  I mean, they both freak out if you don't use their respective renaming tools, but it's a lot easier to use the LV renaming tool and fix SVN than the other way 'round.)

[sth]

To get back on OT (yes, I agree that it should work renaming in the project, and maybe that is (or will be) fixed in LV XXX).  But, it seems that having channels and an FPGA FIFO are the real culprits for the "duplicate VI error".  This is not a problem with typedefs etc.  I have stripped out most of the other code and removed all subVI calls so that the only reference is now to an FPGA that has one simple FIFO in it.  The project and code is attached, simply open the code and try to Build the RT source distribution.  I think I will submit this as a bug report.

[sth]

Bob, just to close out this topic.  YES it is a bug.  Or rather it "is not a bug but a feature and we fixed it in the next release". 🙂

Yes it isn't supposed to happen, but seems to have been mysteriously fixed in LV 18!  In the middle of a project and maybe after next week I will update and test.

NI AE got back to me with the following:

" I was able to reproduce the behavior you're seeing in 2017 SP1.  In the process of escalating it upward, I had a colleague try with LabVIEW 2018 and we didn't see the build warning; presumably, some underlying bug has been fixed but I wasn't able to find anything internally indicating which bug that might have been.  R&D is taking a look right now and we'll let you know what they find.  If you're planning an update to 2018 at some point, that will definitely solve the problem"

[sth]

And after further conversation where I am assured that the compiler knows what it is doing by renaming the VIs, I find that there are now 3 VIs named Initialize, all different in the RT lvuser directory.  Nobody is sure what the 3rd one is for....  🙂  But NI is confident it is fixed in the next release.

% find ~lvuser/natinst/bin -name Initialize.vi -exec ls -l \{\} \;

-rw-rw-r--    1 lvuser   ni           16366 Jul 20 09:32 ./Tag-a[.](dbl).lvlib_TagData/Initialize.vi

-rw-rw-r--    1 lvuser   ni           18094 Jul 20 09:32 ./Error Ring/Initialize.vi

-rw-rw-r--    1 lvuser   ni           18086 Jul 19 17:51 ./Initialize.vi

% 

[Bob_Schor]

I'm not sure myself about the third Initialize, but the first two look like the "Class Initializer" that, for example, initializes some of the Cluster Elements of the Channel's Class wire.  The first one is for a Tag channel, and I'm not sure what an Error Ring is ...

Bob Schor

[Ben]

I am late to the game but...

I do recall there was an issue in source distributions that I was able to get around by using the "save for Previous..." and then select the current version of LV.

It worked for me.

Ben

[sth]

I agree, that these are class initializers and some internal NI thingymabob for the Error Ring.  I did not write any VI that was Initialize.vi and it is not in my source distribution.  The third version is a complete mystery to me (and to NI).  It seems that NI is overloading the Intialize.vi as a name and causing conflicts.  Supposedly LV 18 will resolve this.  But why are their 3 different VIs with a name conflict in my simple project!  The appearance of a 3rd Initialize.vi seems to have stumped the AE.

Ben, the save source distribution might work, except this is a "Source Distribution" build for an RT system and needs to be using the build/deploy mechanism so that save won't work.