ShaunR

QUOTE (Yair @ May 7 2009, 05:52 PM) Lets hope it goes out of scope before you run out of memory then. QUOTE (NI Help) If you use the Obtain Queue function to return a reference to a named queue inside a loop, LabVIEW creates a new reference to the named queue each time the loop iterates. If you use Obtain Queue in a tight loop, LabVIEW slowly increases how much memory it uses because each new reference uses an additional four bytes. These bytes are released automatically when the VI stops running. However, in a long-running application it may appear as if LabVIEW is leaking memory since the memory usage keeps increasing. To prevent this unintended memory allocation, use the Release Queue function in the loop to release the queue reference for each iteration. ----------------------- QUOTE (Yair @ May 7 2009, 05:52 PM) In any case, no one is forcing you to use these (or even a new version of LV). You can go back to an old version, but I still don't see why you say that you have to worry about memory, etc. in the newer versions. Tetchy

QUOTE (crelf @ May 8 2009, 07:25 PM) That's kind of irrelevant. A customer will blame you (the supplier) not NI for stopping production by a fault in your software. Generally you will get a phone call and they will demand you come on-site to fix it. At best, it costs you (as in your company) 1 engineer on a field trip. But we also have a suppliers that we guarantee minimum down time and incur penalties for lost production. So far this year, we have had 2 occurrences similar to this, luckily not with a supplier we guarantee, but it still cost an engineer a day off each time from projects he should have been on (and car rental, etc). We have been using Labview and Labwindows for donkeys years, But there have been murmurs recently from the upper echelons in our company, that Labview is "too risky" and although it may be better in the short term because of the short development cycle, in the long term it may cost too much especially as the sales guys have just gone and sold 2 more guaranteed down-time contracts. In the current climate we have loads of c++ programmers looking for projects and the "powers that be" are looking for excuses to utilize the spare resource. I'm fighting like hell at the moment to get the SSP paid this month. And this sort of thing isn't helping me fight my corner.

Such a simple request yet not as trivial as it first seems. Nevilles idea will most certainly work if you trust whoever is drawing the triangles. Hopefully you can go with that. But if you want a programmatic method, more complicated, but less demanding on the user you might try the following..... 1. "Threshold" the image (I'm looking at your blue icons) to get it in black and white. 3. "Fill holes" so that the center part of your triangle is fully blocked (i.e. you have a solid triangle). This is your major mask. 4. Scale your mask down by a factor (say 5%). And invert. This is your minor mask. 5. Combine both masks. 6. Apply the mask to your original image. You should now just have the white triangle without drawing anything.

Yes. The callbacks were also saved in 8.6.1. I've attempted to save back to 8.0 and took them out of the LLB. Hopefully converted them all, but labview was very insistant on saving them in its current version. Try these anyway and let me know. Download File:post-15232-1241736385.zip

This may help (Hint: Polygons) ROI Descriptor

Everything you need is in \examples\instrsmplserl.llb\Advanced Serial Write and Read.vi

QUOTE (Aristos Queue @ May 5 2009, 12:06 AM) Thats more like it does unless you tell it not too. But I can see where you are coming from. I was more talking about if I called method A and passed that data to method B and then on to C. Do I now have 3 copies of that data just because I invoked those methods (and labview has loaded but not released the VI's)?. Or is it just pointer arithmetic (as it would be in other languages ) and there is only 1 data structure and only a pointer is copied? QUOTE he workaround I mentionned is indeed the use of the vi request deallocation which just seems wrong to me for such simple task in an environment that handles memory automatically. This is one of the aspects I really don't like about the "new" labview (far more I do like though). One of the reasons Labview was much faster in developing applications was because (unlike other languages) you didn't have to worry about memory management. As such, you could get on and code for function and didn't necessarily need an in-depth knowledge of how Labview operated under the hood. There used to be no such thing as a memory leak in Labview applications! Now you have to really make sure you close all references and are aware of when references are automatically created (like in queues, notifiers etc). It's good news for C++ converts because they like that sort of nitty gritty. But for new recruits and programming lamen (which was really where Labview made its ground) the learning curve is getting steeper and development times are getting longer.

It's a bit like the Error thrown on end of file in file functions. Technically correct, , but counter-intuitive and a pain in the proverbial.

Bingo!

QUOTE (sachsm @ May 4 2009, 10:04 PM) Ta very muchly. But I was more interested in how it works.

So does invoking a property or method cause Labview to copy the data in an object? Or is it all pointer arithmatic.

QUOTE (sachsm @ May 4 2009, 02:53 PM) Is there a write up somewhere on the "mirror" library approach?

QUOTE (Jarimatti Valkonen @ May 4 2009, 08:33 AM) If your going with a model-view architecture the (very) old method of using a data pool works well. If you put all your data in a global vi or variable and get your controller to update the global, you can bolt on different UI's for different views.

QUOTE (Aristos Queue @ May 4 2009, 02:02 AM) Ummm. Maybe it had something to do with this statement from Ernest. QUOTE (Ernest Galbrun) The data is constituted of a 2D SGL array whose size may be a few millions of elements.

QUOTE (ccie @ May 3 2009, 11:45 PM) Interpret it as "it doesn't work"...lol. Can't make out much from your graph. The time is in arbitrary units (ms, seconds, light-years?) and you haven't told me what what you are expecting (pk-pk voltage 10-100V? 20ms period?). You say the A2D comes through the serial port. How? Does it have a serial interface and your reading AScii characters? Or are you using the serial port as a digital IO and expecting a bit pattern representing the voltage. The source would also tell us what you are trying to do and expecting. Assuming it's not a software issue. I would check the polarity of the diodes. Getting one round the wrong way is easy to do and easy to check. Then I would probably stick a sig-gen up the A2D and see what was displayed. If you then get what your expecting, its your rectifier. If not its either the A2D or the PC (software or hardware). With all these things its a process of elimination. Segment the system into testable parts and iteratively narrow it down 'till you find the culprit.

QUOTE (Ton @ May 3 2009, 02:51 PM) LOL. Looks like you pressed the send button just before me

You sure its not a 1/2 wave rectifier?

Open your own dialogue prompt (File I/O>>Adv File funcs>>File Dialog) and pass the filepath to the save vi. The File dialogue express VI enables you to set the default extension and passing the filepath means that the default dialogue won't be invoked.

QUOTE (Aristos Queue @ May 2 2009, 11:52 PM) I disagree. IF it worked as it says on the tin (or labview help in this case), this is exactly the scenario where you would use it. Says nothing in the help that it won't work on classes (and they ARE vi's so it should, as in I would see that as a bug too). A slight performance hit using it is better than using up so much memory that you start using the swap file which would be even worse. His problem is plain to me. Large data set remains in memory when not needed. I'm guessing that invoking the the properties and methods also creates copies of that data which remain in memory. I personally would have used a database to store the data and a class accessor to manipulate it (if I used classes...lol) but each to his own. So when's 8.6.2 out?.

QUOTE (ShaunR @ May 2 2009, 08:04 AM) Like this. Its very easy to manage.

QUOTE (MJE @ May 2 2009, 05:50 PM) Funny you should say that. When I found it. It was used for hooking the I.E. browser Active X control (and its on the .Net pallet so presumably that was the intention). I'm not clever enough to come up with these things on my own But I am ruthless enough to exploit them for every ounce of worth However, I have an aversion to active X and the obese .Net (for many reasons but the main one being, if I don't have the source, I can't use it). But I did see a potential for using it within Labview for a scenario that I'd been working around for a while and wasn't satisfied with. And as I explored, a whole new mechanism for inter process comms opened up with (it seems) few drawbacks. I think what I like about your Message Pump implementation is that it it goes far enough to be more than useful without being so huge and complicated to make it unusable. I see many OOP module designs (not just in Labview) that try to be all things to all people rather than a base from which people can start.Your porridge is "just right".

QUOTE (Aristos Queue @ May 2 2009, 03:40 PM) The Request Deallocation function might be of use here QUOTE When a top-level VI calls a subVI, LabVIEW allocates a data space of memory in which that subVI runs. When the subVI finishes running, LabVIEW usually does not deallocate the data space until the top-level VI finishes running or until the entire application stops, which can result in out-of-memory conditions and degradation of performance. Use this function to deallocate the data space immediately after the VI completes execution.

QUOTE (MJE @ May 1 2009, 03:52 PM) I like the abstraction, and can see a use in some of my applications. I'm ambivalent about OOP in Labview......but that's another thread. The idea isn't about notifiers or events really (but it does use the native labview events). Its about the hooking of Labviews existing events (the string controls for example don't use custom events, notifiers etc). The Message Pump callback seems a bit different in that respect. The main difference in your approach seems to be that it is a one to many (the great tentacled controller/supervisor) which doesn't fit most of my implemented models which are many to one. Mine generally use an encapsulated autonomous approach so the "controller" merely has to launch them, provide an interface to the user and then sit around twiddling its thumbs until something interesting happens. Therefore the ability to hook the controls/indicators (even the whole VI or application) is a boon since it requires no code changes in existing VI's (well, maybe have to use the Val(sigl) instead of the direct wiring....but can live with that) and if I add modules they are automagically catered for if/when I call them at run time. It also dramatically reduces wiring and global use without implementing a messaging scheme. One limitation,however, is the number of events that Labview exposes that you can attach to. For example, the Application Reference only exposes a pitiful 3 events for VI's (Activate, Redraw and Scroll). If we had a "Load" equivalent, for example, we could run an event registration callback when a vi loads and we could hook the "Panel Close" to unregister. Then adding VI's would seamlessly fit into our application event system and enable it to be used as many to many. I would also really like to be able to attach to VISA and have proper events that I can handle with an event structure.

This is something I deal with on a daily basis. Many of my screens have 30+indicators/controls. The most convenient way is to cluster the controls/indicators on the front panel then just pass the cluster in to the state machine and use option 1 or unbundle and re-bundle to change the values I don't like using the references as per option 2 since you end up with a huge diagram full of references (just take a look a the Navigation demo in the LVOOP examples directory and you'll see what I mean).