Jump to content

things that have improved


i2dx

Recommended Posts

  • Replies 87
  • Created
  • Last Reply

Top Posters In This Topic

Thank you Chris.

In its defense.

A) I did not cross any wires.

B) Its fun to watch in execution highlighting mode. :wacko:

Should I have posted this to the fifth dimension thread? (insert Twilight Zone music here).

Ben

Defend it all you like - the NI VI Analyzer would vomit if it saw that VI :laugh: That said, I'm sure it'd be even prettier with the NI Logo execution highlighting on (labview.ini easter egg)...

Link to comment
  • 3 weeks later...
If you need this functionality in LabVIEW 7.x, there's a VI that does exactly the same thing in vi.lib\tree.

Except that Ben's image shows the method for a table, not a tree, and I don't know of any vi.lib VI which handles that (and the private method did not work in 7.0). That said, there are some implementations on the web for doing this for tables and arrays.

Link to comment

I read the upgrade notes but I still seem to find other stuff that I do not remeber reading about.

In LV 8.20 you can easily find the root VI that is breaking your application.

I dropped an Config Data Open and wired up a constant to the path.

I went down in the hiarchy and deleted a wire in "Config Data registry.vi" and look what the error list shows!

post-29-1166194243.gif?width=400

I like it!

Ben

Link to comment
I like it!

You're welcome. I get to claim credit for this one, but I have to admit that I only did it because my beloved LVClasses :wub: desperately needed it -- when you break one VI in a class, the entire hierarchy is bad, which is a lot of VIs. Finding the root cause was nigh on impossible, so I added the red X and sorted the broken VIs to the top. The fact that it could help with the regular subVI hierarchy use case was a nice side effect. ;)

Link to comment
Actually, this feature was always there even in older LV versions. The lowest VI in the hierarchy causing the break went to the top of the list. NI broke it in 8.0 and then fixed it in 8.2. I think they added listbox icons in 8.2 as well.

Ah, but if you had two VIs causing the break, there wasn't any guarantee that both were at the top of the list. The second would be at whatever point it was in the hierarchy. Static VI Refs, LVClasses and XControls have a blend of dependencies such that there is no tree of dependencies. Instead there's a circular graph. Thus the sorting is needed.

Link to comment
Except that Ben's image shows the method for a table, not a tree, and I don't know of any vi.lib VI which handles that (and the private method did not work in 7.0). That said, there are some implementations on the web for doing this for tables and arrays.

For 8.x the exact same method exists for trees, it even tells you if the mouse was on the symbol position:

post-2399-1166287302.png?width=400

Allthought the method has the same name, if you change the control ref. type the method is broken

In 7.0 the methos probably don't exist, too bad.

Ton

Link to comment

LabVIEW 8.20 Improvement: LabVIEW RT works much better, I don't lose the connection, even if the RT System runs with almost 100%...

LabVIEW 8.20 Improvement: The PID Loop is up to 14 Times faster :worship:

LabVIEW 8.20 Improvement: LabVIEW Crashs about 14 Times more frequent as well :throwpc:

LabVIEW 8.20 Improvement: A lot of new bugs... http://forums.lavag.org/index.php?showforum=80

After every second restart of LabVIEW i get those error messages fpsane.cpp....

even if I stoped LabVIEW by myself...

Link to comment
LabVIEW 8.20 Improvement: LabVIEW Crashs about 14 Times more frequent as well :throwpc:

LabVIEW 8.20 Improvement: A lot of new bugs... http://forums.lavag.org/index.php?showforum=80

After every second restart of LabVIEW i get those error messages fpsane.cpp....

even if I stoped LabVIEW by myself...

hmm, strange. LV 8.20 seems really stable to me. The only (reproducable) situation when LV crashes is, if I edit a typecasted enum, which is part of a e.g. typecasted cluster AND a VI containing one of the typedefs is open. LV crashes on the "save and replace" dialog.

I have informed NI about this behaviour, but it has not yet been confirmed as a bug - although the AE could reproduce it - it seems they are still working on it ;)

Link to comment
hmm, strange. LV 8.20 seems really stable to me. The only (reproducable) situation when LV crashes is, if I edit a typecasted enum, which is part of a e.g. typecasted cluster AND a VI containing one of the typedefs is open. LV crashes on the "save and replace" dialog.

I have informed NI about this behaviour, but it has not yet been confirmed as a bug - although the AE could reproduce it - it seems they are still working on it ;)

HI All,

Regarding bugs in LV 8.2

NI has historically released maintainance releases that have proved very solid.

You all can help make the next release similarly solid if you make SURE your reported bugs have recieved a CAR#. If it did not get a CAR# R&D will NOT hear about it and it will NOT get fixed!

The easiest way to make sure your bug makes R&D's radar is to post to the NI Bug thread. The Bug thread for December 2006 can be found here.

http://forums.ni.com/ni/board/message?boar...2&jump=true

I am still nagging them to watch the LAVA bug list, but that battle has not been won (yet).

So...

If you want you bugs fixed, report them today!

So please please please help NI help us!

Ben

BTW: NI's responsiveness to bug reporting also qualifies as something that has improved!

Link to comment
I don't think I've seen this mentioned yet. One improvement I like is that it's now possible to get help by right-clicking on a function within a pinned palette - no need to drop the function on the block diagram first.

If I remember correctly, you used to (pre-LV7?) be able to hit CTRL-H while the pallete was open (and not pinned) to accomplish this. In LV7.x, CTRL-H no longer responds while the pallete is open and not pinned. Maybe NI changed window focus for palletes vs. block diagram in LV7.x?

Gary

Link to comment
HI All,

Regarding bugs in LV 8.2

NI has historically released maintainance releases that have proved very solid.

You all can help make the next release similarly solid if you make SURE your reported bugs have recieved a CAR#. If it did not get a CAR# R&D will NOT hear about it and it will NOT get fixed!

The easiest way to make sure your bug makes R&D's radar is to post to the NI Bug thread. The Bug thread for December 2006 can be found here.

http://forums.ni.com/ni/board/message?boar...2&jump=true

I am still nagging them to watch the LAVA bug list, but that battle has not been won (yet).

So...

If you want you bugs fixed, report them today!

So please please please help NI help us!

Ben

BTW: NI's responsiveness to bug reporting also qualifies as something that has improved!

I reported the bug with the Timed Loop on Saturday to my friends from NI Switzerland, they were able to reproduce my problem...

Example:

http://forums.lavag.org/index.php?s=&s...ost&p=21792

They told me that with the 8.2.1 pach, this problem will "probably" be fixed...

I didn't received a CAR#...

How do you get a that CAR#? Or is that the same like the "Support Number" that I usually get from NI Switzerland when I cry for help? :o

Link to comment
I reported the bug with the Timed Loop on Saturday to my friends from NI Switzerland, they were able to reproduce my problem...

Example:

http://forums.lavag.org/index.php?s=&s...ost&p=21792

They told me that with the 8.2.1 pach, this problem will "probably" be fixed...

I didn't received a CAR#...

How do you get a that CAR#? Or is that the same like the "Support Number" that I usually get from NI Switzerland when I cry for help? :o

Getting a "support Number" (service request number) is only part of the game. As of about 3 months ago ALL of the AE (application Engineers) are required to post the CAR (corrective action report) for all publicly posted bugs. Contact your AE again and request the CAR number.

Unfortunately the new rule has not sunk-in for many of the AE's. I get the feelling they are doing a noble act be sparing R&D from the distraction.

Again, posting to the bug list I listed earlier will get the bug into the mill and will result in your ability to track its progress.

Ben

Link to comment
Getting a "support Number" (service request number) is only part of the game. As of about 3 months ago ALL of the AE (application Engineers) are required to post the CAR (corrective action report) for all publicly posted bugs. Contact your AE again and request the CAR number.

Unfortunately the new rule has not sunk-in for many of the AE's. I get the feelling they are doing a noble act be sparing R&D from the distraction.

Again, posting to the bug list I listed earlier will get the bug into the mill and will result in your ability to track its progress.

Ben

Hy I asked the guy fom NI told me, that I don't need this CAR# and I don't need to post it there ("NI-Bug Forum")!?!?!? :oops:

They probaly don't like that we are able to see all bugs on a forum in the internet :oops:

Link to comment
Hy I asked the guy fom NI told me, that I don't need this CAR# and I don't need to post it there ("NI-Bug Forum")!?!?!? :oops:

They probaly don't like that we are able to see all bugs on a forum in the internet :oops:

HI Martin,

I have posted a note about your bug and what you were told in post #9.

I will also pass along your word to my contat to straghten this out!

Ben

Link to comment
I asked the guy fom NI told me, that I don't need this CAR# and I don't need to post it there ("NI-Bug Forum")!?!?!?

Well, to be fair, you don't need the CAR# and you don't need to post the bug, but, if you report a bug and ask for the CAR#, he really should give it to you. You might want to tell him that NI internal policy has changed recently and that he might want to brush up on them.

Link to comment
Recently someone from NI R&D was here, and he told us that most likely the next release had a solved issues list (or bugs) publically. Unfortunately not a known

I can NOT denigh that. :rolleyes:

Ben:

I know you are very interested in CARs and bugs, do you store and monitor them?

Ton

The LabVIEW Champions can explicitly request updates on specific CAR's.

Beyond that let me close by saying that the Bug Lists are making a difference.

Stay tuned!

Ben

Link to comment
They probaly don't like that we are able to see all bugs on a forum in the internet :oops:

We have publically visible bug reports all over the ni.com DevZone, so why would it bother us if LAVA has similar lists? Yeah, some of them are embarrassing, but as long as there are threads like this one ("things that have improved") to remind everyone that it's not all bad news then the bug lists do more help than harm.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.




×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.