LabVIEW
Project with many streams - LLB fails due to duplicate files
When you say "compile the llb", do you mean that you have your VIs in an llb and that the VIs do not compile and are therefore not executable, or do you perhaps mean that you create some kind of build and create an llb for the VIs?
Anyway, Channel wires don't handle naming or namespace change well (at least they didn't in LV2019). I guess that for example channel wires and ppl:s can have issues, and maybe you mean ppl when you say llb?
I'm guessing you let the build place everything in a folder but without preserving hierarchy. When building, do you get messages about VIs being renamed?
Yes, my source is a lvproj, the destination is a LLB.
I don't really understand, what labview is doing. Why are those files in the users/documents folder, and not within the project folder? If someone else pulls this project from git, they are all missing?! Who told NI this is a good idea?
And why can't labview put all files into the llb and is instead creating more and more extern files and folders? (second picture)
Is the destination just on big llb with many streams in it? That will probably not work for channel-instances. I would report it to NI though because of course it should work and the application builder should take care of it, or give you an error during the build.
Try to at least separate so that you have one llb per "Channelnstances". Or if you need the source code preserved, just have it as a folder with preserved hierarchy.
I am curious of what your goal is. Who will be using the llb? An application, other developers,a plugin architecture? If you explain your goal, maybe we can give advice on the best build spec. One big llb is probably not the best solution for most goals.
The ChannelInstances are created when another user opens the code. That had some hiccups before LV2020 but I have not seen any issues with it since then. So it should not be an issue.
Hi thols,
the structure is not that complicated. We build specific test routines for every dut and export this as an llb. Each LLB contains a vi with a test software template, that will be called dynamically by our test interface (executable written in labview). Point is: the vis within llbs can be executed by the labview runtime without the need of having the full development on the test pc. So the llb is part of our "plugin" system. The structure has grown in one and half decade so please don't question it. I'd be the first to change it but that's "none of my business"...
however: I just found out vis are being placed in the <extralib> folder, that is per default in the userdata folder. I tried to move the code to the project but this just triggers labview to throw numerous file missing and reference fault exceptions eventually triggering the rebuild of the stream vis. Simply deleting the extralib content triggers it too, so yes, there is no need in caring about it.
So eventually there seems to be only one issue: duplicate file names in the auto generated extralib lvlibs (streams).
Building the LLB causes a load of warnings:
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\user_name\Documents\LabVIEW Data\2021(32-bit)\ExtraVILib\ChannelInstances\Stream-bool\Enqueue.vi
C:\Program Files (x86)\National Instruments\LabVIEW 2021\resource\ChannelSupport\_ChannelSupport\PipeLogic\Enqueue.vi
C:\Program Files (x86)\National Instruments\LabVIEW 2021\resource\ChannelSupport\_ChannelSupport\PipeLogic\SetSize.vi
C:\Users\user_name\Documents\LabVIEW Data\2021(32-bit)\ExtraVILib\ChannelInstances\Stream-bool\SetSize.vi
C:\Program Files (x86)\National Instruments\LabVIEW 2021\resource\ChannelSupport\_ChannelSupport\PipeLogic\Dequeue.vi
C:\Users\user_name\Documents\LabVIEW Data\2021(32-bit)\ExtraVILib\ChannelInstances\Stream-bool\Dequeue.vi
C:\Users\user_name\Documents\LabVIEW Data\2021(32-bit)\ExtraVILib\ChannelInstances\Stream-bool\Initialize.vi
C:\Users\user_name\Documents\LabVIEW Data\2021(32-bit)\ExtraVILib\ChannelInstances\Stream-bool\Read.vi
C:\Users\user_name\Documents\LabVIEW Data\2021(32-bit)\ExtraVILib\ChannelInstances\Tag-t'M-NET-control_F6AE1631_0830DDDA.ctl'\Read.vi
C:\Users\user_name\Documents\LabVIEW Data\2021(32-bit)\ExtraVILib\ChannelInstances\Stream-bool\Read With Abort.vi
C:\Users\user_name\Documents\LabVIEW Data\2021(32-bit)\ExtraVILib\ChannelInstances\Tag-t'M-NET-control_F6AE1631_0830DDDA.ctl'\Read With Abort.vi
C:\Users\user_name\Documents\LabVIEW Data\2021(32-bit)\ExtraVILib\ChannelInstances\Stream-bool\EndpointRead.vi
C:\Users\user_name\Documents\LabVIEW Data\2021(32-bit)\ExtraVILib\ChannelInstances\Tag-t'M-NET-control_F6AE1631_0830DDDA.ctl'\EndpointRead.vi
C:\Users\user_name\Documents\LabVIEW Data\2021(32-bit)\ExtraVILib\ChannelInstances\Tag-t'M-NET-control_F6AE1631_0830DDDA.ctl'\Initialize.vi
C:\Users\user_name\Documents\LabVIEW Data\2021(32-bit)\ExtraVILib\ChannelInstances\Tag-t'M-NET-control_F6AE1631_0830DDDA.ctl'\Get.vi
C:\Users\user_name\Documents\LabVIEW Data\2021(32-bit)\ExtraVILib\ChannelInstances\Stream-bool\Instantiate.vi
C:\Users\user_name\Documents\LabVIEW Data\2021(32-bit)\ExtraVILib\ChannelInstances\Tag-t'M-NET-control_F6AE1631_0830DDDA.ctl'\Instantiate.vi
C:\Users\user_name\Documents\LabVIEW Data\2021(32-bit)\ExtraVILib\ChannelInstances\Tag-bool\Read.vi
C:\Users\user_name\Documents\LabVIEW Data\2021(32-bit)\ExtraVILib\ChannelInstances\Tag-t'M-NET-control_F6AE1631_0830DDDA.ctl'\))Channel.ctl
C:\Users\user_name\Documents\LabVIEW Data\2021(32-bit)\ExtraVILib\ChannelInstances\Tag-bool\))Channel.ctl
C:\Users\user_name\Documents\LabVIEW Data\2021(32-bit)\ExtraVILib\ChannelInstances\Tag-bool\Read With Abort.vi
C:\Users\user_name\Documents\LabVIEW Data\2021(32-bit)\ExtraVILib\ChannelInstances\Tag-bool\EndpointRead.vi
C:\Users\user_name\Documents\LabVIEW Data\2021(32-bit)\ExtraVILib\ChannelInstances\Tag-t'M-NET-control_F6AE1631_0830DDDA.ctl'\))Channel.vi
C:\Users\user_name\Documents\LabVIEW Data\2021(32-bit)\ExtraVILib\ChannelInstances\Tag-bool\))Channel.vi
C:\Users\user_name\Documents\LabVIEW Data\2021(32-bit)\ExtraVILib\ChannelInstances\Tag-bool\Instantiate.vi
C:\Users\user_name\Documents\LabVIEW Data\2021(32-bit)\ExtraVILib\ChannelInstances\Tag-bool\Initialize.vi
C:\Users\user_name\Documents\LabVIEW Data\2021(32-bit)\ExtraVILib\ChannelInstances\Tag-t'M-NET-control_F6AE1631_0830DDDA.ctl'\TagData.lvclass
C:\Users\user_name\Documents\LabVIEW Data\2021(32-bit)\ExtraVILib\ChannelInstances\Tag-bool\TagData.lvclass
C:\Users\user_name\Documents\LabVIEW Data\2021(32-bit)\ExtraVILib\ChannelInstances\Tag-bool\Get.vi
C:\Users\user_name\Documents\LabVIEW Data\2021(32-bit)\ExtraVILib\ChannelInstances\Tag-t'M-NET-control_F6AE1631_0830DDDA.ctl'\Set.vi
C:\Users\user_name\Documents\LabVIEW Data\2021(32-bit)\ExtraVILib\ChannelInstances\Tag-bool\Set.vi
C:\Users\user_name\Documents\LabVIEW Data\2021(32-bit)\ExtraVILib\ChannelInstances\Tag-t'M-NET-control_F6AE1631_0830DDDA.ctl'\Tag-FPGA-))Channel-NoOp.vi
C:\Users\user_name\Documents\LabVIEW Data\2021(32-bit)\ExtraVILib\ChannelInstances\Tag-bool\Tag-FPGA-))Channel-NoOp.vi
C:\Users\user_name\Documents\LabVIEW Data\2021(32-bit)\ExtraVILib\ChannelInstances\Stream-bool\Write.vi
C:\Users\user_name\Documents\LabVIEW Data\2021(32-bit)\ExtraVILib\ChannelInstances\Tag-t'M-NET-control_F6AE1631_0830DDDA.ctl'\Write.vi
C:\Users\user_name\Documents\LabVIEW Data\2021(32-bit)\ExtraVILib\ChannelInstances\Stream-bool\Write With Abort.vi
C:\Users\user_name\Documents\LabVIEW Data\2021(32-bit)\ExtraVILib\ChannelInstances\Tag-t'M-NET-control_F6AE1631_0830DDDA.ctl'\Write With Abort.vi
C:\Users\user_name\Documents\LabVIEW Data\2021(32-bit)\ExtraVILib\ChannelInstances\Stream-bool\Endpoint.vi
C:\Users\user_name\Documents\LabVIEW Data\2021(32-bit)\ExtraVILib\ChannelInstances\Tag-t'M-NET-control_F6AE1631_0830DDDA.ctl'\Endpoint.vi
C:\Users\user_name\Documents\LabVIEW Data\2021(32-bit)\ExtraVILib\ChannelInstances\Tag-bool\Write.vi
C:\Users\user_name\Documents\LabVIEW Data\2021(32-bit)\ExtraVILib\ChannelInstances\Tag-bool\Write With Abort.vi
C:\Users\user_name\Documents\LabVIEW Data\2021(32-bit)\ExtraVILib\ChannelInstances\Tag-bool\Endpoint.vi
And also it causes two files declared as missing:
Both the "Instanciate.vi"s from the tag streams.
If I ignore those items, build will eventually succeed but I don't trust it and can't test it either right now.
Filing a bug report is somehow pointless. NI doesn't seem to have tested those new functions properly. Introduced 2020 it still has bugs. My company will not go into the subscription so even if this is a real bug and it will be fixed in 2023, it neither will help me now nor will I be able to use it.
I hope I cleared some things out now 🙂
I understand your situation.
If you open a service request, NI can and will try to help you get unstuck. I think you have a very clear case that could easily be reproduced. The downside may be that either you send them all your code or you may need to create a project that shows these issues. The latter should be easy though. Just opening a request with the info in this thread is should be a good start or enough.
Some thoughts: you need to create an llb, but do you have to have everything in that llb? Could you have that llb use code that is deployed as folders with VIs, for example, or a zip?
@Nils_Thomsen wrote:
Well via a config file i point to the interface vi in the llb. Honestly i never tried to simply give a vi path. The only thing that matters is the labview runtime to be able to run the vis. If they are in a llb, or not, doesn't really matter?!
It doesn't matter for LabVIEW. Maybe your test interface requires it. If it does, you could for example only have the main VI in the llb and the rest outside.
