LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW 8.6.1 Project causes slow Open VI Reference

Solved!
Go to solution

nrp wrote:

A possible workaround is to avoid using type defs in projects for the time being.

YES! That is exactly the answer.

 

I mean, who uses typedefs anyway?

 

In other news, because of a bug discovered in LabVIEW, NI recommends as a workaround not to use sub-VIs, and suggest to exclusively use Express VIs instead. 

 

Doh!


It's kind of like the old joke: Patient: It hurts when I do this. Doctor: Don't do that.

 

Is there a way (for a layman) to check on the status of a CAR? Can bug fix request be added to the idea exchange to give NI feedback on the importance of a CAR?

Message 11 of 20
(3,852 Views)

Unfortunately there is no method for external tracking of CARs.  You can check the status of fixed issues in the LabVIEW readme, and the CAR numbers are associated with the descriptions.  Currently, operating outside of a project is the best course of action (I know it is not a true workaround).  I have update the CAR to show updates to this discussion forum.  I will repost on this thread as soon as a solution becomes available.

 

 

Nick Keel 

Applications Engineering 

National Instruments

Nick Keel
Product Manager - NI VeriStand and Model Interface Toolkit
National Instruments
Message 12 of 20
(3,825 Views)

I'm starting to look for alternatives to labview.

It was nice until about labview version 7.1.1.

Since then, downhill....

Visual Studio with C# is getting more tempting these days.

Better tools, better development performance.

Richer GUI designs.

etc.....

Maybe use labview for some data acquisition and math.

then immediatly move it all (via DLL?) to C# or so.

0 Kudos
Message 13 of 20
(3,651 Views)

NAKeel wrote:

This was reported to R&D (# 183991) for further investigation. A possible workaround is to avoid using type defs in projects for the time being.  I will continue to investigate other possible workarounds.  Thanks for the feedback!

 

Nick Keel 

Applications Engineering 

National Instruments

 

That suggested work-around has to rate right up there with ... the most rediculous thing I have ever read.

 

I'm going to raise this post to the attention of R&D but for the time being, I'll deal with in the only appropriate manner... add a link to the Funny Threads.

 

Ben

 

PS: Ys I know this thread is old but even old jokes can be funny the first time you read them.

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 14 of 20
(3,648 Views)

Ben wrote:

NAKeel wrote:

This was reported to R&D (# 183991) for further investigation. A possible workaround is to avoid using type defs in projects for the time being.  I will continue to investigate other possible workarounds.  Thanks for the feedback!

 

Nick Keel 

Applications Engineering 

National Instruments

 

That suggested work-around has to rate right up there with ... the most rediculous thing I have ever read.

 

I'm going to raise this post to the attention of R&D but for the time being, I'll deal with in the only appropriate manner... add a link to the Funny Threads.

 

Ben

 

PS: Ys I know this thread is old but even old jokes can be funny the first time you read them.


Not just an old joke!

 

It explains a "feature" on one of my projects.   Thanks for bringing attention to this!  and I'm NOT laughing.  

 

<Jeffism mode=true>

      In my experience I've found a few unique "Kinds" of funny---

  •  Always funny:Everyone appreciates it all the time. usually based on wit.
  •   e.g. ME: "I've got a GREAT knock-knock joke but, you have to start it.
  • "Victum:  "Oh.. OK Knock-Knock
  • "ME: "Who's There?"
  • DOH
  •  Next Day Funny: These are like cheese or wine in that they need to age before they are appreciated.  Usually based on personal misfortune 
  • While driving last week I noticed the car next to me at a stop light had a tire that was uninflated.  I honked, pointed at the car's rear,  made a signalwith one hand moving in a circle and then used two hands like "=" to show the tire was not round.  The other driver then rolled down the passenger rear window and asked why she needed to roll down her window.  (I don't play charades well I guess)  Frustrating at the time But, funny
  • Other-people Funny: if it happens to you its embarrassing, humiliating or otherwise painful.  Slip-stick humor isn't funny to the practioner. 
This is other-people funny- and happened to me-  I hope you can all get a chuckle   but.... I've got some explaining to do to my customer

"Should be" isn't "Is" -Jay
Message 15 of 20
(3,581 Views)

 

>In other news, because of a bug discovered in LabVIEW, NI recommends as a workaround not to use sub-VIs, and suggest to exclusively use >Express VIs instead. 

 

nrp

WHat does you mean? I should not use sub-vi's? O.o

Can you post the source of these notice??

thank you!

 

 

0 Kudos
Message 16 of 20
(3,331 Views)

He was joking.

0 Kudos
Message 17 of 20
(3,299 Views)
Solution
Accepted by topic author Gleichman

I did not find this CAR (183991) in the LV2010 release notes, but I have tested it in LV2010 and it is fixed.

 

Smiley Happy YEAH!

0 Kudos
Message 18 of 20
(3,180 Views)

Hello Everyone,

 

I checked the information on this CAR and it is indeed fixed in LabVIEW 2010.  It's fixed version was improperly marked in our database so it didn't show up when I created the Bug Fixes.

 

Hope everyone survived by not using type definitions in their projects Smiley Wink

Regards,

Jon S.
National Instruments
LabVIEW NXG Product Owner
0 Kudos
Message 19 of 20
(3,176 Views)

Not fixed in LV2015.

 

Reading approx. 195 typdef controls from disk as variants takes significantly longer when the VI is opened from the LabVIEW project rather than from disk.

 

1783ms vs 8445ms

Message 20 of 20
(1,624 Views)