crelf Posted December 19, 2006 Report Share Posted December 19, 2006 ...the bug lists do more help than harm. Well put - bug lists are great for everyone: they show that we know that NI's aware of an issue, and NI benefits from hearing about the issues from real users - it's a win-win! You should never be concerned about reporting what you think might be a bug: * Someone will help you to understand that it isn't a bug, and you're just doing it wrong * It will be recognised as a bug by NI and fixed in a future release * It will be recognised as a bug by NI and they (or someone else) will help you with a work-around Quote Link to comment
martin@aerodynamics Posted December 19, 2006 Report Share Posted December 19, 2006 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. Hello Aristos First: LabVIEW is great! and I really like programming with LabVIEW. But I lost a lot of time so I was a bit in a bad mood. Usualy I report all "strange things" directly to NI (Switzerland). Since I have SSP it's an easy and fast way. I did't knew bevore, that you have a bug-list on the web. But it would be great if there would be a FULL LIST on the web. Example: As you know "I" found out two bugs with the Timed Loop. As I taked to local NI they told me that one bug (big priority numbers) is already reported. But i was not able to find this message on your support site. The second bug (LabVIEW hangs after a restart of a timed loop which was aborted with the Stop Timed Loop.vi) was "new". So how shold other people know about that? Why do we always have to ask for support for known issues? (I think our local NI support is really GREAT so I really enjoy asking them since we were on the same year at the same university!!) But a "complete" list could help us a lot... Well put - bug lists are great for everyone: they show that we know that NI's aware of an issue, and NI benefits from hearing about the issues from real users - it's a win-win! You should never be concerned about reporting what you think might be a bug:* Someone will help you to understand that it isn't a bug, and you're just doing it wrong * It will be recognised as a bug by NI and fixed in a future release * It will be recognised as a bug by NI and they (or someone else) will help you with a work-around Usualy I'm proud to find out a bug! And your point are also what I think in general. In LabVIEW 8 I found a memory leak with DataSocket. I reported this error (directly to NI Austin), and they told me that it's already in the readme.txt from LabVIEW... But the readme is the LabVIEW Readme from 8.20 and not 8.0!!! So how should a LabVIEW 8.0 know about things like that (since LabVIEW 8.20 was not very old at that time)? Quote Link to comment
i2dx Posted December 19, 2006 Author Report Share Posted December 19, 2006 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. hmmm ... just to be honest: business as usual = show a little smile on things that have improved and rant as loud as you can if something does not meet your expectations. the reason why I started this thread was (as described in the subtitle ) that I felt that I should not just rant but mention the things that have improved from 8.0.1 to 8.20 Quote Link to comment
crelf Posted December 19, 2006 Report Share Posted December 19, 2006 ...it would be great if there would be a FULL LIST on the web. I think that'd be unmanageable and, frankly, unnecessary. Having a full bug list for a product as large as LabVIEW would be enormous - especially since you'd need to include all those piddly-little cosmetic issues. By the time you looked all the way through the list to find if your bug is known, a new version of LabVIEW would be out Note: I'm not trying to say that LabVIEW is full of bugs - really I'm not - I'm saying that a large and dynamic application that's in constant development cycles is always going to have a long list of "to-do" items, some of which are never reached... Quote Link to comment
Roy F Posted December 20, 2006 Report Share Posted December 20, 2006 ... 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 support engineers are trained to report all bugs to R&D via a mechanism we call CAR (Corrective Action Request). You getting the CAR number is not required for this to happen (but it does give you a warm fuzzy). Typically, a support engineer works with a user on a problem, becomes convinced a bug exists, helps the user develop a workaround, completes the call, THEN files the CAR. So, typically, an AE will not have a CAR number until after he is done with the support call. Support engineers know that we need these bug reports filed to make things better. They get credit for filing these, so calling in a problem on a bug in the product or submitting it via the NI.com forums actually helps the support engineer get credits (a good news/bad news story ). Roy LabVIEW R&D Quote Link to comment
martin@aerodynamics Posted December 21, 2006 Report Share Posted December 21, 2006 hmmm ... just to be honest: business as usual = show a little smile on things that have improved and rant as loud as you can if something does not meet your expectations. the reason why I started this thread was (as described in the subtitle ) that I felt that I should not just rant but mention the things that have improved from 8.0.1 to 8.20 OK back to things that have improved: Overall I think the new LabVIEW 8.2 works fine, and there are a lot of improvements- specially on LabVIEW RT- side LabVIEW RT- Remote debugging of executables => Excellent! LabVIEW RT- overal handling => Excellent! LabVIEW RT- Aborting running vi's on RT-Target, reboot of RT-Target in LabVIEW 8.2 works perfetct... LabVIEW RT- Shared variable very easy and flexible to use (+extended datatypes) => Excellent! LabVIEW RT- the new RT FIFO- => Excellent! (My wish has become true :worship: ) LabVIEW RT- Building and distributing applications => even much easyer than bevore => there is only one thing I miss: While building a new RT- application I can not debug another application on a RT-Target, because the application Builder Window is "frontmonst" But if you have only smal apps. you don't need that. Quote Link to comment
Ton Plomp Posted December 21, 2006 Report Share Posted December 21, 2006 => there is only one thing I miss: While building a new RT- application I can not debug another application on a RT-Target, because the application Builder Window is "frontmonst" But if you have only smal apps. you don't need that. What if you run two copies of LabVIEW? Ton Quote Link to comment
martin@aerodynamics Posted December 21, 2006 Report Share Posted December 21, 2006 What if you run two copies of LabVIEW?Ton Never tried... Do you have to install LabVIEW twice for that or how sould that work?? Quote Link to comment
Grampa_of_Oliva_n_Eden Posted December 21, 2006 Report Share Posted December 21, 2006 Never tried...Do you have to install LabVIEW twice for that or how sould that work?? Going back to LV 6.1 you could copy LabVIEW.exe to LabVIEW2.exe and use one for the RT and one for the Windows side. It's not supported and be careful with which is which. Ben Quote Link to comment
i2dx Posted December 21, 2006 Author Report Share Posted December 21, 2006 be careful with which is which. hmm - I am not sure - but I think this is a really good way to get a corrupted project. LV 8.x opens one application instance for each target and keeps them synced. If you edit a VI with your "own external" LV instance you can have different copys of the same file in memory and I think that will mess up your whole project. Quote Link to comment
Grampa_of_Oliva_n_Eden Posted December 21, 2006 Report Share Posted December 21, 2006 hmm - I am not sure - but I think this is a really good way to get a corrupted project. LV 8.x opens one application instance for each target and keeps them synced. If you edit a VI with your "own external" LV instance you can have different copys of the same file in memory and I think that will mess up your whole project. I would not try it with LV 8 because ti does use project and natively support apps on more than one target. The above note about renaming is useful for Pre-LV 8 when you want to watch the RT and Windows at the same time. I have only used in once but it did beat using two laptops. THis was originally posted by DR RT (someone at NI) years ago when there used to be an RT forum. Ben Quote Link to comment
martin@aerodynamics Posted December 22, 2006 Report Share Posted December 22, 2006 I would not try it with LV 8 because ti does use project and natively support apps on more than one target.The above note about renaming is useful for Pre-LV 8 when you want to watch the RT and Windows at the same time. I have only used in once but it did beat using two laptops. THis was originally posted by DR RT (someone at NI) years ago when there used to be an RT forum. Ben I think I will not try with two copies of LabVIEW since I can drink a coffee during every build... Quote Link to comment
Ton Plomp Posted March 31, 2007 Report Share Posted March 31, 2007 One nifty feature I found out today (I think it is new in 8.0): SMART Right mouse button on error wires Explanation: Here's your error: http://forums.lavag.org/index.php?act=attach&type=post&id=5354 And here's your pop-up menu: http://forums.lavag.org/index.php?act=attach&type=post&id=5355 See the 'Insert Index array' and 'Disable indexing at Source'. absolutely in the right place! It gets even better if you insert a 'Merge errors.vi' this will insert like you want it to (the array on the array input), the same thing has happened with the insertion of a 'Bundle by name' feature, which[?] fits in quite nicelay Ton Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.