Kurt Friday

Using Tim's and Eric's Ideas use a circular buffer. So you are going to have an array of points X of dimension N As each new chunk comes in do the following test. Find the minimum point xi Is (x0 - xi) > Dip Threshold Is (xn - xi) > 150mV Is (xn - x0) > Difference Threshold If all are true then acquire for the desired number of seconds.

In the example set your desired frequency to 40KHz set the samples per buffer to 25 and the number of cycles per buffer to 1. This will generate a 40KHz sine wave with a timing resolution of 1MS/s I played with setting up a simulation board to test this and it works, however if I go above 1MS/s I get a warning that "Sample clock rate specified is so high that it violates the settling time requirements for the generation." Its just a warning that you are driving faster than the settling time of the AO, its not an error though. This should get you up and running.

Hi You should have no problem, the NI-6281 can output at 2.8MS/s. The examples are the best place to look and the best example for your case would be Cont Gen Voltage Wfm-Int Clk-On-Board Regeneration.vi With this example you define your waveform, in this case a sine wave and it just cycles it continuously.

I just had a little play with my 6008 and what I found is that although I set my range to 0 to 1 V it will still pass a small negative voltage. I think the reason why is that the range is not setting a coercion range but sets the programmable gain of the device. when you set 0 to 5V its using the + 5V span or gain of the device ( ie 16 bits over +5V) so you will see negative values being propagated due to noise in the system when the microcontroller is outputting 0V. When you go to write your voltage, the limits on output are 0 to 5V, and that's a hard limit and the driver does a reality check first before it tries to write it, so if its negative you are going to get an error. The way to get around this is to use the In Range and Coerce function in the Comparison palette to coerce your voltage between 0 and 5 volts before you write it.

Hey Dak, good stuff. At first it was a bit like staring into the sun, but now I see it, very cool I like how your framework is implementable, all you need to do is have your desired class inherit from the Interfacable class, and then build your Interface class and then make the desired class a friend of the Interface class. I noticed that in your example that Baby is a friend of ISleepableBaby which made sense but I didn't understand why ISleepableBaby:Wake.vi is a friend of Baby. I'm still a bit sketchy on friends however your framework points to a really good use case. I'm still working through your demo, its a substantial piece of work, I'm hoping to test drive it a bit on some of my demo classes.

Check out this cool presentation by Michael Aivaliotis. It goes through how they made the buttons for the JKI VI Package Manager it will shed some light on how it's done.

Looks like Mars.

Check out the dust storms in Sydney Cough Cough. I woke up this morning, looked out the window and it was all red. I live in the Blue Mountains west of the city surrounded by bush so I thought it must be bush fires, thankfully its just dust. I can taste it in my mouth as I breathe, yurk

Hey, welcome aboard

Hi Tomi Nice to see you back in the ring, brilliant analysis, you found a couple of pitfalls that we need to look out for or address. One idea for handling atomic transactions that involve parent and child is to have a method called GetDVR, this just returns the DVR of the object. In those child methods that need to be atomic in its data transactions involving parent and child simply wire the parent DVR and the child DVR to the IPE, or have the parent IPE outside and child IPE inside. Now you have locked both parent and child data while you do your operation. It may be a little inelegant but it gets you around that particular problem. I also like Jim's idea of a semaphore, I'll have a look at that. Or perhaps a SEQ that acts as a token, as Kugr mentioned. I view it as child needs to be able to lock parent, but parent shouldn't lock child. So having separate DVR refs for parent and child has its advantages. I can imagine where you could have an active object that has a process running for parent and one for child, and example could be a specific server class. The Parent process manages connections, tickles to clients and sending and receiving messages. The Child process acts on the commands recieved and performs actions and sends responses. You wouldn't want parent methods locking the child, but you may want to lock the parent from the child. We need a by ref solution that is easy to implement but also easy to distribute. If I make a OOP by value driver for some instrument then I don't expect that the end user needs to be an OOP expert just to implement it into their code. I would expect that they are familiar with things such as File IO, Queues, Visa, DAQmx tasks, VIserver where they have a ref to something and they just perform methods on that ref. I can imagine distributing a driver that was LVOOP inside DVR and then users getting frustrated and confused that they have to start placing IPE structures within their code just to use your driver, to them it wouldn't be consistent with their experience and in many cases outside their level of understanding.

"They weren't listening to me and were rude. They had three people around me. It was intimidating." That's a bit nancy coming from a Jedi, I thought they were made of tougher stuff.

Weird, I see the same thing. It looks like the Numeric Properties Data Entry tab page isn't refreshing with properties of the current control but rather keeps the settings of the last control edited. I'll check LV9 and see if it's the same dea. Edit LV9 is OK

Sorry to take my time getting back to you, I was out of the office all yesterday. My original Idea was have a set of vi's called interfaces that have default object inputs, inside the interface vi I would determine the class it was acting on using Get LV Class Path.vi and then call the method in the class that has the same name as the interface. So if a DMM object was input to Interface.Read.vi then it would determine that it was acting on DMM and then call method DMM.lvclass:Read.vi. It was a simple idea to get something working but when you wire a CIN to a Dynamic Dispatch vi type then you get a block diagram error and the reason is "Call By Reference Node: Refers to a dynamic member VI. I looked at the LV help and it states "The Call By Reference Node does not support dynamic member VIs in this version of LabVIEW" So the other idea was to have it call a static member vi in the class called Interface that has the methods you want to include. The problem I can see with a class is that it then becomes typed and I wouldnt be able to wire in my DMM or Thermometer instance to the interface methods because they now belong to the Interface class. I like the idea of it belonging to a class for the reasons you mentioned. I'd love to see it when you have it all firing, sounds like you have the OOP bug. When I was building it I was just creating a constant from the default object terminal of the Interface.vi, I thought at the time why does it look non default but there were no issues or coercion, so I thought OK. But just trying it now I can't re-create the same constant, ie black cube, I get the expected white cube. So it could have been due to creating a constant from a default LV Object that contained non default data?

Good idea, new thread over here

New topic generated from this thread I've been having a play with interfaces and I've got something fairly hacky that I thought I would throw up here. One of the problems that I was running into was the inability to call a dynamic dispatch vi using a CIN or a Run VI Invoke Node. What I was able to do is define a static dispatch vi for each class called Interface and in there I would have the methods that could be executed by the interface. I then define a set of vi's called interfaces that know what class they are operating on and hence can call the appropriate static dispatch interface method using VI Server. I'm a bit green on interfaces so there may be big holes in this. The demo implements interfaces on two classes that are unrelated, a Thermometer and a DMM, the interfaces handle Create, Read and Destroy. InterfaceDemo.zip I agree, using CIN's aren't the best way to go, especially if your interface is broken. I was thinking about a class for the interface but I couldn't see what a class could contribute since the Interface vi's take on the methods of the class they are assigned, and the interface has no data and no dynamic dispatch (the methods that the interface calls can have dynamic dispatch), they are more or less acting as a wrapper. Perhaps a library would be more appropriate. I liked your example, so there are a few ideas kicking around, would be cool to put some collective effort into this.

OK, It looks like a Vista problem, you are the 2nd user to report this on Vista, I'm currently looking at this. It's an ActiveX issue for sure. Let me have a deeper look and get back to you.

If you scroll back through this tread you will find some demo code that I posted early into this discussion. Just recently I added a By Ref OOP Framework that also includes examples.

I assume you are running the exe? Have you configured your LabVIEW VI Server settings correctly? The tutorial steps you through the steps, but follow the settings shown below. For LabVIEW 7.1 You can edit the port that GOOP Developer uses to connect to LabVIEW either via the GOOP Developer.ini file or from GOOP Developer main menu, goto Optons -> VI Server Settings. Your GOOP Developer VI Server port and LabVIEW VI Server Port must match.

That is nice and neat, I like it.

Cool thread I've been having a play with interfaces and I've got something fairly hacky that I thought I would throw up here. One of the problems that I was running into was the inability to call a dynamic dispatch vi using a CIN or a Run VI Invoke Node. What I was able to do is define a static dispatch vi for each class called Interface and in there I would have the methods that could be executed by the interface. I then define a set of vi's called interfaces that know what class they are opperating on and hence can call the appropriate static dispatch interface method using VI Server. I'm a bit green on interfaces so there may be big holes in this. The demo implements interfaces on two classes that are unrelated, a Thermometer and a DMM, the interfaces handle Create, Read and Destroy. InterfaceDemo.zip

Hi Ben Just looking at your code, are any errors reported? I cant test this with my hardware but one thing I would look at playing with is the size of your DAQmx Buffer, try increasing it.

Hi Mate Yeah, I've been good. It's kfriday AT sciware.com.au

I think what is happening is that you are trying to execute two tasks that both require the same resources. Take a look at this link in particular Case 6 it will explain things in a bit more detail. What you need to do instead is combine two or more channels into one measurement task. Open up example finder and find the example "Acq&Graph Voltage-Int Clk.vi" you can make this example acquire multiple channels by selecting on the Physical Channel input then Browse and then from the dialog select multiple channels as shown.

Name: By Ref Active Object Framework Submitter: SciWare Submitted: 14 Sep 2009 File Updated: 14 Sep 2009 Category: LabVIEW OOP Version: 1.0.0 LabVIEW Version: 2009 License Type: BSD (Most common) By Ref Active Object Framework Copyright © 2009, Kurt Friday All rights reserved. Author: Kurt Friday LAVA Name: SciWare Contact Info: Contact via PM on lavag.org LabVIEW Versions: 2009 Dependencies: None Description: This is an OOP Framework that allows the development of By Reference Objects with the capability to also be Active Objects. By Reference capability is achieved by wrapping a DVR of the Data Members in a LVOOP Object. An Active Object is one that has its own background process which is launched when the object is instantiated. Active Objects are useful if your object requires time dependent characteristics. Examples: By Reference Object Demo Demos\BikeDemo\Src\BikeDemo.vi By Reference Active Object Demo Demos\PumpDemo\Src\PumpDemo.vi Version History: v1.0.0: Initial release of the code. License: ### BSD License (http://www.opensource.org/licenses/bsd-license.php) Begin ### Copyright © 2009, SciWare <http://www.sciware.com.au>, Author: Kurt Friday All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. * Neither the name of SciWare,nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. ### BSD License End ### Support: If you have any problems with this code or want to suggest features: please go to lavag.org and Navigate to LAVA > Resources > Code Repository (Certified) and search for the "By Ref Active Object Framework" support page. Distribution: This code was downloaded from the LAVA Code Repository found at lavag.org Click here to download this file