Cat

I agree, I was hoping that using a waveform data type was going to magically make all that worthwhile in the long run. But since a waveform is just a cluster... Thanks for reminding me about DVRs. I looked at them briefly when I upgraded to LV11 (from 8.6.1), but it didn't help the application I was working on at that time. This app might benefit. Huh. That is a little counter-intuitive. I think I am going to stay away from waveforms, unless there is a real driving reason to use them.

Short and to the point. Thanks! No, I'm not using RT FIFOs. But this is good to know if I ever do.

I have a vi that reads a bunch of channels of data, puts each channel into a cluster with some other information (sample rate, channel number, location, etc) and puts that cluster into a queue. Somewhere else in my program is a vi that reads the queue, pulls out the data and info and does stuff with it. Thanks to all the time I've been spending with sound vis lately, I've been working with waveforms more. I'm wondering what the impact on my code efficiency would be if I were to use the waveform data type instead of a cluster, and store ancillary channel information as attributes. My program is currently loping along doing the cluster transfer. But I only have 65 channels. I am about to start a system that will have 1300+ channels. So I've been going over code with a fine-toothed comb to figure out where I can make things more efficient (faster/less memory usage). My first thought is that using a native LV data type like a waveform to transfer data and attributes around is going to be more efficient than a cluster. Is that naive? Does it even matter? Using a cluster seems much more readable and easier to code, IMHO. But if using a waveform will help move things along better, that might be important for the new project. Any thoughts? Cat

Not programmatically, if that's what you mean. I did try various devices with no luck, but all of that was all via configuration files. All I can say is, if you had any issues with sound while running LV2011, try it with LV2012 and you may be pleasantly surprised. Or really annoyed that you spent all that time trying to debug something that was actually a LV problem. :-)

I remember reading on ni.com somewhere that there are issues with only getting 75% of requested sound. FWIW, I just fixed all my sound problems (both input and output) by upgrading from LV2011 to LV2012. lvsound2.dll seems to be the same for both (exact same # of bytes, anyway), so it seems to be something in LV2011 that just doesn't play well with sound.

So, I think I was having a senior moment this February when I completely forgot about this thread and "upgraded" to LV2011. No problems at first, and then I started working on a new project that included using DAQ hardware (USB-9234). When listening to sound, there would be 1 second clicks (the sample interval) and when hooked up to a function generator, there were what I call "stutters" -- when changing frequencies, the new freqency would play very briefly, the old frequency would play even more briefly, and then it would finally settle into the new frequency. Not good. The only upside was that the clicks and stutteres weren't in the actual data -- just in the sound output. I beat my head in on this for a week or so, and then finally lobbed it over the fence to NI technical support. They, of course, couldn't replicate the problem, so after a few back-and-forth exchanges of code, I asked the nice application engineer if he could test it on LV2011. Lo and behold, he finally hears the same thing I'm hearing. In the meantime, I'm trying to add microphone signal into my data stream and (surprise, surprise) have the same problem Martin does. This finally jogs my memory and I remember this thread. A little too late... So, I've upgraded to LV 2012 (NI's recommended fix). Much to my team leader's dismay, as our usual LV upgrade only happens ever three years or so. But I told him it was either that, or have very unhappy acoustic analysist. The moral of the story? Pay attention and remember this kind of thing when it gets reported on LAVA!!

This is the way I generally deal with multiple dynamic reentrant vi calls. I put the caller vi and the reentrant VI in the same directory level. Works with both source and EXE (with the caveats GregR mentions, I suppose). The benefit to this is I can reuse my calling program by just having the vi name (no path) as an input -- and inputs for "Control Value" and "Value" (flattened) of "Ctrl Val Set", if necessary. Very flexible. The only drawback I can think of is having to remember to include the vi in the build.

My cat is fat So now I’ll dine And eat all up This cat of mine. -- B. Kliban

No biggie! I learned some interesting things about .ly domains today. And it's always an eye-opener to see that big security warning. :-) LOL! Doesn't everyone? Firefox? Chrome?? I'm stuck with Internet Explorer 7, fer gawd sakes. But I will check into these add-ons for my home box. Thanks!

This is bad? Oops...

I can see two reasons for using sub-vis for this sort of thing 1) Cut down on queue wires going all over your block diagram. Of course, some folks would consider this sort of data-flow hiding to be a Bad Thing (kind of like overusing a local variables) 2) Other than that, I can maybe see a reason to have an Init vi. If you only have 1 queue and are using it in a lot of vis it would keep you from missspelling the name. But this wouldn't need to be a functional global, just an Obtain Queue primitive with a name (and data type, of course). It only takes 1 primitive to release a queue or enqueue/dequeue data, so it seems kind of like overkill to use a vi for those functions. So unless there's a messy wiring issue, while doing this in a functional global isn't "wrong", I'm not sure if you need to go to all that trouble. Unless of course I'm not getting the whole point of what you're doing...

I'm getting frustrated, thanks to some of you (Crelf!). I keep getting status updates in my work inbox about neat sounding LabVIEW-related things, but when I click on them, I can't access the site. Probably because all those shortened t.co addresses are aliases for shortened bit.ly addresses which is a domain controlled by the Libyan government. I have found a work-around, which is to replace the bit.ly with bitly.com. Big Brother hasn't caught up with that one. Yet. But considering the big security warning that gets displayed when I go to bit.ly I figure I'm better off following the spirit of the law in this case. Anywho, I understand the tweets should be shortened, but would you all consider putting full URLs in any actual LAVA posts you make? That saves me from having to get out my phone, type in the short URL, get the real URL and then copy it to my computer. Especially considering our personal phones are supposed to be in a lock box outside our offices...

Some of us have to fight to be allowed to upgrade. I went from LV8.6.1 to LV11 after SP1 was released, and that was only by using the, "It's easier to ask forgiveness than it is to get permission" principle. A fine Navy tradition. :-) So I'm happy to see NI sends out patches to "legacy" LV versions. (Of course I'd be happier if it didn't need them!)

Thanks for the heads up. "Searching for text in an enum that resides within a typedef will cause changes to the values within the enum" is particularily disturbing to me as almost all my enums are typedef-ed and I search some of them fairly often.

Exactly. Anything that helps me code more efficiently (and several of the top ten items would) is beneficial to my end user.

Great job!

I'm keeping my fingers crossed that true here. Really? Yes, the host application will get uploaded to a web site (or passed around on CD) whenever there's a new version. Hopefully I won't need it for this project, but cRIO is something to keep in mind for the future. Thanks!

I appreciate the condolences. Even when it's "expected" it's never really expected. Anywho, all I've really been missing in the past to take my CLD (other than the CLAD ) is some current hardware experience. So hopefully I can fit the CLAD/CLD exams in sometime before the end of the year.

More update: My local NI rep tells me that now the expected ship date for the cDAQ-9184 is this week! I'm not sure how that will work when there's still not a way to buy it, or even pricing, on the NI website. But I'm going to keep my fingers crossed NI isn't just blowing smoke up my skirt.

Well, maybe it's not "perfect". Would you take "good enough"? Seriously, thanks for the warning, Rolf. I'll take a look at these calls more closely when I get back to that project.

NO! No way! Uhh uhh. Not me! (Besides if I told you, I'd just have to drown you.)

I need this chassis to go into a box that can fit easily in a backpack. This box will also have a router and a 16 channel signal conditioning board with multiple gain stages and filtering. And power supply and cabling, etc. The 9188 has too big of a footprint for this. That's what I told the NI guy at NI-Week 2 years ago when the 9188 came out. That's great, but can you make it a little smaller?!? Hmm. I've never used cRIO hardware before. The only thing I can think of offhand that might be an issue is that eventually there will be 8 or 10 of these spread around the USA. Doing software upgrades would be a bit of a logistics problem if I actually have to lay hands on all the boxes. Anyway, I'll keep that in mind if all else fails. I really don't want to have to run both an Ethernet and an USB cable to this box. Thanks! I'm not sure where I find this. Does 2.7.0f2 sound right? It's whatever came with LV2011 SP1. An update: I've got an old AnywhereUSB hub that I tried using today. It works fine. The problem is, while it is USB2 compatible, it runs USB2 devices at USB 1.1 speeds. That's about 1.5MB/s (on a good day) and I need at least 6.25MB/s. So while it's not fast enough, it gives me hope there might be something out there that can do this. I'm just leery to buy Yet Another Converter, when I've gotten two so far and neither one works.

Talk about taking my time getting back to someone... asbo, obviously I never got a chance to try your code out. A few months ago I started getting complaints about longer than normal wait times on starting up my Big Project. Most of my users had recently upgraded to 64-bit Win7 machines. This problem was worse on those than the 32-bit WinXP machines. I finally tracked the problem down to a delay being caused when I opened a reference to a vi that was using .NET to get the available physical memory. Hoping someone here had solved this problem, I hopped on to LAVA, did a search, and ended up at this thread... I think I'm getting senile! Anywho, to make a long story even longer, I tried the code you wrote and it works perfectly, on both types of platforms. Thanks again!

With the 9174 connected to a usb port on my computer, I would see it and all the 9234s in MAX. I would then disconnect it from my computer. The 9174 entry in MAX would get a red x thru it. I deleted the 9174 entry. Then I plugged the usb cable from the 9174 into the usb-ethernet converter. MAX, without any prompting from me, would start its refresh cycle, and end up with the 9174 enty there again, but red X-ed. So the converter is doing *something* just not enough. Yes, I installed utilities on my computer to do something. Once again, I just don't think it's enough. The converter I have is for storage devices, printers, cameras, etc. Unfortunately "etc" doesn't seem to cover this NI device. Yup, I had been using that very cable in my computer just a few minutes before.

I so very rarely post in hardware. This is exciting. I have a cDAQ-9174 (filled with NI-9234 modules) that I need to talk with via ethernet. I have tried both a router with a USB port, and a single USB device to ethernet converter. Neither works. With both, I can see the 9174 in MAX, but it has a red X thru it, and the 9234s don't appear. Self-test, etc, fails. I've sent a request off to NI tech support for some help, but was hoping one of you all out there had already solved this problem. (I know NI is advertising a cDAQ-9184, which is the 4 slot ethernet chassis. But despite it being on their website, my local sales rep tells me it probably won't be ready until December. Grr... And I need this system for a test in October.)