mross

QUOTE(PeterB @ Nov 9 2007, 11:00 PM) I am one of those guys with an event driven P/C hammer. To see what my VI is up to, I put a string indicator for each action loop on the FP and write the case name to it. I could imgine doing this with a cluster similar to the error cluster which contains a status boolean or similar. Of course I never put this write operation in any fast running loop. If I wanted to know about the status of some fast loop I would write to an indicator only when it starts, when it pauses, or stops. That is crazy talk what he did with the LED indicators.

QUOTE(bono02 @ Nov 11 2007, 10:57 PM) Greetings, 1)These are architectures designed to fulfill specific needs. That is not an exhuastive list either, there are plenty more options. It is probably too soon for you to be worrying about them. See item 2. You have not provided enough information about the top level funtion for anyone to give you a sensible answer. I advocate that if you don't know what you are doing, then explain the basic needs to be met by the program, and what decisions you neeed to make based on the results of the program. If you assume too much about how the task should be done, you may get answers for the question, but maybe not the best overall solutions. For example, say it like this: I need to position the following components so they can be assmbled together and fastened by the following techniques, then I must verify that the assembled form is within the following specifications. I will need to verify dimensional compliance to pass or reject the assembly, and I need to activate the assembly, acquire voltage data from the following transducers operting at the following levels, and current data from this one. The fasted acquisitions will be done at the following rates. Then I must analyze this data in the following manner to provide the following dynamic responses for immediate graphical display and review by a human. The human can react in the following ways to the graphical display. Two responses can be evaluated by the program without human review and the following actions initiated based on these responses. The data must be recorded in such and such a form for record keeping only. The front panel must provide the following controls and indicators for user interaction. Say it like that and you will get higher quality answers. Based on your comments I would say use the producer consumer becasue it is very flexilble, very orderly, and with modifications allows for human interaction, and I just like the P/C architecture and am familiar with it. Since I really don't know what you are trying to do and there could very well be better ways to do it. Whether or not you are storing the data and the size and format of that data are very important. How fast you are acquiring data or issuing commands is very important. Do the motors require active control? Will they just follw a script? Whenever there is motion you have safety concers to deal with. 2) This is how I would proceed. You must eat the elephant one bite at a time. Regardless how you package the various functions, you need to get these functions to work first. The control of the motors can be programed without the use of the top level architecture. Make smaller Vi's to become sub-Vi's for the top level later. Get your hands dirty with the details immediately. Pick a simple task and learn to do it. Pick another and do it, repeat. Expalin in detail small parts of what you need to do and ask for help. Read the forums at LAVA, infoLabVIEW and at ni.com. 3) You may want to change your display resolution if you have trouble reading the code. However I use very high resolution to get as much onscreen as possible. I am near sighted so it is not a problem for me. You can't zoom, but if you learn to develop the code using subVI's drilling into those is equivalent to zooming. You will become accustomed to it and you will come to see that it is not not a hardship. Windows does have a magnifier, maybe you will like that (doubtful). 4) no Mike

QUOTE(EJW @ Nov 9 2007, 12:22 PM) What you are describing sounds like it could work. There are some problems that can occur when you put a lot of code in an Event Structure, if you avoid them, who is to say there is something wrong with the idea? The two problems I find are if the code in the event structure takes a long time, then the user may load up the queue with commands while pecking around trying to get a reaction out of the software. The other is in getting a particular event to stop if vi's are cranking along inside it. This will hang your vi nicely. The more complex the code becomes inside the structure, the more likely it is to have problems that are hard to debug. The Event Structure isn't deterministic, so it is fairly easy for unforseen combinations of input to cause trouble. My favorite application of the Event Strucure is a producer consumer form with queues communicating between the event structure and the non-UI loops. Most of my work with labview is making instruments that need manual control. I am usually automating a variety of DAQ, storage, analysis, and display strictly for my own purposes. What I want in the end is often not apparent when I start. The event driven P-C form is very flexible expandable and predictable. In this form the event structure is taking care to slow inputs from a human. I may have several activities underway in parallel loops. A state machine like you describe wouldn't be as easy to develop for these applications. Anyway, I am not going to start loading up event structures. I've had enough of trying to figure why my vi is locked up. Mike

QUOTE(JDave @ Nov 1 2007, 06:56 PM) I get to play with those things for which I can claim some ROI. If I can't make a case for it I have to go open source or make do.

QUOTE(TobyD @ Oct 30 2007, 06:25 PM) That is nice. Much less trouble than my example. I knew there had to be a better way. Though as I was looking at it I kept thinking, I wouldn't trust that - running the loop every 1ms, clearly it works for lighting 3 booleans. But the loops aren't independent so if one light operation runs slow, it would hold up the others. Dataflow and all that. I added a subtraction between the start and finish millisecond times for one lamp and monitored how close to the commanded time the iterations were running, and it wasn't just so. Adding a delay to the on or off case is seen by the subtraction. Adding a large enough delay shows that one loop running slowly messes up the other automatic functions. If there were 8 Write to Line operations would it keep up? If one of the write operations were taking longer than 1ms the timing would be off by that amount every iteration. That wouldn’t be much of a problem for lights that are lit for minutes - as long as the writes that don't change state are all less than 1ms. But if there was a lag for no change operations, then that would accumulate and might cause the automatic function to be off. For example if one Write to Line took 1.5ms, then each iteration would casue a 0.5ms lag and 1.5ms/iteration cycle time. Over the entire on or off time that does add up. Say you had a light on for an hour that 0.5ms would add up to 30 seconds delay. It would be possible to test for no change and skip the write if it isn't needed. That would solve any pernicious lag problems. This is a good and elegant solution as long as some stray delays don't add up in the long run. Mike

QUOTE(gronfelt @ Oct 28 2007, 03:01 AM) I checked the upload and saw that it omitted the queue control and a couple small utility vis. So ignore that. Still not right ---try the upload called Light Experiment Folder.zip Nobody jumped all over answering this becasue it isn't exactly simple to do. There are also other ways to do this. This just happens to be how I think about it. I hope someone offers up another method so I can learn myself. ========================== So here is what occurs to me. You need independent functions, but what you have described sounds like it has no parallel operations. (It never hurts to show us what you have done when asking for help.) Assumptions: There is a default mode that the lights each follow a default on/off shcedule unless operation of the channel is set to manual. User input is required to activate and terminate manual mode for a light. When the manual mode is terminated, the individual light returns to the default schedule. If the scheduled on time for a light is set to 0 then the light is off, if the off time is set to 0 then the light remains lit coontinuously. When manual mode for a light is activated, the mode is only achieved after the light is turned off - if the light is on, its on duration must complete before the manual mode can be activated. You have the following controls on the FP: One boolean toggle switch for each light channel that toggles between on and off that is used to activate and deactivate manual mode. Two numerical controls for each light, one of which sets the on time and the other off duration. A Stop All operations boolean push button. Uploaded is a file called Light Experiment.zip ====================================================================== What I have provided has only 4 loops, you can do the necessary grunt work to make it do 8. I have not bothered with the actual write to line functions that will command the digital lines to switch state. I just turn on an off the lights on the front panel. You can substitue what you need in the Automatic and Manual cases where that code would go. It sounds like you have already figured this part out. The VI needs a little (heh) explaining. If you have not used queues, you are about to get educated. A queue is a FIFO buffer. You get to define what goes in the queue - in this case I have made the queue elements to be an ENUM. The User Event structure loads the 4 queues that run the 4 parallel loops with the value of the ENUM. Every time a function loop runs (as opposed to the user event loop) it reads its queue for either the Manual, Automatic, or Stop All commands and performs prescribed operations in the corresponding case. If there is nothing in the queue it just waits until a command is placed there. This is what is called the "user event driven producer consumer architechture." It is an excellent way to run parallel functions that are sometimes commanded by a user. The paralle loops can also be machine driven - reacting to information from transducers and in response to analysis - not human driven. This is a pretty straight forward implementation of this architecture, but it is not trivial when you have many loops running as you can see. Some important things to note: The VI that times the loops is set to be re-entrant. If it is not re-entrant then the many calls to the VI conflict while trying to access the same shared subroutine. Re-enetrancy allows that each instance stands alone and does not interfere with the others. Rentrancy is set by accessing the Vi Properties/Exectution of the "Wait for Multiple with boolean pass through.vi" subroutine. This vi is a simple wrapper that allows the re-entrancy and the pass through allows control of the data flow and sequencing without resorting to sequence structures. Observe that I wire the boolean for the light through the Wait vi. The wire then sequences the operations. If you aren't clear on data flow "sequencing," ask about it. The logic that manages the Stop function was a head scratcher for me for a while. I never used the x.implies.y before. There are error cluster wires routed all over that are not necessary, but I have a habit of putting these in as I go along. The wisdom of that is another lesson. OUt of habit I release the queues when all is finished. If you have any questions, just ask. Enjoy, Mike

QUOTE(brianafischer @ Oct 22 2007, 10:14 PM) One simplification is to take all the data at the fastest rate needed and simply display the results in whatever decimated, smoothed or averaged form provides the the best utility for the human operator. This only makes trouble if the readings are not all analog voltage. For instance a mix of serial, analog and digital complicates things considerably. You say that the output and interface is reports. This implies there is no real time or even quasi-real time response needed from the operator. This also simplifies things and all the data may be post processed. You have two regimes with very different time scales. The Producer Consumer architecture is designed for this sort of situation. If you aren't familiar with it you may find it useful. Numerous parallel loops can come in handy, don't shy away from the idea of introducing another loop. It is what LabVIEW is good at.

QUOTE(brianafischer @ Oct 22 2007, 08:11 PM) I guess I was too cryptic, by "higher level" I meant, What is the top level goal? Removed from any real world context it is like a class assignement or something. What is the point of this? What is the data about? Is the analysis strictly eye to brain (why else smooth the data?)? What decisions will be made from the result? On some level an acquisition tells a story. Mostly the stories mine tell are where and how does this hall effect sensor respond to changing flux. Or when I vary the pulse width of this signal how does this actuator change its angular location, and what are the secondary conditions that may impact this? A favorite I remember on another list was, What is the amount of urine these mice produce, and when? I never did hear how that turned out. Truth is I still don't get it, so I can't say what you should do. I can't do better than Yen's answer, which is a general recipe that could work. Do you still have a problem with the idea of a circular buffer and how that fits into the scheme of things with LabVIEW? Mike

QUOTE(brianafischer @ Oct 21 2007, 11:10 PM) Pardon me if you already know this. A circular buffer is the best way to aquire data in the majority of cases. It allows the hardware to go about its business in the manner is was designed. There is nothing to it either, it is how all the buffered aquisitions work, it is nothing special. I am assuming your aversion to it is coming from a lack of experience. Yen could as easily have said "do a buffered acquisition." Usually acquiring buffered data and post processing it offline from the acquisition is the most useful way to operate if there is no feedback step. It is OK, and often much simpler, to take great gobs data and parse it later. Your description is kind of hard to follow and seems to be making a simple problem hard. Could you describe at a higher level what you are needing to do without assuming what the best way to do it may be? The lack of replies probably reflects the complicated presentation of your questions. Mike

QUOTE(rpursley @ Oct 11 2007, 03:32 PM) We were all missing it. He has the magnitude and two angles phi and theta. It is 3D in spherical coords. It boils down to the angle between two lines in 3 space, which is l1*l2 + m1*m2 + n1*n2 where l = cos(theta1), l2 = cos(theta2), m1 = cos(phi1), m2 = cos(phi2) the angles to the z axis has to be calculated to get n1 = cos(gamma2), n2 = cos(gamma2) using the law of cosines is easiest for this cos^2(theta) + cos^2(phi) + cos^2(gamma) = 1 so gamma = (acos(acos(1 - cos^2(theta) - cos^2(phi))) and so on. Might be a dot product for this too, but I have never used such. Mike

I was taking phi to be length and assumed you were doing polar reather than spherical. You didn't mention the vector length so I thought is was an easier problem. Lot's of bookkeepping, not trivial, I see now. So you have to ignore what I wrote.Sin(phi) is wrong, I meant to say sin(theta). Sorry. Now I get it, maybe I have what you want somewhere. I don't want to derive it on the fly since I am demonstrably bad at that, eh? M QUOTE(dthomson @ Oct 11 2007, 02:03 PM) OK. I have the CRC in front of me now. Quoting now [my stuff in brackets]: For the line P1(x1, y1, z1), P2(x2, y2, z2) [where A, B, and © are the angles from the x, y, and z axes respectively, you don't have ©] [d is the vector length] [x1, x2, y1, y2, z1, z3 are projections onto the the X, Y and Z planes of the line end points] [d = SQRT((x2 - x1)^2 + (y2 - y1)^2 + (z2 - z1)^2)] l = Cos(A) = (x2-x1)/d, m = cos(B) = (y2 - y1)/d, n = cos© = (z2-z1)/d The Releationship Between Direction Cosines : cos^2(A) +cos^2(B) + cos^2© = 1 [looks like you need to calculate angle © from this to get n] [the editor is making the copyright symbol out of parenCparen and I don't know how to escape it :-( ] or [simplified] l^2 + m^2 + n^2 = 1 The Angle PHI Between 2 Lines with the Direction Cosines l1, m1, n1, and l2, m2, and n2: PHI = l1*l2 + m1*m2 + n1*n2 That seems to be all you need. Better than I remebered. The Law of Cosine is pretty cool. Mike

QUOTE(gottfried @ Oct 11 2007, 09:01 AM) With E series boards you couldn't do it. But I don't think I ever tried and I haven't on my 6251 either. But you can do you slow DAQ with a second cheap USB board. Irene He sells a little USB DAQ board for US$86. 32kS/s for 8 channels. http://www.hytekautomation.com/Products/IUSBDAQ.html If you try that I would like too know how you liked it. (I am in no way affiliated with Hytek Automation) There are other inexpensive DAQ boards available as well. If you must use NI then the low dollar choice is USB-6008 that does 150S/s: http://sine.ni.com/nips/cds/view/p/lang/en/nid/14604 Be sure to make sure the other specs for these are good enough for you. Mike

QUOTE(dthomson @ Oct 11 2007, 11:53 AM) Well, it isn't addition... Convert polar to rect for the end points: sin(phi1) = y1/phi1 then y1 = sin(phi1)/phi1 cos(phi1) = x1/phi1 then x1 = cos(phi1)/phi1 m1 = (y2 - y1)/(x2 - x1) you said (x2,y2) = (0,0) so then m1 = y1/x1 get m2 for the (phi2, theta2) line the angle rho between two lines is tan(rho)= (m2 - m1)/(1+m2*m1) put it in a formula node. Did I really do that for you? It's not like me at all. Maybe I did it wrong ;-) Mike

QUOTE(CamilloN @ Sep 24 2007, 07:41 AM) Yes the threshold array function may be useful. I have never used it myself. I believe is walks through the array untill it finds when the threshold lies between two adjacent points and it returns the interpolated x value for the threshold crossing. So you need to do that and get the result, then return to searching the array at the index after the threshold crossing just detected. Round the returned fractional index to +infinity and convert it to an integer. Starting at this index in the array, again use the Threshold function to find the next instance of a crossing and continue until the array is searched from start to finish. If you find instances where the returned index fractions are very close together you may wish to investigate them further to see if they are real data or noise. This can all be done within a for loop. It will be very worthwhile for you to figure this out on your own. We all have to struggle with how to investigate arrays of data. You can't really be shown it all, you need to experience it. I find that I have to think hard to do these things, so don't be impatient. A better brain than mine may find this easy, but I do not. If you have an actual array of the data you wish to analyze you should post that on the forum so we can use it to help you. We can lose a lot of time tryig to work with fake data. Mike Mike

QUOTE(Gabi1 @ Sep 19 2007, 05:04 PM) With producer consumer if you have a Pause case in the consumer loop, you can insert the queue call to that Pause case using an event driven producer loop. If you want the Pause case to be immediately the next operation, then use the Enqueue Element at Opposite End to run the Pause case as soon as the current operation is completed. If you put a while loop in the Pause case it can wait for a user input before releasing the consumer queue to perform the next queued function - whatever is appropriate to happen before the Pause is released. This could be deterministic pausing only after allowing the Consumer to complete whatever it is doing and not stop at some random point during its progress. Depending on when the Pause issued, the various activities previously queued up might or might not need to run unimpeded. You could test for these in the Producer loop or in the Pause Case whichever is appropriate. In your case where you wish only to give the CPU time to perform some other operation, the Pause function could be reading an LV2 global boolean until the interrupting operation sets that global to the "I have finished, proceed to the next operation" state. Since you were having trouble with unexpected behavior perhaps this method would be more dependable. I still don't know why notifiers and occurrences are needed. I am probably being old fashioned. Liking them is not necessarily a great reason to use them. Mike

QUOTE(Gabi1 @ Sep 19 2007, 02:02 PM) Just what to you mean "Pass" data? What is the data? What causes the data? Are you reading a digital line or something? What are the occurrences? Scratch that. What are you DOING? I am clueless what the function of this may be. If you are transparent with what you are trying to accomplish at a higher level, you may surprised what useful responses you may get.

QUOTE(Gabi1 @ Sep 19 2007, 11:23 AM) Maybe your loop is paused, but I am talking about something different. The loop I am suggesting continues looping constantly. The "pause" is due to the condition of the inputs. If neither input has changed since the last iteration, then a case structure inside the while loop chooses to do nothing, but when one of the inputs has changed then the case structure runs some other operation and is not "paused." The condition of no change runs a "do nothing" operation - same as pausing in terms of physical result, but the loop is running always. There is no notification. The values are simply read in whatever manner that is done. If the values have changed a different procedure is run. Why don't you show us your block diagram in an image or downlioad the VI so we can test it. It is not helpful to guess from the small amount of information you have given us. Mike

QUOTE(Gabi1 @ Sep 19 2007, 09:44 AM) Since you haven't shown your VI it is hard to say much. I wonder why you have notifiers at all. It is extremely easy to check two values inside a while loop, put the values in a shift register, next time the loop runs see if the new values are different, if one has changed (or by whatever logic you desire) then do some specific action pertinent to that logical conclusion. I would say in general you do do not want to use notifiers if a more conventional method works. Mike

QUOTE(CamilloN @ Sep 18 2007, 03:11 AM) Good that you have LabVIEW. I have never used the data loggger, but it may not be able to provide the peak detection that you need. In LabVIEW if you can define good criteria for the peaks you can find them, getting the elapsed time is the easiest of all. When you take your readings is will be at a very steady rate. The rate of acquisition is NOT set by the PC. Your DAQ card has an accurate and stable clock specifically to provide this steady rate. In the case of the example I gave you the data rate of generation was 10KHz. If your data acquisition rate is 10KHz then you will have the same situation. When you acquire 10K readings in one second, then the time between readings is 1/10000 seconds. 1/freq = the period. To find any elapsed time from data taken at 10KHz you simple count the number of readings between start and finish and multiply by the period between readings - 1/f. For your experiment you need to some common point in time from which to calcualte the relative time between two events. You could even have two different data rates and still get a good answer. In your case it is easy because you start both acquisitions at the same time and take the data at the same rate, they have a common point at 0 and at every other time. So when I see the index of the peak of plot 1 is at 517 that is equal to 517 * 0.0001 = 0.0517 seconds from the start. If the index of the peak of plot 2 is 9433, that is equal to 9433 * 0.0001 = 0.9433 seconds from the start. The elpased time is 0.9433 - 0.0517 = 0.8916 seconds. In the example I just subtract the earlier index from the later index and then convert to seconds. Index 2 - Index 1 = difference between indexes. Difference between indexes *(1/data rate) = elapsed time. Comprende? The tricky part is actually finding the peaks. In the example, I added the Gaussian Noise to show you that with real signals the peak that is read is not always the true peak. If you were to generate just the sine wave and compare it to the sine wave with noise you would get different times for the peaks, and the noisy peaks would have an absolute value that is higher or lower than the actual peak of the signal. If you can accept slight incorrectness due to noise then you are able to use the simple methods. If slight incorrectness is a problem, then you must investigate filtering which can introduce phase shift. You can look at averaging about each data point to reduce the effect of random noise, and so on. If you have multiple peaks then this can be very interesting. If you have only a step input and are looking for a distinct maxima caused by the step, then it may be simple. If you have a lot of noise (a small signal to noise ratio) you will also have difficulty. In the example I gave you I increased the amplitude of the sine wave so that the noise would not obscure the results too much, but so that you could still the potential for error caused by the noise. If the sine wave had only an amphiltude of 10 volts then the noise would caise much more error in the readings. Best regards, Mike

QUOTE(mross @ Sep 17 2007, 10:07 AM) Here is a VI that does the very simplest calculation of the elapsed time between maxima of two signals. I am sure it is not what you need but it will be instructive if you study it. Mike

>> Hi, i am attaching my spatial logic.vi.In this i have one main pump which runs five smaller pump(SP1 to SP 5) and once the tanks reach 75%,the pumps stop and the recirculating pumps open for 5 sec(SP 6).After that the volume is drained off(SV1) to Interim Storage. >> The attachment procedure did not work >> The recirculating pumps work fine in the first cycle of loop,but the second time they open for a second even though i have given a time delay of 5 secs.Plz Help. >> Without the attachement is it is impossible to answer this question. You should investigate using the Highlight Mode (small lightbulb symbol on menu of Block Diagram) of operation which will slow down the operation and move small dots along the wires so you can see how the data is flowing as the VI operates. You can also create probes to show the values of the data as the VI operates. You need to learn these basic debugging techniques as soon as possible. Your problem is certain to be a lack of understanding of how "data flow" programming works. LabVIEW is not a sequential language, it is a data flow language. Operations are not simply sequential - one after another. Many functions can be occuring at the same time. At what time these functions operate depends on the flow of data. How a VI runs. You must understand this: ALL the items on your block diagram that have no inputs (and are not inside a structure such as a loop or sequence frame) will run immediately and at the same time when the VI is run. Each one produces an output that is put on the wires that are attached to the output terminals. Then the data goes to the ends of those wires and is ready to be used by the next function of sub-VI which receives the data on input terminals. This is important: After the intial operations - every function or subVI will run as soon as all its inputs receive data. If a function or subVI never receives all its inputs, it will never run. Anytime you use a structure such as For Loop it is the same. All the wires that bring inputs to the structure MUST deliver the data before the structure will operate, and in the case of repeating loops, all the wires that deliver data to the output border of the structure must produce their data at the border or the loop will NEVER finish. Loops must complete an iteration to run again, and if the wires attached to the border never receive the data from inside the structure, the loop will not ever run more iterations. The outputs of a structure never send their data on to the next function until the loop has finished completely. >> Also i am attaching my second Vi-ARC-Project Vi.As u can see both the VI's have common Interim Storage.As i am new to labview i broke the project in two VI.How do i add the volume collected from VI no 1 and VI no 2 together. Thanks in advance.. >> You are missing a basic idea about VI architechture. In LabVIEW ou can have VI's, inside VI's, inside VI's. You need a higher level VI the the two VI's you have are placed on the Block DIagram (BD) of the higher level VI. The values you want to add are outputs of the VI's in the higher level VI. In the Higher VI you wire the valus to and addition functions and the result is available on the output of the addition function. In order to do add you two values you will need to create "Connector Panes" for the two Vi's producing the volume values. You should look up how to make a connector pane in the LabVIEW help system. You should also find example VI's and run them with highlighting turned on so you can become familiar with how the VI's work, how dataflow works, and how it is different from sequential programing languages. Mike

QUOTE(CamilloN @ Sep 17 2007, 06:27 AM) I have to ask more questions, sorry. Do you have the LabVIEW development software? Or, do you only have the VI Logger software? Mike

QUOTE(CamilloN @ Sep 14 2007, 05:29 AM) There are a lot of ways to do most tasks. It is useful to know some more about the problem and the equipment on hand to do the task. What DAQ hardware will you be using? What version of LabVIEW? Will you be using DAQmx or Traditional DAQ? You should be giving the answers to these questions every time you ask help so you can get useful advise quickly. It is also very important to know more about the signals themselves. What will be the characteristics of the steady state of the two signals? What will be the characteristics of the peaks? How quickly will the peak events occur or how slowly? How far apart in time from one peak to the other? Are there any other important characteristics about the signals that are impossible to guess such as AC or DC? Do you really need an absolute timestamp? Or do you just need the time that elapses from the start peak to the end peak? It would be very simple to get Date and Time when the acquisition is started. On the other hand the acquisition data rate is very well controlled so you can get the elapsed time in terms of the data rate by simply counting the number of readings taken between the two peaks. You can acquire the two signals and post process that data to find out the timing between all sorts of events. By post process I mean indexing through the array in a for loop, looking at the values of the readings, analyzing what they mean, and sorting out the important events. The index of a reading in the array is the elapsed time of its occurrence. You can examine the slope by comparing adjacent readings, you can react to any readings exceeding a threshold, and so on. If your acquisition is buffered (not continuous) then you always have data in the buffer from past readings. When you detect the peak and use this as the start trigger (also a normal thing to do) the data record is set to save some of the old data so you can see the peak and the shape of it before the peak occurred. This data is recorded until some other trigger occurs to says stop. Then your result is an array of the readings from two signals. Again you need to detect the end peak to tell the acquisition to stop. Any storage scope does the same things, and LabVIEW can do it as well. The hard part is dealing with the peaks. You must know something about the peaks and that should be shared with us. If you know that your first peak will occur according to some precondition, please explain that. It is good to know what the peak will look like in general terms. The end peak must occur during some roughly known period of time, or related some how to some other detectable event. There must be some expected difference between the steady signals and the peaks. Knowing these things it will be much easier to detect the peaks to control the acquisition and to post process the analog data to measure the elapsed time. If the signals are very fast then it is possible to use counter timers to sense the edges. But you still have to know the threshold of a peak that makes it THE peak and not just some insignificant rise in the signal. Imagine you had the acquisition of these two signals on a roll of paper in front of you. What thinking process would you use to determine that, "THERE! and THERE! are the two peaks I care about." What information did you use to decide that? Is that the correct information for all the peaks you will use? Or is there some variety in how those peaks will look? At what point is a peak not a peak? If you only need to do this sort of acquisition one or a few times is may not even be useful to automate with start and stop triggers. If you can start the acquisition manually, watch a scope, and stop the acquisition manually you get what you want then take the resulting array and use LabVIEW to analyze it. Sometimes it is only worth writing a fancy VI if you are going to do the operation many times. Mike

QUOTE(jdunham @ Sep 13 2007, 04:11 PM) I am just learning the ins and outs of DAQmx so I may be off base here (BS warning). I think you can run E Series cards under DAQmx, but they have only one DMA channel so the simultaneity is compromised. I think the M Series cards will do it though. Like most advise this is highly dependent on what hardware is used and what job is really to be done. Things we don't know about yet. Mike

QUOTE(Novice @ Sep 13 2007, 03:48 AM) Novice, I haven't actually had to do this - use both AI and AO at the same time. It is certainly possible to take a reading and then place a change on an output and switch back and forth between the two operations. But it does not look to be possible within one DAQmx task. When you create a task you have to choose between one or the other. That does not mean there is no way to get the same result. I assume you are asking because you do not know how assemble a VI that involves more than making a single task and running it. That is what you are going to need to do - create a more complex program that runs at least 2 tasks. You can certainly put two tasks on the block diagram, and if your hardware supports it, you can perform both input and output at the same time. It is that simple if your hardware will do it. Usually there is a lot more to the job than this if it is not simply an acedemic exersize. Often a DAQ card cannot do input and output simultaneously. Sometimes you need to have two serarate cards running simultaneously. Maybe simultaneous operation is not really needed... Maybe if the operations happen nearly at the same time that is good enough... So perhaps you should tell us what hardware you are using. CPU, OS, version of LV, what DAQ card or other card are you using, signal conditioning equipment, etc. Then say more about the job you are trying to do. What will you be reading specifically (what sort of transducer, what range of voltage, how fast you need to read it, how long to read it?). What sort of output do you need to produce? What system will receive it and what is its purpose? And perhaps most important of all, what do you hope to learn from the exersize and what decisions do you need to make? Do you need only to tabulate or graph the data? Do you need to analyze the data? Perform some action directly based on the analysis, or simply store the information for later use? All these things can have an impact on the sort of VI design you should use. If you answer these questions, then any effort we make to answer will have a better effect and be more worth the time to write the answer. Best regards, Mike