Leaderboard

http://www.eaipatterns.com/docs/IEEE_Software_Design_2PC.pdf

I hate it when mom and dad fight...

This is an area in LabVIEW where there have been subtle changes over the versions. But basically if you only enter the DLL name into the path then LabVIEW will call the LoadLibrary() function with just the DLL name, which will cause Windows to search in all standard locations for the DLL. LabVIEW will update the path constant with the entire path to the DLL that Windows has loaded the DLL from, but will remember to only use the DLL name itself even in the future. And it will also not include the DLL into any build if you go to build an executable, assuming that it is either a system DLL or one being installed by a seperate installer (which is usually the common way that you get the directory to the DLL path in the PATH environment variable). If you however browse to the DLL or enter the enitere name directly, then LabVIEW will assume that the DLL is private to your application and also include it in any build. This can cause havoc for system DLLs, since kernel32.dll on your XP system is seldom the same on another users system which will cause troubles. Also since about Windows XP Windows will attempt to load explicitly loaded DLLs (LoadLibrary() calls with a full path, even though the same DLL is already in memory from a different path as this was required to support the SxS DLL loading, an attempt to alleviate DLL hell, but in my opinion just a way to cause more DLL hell) and that causes total havoc for many DLLs from the Windows system. Personally I think LabVIEW should explicitedly avoid from including any DLL into a build, that resides in either the Windows or the system directory, even if the user entered a full path, but it is debatable if it is LabVIEW's job to worry about such things. I do think that the influence of initially entering just a DLL name in the Call Library Node versus the entire path, should be made visible somehow and also be better documented.

Elegantly put. I redact my comments. This sounds like a weak case to use scripting to dig through property nodes. Personally, sticking a "TODO:", "DEBUG:", or "FIXME:" just as easily facilitates finding these comments without requiring that the free label be of any specific format. I recognize that it is a standard, but argue that it's simply one that does not apply. Keep an eye on your svn logs, I'm going to start changing all of your comments.

Hey guys, I'm faced with the challenge of having a plug-in type architecture where one of the primary plugins is responsible for listening to an FPGA DMA FIFO and placing the data extracted into a set of queues which can be obtained and then destroyed by any number of consumer VI's (in sequence, not simultaneously). The way I've been doing this is to maintain a "database" of queue references encapsulated inside clusters, the database is maintainted inside an AE. So the input to the AE is of type "Data Queue Handle" which is a single element cluster of type "variant". The data queues created are loaded into these clusters and then added to an array inside the AE. To obtain a data queue, a consumer will search through the array for the variant type which matches the queue type it needs (the one that doesn't return an error when the cluster is passed into the "variant to data" block). This is functional, but makes me feel icky for some reason. I would like to just pass the raw references into some sort of database, which can then be chosen by a simple Equal? comparison. I can't figure a way to do this inside an AE though, as you can't build an array of different data types and you couldn't have a single input to accept all possible Data Queues. Maintaining clusters of clusters of clusters is impractical and even more icky. So, to summarise the question. How would you construct a routing house type function for queue references, which can be searched by any function which knows the right command? I guess I could manually maintain a Typedef of the different data queue types as they're added to the project, then simply talk through that type def. Hmmmm

Hi friends, Is there a way to read the value of excel cell color in LabVIEW? I read some posts on ni.com forum but I could not download any attachments- I'm getting some error. Thanks for your time...again !!! Sharon Found it.. Thanks, Sharon Sorry. Forgot to attach the image............

Having worked with LabVIEW for a few years now, it seems to me that such dynamic user interfaces are simply nigh-impossible in LabVIEW. The way the front panel / terminal / block diagram system has been designed has some strong advantages, but dynamic control instantiation seems to be fundamentally incompatible with this paradigm. If you really think this type of UI is useful, you should consider using a different tool — .NET for example. There's plenty of extensive libraries for this sort of thing in the .NET world. You really don't want to solve the intricate usability issues of docking/undocking etc. yourself, if you don't have to On the other hand: does the UI you have in mind really solve concrete user problems? My experience thus far tells me that often a well-designed, static UI trumps an overly-configurable, dynamic UI. Especially for "your average user" (whatever that may be), too much configurability makes an application harder to use. For a good example on this, read the interesting story of how the Microsoft Office Ribbon UI was conceived. There's a reason Microsoft turned its back on the mess of floating toolbars, dynamic menus and over-configurability that was MS Office 2000-2003. (Even though, personally, I quite liked it!) One additional tip, to make this downer-of-a-reply a bit more useful: you can look into LabVIEW OOP (Object Oriented Programming), and the Actor Framework, to see some examples of how you can make a UI more 'customizable' — by, for example, making multiple versions of the same UI, and decouple those UIs from the underlying actual program. Let me know if I'm being too vague here, or if you'd like some more concrete pointers. Best regards, Onno

Hi Alex, With the multiply I think you should be OK. As you said it returns within one cycle and this means it will return its output in the same cycle when it is called in the single cycle timed loop. I wouldn't go as far as to say all as there may be other elements which can't return in one cycle (e.g. is there reciprocal in high throughput? EDIT: I guess not as this is what you are doing!). I think the overhead is minimal if you enable the handshaking when available. The one problem with the code above is what happens if the output FIFO is full? To truely complete the four wire handshaking on the divide you should handle the time out case there which involves latching the divide output until you know it has been succesfully read, I think there is an example of this in the FFT shipping example. Cheers, James ...or to avoid latching I think you could do it just with checking the queue status has a space (available elements to right). If this is greater than 0 then set ready for output on the divide.

I call "dad".

Damn right. I choose to stop reading your post at this point.

Well then you're a stupid poo bum doodie head. Lots of things - like custom classes of tags that cen be read by scripting nodes (eg: run a report that scans free text labels that are a particular color or start with a particular tag to show all those "fixme" notes). It wasn't as much chosen for OpenG, it's an already accepted standard in multiple programming languages - to make it something else is unintuative.