Jump to content

Tomi Maila

Members
  • Posts

    849
  • Joined

  • Last visited

  • Days Won

    9

Everything posted by Tomi Maila

  1. QUOTE(Dirk J. @ Mar 6 2007, 04:33 PM) I've developed an internal spam filter so that I simply ignore text with too much font-formatting.
  2. QUOTE(Aristos Queue @ Mar 6 2007, 04:24 PM) Now that AQ has announced that 8.2.1 will be there, I'm not braking my NDA anymore by saying that yes I've tested 8.2.1 and it's much more stable than 8.20!!! But AQ is right in that there are still bugs that I reported too late that will not fixed wich are making some of my days a nightmare. EDIT: However I think if you are not taking LabVOOP to the same level as I'm, then you will have everything close to fine with 8.2.1. Tomi
  3. QUOTE(tibobo @ Mar 6 2007, 02:06 PM) No comments
  4. QUOTE(tcplomp @ Mar 6 2007, 09:48 AM) I don't think there is a need to make IP addresses public. I think it's nobody's business which IP address I'm using.
  5. QUOTE(Mikkel @ Mar 6 2007, 10:31 AM) I propose an XNode coding challenge on writing a for loop with a break. I don't know if XNodes are capable enough but timed loop is at least partly based on XNodes...
  6. QUOTE(Jim Kring @ Mar 6 2007, 09:17 AM) Nice request Jim. You should send him an official offer from your company $1500/day. Or is this still too low a price for JKI? P.s. What are you people charging for LabVIEW consulting where ever you guys live? (OT)
  7. QUOTE(spacetoon34 @ Mar 5 2007, 11:42 PM) You can do this with while loop. Do { what ever you want to do } while (i < N && !stop)
  8. Hi, I've also some questions that's SCC / SVN related. I don't have SVN repository set up yet. I heve heard rumors that SVN cannot handle renames. Instead of file being renamed in the repository, the old files is marked as deleted and a new file is created. LabVIEW on the other hand requires renames to occur inside LabVIEW project or files don't get properly updated. So what's your experience of renaming files with LabVIEW when you use SVN as your SCC provider directly or using Tortoise? LabVOOP projects require compiling all project files all the time. That means that every single file in the project gets updated when ever you do something. Has anybody used SVN with LabVOOP? How to deal with files that get constantly updated? Do I always need to check out the whole project and then check the whole project back in? Has anybody good experience on other SCC products like bitkeeper or sourcehaven? Does SVN repository allow incremental backups or is everything stored in one large file that keeps growing and needs to be backed up complitely every time? (this may not be a problem with LabVIEW projects but if I use SVN to store data files as well then it is) EDIT: I'd really appreciate if someone would like to write a knowledege base article on using SVN together with LabVIEW (8.0 and later).
  9. One more recommendation I forgot from the last list. If you fail to compile your LabVOOP project, change all classes to inherit from LabVIEW object and then recompile the base class. Then add classes back to inheritance hierarchy one-by-one and recompile after each addition. This may help. If it doesn't help, it helps you to identify the problematic class at least. EDIT: You may also benefit from opening parent class alone in the memory, then recomiling it and closing it. It helps some times.
  10. QUOTE(spacetoon34 @ Mar 4 2007, 09:09 PM) Please, never use anything else than the normal font. It's annoying and it doesn't get your questions better answers, on the contrary.
  11. QUOTE(zero-tolerance @ Mar 4 2007, 08:08 PM) Ton's answer was proper and that's all there is to your question about why the FFTs of the signals are the same except for the DC component. Your reply above doesn't make any sense. Please tell us what are you trying to do, not just the FFT part of it but the whole story. You may be doing or thinking something the wrong way and it's not the LabVIEW FFT that's the problem here. Tomi
  12. QUOTE(yen @ Mar 4 2007, 07:20 PM) Mostly just annoyances, you may loose your work after last save. However some bugs corrupt your project as compiler cannot compile the change. Then you may find yourself in a position that you simply cannot do something you try. It simply doesn't compile. Everytime you try you get a crash. QUOTE(yen @ Mar 4 2007, 07:20 PM) Using TDs (and even more so complicated TDs) is something that is almost a must for many many projects, so avoiding them is not a real option unless there is some alternative. I know, there is no alternative.
  13. QUOTE(JFM @ Mar 3 2007, 08:13 PM) All my major projects involve LVOOP, so I guess the answer is I don't experience these issues in projects without LVOOP. It doesn't mean that there are no such issues, I just don't have experience. However other like Ben have not encountered similar problems than I so I assume that most problems must be LVOOP related. There are a number of random crashes and corruptions the reason of which I don't know. The list I posted are just some things one can do to avoid some crashes not all. Tomi
  14. Here are some tips to survive with LV 8.20 and later Avoid renaming VIs in project, your project may corrupt If you need to rename, make a backup before you rename Avoid typedefs, compiler cannot manage complicated typedef references Compile as often as you can by pressing Ctrl + Shift + Run and then save all If your project get corruptedOpen your project and try to recompile by ctrl+shift+run Don't use save all as it may crash your LabVIEW but save all VIs individually be patient, to get project working may require may rounds of recompiling and saving and recompiling and saving and... If your VIs get missing because you tried to rename them and LabVIEW crashed, edit the project or library XML by hand to change the VI names to actual names If nothing helps revert to backup If you have complicated LVOOP projects, this may be daily fun, especially if you want to rename stuff. Tomi
  15. QUOTE(robijn @ Mar 2 2007, 04:20 PM) Any idea how to detect when a wire buffer is no longer used? Tomi
  16. QUOTE(jpdrolet @ Mar 1 2007, 08:00 PM) I'm not that rookie , although I'm fairly rookie compared to other users here . One example where I need explicit cleanup is when closing references to external file formats. Another example is an XML file where you want to write all closing tags to the file when closing the file. You may also want to clean up temporary files or close data base connection properly or send message to other application instance that we're closing up or... You get it. Tomi
  17. QUOTE(PJM_labview @ Mar 1 2007, 07:08 PM) I get a crash about 2-5 times a day, mostly they are not reproducible. Even more often I get an error message when I start LabVIEW that last time LabVIEW didn't close properly. Most of the crashes are related to either LabVOOP or the new project environment. Also the builder has quite many bugs. Data corruption doesn't occur very often but it's good idea to keep backups up to date. Tomi
  18. QUOTE(dsaunders @ Mar 1 2007, 06:30 PM) I think I was unclear with my question. The whole idea was to build libraries with different kinds of objects carrying external references that users don't need to explicitly close so that users could use them in a same way as they use normal value carrying wires. Creating these objects would launch carbage collector. Carbage collector would monitor the context and when nothing is runnig it would close all open references. It would make programming easier for users and help avoiding bugs. So anything that needs modifications to the main VI is not an option. Aristos Queue proposed using App.Exit event. It seems that this event in LV 8.20 doesn't guarantee that the event is executed before non-running VIs are disposed. So at the time when this event gets executed in LV 8.20, my shift register content is already gone. In an application build with LV 8.0 it doesn't even get executed (although I think the builder should be the same). From Jim's answer I guess that the only possibility is to force the some of the VI front panels to stay open long enough so that carbage collector has done it's job. Keeping a front panel open keeps the VI in memory. But it's not nice to have a front panel open for functionality that should be invisible to the user, especially in a build applicaiton. If anybody comes up with a better idea, I really appreciate it. Tomi
  19. QUOTE(Aristos Queue @ Mar 1 2007, 06:10 PM) Yes it does but it doesn't keep my shift register in memory as my VI is not running. Event case requires a running VI to work. Check the code... Tomi
  20. I have reported many dozens bug reports since the release of 8.20 so I'm not entirely sure this is a stable product. Tomi
  21. Hi, I got a an idea on how to implement carbage collection in LabVIEW. With carbage collection I mean closing stuff such as files after VI stops running. The concept is simple. Keep the stuff in an uninitialized shift register. As long as the VI owning the shift register is in memory, we have our stuff in memory and we can close them. To find out when our main VI has stop running, we can poll the functional global VI using dynamic calls. If the first run primitive is true inside functional global, then the main VI has exited. Everything works fine in development environment. However in an EXE things get more complicated. Here is where I need your help. Any idea how to keep the functional global in memory after the main VI has exited so that the uninitialized shift register doesn't get cleaned up before carbage collection. In development environment functional global stays in memory but in exe it's automatically disposed. I can force the functional global front panel to open but it looks ugly. Are there any methods to keep VI in memory so that we don't have to show the front panel of the VI to users. I must remind also that this VI is not always running so we cannot use runtime properties of the VI only such as transparency. Tomi Carbage collector for LabVIEW 8.0 http://forums.lavag.org/index.php?act=attach&type=post&id=5082
  22. QUOTE(Thang Nguyen @ Feb 27 2007, 11:34 PM) In LabVOOP you create a new instance of a class by forking the wire. Two wires means two instances. LVOOP wires act in exactly the same way as clusters with the exception that the private data is hidden and only visible to class methods. When you fork a cluster wire, you get two clusrers, right? Then you can edit the content of one cluster and you have two instances of the same cluster type. Classes work the same way. If your data in a cluster is a reference, then forking the wire doesn't really make a new instance unless you change the refenrece in one of the wires. Perhaps you could post some of your code. I think you don't fully get the LabVOOP yet and it would be easier to see what you don't understand correctly if we could see your code or relevant parts of it. Tomi
  23. QUOTE(tcplomp @ Feb 27 2007, 09:50 AM) I never noticed that everybody can edit those articles. Or is it a premium mebership feature...?
  24. Hi, We are starting to gain more information on XNodes. However the information get's distributes on various threads and is not easily usable. I suggest that we start a LAVA wiki and as the first topic we add XNodes. Then when new things on XNodes are found out, these could easily be documented via the LAVA wiki. Tomi
  25. Hi, I use Adobe Dreamweaver which is a very good HTML editor. I've written Adobe Dreamweaver templates for LabVIEW help pages. I use Microsoft HTML help to generate CHM files from a set of HTML files I create with Dreamweaver. I attach a ZIP of my HDF5 for LabVIEW help file so you can get a feeling on the quality of this method. http://forums.lavag.org/index.php?act=attach&type=post&id=5033
×
×
  • Create New...

Important Information

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