Kurt Friday

SciWare thanks for your replay,

with the example you've suggested me, my 6281 DAQ board is working but not very good. At 40kHz I receive a worning (200040) that alert me that the clock rate is too hi for the board. I don't understand why; the clock rate I had set after the mathematic calculation as shown in example you've suggested me is 1,8E+6 and, as you indicate me in the post before, my DAQ board can work at 2,8E+6. Is this right?

Can I set 2,00E+6 as value in clock rate node for the NI-6281? Why I receive that worning?

I'm sorry for my english, I hope you can understand my exposition of the problem.

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 guys,

I want to generate exactly 40kHz sine waveform on my PXI NI-6281 DAQ board. How I can do that? Some one can help me?

I saw a lot of examples but I have some difficult to understand if my board can generate that signal. Can 6281 generate 40kHz sine signal?

Thanks to all for future replay.

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.

Hi all,

I am working a simple project, where my first daq card (NI6009) acquires a data (PWM) from a microcontroller and sends it out to second daq card to control a servo. So one card is acquiring and another is generating the same signal. My problem is that, although the daq cards are set at 0-5V for both input and output, there is an error given by the second daq card saying the voltage being written is either too small or too big ( the value it shows is like - 856 X 10^-6 so thats negative 8 mV). I am not sure where this small negative voltage is coming from.

Any ideas guys?? can i implement a filter or something to solve this problem?

This program is just for testing, later i am planing to transmit the signal over the internet for remote experimentation.

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.

After looking the code of SexyGUI from Jonathan Cohn, I found a six picture button with a glyph.

And I still cannot achieve it by myself. Dose anyone know how to make it?

Thanks a lot.

SexyGUI Address: http://decibel.ni.co...ent/thread/3676

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.

I took this picture on the way to work in Sydney.

I had to cover my nose and mouth with a cloth to cycle to work.

//Mikael

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.

Hi

My version of LabVIEW is behaving odd when it comes to Data Entry limits.

Have YOU seen the same problem?

When I open the “Data Entry…” option for a numeric the first time it does show me the right limits for that control.

When I open the same option for the next numeric control these values don’t show the correct values.

They still show the first opened control’s Data Entry-limits.

And if I change the values, that values changes for the other control not the one I open the dialog from.

This is in LabVIEW 8.6

Cheers,

Mikael

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.

I've never tried this. How does it fail? Does it just not dispatch to the correct child class VI?

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.

Probably nothing in terms of functionality. In text languages using Interfaces is a lot like using classes and objects. Wrapping your Interface methods in a class would help give the user a consistent experience.

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.

Yeah, except for that tiny little issue about it relying on a particular feature that cannot exist in a dataflow language. However, I did redesign it around by ref objects and last night I got it working correctly. I'll try to get it posted soon but it is more complicated than my previous design so I should probably put together some documentation for it.

I've been poking around with Interfaces off-and-on for about a year now. I could write a book on what doesn't work! I'm glad I've spent the time doing it though... I've learned a lot of things that I wouldn't have encountered in job-related stuff.

I'd love to see it when you have it all firing, sounds like you have the OOP bug.

Kurt, I noticed an unusual upcast to a non-default Labview Object. Why do you do that?

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.

He probably just copied the constant from somewhere... the effect won't be any different than if he used a regular LV Object constant -- the center input only cares about the type of the wire, not the value on the wire. Of course, depending upon the value of that constant, you might be creating a dependency on a class that is otherwise unused in the diagram. It'd be better to use a default-value constant.

So it could have been due to creating a constant from a default LV Object that contained non default data?

Your implementation really deserves its own thread. Not because I'm worried about hijacking this thread (I think has run its course) but to make it easier to find.

I like the way you've solved the problem of calling similar methods from unrelated classes. That is an approach I had not considered. I think I like that you don't have to obtain the interface before using it. On the other hand I think the reliance on strings and the CBR node will make maintenance more difficult in the long run. What you have doesn't quite present the user with traditional Interfaces, though it wouldn't be hard to wrap your interface in a class to give it a more standardized feel.

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 like the way you've solved the problem of calling similar methods from unrelated classes. That is an approach I had not considered. I think I like that you don't have to obtain the interface before using it. On the other hand I think the reliance on strings and the CBR node will make maintenance more difficult in the long run. What you have doesn't quite present the user with traditional Interfaces, though it wouldn't be hard to wrap your interface in a class to give it a more standardized feel.

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.

I have traced the error to Listview.Create.vi

IListViev node report Error 97 (Null Refnum). The “Value” outof AXCont is 0, even though the reference into it is a valid refnum.

I am running Vista right now, maybe this has something to dowith it?

Edit: It is the ListView ImageList that is an invalid ActiveX container (or dot NET?) "The Control could not be loaded" error.

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.

I also like the look of that.

Does anyone have a basic example of DVR LVOOP object?

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.

Nice, and thanks. But it doesn't work. Not in Lv 6.1 or LV 7.1 It will not connect to the vi server. Everything is set as described regarding ports. The vi server settings report port 0, and when changing it, it still is 0 when trying to change it again. The ini file is set to 3363.

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.

One thing that I've started doing with the DVR-inside-LVOOP scheme is using an IPE Structure to (un)bundle the DVR reference outside of the IPE that (de)references the private data. I like this a lot because it keeps the object/reference/data wire in straight line without any branching -- it seems to have the best "style". Note that I named the DVR "ref" to keep the (un)bundle nodes small in width.

What do you think?

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

Well, it seems no one knows this on the NI list, so maybe somebody here will.

The attached VI has two analog inputs and one analog output. An external signal generator sine wave is connected to the first analog input. This is routed to the analog output which is physically connected to the second analog input. I want fresh data every time so I've set the vi to "No Regenerator". The problem is the AO only outputs one cycle of the sine wave before stopping, even though it keeps being supplied with more sine wave. It seems if there is any gap in data being provided to it, it just shuts down.

Any ideas?

Thanks,

Ben

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 Kurt, how you've been?

May i ask you for your mail so i can ask you directly some of my new questions about the temp. controller?

If you can´t give it or don't want too, i understand and i will post here asap.

Hi Mate

Yeah, I've been good.

It's kfriday AT sciware.com.au

Didn't know under what category it falls but here's the prob -- > I work with DAQ 6008 (for Measurements).

For instance , i wanna measure Voltage. But i can use only one channel in the DAQ. If I use another channel to Measure something else , It says that The DAQ is already in use.

How can I write a program that can run measurements simultaneously in 2 channels (or more) ?

How do I write this program? Am I suppose to Duplicate the DAQ VI or can I use only one VI with two exits (for the 2 channels) ?

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

Between your scheme of DVR'd member variables and daklu's Interface/Implementation work, this solved a huge problem I was having in my project. I also plan on posting some of this too. I am a bit restricted on what my employer will allow me to publish .

Cool, I'd love to see some OOP frameworks, would be great to have a bit of a community effort on this.

The only downsides (that I can see) of using the DVR inside an LVOOP object are:

1) You can't tell just by looking an an object that it's by reference (as you can when you see a DVR with an LVOOP object inside)

2) You have to unbundle the DVR before you can pass it into a IPE Structure

Good points, would be useful to see at a glance that your object is by ref, but I suppose we are using by value objects in a by ref capability. Perhaps a convention could be started by choosing a specific wire color, I'd suggest a green color which is consistent with other by ref implementations such as File IO, VI Server, control refs.

Yes, unbundleing all the time is an overhead and takes up a bit of real estate. At the moment I'm also placing a few more items in the object data other than just the datamember DVR to achieve active objects so its usefull to unbundle and get what I need. It would be nice to just plug the object into the IPE but then how does it know what to unpick since the object can hold many things, multiple DVR's possibly

Oh, and there's one situation that you also have to be very careful for:

Ifyou're inside a child method and you call a parent method inside an IPEstructure, you might deadlock if the the parent method is itself, orcalls inside of it, a dynamic dispatch method that results in childmethod being called.

With this in mind, one feature that I'dlove to see in LabVIEW is for IPE structures to be smart at run-time and output an error (rather than deadlock) if an IPE is called inside another IPE and tries to dereference data that has already beendereferenced by the outer IPE.

Ahh, yes, that would get you. At the moment I'm carefull about placing methods inside an IPE unless I have to. If I dont I just use them outside. I agree with you that there needs to be some checking that looks at the method you place and does a check to see if there is any possibility of cycling back to a read on the same DVR

Two more disadvantages of DVR's data members:

1)DEBUGGING: With DVR'd data members, when you look at an object, all you see is the reference number. This is certainly true for DVR'd objects as well, but perhaps you would be in a IPE more often than just the Read/Write accessor methods.

2)Flattten to XML: Here too all you get is the reference number of the data. Not surprising, just dissapointing.

Even with these two additions, I am not swayed until NI comes out with something to help.

A probe on the DVR to show the data would be handy, I suppose the probe would have to implement an IPE behind the scenes and then I can see a situation where you probe your object within and existing IPE and then you get a lockup. I suppose you could make your own custom probe that is a member of your class, a bit like the old object explorer.

I'm really happy that everyone is on the same page with respect to implementing by ref objects. Looks like we have a great kickoff point with a workable framework that is easy to implement and doesn't require a heap of support vi's. In the past I've always used my own OOP implementation to give me what I want because LVOOP just wasn't there yet, but now it is and I'm very happy and I have to say a big thank you to NI for working on this

However, one thing that makes me uneasy about putting the DVR inside the object (as your example does) is that each level of the inheritance hierarchy has it's own DVR and is locked/unlocked separately. I worry that this could cause some nasty race conditions or deadlock -- have you thought about this? And, an attempt to remedy this issue takes us back to where we have a lot of framework/support VIs for each class.

Cheers,

I've been having another play with the concept of datamember DVR inside object ref and it’s appearing to be solid.

The only thing you need to watch is that you don't perform a method call inside an In Place Structure DVR R/W that acts on the same data. So placing a method of the same class or a parent method with dynamic dispatch will cause it to lock. Placing a parent only method inside a child method's InPlace Structure DVR R/W is OK since it only acts on the parent data which has its own DVR. But in the end it’s the same kind of rules you would use as before when you had lock and unlock primitives in previous architectures.

I haven’t been able to create a race condition as a result of implementing parent and child data member DVR’s. Since parent data is accessed in a child by parent methods the data is protected, the data locking protection mechanism exists at all levels of the object hierarchy.