Cat

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

Do you, by chance, add or remove devices during your application's lifetime? I had a big problem with that on a tester which paired and unpaired BT audio devices. I can't remember if we ever tested it on LV2012.

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.

Have you reported it to NI? I was thinking about sneaking in a LV2011 upgrade while my boss wasn't looking, but maybe I'll wait. Considering the problems I've had with the sound vis in the past, I'm a little gun-shy on this topic.

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!!

Just to clarify for others that stumble across this discussion. You can open references to VIs built inside an EXE by path but this is only possible from VIs running as part of that EXE and the path will be different than during development. That path difference makes this error prone and a bad idea, but it is possible.

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.

Sure! With gravy, a side of potatoes and peas.

My cat is fat

So now I’ll dine

And eat all up

This cat of mine.

-- B. Kliban

Sorry Cat - I fully support the concept that links in posts should be full, as there's no reason for them not to be.

No biggie! I learned some interesting things about .ly domains today. And it's always an eye-opener to see that big security warning. :-)

so we can see what stuff y'all are actually interested in. Apparently you like cats.

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!

I'm even worse (although I don't use a FG. Instead I use named queues) and only use strings for all my queues' data 1 VI for any queue anywhere within my code

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 thought it was odd that a patch was released for a version of LabVIEW which is not the latest, and by that I mean 2012 which was released a few weeks ago.

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.

I'll admit that the current top 10 has no killer apps, but it has several things that I would use on a daily basis to help me save time, either in development, or to better document my own code.

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

Great job!

NI often seems to be a bit conservative in their estimated shipping dates.

I'm keeping my fingers crossed that true here.

There is a Real-Time Deployment Library that allows to build in code into the host application, that can update, reset and restart a realtime controller from the host application at runtime. No need to have access to the cRIO over internet or to a LabVIEW development system on the host for upgrading the realtime part.

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.

You don't know anything about TrapWire, do you, Cat?

NO! No way! Uhh uhh. Not me!

(Besides if I told you, I'd just have to drown you.)

Have you considered to use the cDAQ-9188 instead? True it's about double the price of the cDAQ-9174 but it is shipping.

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?!?

The cRIO-9075 would be a little cheaper but you don't use DAQmx to access it, but instead place a realtime control programm on its integrated controller and transfer the data from there.

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!

What version of DAQmx is installed?

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.

This isn't a terribly complex API call, so I doubt you'll need this, but I had a play at it. The cluster should be typedef'd, but ehhhh. If you use this and your computer explodes, I am not liable, etc etc. I've only tested it on Windows 7 x86, LV 8.6 and LV2009.

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!

I have never tried out the adapters so I can't comment on them but the red X actually means disconnected I.e. I have seen this device before but can't now so I suspect nothing has worked through the adapters.

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.

I thought the adapters are normally only designed to work with specific classes of devices e.g. Mass storage, at the very least you would need some sort of local software to have it emulate a standard USB hub.

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.

Have you verified the Ethernet path is good (right kind of cable, etc) with something else?

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.)

Thanks for noticing, Jon and Shaun! I've posted a full report over here.

I thought I'd be able to slide in under the radar while everyone was off at NI Week. :-)

It's been a long 8 months. I spent last fall and winter fighting chronic sinusitis (finally gotten rid of by massive and prolonged doses of antibiotics, steroids, and practically every OTC medicine you can think of. Drugs are our friends!). Then my Dad was sick and I was travelling back and forth across the country to see him. Then there was the funeral and all that to deal with...

In the meantime, I had other groups clamoring for me to work on projects for them, and I find it really hard to say no. And the usual continual submarine stuff. So between ill health, personal travel, and work travel, I've had to keep my teeny little nose to the grindstone when I've actually been in the office. No time for playing professional development on LAVA.

But I have a little breather, for the moment. Mostly just mopping up and dealing with ever-changing user requirements on previous projects.

My big excitement this year was I actually got to play with hardware again, for the first time in years. Timing cards, A/D cards, etc. That was fun!