Kurt Friday

Hi Ataru There is an example called Dig Output-Digital Edge w Ctr.vi Take a look at that it might guide you.

I've been playing some more with LVOOP 2009 I've been working on implementing active objects into the framework I posted earlier. An active object has its own process which is spawned when its instantiated. Active objects are useful if you want your object to have time dependent characteristics such as a pump controller. You can imagine that with an ordinary pump you can turn it on or off, but what about PumpVolume? You wouldn't want your PumpVolume method to hold execution while it turns the pump on, waits and then turns it off, instead a better way is if your PumpVolume method messaged to a process that handled this operation. Attached is a demo that instantiates two pumps to demonstrate Active Objects and that each instance has its own process. LVOOP2009_ActiveObj.zip

I've been playing with 2009 today and I'm impressed, I love the ability to now build by ref objects using Data Value Reference and the in place DVR Read Write, this is brilliant. I've been playing with an OOP framework and I've knocked up a simple demo. Have a play LVOOP2009.zip

Hey I had a play with it and at first is frustrated me too, but I found a bit of a hack. The format code you need to use to force text is @ However if you write your text before you format the cell and a cell has 11E6 then Excel will auto format it because there is no format set, then if you format it to text you just get 11+E6 as text. But if you format the cell before anything has been written then the cell essentially doesn't exist or hasn't been allocated and the toolkit throws an error. The way to do it is write an empty string constant to the desired cells, write @ as the format code then write your cell ie 11E6 The following is an example that demonstrates this.

Very cool, looks like a Dr Seuss application.

Hey, no problem, I enjoy tinkering with this stuff anyway. I've modified the demo so that instead of reading a script from file it builds it directly from a sequence of ramps. Each ramp is built from a template script which has hotnames in it for rate, setpoint, wait and ramp number. As each ramp is built the hotnames are substituted for their actual values which come from the user defined list. After the script is built it gets sent to he consumer to be processed. I've updated the Packages.vipc as I also implemented a read config from ini file as well. TempControllerDemo_V2.zip

I saw the same thing when I tried to do my first post. But then I switched to Firefox and all OK.

Ha, no, more like a secret squirrel that I send in. I'll be releasing GD source code soon under BSD, but if you want to look at the Agents take a look in the Agents folder. You will see for each version of LV a folder, in each folder is a set of vi's that perform the scripting and other operations not available from runtime, to unlock them the password is scigoop

Its possible, GOOP Developer is a LV7.1 executable that communicates to any version of LabVIEW development environment from LV6.1 up and gets it to perform scripting operations. It does this by using agent vi's which are called into the development environment by the executable to do the scripting.

I've knocked up a bit of a demo that I think will help you out. Its based on a Queue Driven State Machine architecture that executes a script. I've written a simple script that will demonstrate how it works, shown below. status:Test Start wait:1 temp_ramp:0.5 temp_setpoint:10 status:Waiting for ramp 1 completion temp_rampcheck wait:60 temp_ramp:1 temp_setpoint:20 status:Waiting for ramp 2 completion temp_rampcheck wait:60 temp_ramp:1.5 temp_setpoint:30 status:Waiting for ramp 2 completion temp_rampcheck status:Test Complete End When executed the script tells the system to display the status "Test Start" then 1 second later it sets the ramp to 1 deg/min and the setpoint to 10 deg, updates the status to display "Waiting for ramp 1 completion" and then waits until the ramp has completed when it hits the "temp_rampcheck" command. Once the ramp is completed it waits 1 minute and then moves into the next ramp sequence, ie ramp up to 20 deg at 1.5 deg/min. When all ramps are done it then displays to the user "Test Complete" Have a play, this is only a demo but you can expand your other HW into it and build your system from it. The demo implements OpenG library components which I have packaged. Use VI Package Manager to unpack the Packages.vipc file. TempControllerDemo.zip Hope this helps

Could you provide more detail? I'm not quite sure what the issue is.

Your class hierarchy looks fine. I don't have any LVOOP based instrument drivers I could post, but I'm sure someone has one kicking around.

The best way to do what you want is to use a queue. Input the queue into your Slave by either using the VI Server Control Value Set method or use a named queue, when pause is hit or elapsed time occurs it messages into the Slave. If you use 2 queues queue 1 can message into your slave from master and queue 2 can message into the master from slave. Have a look at Queue Driven State Machine Architectures. Another way that might work for your use case is instead of creating and destroying the notifier in the Slave, create it in the Master and give the Slave a reference, that way the Master can message into the Slave.

Cool, that's the one

Hi Angelo Definitely the Master Slave architecture is superior to polling, don't go back. I don't know why in your case you can't call it as a subvi and display in a subpanel, the Notifier shouldn't be killed, take a look at the attached demo. MasterSlave.zip I just built it up from a LabVIEW template in 8.5. If you need more help post some code up that replicates the issue.

Just having a quick look at your code and the driver and off the top of my head my suggestion would be to check the status of the ramp using Ramp Status.vi. If ramp is done then load your next ramp using Configure Ramp.vi and then call Configure Setpoint.vi. If your rate is the same then you only need to call Configure Setpoint.vi

Hi Bjarne I just ran the two demo's on my machine running LV 8.6.1 and the difference between the Traditional and the LVOOP implementations is that the LVOOP solution takes 100 msec longer to test 148 boards, each board having 13 tests. So 0.7 msec per board overhead using LVOOP, not too bad I tested under 8.2.1 and I get 350 msec to do the 148 tests, so a bit longer, I suspect LVOOP has been optimized a bit since then. Note that these tests were performed on my crusty but trusty 5 year old Dell Inspiron 1150 2.4GHz Celeron laptop. For me, the benefits of implementing LVOOP would greatly outweigh the performance hit, especially when I wanted to implement new tests and new boards. The code is simpler and self documenting, easier to farm out within a team of developers and easier to debug.

I can see some value, or curiosity in who votes your posts, but I think many would like to be anonymous in their voting. I can see situations where posters get upset that certain users don't vote their posts, or that users will vote because they might feel that the poster will be upset that they didn't. I personally like it the way that it is.

Ha, no, I’m just a LabVIEW geek. I think if I was a Marketing freak then GOOP Developer would never have seen the light of day. If I’d done a market analysis and income projection against development cost and blah blah blah at the start then the outcome would have been “Are you nuts!”. But I’m glad I didn’t because it wasn’t all about cash, I basically did it because I’m interested in OOP and at the time it was my mountain to climb, and working with Jim Kring on the OOP Templates and refining GD was a lot of fun. The entire experience has made me a far better LabVIEW Developer than before I started. I think the best marketing is honesty, if you inform your market of the pro’s and cons of your product then people will make an informed decision and be happy with their choice. I haven’t had an upset or disillusioned client, so seems to work. I remember a very good manager I worked with, his mantra is “Engineers and Accountants should always tell the truth” I’ve tried to find an old post I did where I raced all the different flavors of OOP, but I can't find that post, weird. I have the benchmarks which I could re-post if anyone is interested.

Hi Adam You mention that you haven't tried plugging in the breakout device into the other PCI card only because you don't think the pins line up. Do you have a PCI-6110 in both machines? You need to check if the traditional NI-DAQ driver supports your hardware, to get your NI-DAQ version open up MAX and expand the tree to display Software, down the bottom you will see Traditional NI-DAQ as show below. Then take a look at this document on the NI site which lists hardware against driver compatibility. Also you ran a test panel, which will work because they are based on the DAQmx driver, which is the latest driver architecture so it's not surprising that it works. But what you need to do to test your case is make a Traditional NI-DAQ Virtual Channel and then test that. To do so right click on Data Neighborhood to create one. If you can go through the process of creating one and then test it, then it should work in your application. If not then there is likely a compatibility issue. You mention that an error is not being returned, do you have all DAQ vi's error flowed? If so and you are not getting an error then I would suggest the problem is electrical or connector issue. To find out more about DAQmx and Tasks have a look through the following tutorial. Once you get over this issue I would strongly reccomend taking the time to understand DAQmx and how to write measurement code in LabVIEW to use it, its powerfull stuff. Perhaps then look at how you could edit your code to use it.

Hey Vugie I've just been playing with VIpreVIEW, this is amazing! Well done, its really cool

Awww, not even worth a look at Chris. At the time I had no idea that “GOOP” was a registered trademark of Endevo. I found out later that it’s was a registered trademark in Sweden when I worked with the guy who developed Endevo GDS. I did think of changing the name to POOP (PrettyCool Object Oriented Programming) but it didn’t have the same ring about it. Basically GOOP Developer is a code generation wizard and class manager that builds your classes from Open Source OOP Templates. It doesn’t implement LVOOP because they were developed before then, but they support Inheritance, Active Objects and you can run it on RT platforms. In my opinion, considering that LVOOP has come along way since it was initially introduced, my recommendation is that you take a look at Endevo's GDS, it’s beautifully implemented. I’ve had the privilege of contributing to a design pattern for Active Objects and to some of the mechanics of data locking.

Ahh, true, but I agree not much use for what you want to do. I had a bit more of a play now understanding what you want to do and I can't get the user event case names attached to a particular terminal either. Yair is right, doesn't look like its exposed.

What you can do is get all frames, then for each frame get all objects, cast all objects to Control Terminal ref and keep the refs that do cast and get the terminal label text. Now you have a list of terminal refs against frame refs by terminal label text. If you search for your control by label text you can get its Terminal ref and also the ref of the frame that it belongs to.

Here is a great article in NI Devzone that you might be interested in. http://zone.ni.com/devzone/cda/tut/p/id/6349 Also take a look at this discussion