Leaderboard

Hi Everyone Just a heads up that GOOP Developer has recently been released free of charge for commercial use. To obtain a copy just navigate to my site. I'm also toying with the idea of releasing the source code for GOOP Developer under the BSD Open Source License, let me know if you are interested. As you know GOOP Developer uses a lot of scripting to achieve its voodoo. The scripting is performed mostly by agent vi's which are called by the GOOP Developer exe using vi server, if you are interested in having a look under the hood at some of the scripting functionality take a look in the agents folder, the password to unlock them is "scigoop"

A previous post about sharing a FG between two separate LabVIEW projects (or computers) got me thinking about an example I had been working on, but at some point I lost some focus on it. I thought I'd throw it out here in case it helps or interests anyone, and hopefully to get some solid feedback on how the idea could be made better and more applicable. The idea is to wrap the LabVIEW Queue functions into a library that allows users to share queue-based data over a network with basically the same API as the normal Queues. In the example I'll post below there are only a few differences between regular queues and the new Network Queue: Network queues only transmit variant data. Users would have to wrap the functions to get specific data types in and out, but it wouldn't be hard. There are two functions to obtain the queue instead of one. There is Obtain Queue (Client) and Obtain Queue (Server). There is one and only one server where the actual queue is hosted, and there can be any number of remote or local clients. In the current architecture, if a client calls a function that blocks (like trying to dequeue from an empty queue with a timeout), then all other function calls from that same client will also block until that one completes, even if they wouldn't normally block (like a Flush or Get Status function). This is because there's only one pipeline for all function calls for each specific client. I'm using LabVIEW Classes, which restricts the functions from being used on RT. There's no particular reason other than encapsulation that I'm using LVOOP, so we could strip that dependency out. So there are a few limitations, but basically it's a pretty useful library that makes it pretty simple to share data, distribute data over Producer/Consumer type design patterns, and so on, without having to use Shared Variables which for the most part have the same limitations and dangers as regular Global Variables. So take a look at the attached class. It's meant to be extracted into user.lib. It's written in LabVIEW 8.5. Please let me know what you think! Network_Queue_Class.zip

I just got my grades for the Certified LV Developer exam. Passed! Woot! But even more exciting: I turned in a pure OO solution to the problem. No naked VIs -- meaning every VI in the hierarchy was a member of a class, every ounce of functionality in my application was delegated to one particular object to manage. All objects were passed using dataflow -- the queues of objects that I had were mono-directional, for communication, not for data storage. I obviously cannot discuss what the exam question was, but the heart of the application was a message passing interface like the one described by Yair recently on LAVA. I am very pleased with how the OO features of LV responded. Under standardized conditions, such that we can directly compare against a traditional solution, in the same time, I was able to generate an application with better than traditional flexibility (able to plug in new messages into the system without modifying the framework) and with accepted run-time performance. And the single biggest time sink that I had is being worked on by an intern even as we speak. ;-) I am fairly certain this is the first pure OO solution submitted for the CLD, and I was a bit worried about the solution being accepted given that part of the CLD is to grade knowledge of the accepted standards of LabVIEW programming methodology. Apparently, three years since its release in LV8.2, OO passes that test. The clock now begins, counting down until the day when a non-OO solution is not accepted. Not everyone is as much a believer in OO as I am, but OO has slowly consumed every other programming language it has been introduced into. It will definitely be years away from today, but I believe it will happen. For those who have not joined the faith, I'll be serving Koolaid at NI Week. ;-)

I just fixed the links.

I do not generally promise future features, but last year at NI Week, for the first time on any topic, I went so far as to say that classes would be on RT in the next version of LabVIEW even if that meant trying to hold up the entire LV release until it was ready. I can't say anything further except to say that I'm spending this week writing NI Week presentations, not working on LV features. ;-)

Don't get me wrong, I try to make the majority of my posts helpful (not like this one). I think the voting posts up and increasing rep thing hasn't caught on in LAVA yet though as it's pretty new. Until it does catch on, a post count at least shows you're not hiding in the shadows and you participate in the LAVA community. I still find it a bit intimidating to post a reply in the same thread as someone who has over 4000 posts, especially if they reply and increase their font size and encapsulate in exclamation points, hypothetically speaking of course. Maybe some of the mystery will fade at the LAVA BBQ though...

There is a novel technique that I have seen and done a variety of times. It requires creating a wrapper for the "Send Notification" VI like this http://screencast.com/t/zRDGaScM What the video hopefully details is that you can create a VI that is in memory on Application A. Inside of that VI is a shift register that holds the reference to the needed thing (semaphore, queue, user event and so on) Then you pass that VI the data that you want to end up in the (semaphore, queue, user event, notifier, and so on) using Call by Reference Node And then the VI fires the (Notifier, user event, EnQueue) with that data and the stored reference. By doing that, you have successfully sent data to any other LV application regardless of whether it is another Application Instance, an executable, or a VI across the world. Note: Scott Menjoulet (LAVA member w/ the Detroit Red Wings Avatar) is the originator behind this idea, and I have merely been it's rah -rah boy over the years and strange uncle to work it into a generic LVOOP based implementation in LVx See the attached file for the VI's and projects used in the video Step 1 is to open both projects, local and remote and then go from there. -Norm REx.zip

! The goal should NOT be increasing your total post count, it should be increasing your reputation points !

QUOTE (skof @ Nov 27 2008, 05:29 PM) Another possibility is that you target the wrong application instance. Since LabVIEW 8.0 a LabVIEW process can have many application instances with one main instance and then one additional instance for each possible target in every single project. Of course they don't always remain on the same host (RT target in a project) and consequently have different IP nummers to open first. But when I was deploying a project to a cFP controller recently and tried to access a VI through VI server that existed in this project I got this error too. Solution was to explicitedly configure VI server in the target of my project to use a different IP port and connect to that. This did kill my performance though so badly that I had to abandone this approach. I guess there is a default VI server on a RT target (as I could connect to it) but a directly deployed application from a project gets instantiated in its own application instance that has to be enabled first. Rolf Kalbermatter

QUOTE (neB @ Jun 6 2008, 07:53 AM) You are of course right. Creation of any refnumed objects in LabVIEW has to be done in the context of a VI hierarchy that does not go idle for the life time of the refnum. In this case the best thing would be to have a deamon running in the background that gets instantiated if necessary by the remote queue VIs and takes care of queue creation on behalf of the those remote queue VIs. Rolf Kalbermatter

QUOTE (ragglefrock @ Jun 1 2008, 06:18 PM) Actually I think the Call By Reference call will handle arbitration nicely so if you can provide VIs with atomic access to a particular queue you should be fine. Rolf Kalbermatter