LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Mac Application Builder hundreds of 'You have connected two terminals of different types.' errors

When building through our continuous integration system, our mac builders, are consistently failing with hundreds of 'You have connected two terminals of different types.' errors.  Kicking off builds manually is inconsistent, usually errors out in a similar way to when run by CIS.  For some background, this started happening on our 2 mac builders and one of our 2 windows builders around the same time.  The Windows server started working after just kicking a few builds off manually for no real reason.  No such luck on the mac's.  

Details of the error are:

Details pane reads:

Click the link below to visit the Application Builder support page. Use the following information as a reference:

Error 1003 occurred at AB_Get_Detailed_BrokenVI_Message.vi -> AB_Targetfile.lvclass:Open_Top_Level_VIs.vi

Possible reason(s):

LabVIEW: (Hex 0x3EB) The VI is not executable. This error may occur because the VI is either broken or contains a subVI that LabVIEW cannot locate. Select File>>Open to open the VI and verify that you can run it.

 

And an excerpt from the 'possible reasons' pane:

Broken VIs:
- Acquisition Channel Collection.lvclass:Write Play Buffer.vi:Instance:6a95dd55-7b1f-4622-9396-9d8b284bf9cc.vi:Instance:04fede94-e80d-4ae0-b79f-3ecfede430cc.vi:Instance:529e3ff3-7b1a-4637-8f9b-fb3c31bc4e4f.vi:
An unsupported data type is wired to this subVI node.
Polymorphic terminal cannot accept this data type.
Polymorphic terminal cannot accept this data type.
Polymorphic terminal cannot accept this data type.
- Acquisition Channel Collection.lvclass:Write Play Buffer.vi:Instance:6a95dd55-7b1f-4622-9396-9d8b284bf9cc.vi:Instance:04fede94-e80d-4ae0-b79f-3ecfede430cc.vi:Instance:529e3ff3-7b1a-4637-8f9b-fb3c31bc4e4f.vi:Instance:5d3ee391-5e24-46f3-8538-f76ba2ee4917.vi:
Contains unwired or bad terminal
Class conflict
You have connected two terminals of different types.
You have connected two terminals of different types.

 

The above is repeated several hundred times just with different vi's and instances.

Any thoughts?

Thank you.

0 Kudos
Message 1 of 7
(1,227 Views)

The question everyone is going to have is, what all has changed since the working condition?

 

  1. Changes to code?
  2. Upgrade of LabVIEW year/SP, or a change in bitness?
  3. Changes to your antivirus software? (Cybereason and LabVIEW hate each other)

 

Have you tried a mass compile yet?

Redhawk
Test Engineer at Moog Inc.

Saying "Thanks that fixed it" or "Thanks that answers my question" and not giving a Kudo or Marked Solution, is like telling your waiter they did a great job and not leaving a tip. Please, tip your waiters.

0 Kudos
Message 2 of 7
(1,220 Views)

Hello, I work with OP.

 

We will clear the compiled cache and maybe mass compile as well and see what that does.

 

As for your questions

 

  1. Changes to code? - apparently we've narrowed this to a change where a class inheritance was switched to a different class which is an Actor (Monitored Actor I believe).  Also in this changelist, some code which was statically linked is now called by Actor Core and as such is a bit less static I believe.

  2. Upgrade of LabVIEW year/SP, or a change in bitness?
    LabVIEW 2020 MacOS 64 bit.   not sure about service pack will get back to you on that.

  3. Changes to your antivirus software? (Cybereason and LabVIEW hate each other)
    No.  Furthermore, we can get things to build successfully if we tell our builder to build the changelist prior to the one identified as problematic.

 

0 Kudos
Message 3 of 7
(1,177 Views)

As Thomas mentioned, yes, there was a changelist where this problem started happening consistently, though the problem did occur sporadically before that.  Re-attempting that first changelist that didn't build yesterday, failed again, and rebuilding the last good changelist was successful, so there certainly is something about that changelist that App builder didn't like.

 

LabVIEW version is 2020 SP1, as mentioned nothing we know of was changed recently as far as the LabVIEW environment or any of the other software on the builders.

 

Waiting on a mass-compile on one of the mac builders right now.

0 Kudos
Message 4 of 7
(1,163 Views)

@JDBaker wrote:

As Thomas mentioned, yes, there was a changelist where this problem started happening consistently, though the problem did occur sporadically before that.  Re-attempting that first changelist that didn't build yesterday, failed again, and rebuilding the last good changelist was successful, so there certainly is something about that changelist that App builder didn't like.


 

If I'm understanding you both correctly, you have a 100% good changelist c0 that builds successfully every time, another changelist c1 where the build fails sporadically, and yet another changelist c2 where the build fails consistently? That sounds like a real mess 😬

 

Assuming I described things correctly, I would start by looking at c0 vs c1, ignoring c2 completely. 

 

Do you have verbose logging enabled for your builds? I feel like it's not gonna tell you much that you don't already know, but it might. If you don't already know, turn it on by going into your LabVIEW.ini and adding the NI_AppBuilder_Logging=True token.

Redhawk
Test Engineer at Moog Inc.

Saying "Thanks that fixed it" or "Thanks that answers my question" and not giving a Kudo or Marked Solution, is like telling your waiter they did a great job and not leaving a tip. Please, tip your waiters.

0 Kudos
Message 5 of 7
(1,160 Views)

@FireFist-Redhawk wrote:

If I'm understanding you both correctly, you have a 100% good changelist c0 that builds successfully every time, another changelist c1 where the build fails sporadically, and yet another changelist c2 where the build fails consistently? That sounds like a real mess 😬

 

Assuming I described things correctly, I would start by looking at c0 vs c1, ignoring c2 completely. 

 

Do you have verbose logging enabled for your builds? I feel like it's not gonna tell you much that you don't already know, but it might. If you don't already know, turn it on by going into your LabVIEW.ini and adding the NI_AppBuilder_Logging=True token.


It's even weirder than that.  c0 builds successfully, c1 fails sporadically, c2 builds consistently, c3 fails consistently.  (note that some of those are ranges.)  Also 'consistent' is 2-3 builds, as our builds take about an hour, so I haven't been running these 10x or whatever.

 

I tried NI_AppBuilder_Logging=True but it didn't really seem to show much more info.  I still haven't combed through the log, I'll try and look at it soon.

0 Kudos
Message 6 of 7
(1,144 Views)

We found a workaround, but would still like to try to figure out what is going on and hopefully implement a more direct fix.

I found that manual builds (kicked off from LabVIEW project explorer) failed if I ran them right after opening the project, but built if I opened our VI that includes all our always included VI's.

So I added some code to our builder to open the front panel of that vi before building and it's working now.

Does that mean anything to anyone?

Thanks yet again.

0 Kudos
Message 7 of 7
(1,110 Views)