Jeff Plotzke

QUOTE(ironcross77 @ Feb 13 2007, 10:00 PM) The easiest way to do this is probably to have a while loop around your acquisition -- Have it exit the while loop when the value is 5 degrees more than the last time the loop exited. I'm assuming that you're acquiring the temp signal in the "LJ EAI" VI towards the top of the loop. Inside that VI, where you actually do your DAQ read, make this VI wait until temp is achieved. However, two warnings to watch out for: -You'll need to make sure you synchronize with the other VIs in your top-level for loop. As it is right now, it's undetermined if the top "LJ EAI" VI will run before the bottom one. You'll want to use a wire to make sure that the bottom executes after the top is complete. -While you're doing the acquire and waiting for temp to become greater than 5 degrees from the last reading, this loop may run forever if the temp never rises. You'll need to implement a way to ensure that this loop will stop (A notification from the top-level will work, or something similar) Note: You could put a while loop around the top "LJ EAI" VI assuming that all that VI is doing is acquisition of your signal. I've attached a quick screenshot of what your acquisition would look like.

I'm developing a UI for a LVRT system to be run on a remote front panel. I need to allow the user to use a button to open a valve in increments. Each time the user presses the button, the valve opens a set amount. However, I also need to allow the user to hold down the button and the valve will continously open at a certain rate until the button is released. My problem is that it seems that LVRT doesn't support the two boolean mechanical actions that I need: Switch/Latch until released. The other four actions only allow the button to trigger once and doesn't support the user "holding it down." Does anyone know of a way around this problem? Thanks!

QUOTE(van18 @ Feb 13 2007, 08:50 AM) If you can read both analog channels in the same place of your code, you can put both channels in a DAQmx Task and read them using a DAQmx Read. The task will handle the resources so you won't need to worry about doing the locking yourself (assuming that you're only reading the task in one place).

QUOTE(alnaimi @ Feb 12 2007, 05:17 PM) Are you having a problem with creating the sine wave or setting up the channel? What have you done so far and what's giving you the problem? To create a simple sine wave on a DAQ channel, I'd check out the example: C:\Program Files\National Instruments\LabVIEW 8.2\examples\DAQmx\Analog Out\Generate Voltage.llb\Cont Gen Voltage Wfm-Int Clk.vi

QUOTE(vee_yar @ Feb 12 2007, 09:10 AM) Here's a few suggestions I have for your VI: You're calculating the heart rate based on finding peaks each time this loop runs. However, this loop will execute every 0.1 sec (It's timed by your DAQ acquisition -- Continous samples at 1kHz, grabbing 100 at a time). So, right now you're assuming that you're going to find two peaks in your data each iteration of the loop... This means that you'll need a signal hooked up going at 20 Hz -- or a patient with a heart rate of at least 1200 beats per minute! (Talk about a stress test! ) What you'll want to do is to store the last peak found and store it on a shift register of the while loop, since there will many iterations of the loop without any peaks at all. You know that there will only be, at maximum, one peak per cycle, so you don't have to worry about if there's more than one. Now, for each subsequent peak detection, you can take the time of the current peak, subtract it from the value on your shift register (the time the last peak was found), and find the difference. Then, as you did, take the inverse of that time to find the frequency (altough this is in 1/sec, you want 1/min, so multiply by 60) You may also want to consider averaging the BPM you find over time. If there's some peaks that aren't detected, or if you find some extra peaks, this number will jump all over place. You'll probably want to average over the last few times to smooth it out. I've attached a quick fix I did to your VI to help my explaination... You'll of course want to clean it up -- And this doesn't look at all at the averaging issue.

QUOTE(xavier30 @ Feb 12 2007, 12:19 PM) I don't think there's much you can do to raise the limit, other than getting a faster ethernet card... Here's a few suggestions: -Run the shared variable engine on the faster of the two computers. The engine will take up lots of CPU usage, especially during intensive read/write operations, so I would put that on the faster cpu to make sure the CPU isn't holding you down. -Are you running this on a network which has other network traffic on it? Other network traffic will significantly slow down the data transfer rate. You'd probably get better results if you had a direct connection between the two. You can take a look at this article on ni.com regarding shared variables: http://zone.ni.com/devzone/cda/tut/p/id/4679 If you scroll down to Test T3, they're doing the same test you're trying. They first do a large transfer via TCP/IP VIs from one host to another, then they do the same test using shared variables. The results are interesting... It looks like the data rate starts to cap off at about 1000 DBLs (so 8 Kbytes), and that's operating at about 9-10 MB/s (72-80 Mbps). At the bottom they mention they're using a 1 Gbps connection between an RT PXI Controller and a host PC. That said, they still recommend in the article to use plain TCP/IP VIs for faster performance -- and, as you can see from their graph, the TCP/IP VIs did much better at around 40 MB/s -- 320 Mbps, which isn't too bad since a lot of the TCP/IP bandwidth is header/handshaking information. Hope this helps!

Congratulations, Chris! When I grow up, I want to be just like you!

I agree... as a musician myself too, I had to put that side of me away while watching. It really doesn't do much musically. But, the pretty lights and colors made the engineer side of me want to build one!

Haha... Yeah, it started doing that for me too... I'd be sitting here listening to music and all the sudden "I'm worried about my little Dilbert..." starts up If you go into the "Plug in Preferences" (click the little button to the lower right of the movie), then uncheck "Play movies automatically"...

The differences between 'PnP' (Plug and Play) and 'PnP Proj' (Plug and Play Driver in a LabVIEW project) is that the 'PnP Proj' takes advantage of the LabVIEW project architecture which debuted in LV 8.0. It's easier for driver developers to organize their drivers and mark VIs as public/private. You can read about the differences of the two here: http://zone.ni.com/devzone/cda/tut/p/id/2921 In your case, both of the drivers shown look like they're the same (the same name is on both), but the 'PnP Proj' is newer. (If you look at the revision numbers on the right, the PnP is driver revision 2.0, while the PnP Proj is revision 3.0. You can certainly use the LV 8.0 driver with LV 8.2, altough it will ask you to re-save the VIs once you start using them since it has to recompile them for LV 8.2. It would probably be wise to do a mass-compile of the driver after you download it using the Wizard. (Tools > Advanced > Mass Compile) After you download the driver, it will tell you where in your instr.lib directory it put it.

Hmm... most of the software they use, at least for the object tracking is all open source available here. All it needs is a camera and a projector... Doesn't sound that hard to build

I love it! Where can I get one?!

Is there any version of the Tunnel Wiring Wizard that works in LV 8.20? I'm trying the 8.0 release of the wizard (on LV 8.20) and it always says that I'm not selecting two tunnels, even though I am. I know that with 8.20 you need the license to do scripting... but I hope one of my favorite tools isn't destroyed! Thanks!

Be sure to follow your own rule and share, Chris!

This is a pretty vague question... If you haven't used LV DSC before, I'd start with LabVIEW Help / DSC Examples. They can give you a start for how to use DSC. I think NI has some examples/tutorials on their site as well.

Can you show us any of the code that you're using? (at least a screenshot?) One thing that I forgot to include in my post yesterday is that you need to call the .NET constructor before you can use the reference. On your block diagram pallette -- Connectivity -> .NET -> Constructor. Use this to create your .NET reference instead of dropping down and using the .NET refnum control on the front panel (You'd use this method to pass the already created refnum to a subVI after you call the constructor to create the refnum). See if the constructor fixes your problem. There's also a few .NET examples with LabVIEW that can give you an idea, too.

First of all, make sure you have the latest .NET framework off microsoft.com (You need at least .NET 1.1 SP1 for LabVIEW). If you have VS.NET, you're probably OK. Drop a .NET refnum on your front panel. On your block diagram, right click it and select "Select .NET Class" > Browse... You can select the DLL to use and the .NET class inside the DLL to use. From there, wire up a property node or invoke nodes to use the properties/methods of the .NET DLL.

The subpanel uses the same properties set in the 'Window Appearance' VI Properties. So, in your subVI that you want in a subpanel, open up VI Properties -> Window Appearance -> Customize -> Uncheck 'Show Vertical/Horizontal Scroll Bars'

Can you post a screenshot of the code that you're trying for the subpanel? If you wire a path to the Open VI Reference VI, it will load the VI from the path you give. If you just give a VI file0name (with no absolute path), it will load from the current running VI's folder. For example, I just tested with the code attached. I have "C:\master.vi" running "C:\subVI.vi" in a subpanel. It works either with "C:\subVI.vi" or "subVI.vi" wired to Open VI Reference. (I made sure all VIs were out of memory before each test) As for distribution, you'll need to either make sure that if the user won't have the subpanel VI in the same folder, that your program accounts for this and asks the user to enter the location of the VI. That way, you can build the path to pass to 'Open VI Reference'.

I don't know about the hands free profile... but one thought is if you could find a device which supports the "Audio Gateway" bluetooth profile, your computer could see if as a normal soundcard and you could play audio like normal...

Jim, I find that the confirm works correctly and asks for confirmation only if you leave the file input unwired (to use the file dialog)... But you're right, it ignores it if you wire in a file name... :headbang:

Now that's a coding challenge right there! Create a program that reads a subVI, understands what it does, and then detect other VIs which do similar functions! whew...

It would be interesting if you could scan through the code and detect a "code sequence" that you use in multiple places -- something that could be made into a subVI...

When you say they aren't working, are you getting an error messages? One thought is that since the examples are using TCP port 2055 perhaps a firewall is blocking the connection (turn Windows firewall or any other firewalls you have enabled off). Are you setting the client VI with the right IP address of the server? You of course need to replace the 'localhost' string with the IP of the server.

A straight wire 32767 pixels long!?! I don't even want to know how someone discovered this...