peteski

Sven, I was thinking about it while listening to the radio in the car this morning, that in theory what I was doing in the car seemed to be quite similar to what you seem to be trying to do. It would appear that if you had an FM (Frequency Modulation) receiver that could go down to 17 MHz (my car's FM receiver bottoms out at 88 Mhz ) and a "sound card" capable of continuous recording, you might have something that looks like a solution. Just a thought... -Pete Liiva

Sven When reading data continuously, the devil is firmly planted in the details and waiting to trip you up at any moment! For instance, is your waveform triggered? What frequency is your trigger? What is your sampling rate of your waveform? How many points do you need? Do you need to capture every triggered waveform or will a "representative" sample of triggered waveforms do? And do you plan to do any in-situ analysis of the waveform or just stream them all to disk? Does "reading data continuously" mean for a few seconds, minutes, hours, days, weeks, months, or years? Once you have done this analysis, you then must consider your scope and the modes it operates in, the buffers it has, and the data throughput of its interfaces (especially the interface you are poised to use!). For instance, 24x7 raw gigahertz measurement, 100% duty cycle, for even just one channel, and expecting to pipe it over a GPIB interface, is losing the battle before beginning! (I don't mean to imply that the above example is what I think you are doing, its just my way of illustrating an extreme situation.) BTW, I can't look at your vi, as I'm still sticking with Labview 7.1.1. I'm unwilling to even touch Labview 8 until I see a LabView 8.1 version! (old habit born of getting way too many Labview n.0.n bug bites! ) -Pete Liiva

tirhoads, Your example "screamed" to me for this subtle modification. Hope you like it. Mind you, it depends on the following path\file existing: C:\WINDOWS\system32\oobe\images\clickerx.wav Three Windows XP machines I had quick access to here have this path\file. My sincere apologies to any Mac and UNIX users, but I assume similar sound system calls ought to exist for those platforms so you can insert your own favorite *click*. -Pete Liiva Download File:post-2931-1143592156.vi

Yes, at which point a second card might be an interesting option. Acquire on one card as you download from the other, sort of a "rich man's" double buffering, to bastardize a term Of course, then, some consideration has to be taken into account for properly balancing the split signal, as not to distort the original signal. And then there are signal losses, and maybe some other issues I'm forgetting at the moment. -Pete Liiva

I've never dealt with Gage, so its good to know to be on the lookout for this! I know that if certain things aren't implemented well in the dll's, what might be good in the hardware specs can go to waste in the "bottle necks" created along the way. But still, even if double buffering is not happening at the card side, specifically in this application it might not matter too much, since it would seem there is a 2% duty cycle to the acquisition itself (20 usec every 1 msec). If the dll seizes the control of the CPU from the start of the request for data until the moment it is tranfered to memory, then that would be a royal pain in the...! Regardless, I agree with you that keeping the data acquisition loop as lean as possible is simply the best bet! -Pete Liiva

Yes, I fully agree! Been there and done that, and have a couple of T-shirts as a result (yes, literally! ) In fact my avatar happens to be "loosely based" on the program I did that for. It was my full immersion into queues for a variety of aspects of a test and measurement system. TCP/IP is something I had played with prior to that project, though. Its a fantastic protocol and for my purposes, I find its well implemented in LabView. I would tend to try to start out with a parallel loop on the same machine first, though. It requires just a little less development to implement and less equipment. Maybe with the new gigabit NICs you can stream all that raw data (1 Gbits per second * 0.4 "empty" network efficiency / 8 bits per byte = ~50 MBytes per second, hmm... not bad...) but you need to be aware of whether you are using a xover cable, switch, or hub. Most importantly in such a case, IMHO, is to keep the network between these "lab" machines disconnected from all other machines, and especially the Internet! -Pete Liiva

I'm somewhat surprised that full 1 GHz is necessary for for an ultrasonic non destructive testing application, but then again I'm used to the speed of sound in air (much slower then in solid, I hear! (all pun intended )) and I imagine you are trying to pin down the edge (and phase?) of some form of echo pulse(s). Sounds like a neat project! :thumbup: Again, I suggest that if you want continuous Daq, don't decimate or analyze in the same loop as the Daq is occurring in. Because of the onboard FIFO of the card, if the code interface calls are set up properly, while the acquisition is occurring your PC should have a little "free time" on its hands to try to accomplish tasks. If your analysis tasks are in a parallel loop, then those tasks can happen while the PC waits for the next data dump to come out of the card's FIFO. If you don't do it in parallel, the PC has to: (1) ask for the data (2) wait for the data (and maybe wasting CPU cycles in the process!!) (3) receive the data (4) then do the analysis (5) maybe then occasionally update a display (6) then it can come back around and go back to step (1) Best of luck! -Pete Liiva

Well, it sounds like you might have half the challenge behind you, and half the challenge ahead of you. Without knowing your particular display needs, its hard to give specific advice, but I'll shoot off some "random" suggestions non-the-less. 20MBytes/sec of information is obviously alot for the "average human being" to digest, visually. Consider your analysis carefully, and then decide what really needs to be displayed to the user "real time". Keep in mind that a user is unlikely to be able to keep their attention to a screen for more than maybe a minute, at best, on a good day, with just enough but not too much coffee, etc. You may be able to use these facts to your advantage. I'll guess that you have waveforms of 20,000 points each. Your monitor is on the order of about 1000 or so pixels, so you could bin your waveform into one of less than 1000 points, and then keep track of a max, mean, and min of each bin. It might be possible to do that fast enough, but it means being very careful in how you do your operations. Additions are quick, but multiplications are slow, at least at these timescales. You should only update the screen at the fastest once a second or so - anything faster may look sexy, but its not going to impart enough of a lasting impression. I'd strongly suggest going with the two parallel loop shared queue solution, with your analysis in one loop and your daq in the other. It might be possible that you would then have a third parallel loop, which would be your display loop, that would share a display queue with the analysis loop that would be fed "well distilled" information once a second or so as an indicator of what is going on "under the hood". Do NOT try to display OR do data analysis in the data acquisition loop, please. I'm taking a wild guess that this is what kicks you into the 2300-2400 msec range. If you need to display, feed a queue and let a parallel loop eat from the queue and let that loop do analysis, update the display, take out the garbage... Displaying and data analysis in the data acquisition loop is fine at slower, more pedestrian applications, but it will simply not do for high speed applications such as the one you are working on. I hope this helps! -Pete Liiva p.s. Is this a LIDAR application? It sounds not entirely unlike some things we do around where I work.

Hmm... I don't think Labview RT is going to do a bit of good, I suspect that there would not be any drivers for this board. Perhaps the "state machine" is not doing what you need it to do. For DAQ systems I prefer a two parallel loop process with one loop simply doing nothing but acquiring the data and stuffing it in a queue, and the other loop feeding off of the same queue as fast as it can. Here is a quick and dirty idea to see if you even have a chance. Try a simple loop where you acquire the data at the rate you intend to in real life, and do nothing with it. Put in the loop the bare modicum of timing checks to see if things loop fast enough to imply that the data is being acquired that fast, and maybe set a display outside the loop to look at the last data set acquired AFTER the loop is terminated to verify that you were getting real data. Forget about the state machine, data processing, etc. Just initialize an array fed through a shift register to the 20Ksample size and replace that over and over. If you keep it simple enough, you ought to see if it is even possible to do what you require with your setup. Would you be willing to show your code for people to look at to see if there are any "gotchas" in the diagram? You might want to do screen captures, since the code for your code interface calls will typically be a pain to properly transfer with the actual vi if you posted that. -Pete Liiva

I'm afraid that if nothing is done soon, <customise this text> will be the equivalent of "The Big Kahuna" for all intesive "porpoises" ;-) AND, I am must congratulate and thank Jim on his contributions. AND, without doubt the same goes for Michael Aivaliotis AND, of course kudos to all of the other gurus who make this happen. (wait, should those really be OR statements? Sometimes I get so confused?!? ) -Pete Liiva

PaulG, Would it be possible to tell us the hardware you are using? 20MBytes/sec of sustained/undisturbed transfer for an undefined amount of time is likely to be an issue for a Windows based system, UNLESS there is a "generous" application of buffering involved. -Pete Liiva

didierj, YES!!! I've DONE this step on many a work computer from time to time, followed by the obligatory (at least in my case) "reinstall Windows Operating system". I want to do that at home, but I unfortunately bought a HP PC a couple years back without the original Windows software disk (just a recovery partition and disks), and with XP Home, and if I reinstal I'm afraid I'm going to have all the $#!+ that HP shipped with the thing. I've been looking for the justification to pay for the XP Pro upgrade so I could start fresh, but haven't decided to spend that money at home (yet). As far as I can tell, a fresh format and reinstallation is the only way to gain back all the previous performance. Windows does not age well, I'm afraid. -Pete Liiva

Oh my god, I remember when Labview didn't have Undo, and then did! Or is that Undid the no undo? I remember being at a Labview Users Group Meeting at a MacWorld conference in Boston around 1994 or so where that was the "hot button issue" of the meeting (as in why no undo). Boy, that brings back memories... So does the Labview 2 box, I'm forced to admit... I feeling a little old right now... Time for a senior moment or something... -Pete Liiva

I agree with what Louis said, and would like to add that if you have an encoder that gives a pulse once per RPM, there are specific concerns as to accuarcy depending on the speed in RPM of your motor and the clock rate of your counter, etc. An encoder really is a position measurement, in theory, and velocity is a derivative of the position measurement. Performing a derivative function tends to dramatically decrease the "signal to noise" ratio, so sometimes a modest amount of filtering can help. With the 3 Volt and 8 Volt pulses going into counter/timers, I'd suggest a quick check of the counter input characteristics. If you were going into typical NI hardware, the 3 Volt pulse might be at the hairy edge of triggering properly (typically on the low side for TTL or CMOS logic, 5 Volts is more "nominal") and 8 Volts is a bit high, so check the specifications to be safe. -Pete Liiva

pbrooks, I'm looking foreward to checking these out when I get back to work on Monday. I use the Enterprise Connectivity Toolkit for this sort of thing in one aplication right now, but a trick like this could be very useful in places that have not purchased that toolkit. As an aside, a long time ago in a job far far away, I developed a labview vi which allowed to do TAP/IXO protocol, which is what alpha-numeric pagers use to use. I gotta say that it was a fun thing to do, I loved the following part of the protocol documentation that I found on the net: TRANSCRIBER'S FOOTNOTES: {1} It lies. All the way through this document, it lies. Gotta love truth in advertising... when you can get it, that is... -Pete Liiva

Ah! But is not the code simply hidden in plain sight here? And none-the-less elusive, proven by nothing less then example itself? Is it perhaps really the code "behind" the code that matters... In a box? With a fox? -Pete Liiva

alphaone, I'm sorry, but in Labview, the way you have diagramed it, is the "Basic" equivalent of: i = 0 j = 0 for k = 1 to 100 next k input l if l = 1 then m = j else m = i no matter how you cut it, you still get zero, but no matter what you do you have wasted 100 loops getting nowhere... However, if you want to branch and conditionally decide if you want to go nowhere FAST or nowhere slow, the folowing diagram will get you nowhere at your desired pace. Download File:post-2931-1133504940.viRegards, -Pete Liiva

How about "The number of elements, down trodden under the sum of the elements, will ultimately mean a division of classes" Oh wait, sorry, that’s not irony, that’s absurdity... I think... How about "Labview Programming is restricted to being in the box" Or more simply put "Labview means programing inside the box" That could be extremely ironic if you consider This Topic

Maybe, but on the other hand if the array is empty, instead of "Mean Joe" we may have to call him NaN - not that there is anything wrong with that... -Pete Liiva

laksa, Yes, I agree with you that the RTSI cable will allow for synchronization of signals between the PCI-6602 cards, but it won't help with the PCI-6509, as it does not have a RTSI cable interface (or at least it appears not to on the NI Website <- click for link). If synchronization needs only to be within an order of magnitude or two of 1 second, the RTSI cable is not really necessary, all the synchronization can be done through software and careful application of either "Get Date/Time In Seconds" or "Tick Count (ms)" calls. HOWEVER, if millisecond or better synchronization is required, it will be critical to get these cards running on the same clock, whether it be an internally or an externally supplied clock pulse. Also, if greater than 1 millisecond synchronization is needed on a large multitude of Digital Inputs, the PCI-6602 may not be the best choice. It seems to me that the card is designed as a multi counter/timer card first and as a DIO card second. And though the counter/timers could be used as extremely well synchronized Digital Inputs, in this mode you would only get 8 channels per card. Mind you, sometimes the best tool for the job is the tool you have, as opposed to the tool you can't have, depending on your budget, time, and management resources -Pete Liiva

Ayumi, At a rate of one event a second, synchronicity should be quite easy to do through software. If you start getting to a rate of one event per millisecond or faster, much greater care may be needed. Next question is do you need to trigger off one of the digital inputs, or do you want to asynchronously sample the digital lines with respect to their events? -Pete Liiva

Ayumi, Without even an order-of-magnitude estimate of the tolerance to which you need to synchronize, it is impossible to provide much advice. It's a completely different matter if you have to synchronize things to a tolerance of say 12.5 ns (which is the smallest time period potentially resolvable by the counter/timers on the PCI-6602) vs. synchronizing things to a tolerance of 1 second. And all the orders of magnitude in-between imply different trade-offs. It is also important to provide information as to whether you need counter/timers or DIOs synchronized, and if you are using DIOs, how many are inputs, how many are outputs, and if there are outputs which need to react to the inputs. -Pete Liiva

Oh yeah, that's a biggie. That was the third thing I was going to mention, but held back only because I don't think that it affects the boot up of the system. I found that forgetting to replace the lvalarms.dll would cause the system to hang whenever I downloaded to the RT system an application that had any of the RT Timer functions in it. It would hang during the download. I seem to use the Timer functions alot in the small amount of real time environment development I've done up to this point. :headbang: I'm going to take a stab in the dark and say that I think that if the system seems happy(ish) booting off of the floppy, that the chipset might not be the problem. But, as always, YMMV. -Pete Liiva