mross

QUOTE (zorro @ Aug 7 2008, 04:15 PM) I guess "compatible" means you can generate a trigger signal that is digtal or analog without particular need for signal conditioning, amplification, or attenuation. You can probably do as you wish and assume that normal and simple to implement variations of the analog output will be sufficient. When the word "trigger" is used typicallyit refers to a digital signal (on or off with a fast transition) that adheres to the TTL specification (nominally 0V to 5V), or an industrial application which may operate betwen 0V and 24V. This is by no means definitive, analog signals can trigger as well, of course; but digital is used where something more deterministic is needed, such as starting an acquisition when a particular mechanical event has happened. You should be knowledgable of typical practices for field wiring and grounding to be a guide when you attach your DAQ system to the other hardware. The folowing is a good reference: http://zone.ni.com/devzone/cda/tut/p/id/3344

QUOTE (crelf @ Aug 6 2008, 08:33 AM) OK. I had a bunch of E Series VI's builtwith Traditional DAQ, when I replaced that board with an M Series I had to redo all the Traditional E Series Vis with DAQmx. I conflated that to get the incorrect idea that DAQmx won't support E Series. But really Traditional DAQ won't support M Series, my mistake. I haven't actually written DAQmx to support E Series so I spoke out of ignorance. Thanks very much for the correction. Mike

Use digital output to create the trigger signal.

QUOTE (zorro @ Aug 5 2008, 03:21 PM) Ok, there you have it, the DAQ card will generate a signal from 1V to 10V. I am sure you can contact an application engineer from ni.com and they will help you understand the specs. You should be getting this help if you don't have access to a qualified EE for counseling. You can ask specifices here and get some help. I would suggest that you make these things as easy as possible, no reason for your benefactors at LAVA to be looking up specs, if you can compile them and show us. Providing links was a great idea. It is good to know that you have an E Series DAQ board becasue this means the normal recommendations touse DAQmx VI's will be wrong. DAQmx is for M Series hardware. Please do not hesitate to tell us what hardware you have when every you have a question. Is the receiving hardware the same E Series DAQ card? It sounds like the generated signal is only a trigger signal. Is this correct? Or is the signal something more complcated. If you are triggering a progrram that is on the same computer and using the same DAQ card there should be no need to use extrenal wiring to trigger. Generally you would not trigger using analog output generation. Instead you would use a digital ouput which will be 0V to 5VDC. A simple relay or solid state signal amplifier would be used to provide a higher trigger voltage. You can use analog output, but it is possibly more trouble. Perhaps you could be more specific regarding what you are trying to do. Mike

QUOTE (zorro @ Aug 2 2008, 11:01 AM) The only difference is that you see the array at different times. I suggest you wire a create a second array so you can observe it as the VI runs. I temporarily create many arrays so I can see how the changes as the VI is progressing. The arrays are free of cost and you can delete them after everything is working the way you want. You can also right click on any wire and create a probe that shows you the contents as the VI runs.

Z, If you go to ni.com you can look up the specifications for the type of DAQ hardware you are using, then you can see what the capabilities of your hardware may be. It is worth noting that you have provided almost no information which would help someone to answer your question. What hardware are you using? What voltage do you wish to generate? 10 000V? 200 000V? 1V? What other program? On what sort of other hardware? Good luck, Mike

You did generate one, but the data is not passed to the indicator until you stop the loop. This is called data flow you need to learn how this part of LabVIEW works. If you turn on the light bulb on your block diagram you can watch the VI run and you see what i am talking about. If you right-click on the tunnel and choose Replace with Shift Register. Then place the other "end" of the shift register (SR) on the left side of the while loop. When the loop runs the data goes into the right side node of the SR, then the loop starts again and the left side node of the SR sends data out, and so on. You place a two terminal Build Array functions on the diagram, wire the random number to the lower terminal and wire the left side SR to the upper node; the right side, output node is wired to the rigth side node of the SR. Create an indicator on the output of the left side SR node and you can watch the array grow in that array (Which is inside the loop, it runs every time the loop iterates).

QUOTE (zorro @ Jul 31 2008, 02:07 PM) Investigate shift registers.

QUOTE (Xrockyman @ Jul 29 2008, 10:04 AM) For us to be more helpfull the block diagram or the actual VI is better to share. Without that information, I can only give the simplest advise. An XY graph requires an array of ordered pairs to make a plot. After all there is no regular increment between x points so you must provide the x datum information for each and every y datum. (x1, y1), (x2, y2)...(xn,yn) is the mathematical form, but the requirement is for a 1D array of x "bundled" with an 1D array of y --> (x1, x2, ...,xn) and (y1, y2, ..., yn). If you did not get the plot you desired you have only to look at the ordered pairs you sent to the graph to see that it plotted exactly what you told it to. This becomes a little more complex when you wish to plot more than one set of ordered pairs to a single graph - a multi-plot XY graph; but without any failure, if you provide the information in the correct format, and in the correct order you will get what you asked for. If you bring you cursor over the XY graph icon on the block diagram and the context help of LabVIEW is activated, you will see a brief descrition of what it takes to creat a single XY, and a multi XY graph. The multi XY graph is simply an array of valid multiplot XY data: Ordered pairs: (x1, y1), (x2, y2)...(xn,yn) and (a1, b1), (a2, b2)...(an,bn) are formatted to: 1d array [x1, x2, ...,xn] = [x] shown as a bold orange line 1d array [y1, y2, ...,yn] = [y] AND 1d array [a1, a2, ...,an] = [a] 1d array [b1, b2, ...,bn] = bundle 1D arrays together you have: {[x],[y]} = {x,y} bundle shown as a purple ladder shaped line and {[a],} = {x,y} bundle then create a single array of 2 bundles: [ [x,y}, {a,b} ] shown as a purple line with diagonal ladder rungs mike

QUOTE (ExpertQTP @ Jul 22 2008, 08:16 AM) Since I have never seen anything on LAVA quite this commercial, it makes me wonder what is the policy and general opinion about this sort of thing. My initial resoponse is that I find it intrusive, but perhaps that is a harsh and reflexive reaction. I dislike it greatly that the author has chosen to be anonymous. Without the anonymity, I might be OK with it, if there was a commercial forum to place things like this (maybe there is and I don't know of it). Or if the subject subject line clearly noted that the posting was commercial. Of course, I wouldn't subscribe to the commercial forum and would seldom look at it. And what are the odds that someone who has just joined LAVA and the first post is commercial would know about labeling subjects? So it is a gray area for me. It is perhaps a good idea to supoort the money making between us. The Info-LAbVIEW policy that commercial posts be mercifully brief seems to work, however, this one cuts it too close. We used to have a paid advert after every initial posting, that was really irritating. If I was trying to drum up business, but was instead engendering that reaction, I would not be achieving the desired result for the expense. Anyway, this posting strays from the usual mutual support and freely given help that we consistently see here. At best it seems out of place and at worst a bad idea. Mike

QUOTE (han_5583 @ Jul 20 2008, 05:40 AM) Buffered versus continuous is a software option - depends on the example you start with. I believe that all NI DAQ is buffered, if you want it. You do not need to DO anything to use buffered DAQ beyond using example code that accesses this function. The DAQ hardware has its own private memory on board that is the buffer. The PC is not involved in the buffering and buffering is transparent to you. With a buffered acquisition, when you press the run button the DAQ card begins reading and temporarily storing the information in a circular buffer. When the buffer is full the new data overwrites the old. This continues until the VI is stopped. When you "Start" the acquisition, the data already filling the buffer is output to the arrays and other processing software of the virtual instrument. You can "Stop" and re-"Start" the acquisition, but in reality all you are starting and stopping is the use of the data in the buffer. The buffering of the data continues whether you use the data or not. You have to Close the acquisition to stop buffering. This background information is all low end function that you may not need to concern yourself with if example code does what you want. You do not need to DO anything to use buffered DAQ beyond using example code that accesses the function. You need to simply find an example that has the function you need and try it. Do not over think this. Go to Help/ Find Examples. If you look for information about buffering you won't find much. That is because you are not supposed to worry about it. The common concerns are only at a higher level, like how big should the buffer be, is the buffer keeping up, and so on. You can easily skip over this at the start. The main distinction between continuous and buffered acquisition is performance. Buffered is better. When you use a continuous acquisition you force the software to leave undefined and open for increase the amount of memory it has allocated (there is a data array of unknown size that the program must be prepared to increase in size). With a buffered acquisition the memory is fixed and things can be more efficient. Generally, if all you want to do is watch pretty squiggles on screen that you react to at human speed, then continuous acquisition is fine. If you have computation and analysis to preform on the data, then you should limit the number of samples and use a buffered acquisition. You can use a large size and there is no great penalty. Acquiring the data in discrete blocks and processing it afterward is often best. In your case you need to count waves over a period of time and convert the result to RPM. You need number of waves, the time period, and the number of wave per revolution. Post processing an array is the simplest way to do it. You would run this repeatedly to get a constantly updating indicator on your front panel. Take data for a second, calculate the RPM, do it again and again. Go find an example that seems to do the thing you want and try it. First set up channels using the Measurment and Acquisition eXplorer (MAX) this way you can look at the data coming in before adding the complication of your own VI. This will save you some confusion. If you have a more current version of LabVIEW then go ahead and let MAX create tasks and use them. Regarding counters. You should also explore the ni.com literature on counter use. Everything you need to use the counters is there. There will be examples appropriate for the USB-6008 the show you how to measure the period of an TTL square wave. If your wave goes below 0.3V and above 2.5V the counters may be able to read it even though it is a sine wave. If is not readable as TTL then you will have to condition it to TTL for it to be useful and reliable. When you have the period it is easily convered into RPM if you know the number of cycles per revolution. BTW- it looks like you may be a student given the question and the hardware (which part of a student kit for classes in LabVIEW perograming). I am hesitant to spell out exactly what you should do since as a student you should be figuring this out your own. Also when communicating with LAVA for help, you should ALWAYS explore the example code and try to write something on your own to show us before asking advise. It really does not make sense for us to work harder at it than you do. Mike

I just read this snippet in a little noise reduction article from ni: http://zone.ni.com/devzone/cda/pub/p/id/26...amp;metc=mtpsh3 "For industrial applications, TTL has the inherent disadvantage of small noise margins. With high- and low-logic levels of 2.0 V and 0.8 V, respectively, [TTL has] little room for error. For example, the low-level noise margin for a TTL input is 0.3 V (the difference between 0.8 V, the maximum low-level TTL input, and 0.5 V, the maximum low-level TTL output). Any noise coupled to the digital signal in excess of 0.3 V may shift the voltage into the undefined region between 0.8 V and 2.0 V. Here, the behavior of the digital input is uncertain and may produce incorrect values." In this case we are talking about applying an analog signal to a digital input which is not always a bad idea if the levels are in spec, but signal conditioning is good insurance against errors that would be hard to notice. The op amp comparator could be between 24V and 0V rails as well as between 5V and 0V. Of course you need a DIO board that has 24V digital IO to make it useful, but it is the way to go in a noisy environment. You would want to make very certain there is no confounding noise on the IR sensor output to the op amp. Mike

QUOTE (AnalogKid2DigitalMan @ Jul 16 2008, 02:25 PM) Oops, I missed that. The TTL spec will only call it low below 0.8V. And only call it high above 2.5 (I think). My experience is the ni counters are exeactly to the spec so 1.8V wil NOT be seen as a low signal. I would make a threshhold detector of a basic op amp comparator operating between 0V and 5V rails. Set Vref to the voltage of the signal above which you want to the output to be high and below which you want the output off - for example make Vref 2.5 volts. The comparator will put the high rail on the output above 2.5V and it will be ground below 2.5V for a 50% threshold: 50% * (3.2 - 1.8) + 1.8 = 2.5V. Sorry, if you are an EE and already know this by heart. Mike

QUOTE (han_5583 @ Jul 16 2008, 09:41 AM) You can use a counter to measure the time period between pulses. There are examples on how to do period measurement with counters. OR You can acquire the analog voltage and measure the time between the pulses the sensor produces. This is normal data acquisition and you should first consider a buffered acquisition not continuous. You can repeat the buffered acquisitions to produce a quasi continuous output of RPM. The conversion from time in milliseconds to RPM is fairly simple. (X milliseconds / time between falling signals) * (1 minute / 60 000 milliseconds) * [(time /rev) / (time between rising signals)] = X minutes / rev 1/X = RPM If you use the counter method the falling edges are much less prone to noise problems. Mike

QUOTE (photon_guy @ Jul 15 2008, 08:09 PM) I am not familiar with photons, but are not most diffusion phenomena Arrhenius functions? http://en.wikipedia.org/wiki/Arrhenius_equation

QUOTE (Xrockyman @ Jul 14 2008, 07:01 PM) The set up you have is sort of a one shot. You see that initial count control? That has to be redone so you must expand the VI to a lower level to find that function and get it inside the loop. You will also need to institute a Stop function inside the loop. The simplest thing might be to look for a different example that extends the VI to be reset, or another counter VI that resets to get an idea. (I apologize, but I haven't used counters much with DAQmx). This is point where I would start using an Event Driven Queued Producer Consumer architecture. You have a fast machine operated function (counting) and a slow human input GUI function where you pick on screen and it resets and perhaps begins or waits for a signal, this is what the EDQPC is designed for. Mike

QUOTE (Xrockyman @ Jul 14 2008, 11:58 AM) Please check the following in this order of priority: The counter must be wired correctly. The signal must be correct. The channel must function. Then finally, the VI must work. Be certain that you have correct wiring to the counter. There is a note in the Block Diagram directing you to information about correct wiring. The signal must adhere to TTL specifications (if it never rises above 2.5 volts, or never drops below 0.8 volts there will be no valid change of state to count). Any mechanical switch used in this way will need electronic debouncing. The counter is sensitive enough to see the contacts settling, even if the time is very short. This will produce many counts instead of one count - therefore this not your current problem, but you WILL have this problem without debounced switches. You should set up a task using (MAX) Measurement & Acquisition eXplorer and be sure to test the task and circuits in MAX before procedding to use the channel in a LabVIEW VI. If you successfully get the counter to work in MAX then we can talk about how the VI is operating. Good luck, Mike

Space issue...this is the fault of less than optimal coding preactice. I don't see a single sub-Vi on there and that is wrong. Very hard to read and hard to trouble shoot. You should make it a point to encapsulate functional sections of the code into sub-Vis. I understand that it doesn't add much value relative to proper coding up front, but it may have some merit just the same. When writing new code you should become familiar with the practice. Mike

QUOTE (Gary Rubin @ Jul 3 2008, 01:12 PM) I suppose you are right - sort of. Since you must have more than one datum to get rate of change doesn't that make it always post processing? And you can't rotate an array until you have one. Hard to beat the derivative for real estate. I tend to do everything as post processing so it slipped my mind that he was sounding like it was on the fly. Another good reason to post code. No misunderstandings and no benefactors wasting time. As for on the fly, using a shift register to save that last datum allows one to calculate rate of change as each new point comes in.

QUOTE (solerpwr07 @ Jul 3 2008, 10:31 AM) OK. Actually a shif register is not needed (but you should learn about them). Here is how to take an array and calculate the rate of change between points. I faked up a sine wave, calculated the slopes, put them together with the sine wave an show them in a graph. But the easy way that doesn't teach much is to take the derivative. It is kind of a dirty trick, but you will have to create all this yourself. Your penance for not posting your own code, so to speak.

Welcome single poster, Maybe I am paranoid, but this sounds like class work. You should be showing us what you have done (attach code or screen dumps of the block diagram) to encourage us that you are doing real work rather than trying to get a leg up on your classmates. I will give you a hint though. You need to understand and use shift regsiters on your loop structures. Then you must understand how to feed more than one plot to a chart or graph. All the information you need to do these things is part of the regular help and example code of LabVIEW. There are also a comprehensive knowledge bases that you should learn to use at ni.com. Best regards, Mike

You said the word assignment. Good to own up to that because we'd know it without asking. It is the typical "not real work" stuff you see in a programming classes. Not many of us care to do your school work for you, nor should we - it would be a diservice to your collegues who are doing it alone. Showing us an attempt at your own work will help a lot in getting help. You should begin by introducing yourself to the help, tasks, search, and example code in LabVIEW. Also the knowledge bases at ni.com. Everything you need is there. I suggest you start out by creating the Front Panel first - the indicators and controls you want to use. That is often the first step in working for the customer type work. It will help you sort out the indicators and controls you will need. Then a block diagram or functional description that is a bit more than you gave. Mike

QUOTE (tnt @ Jul 2 2008, 07:44 AM) Hey, I never thought of that, but it does work. A standalone computer...I guess you could set up a network on it even if no others are connected...

QUOTE (Dirk J. @ Jul 1 2008, 03:36 PM) Complaints about noise are always themselves noise, now I have added yet another.

QUOTE (rharmon@sandia.gov @ Jul 1 2008, 08:05 PM) Out of the box, but supports moving on quickly: You could buy an E:drive for $60 and be done with it.