ShaunR

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).

This may be of help: Inter thread Comms

I was searching for a way of being able to effect events from dynaimically loaded vi's elagantly. These vi's make it very difficult to use with events and generally it gets all messy with globals since you have to wire them somehow. Then I stumbled upon callbacks (never seen them before). And there doesn't seem to be much information about them apart from using with Active X, so I thought I'd knock up an example to demonstrate their enormous member power. The example attaches a couple of callbacks onto a dynamically loaded vi's controls. One callback is an event generator so that any time a value changes on the dynamically loaded vi, our custom event fires in our top level vi. Every time we load a vi, we attach these callbacks, meaning that any vi will generate our event.

Mark I ear hole and a precision digit works best.....lol If you search this forum you will find a IDE addon that enables you to control Labview using voice commands. Most of what you need is in that.

Welcom Markus. Not sure about a good time, but is always interesting

QUOTE (normandinf @ Apr 30 2009, 10:30 PM) Right...lol So it must be impossible to do this then http://lavag.org/old_files/monthly_04_2009/post-15232-1241128886.png' target="_blank">

Whats the micro controller expecting?

You can change the cursor legend font as with any other indicator/control. Just set the font of the cursor legend to "Plain". Then they won't be bold.(If that's all you need to acheive).

QUOTE (bEMOL @ Apr 30 2009, 12:14 AM) If you want to programmatically add tabs to a tab control then use an active X container and browse for the Microsoft Tab Strip. This has the methods to add, delete,clear etc. http://lavag.org/old_files/monthly_04_2009/post-15232-1241110320.png' target="_blank">

There's an example in the Labview examples directory of a tank filling system. Might be worth a look.

QUOTE (jdunham @ Apr 30 2009, 02:45 AM) I'll take a look later...thanks. QUOTE (jdunham @ Apr 30 2009, 02:45 AM) That's an interesting quote. I think just shows that the NI VISA team is not on the forefront of LabVIEW development (to be fair, I don't know how old that doc is). Their API could easily accept a VI reference and invoke VI.Run on it when the event happens. They could also accept an occurence or a queue refnum, but I think it would make more sense to do the VI reference. Then inside that VI you could invoke whichever queues or notifiers or occurrences (or polled globals) you need to interact with your running processes. LabVIEW with a callback (which you can also implement in your own code with a private notifier or a VI reference) is no less event-driven than C code with a callback. Jason You may be right. In fact, there ARE callbacks, in the true definition of callbacks (well in 8.6.x at anyrate). I've been playing with them for my event problem (well its not really a problem, it would just greatly simplify code and maintenance). But VISA doesn't expose the event refnum so you can't attach a callback. Or conversely, callbacks don't accept VISA resource sessions.There is/isn't/probably a way to get at it, but that aspect isn't on my priority list at the mo. I would go one statment further. Labview is event driven (in the context of truly asynchronous events) with a callback, however C is not event driven....ever.

No. Your DAQ definitely won't be enough to drive the motor. Motors are high current devices. You will need a separate power supply and control it via that. I agree with carlover in so much that really you need a dynamic tracking system (as well as it has been done before). You will also probably want to go backwards and forwards, as well as up and down (since the sun tracks in an arc and starts in the east and sets in the west every day) so a single motor probably won't be enough (2) and they will need to rotate in both directions. You might find this useful in thinking about what you want to acheive. Solar Tracking Project Although I'm at a loss as to why it took 13 weeks...lol.

QUOTE (Mark Yedinak @ Apr 29 2009, 09:53 PM) Read the thread again from 7 posts up.

Short answer "yes". We need to know more too. How are you interfacing to the motor (is it RS232 , PWM card, digital card, parallel port, force of will?). Regardless of the interface, you will need a while loop that generates a timed pulse. It'll look something like this There are many examples in the Labview examples directory. I would take some time to look at them as quite often you can modify them to suit your needs.

QUOTE (Mark Yedinak @ Apr 29 2009, 03:50 PM) We were talking about a full Labview development environment my comment was aimed at this QUOTE The LV development environment is very useful in debugging on the fly if you have live code. NI even supports it with a licensing option. Since the OP said he deploys the vi's and anyone can change them (have to have labview on there for that). That is more than $500.

QUOTE (shoneill @ Apr 29 2009, 02:03 PM) Ah. Thats not it then. I'm looking for a way to link events from dynamically loaded vi's So that the vi can basically "hook" the existing event mechanism.

QUOTE (shoneill @ Apr 29 2009, 08:12 AM) I think that's what I'm missing for me to use events effectively from within an encapsulated architecture. Whats the workaround?

QUOTE (manojba @ Apr 29 2009, 08:00 AM) Hmm. Got me thinking. This would be a good one for a Coding Challenge. Who could write the best URL Label XControl. Be nice to be able to just plonk one on the FP.

QUOTE (jzoller @ Apr 13 2009, 09:40 PM) I'm thinking more about the cost of deployment. Exes and dll's are don't require licensing.I'd find it impossible to justify that the customer pays thousands for a full package which he/she never uses just so that they can use my software.

QUOTE (candidus @ Apr 29 2009, 09:02 AM) Much better solution.

The "Specify path on diagram" is the way forward but I don't think that exists in 7.1 (long time since I used that). So you would have to use the old method of creating an intermediary DLL which you can call from the "Call Library Function node" to pass data too and from other the other DLLs. (2D array in and out always worked best for me). Not elegant, but it works.When you create the plugins, if you make their inputs/outpts are a 2D array then your intermediary dll only needs 2 inputs (the dll name and the 2D array) and one output (2D array).