05-08-2023 09:51 AM
I've already opened a support ticket with NI for this, but since the issue is also there in the new beta I thought I'd mention it here to get some additional attention. Request #02192158.
Attached is a zip with a project and a few VIMs in it. In the project is a main VI. If you run this VI it runs like normal filtering a 1D array. But if you attempt to build the application using this main VI it gives an error that a VI is not in memory. NI support has pointed out that if you check the Disconnect type definitions, from the application builder it will build successfully. I'm happy with having a work around for my application, but I have some VIMs posted online, and I don't want my users to have builds fail, and not know the thing needed to make it work.
Unofficial Forum Rules and Guidelines
Get going with G! - LabVIEW Wiki.
17 Part Blog on Automotive CAN bus. - Hooovahh - LabVIEW Overlord
05-08-2023 08:57 PM
Hi Hooovahh,
I managed to get the example code building without disconnecting typedefs. If you replace this call to Search 1D Array-VIM.vim with itself, then it'll build just fine. I've found any time something odd with vims happens, relinking them helps to resolve things.
Out of interest, do you see this issue with your library code before it's been packaged up with VIPM? I've had some oddities in the past with libraries that have gone through the VIPM build process, where the resulting calls to vims had the characteristic broken-but-not-broken wires.
05-09-2023 11:36 AM
Thanks for the input. I was able to replace the VIM you suggested and it did build properly. However the VIM does appear to be changed in some way during the VIPM build process. When linking to the source in 2020 I replaced the VIM and it fixed the issue. I built the VIPM package, then tried to make another application linking to the user.lib source. That then wouldn't work. I replaced the VIM from the user.lib source but that didn't work either.
Can anyone at NI look at fixing this? A work around is fine but there clearly is something wrong with VIMs that needs to be addressed.
Unofficial Forum Rules and Guidelines
Get going with G! - LabVIEW Wiki.
17 Part Blog on Automotive CAN bus. - Hooovahh - LabVIEW Overlord
05-16-2023 09:12 AM
@Hooovahh wrote:
Can anyone at NI look at fixing this? A work around is fine but there clearly is something wrong with VIMs that needs to be addressed.
The automated forum email reminded me to mark a solution to my problem. So I'm here reminding NI this bug exists. My last correspondence with support was asking for the bug number for this issue.
Unofficial Forum Rules and Guidelines
Get going with G! - LabVIEW Wiki.
17 Part Blog on Automotive CAN bus. - Hooovahh - LabVIEW Overlord
05-17-2023 07:54 AM - edited 05-17-2023 08:17 AM
NI did respond with a bug number 1769482. I hope that by providing a simple set of code that reproduces the issue, that it can be isolated and fixed.
EDIT: Nevermind I just googled the bug number and it already existed, and doesn't seem to be my issue...this feels like an attempt to quickly close out issues instead of resolving it.
Unofficial Forum Rules and Guidelines
Get going with G! - LabVIEW Wiki.
17 Part Blog on Automotive CAN bus. - Hooovahh - LabVIEW Overlord
05-18-2023 10:56 AM
@Hooovah
Hi Brian,
Be assured NI is investigating further. Based on the information you have provided, we may create a new bug.
Did you identify this issue while testing the beta, or have you seen it previously? I am wondering if there are other support cases/forum posts related to this issue.
Thanks,
David.
05-18-2023 11:49 AM
I discovered it in LabVIEW 2022 Q3. I then tested it in the beta to confirm the same behavior.
Unofficial Forum Rules and Guidelines
Get going with G! - LabVIEW Wiki.
17 Part Blog on Automotive CAN bus. - Hooovahh - LabVIEW Overlord
05-26-2023 08:19 AM
NI issued a new bug number for this 2401803.
Unofficial Forum Rules and Guidelines
Get going with G! - LabVIEW Wiki.
17 Part Blog on Automotive CAN bus. - Hooovahh - LabVIEW Overlord