mross

QUOTE(EJW @ Sep 12 2007, 03:01 PM) Take a look at this example I made a while ago to demonstrate what you want. I apologize the paths will be all messed up for you and you will have to browse for the files to get it to run. It is easy to see what is needed. Mike

QUOTE(tcplomp @ Sep 12 2007, 12:34 PM) So it is. The LAVA GUI keeps putting these little teasers at the bottom of the page and I pick this one. I should have looked at the date.QUOTE(tcplomp @ Sep 12 2007, 12:34 PM) Mike you know the topic is allready dead for one-and-a-half year?Ton So it is. The LAVA GUI keeps putting these little teasers at the bottom of the page and I picked this one. I should have looked at the date.

QUOTE(YouMiss @ Jan 10 2006, 03:43 AM) Since you have a teacher and they expect you to do your own work, I will only hint. You should investigate the use of event structuresand XY graphs. It is VERY simple, but I won't give it to you. LabVIEW requires a lot of self instruction and self directed investigation. You should become familiar with the Help system, the knowledge base at www.ni.com and the Vi Examples provided with the software and at ni.com. Good luck, Mike

QUOTE(dee @ Sep 12 2007, 09:49 AM) When you click the image in the orignal post you just get the thumbnail - at least with firefox you do. Seeing the image doesn't change the answer. You just need to learn to use the functions in the Array palette. Everything you need is there, and no amount of advise will substitute for creating the array and using the array functions to manipulate it. What you describe is a simple delete from array operation. Start with that.

Sorry, no. It is unreadable - too small. I have alot of types with multiple elements. I need to take info fromthosetypestocalculatewith.ThenIwanttofilteroutalltypesthatdon'tfit and show the remaining types. I can simpelfy theleft"hoogte" rowbyputtingthehoogteinasanelementofthetype.Icouldmakethe columns into"typeXhoogteY"forexample. Anyone know a clean and easy way to start on this? I would put everything in arrays. That way I could have easy access to all elements. problem with that would be filtering out whole columns and showing the remaining. What you call filtering sounds more like deleting a column. There is an entire palette of functions (called the "Array" palette) for manipulating arrays including, deleting portions, creating specific subsets, transposing, reversing, etc. You just need to learn how these functions work. Looking at example code is a good way to get started. Array use is so common that you have a hard time not seeing examples of it. But you can search in the Help for "delete column," "array," and other similarly obvious keywords. This is probably not the best forum for this sort of basic question. Maybe use the LabVIEW General forum in the future for new user stuff. Generally, you should be prepared to say what your own efforts have been to figure out the problem before asking for getting lots of help.

You will need to use the XY Graph function. This will be found in the palettes. If you turn on the context help (Ctrl-H) when you pass your cursor over the XY graph icon you will see in the context help the data formats needed to serve the numbers to the graph. Create and fill out this datatype with your data, wire it to the graph and run the VI, the data will be displayed in graph form. The normal first step is to try and find the answer yourself by looking in the Help section, finding VI Examples, and querying the knowledge base at www.ni.com and other places you will learn about, after you have tried these things ask for help in the forums. It is generally felt that you should expend similar or more effort than the person answering your question will have to expend. This request has the sound of someone asking for help with their school work which always raises the ire of someone like...me! Also, this question is inappropriate for the Application Design & Architecture forum. A basic question such as this one should be placed in the LabVIEW general forum. Mike QUOTE(shashank @ Sep 12 2007, 04:20 AM)

Salaheddin, I am very sympathetic. I had to learn LabVIEW on my own with no one else to help me learn. This was not easy, but I had access to the internet and the telephone based technical support which is excellent. You may know these things, but I wish to make amends for my impolite response to you. My best advise is to make many subvi's. You can create or generate fake data to test how each subvi is operating, then add them one by one to the larger vi after you are certain they doing everything properly. We have a saying that you can eat an whole elephant one bite a a time. You can also use the Create SubVi function to encapsulate parts of the block diagram. Sometimes this makes debugging problems easier. I hope that your predecessors wrote good clean code and added useful notes as explaination. One thing to keep in mind is that the newer versions are using DAQmx functions and hardware. You cannot use DAQmx with Tradition DAQ hardware. You need to keep this in mind - if you need some DAQmx function, you will need new hardware to use DAQmx. When I got the version 6i this was a good release, and v7 and v7.2 were very good to use with Traditional DAQ. In particular the addition of user event structures and queues has been a great help for my own work. Eventually, if you continue using LabVIEW you will definitely want to upgrade. DAQmx, v8 and beyond will be much better than Traditional DAQ. So if you can migrate your hardware and software in that direction it willl be good. Mike

QUOTE(John Rouse @ Feb 27 2007, 12:39 PM) And it is flexible if you talk to them about it. Or I want to hear that it has changed, because it makes a big differnce to me.

QUOTE(crelf @ Feb 27 2007, 07:50 AM) Nicely put. I could learn a thing or two, eh? I agree with you. I think it was just too late at night or something. Feeling tender about the subject. I did wonder how anyone could have a legal copy and not know how to get a new one a couple versions down the line. Nevertheless, I was out of line. In the absence of evidence to the contrary one should assume good will. Mike QUOTE(siallid @ Feb 27 2007, 06:33 AM) you can not learn me such things because I ask about an original software we bought it for our company where I work and Iam now working on it in my work. and about labview 8.2 it is only a mistake in filling the information or if I have labview 8.2 why I ask about upgrading labview v.6.1 to a new version. in any case I don't thing that there is a bad people like you. Siallid, I apologize for my harshness. I made assumptions about you that were incorrect. I should not have done that. With National Instruments, almost all information can be found online at htp://www.ni.com Also, when your company bought LabVIEW 6 they were probably assigned a sales person and a field engineer. These people will be the most knowledgeable and may be able to help avoid any language difficulties. My company pays annually for the subscription servivce. I get upgrades automatically, and I get cost free and fast telephone technical support. If you are not in the USA I am not sure if the same service is offered. This service is very valuable to me and I recommend it to anyone who uses LabVIEW on a regulr basis. I believe this service is more economical than only buying the versions as they are issued. Once again, I am sorry to have been uncivil in my comments to you. Mike

QUOTE(siallid @ Feb 27 2007, 01:10 AM) The way it works: people write LabVIEW so that they can feed their families, and save for their retirement; and for that to happen you have to pay them for their effort. That means you write a check to National Instrunments and they send you an upgrade. This is a serious forum full of hard working people; most of us write software and are paid for the effort. Please don't come here looking for bootleg copies and advise on how to steal the develpment system. If I am mistaken about your intent, I am sorry. If I am correct, you probably lost any chance to get useful advise on how to use LabVIEW. Mike

QUOTE(BrokenArrow @ Feb 26 2007, 11:11 AM) NI has said they would treat this sort of thing as within the intent of the license agreement. But the lawyers wanted a line laid down. I am in a situation similar to "your friend." There is no one here who is going to use LV that doesn't have a license of their own. If I have to be strict about where the development system is installed, then I am going to need to go to a lot of extra trouble deleting it and reinstalling it to keep the numbers right, or I have to buy extra seats that will never be used. NI have said this is not their intent. You can ask your local rep to get it in writing if you think that is needed to keep your IT/SOX folks happy. It would only be fair to be willing to show the local app eng around you place as a show of good faith. An ongoing relationship with the app eng couldn't hurt. If you find out it isn't they way I say, I would like to hear about it. Mike

QUOTE(Jeff Plotzke @ Feb 17 2007, 11:02 AM) I am picking on it but nothing is happening.

Jeff, Thanks for the link. It boils down to go find the RSS licon and press it to get started, I think. The discussion coverd abit more than that. I have to say though that I can't find the RSS icon to begin with. I was looking for that prior to asking for help and it is not there. I am running the current version of Firefox. Maybe I have set something that disables RSS. I will have to look. MIke

I have decided to give RSS a try, but after wandering around LAVA quite a lot, I haven't found anyway to implement it. Can someone point me in the right direction? Mike

That is an odd statement. Do you not know how to do the analysis in LabVIEW? There are agreat many tools for analyzing data. You could use LabVIEW for many years and never exhaust the methods of analysis. Furthermore, LabVIEW is much, much better than Excel or an office spreadsheet, particualrly when the data set is quite large. You say:People using the system need to see the values on the screen in real time. I ask you: Why? What decisions will be made based on the visual display? Frankly, if I need to visually investigate a signal, I find a good fast oscillosope to to be much more useful. Then I use that information to guide me in choosing the correct speed and resolution for an LabVIEW acquisition. I then use LabVIEW to acquire a limited data set (not continuous) process the data, store it, analyze it, and present it graphically. Refresh rate is an issue only if you acquire data continuously and display it onscreen in a graph or numeric indicator or array indicator. If you are not reacting to the visual display in some manner, then you have no real need to display it. You could just show an hourglass if that makes the operator feel better. If you are reacting to the visual display in real time, you need to qualify and quantify what you are going to do with it. It is also possible to apply PID to control the process if that is desired using LabVIEW functionalty. {quote] >>SNIP -The second one for people who wants to acquire at 1 Hz. This version still needs to acquire the values at high rate to make sure that the 3 pressure sensors have the right average. I am sorry that is a self contradictory statement: ...wants to acquire at 1Hz...needs to acquire at high rate.... And how does acquiring make sure the three sensors have the right average? Are you implying some sort of decision making process and manual contorl of the system? I said this earlier. You need to look deeper into the function for writing to file and get the functions that open and close the writre operation out of any loops. I haven't used this example made in v8.2 so I apologise if it isn't actually functional, but it illustrates the idea. Opening and closing the write operation depends on the OS which can take a lot of time. So to make it run faster you need to leave the operation open, and call ONLY the Set Position and Write To Text File functions inside the loop. Only close the file after you are completely done writing to it. The example I show is a couple layers of sub vis deep inside the basic Write to Spreadsheet.vi file function. You keep double clikcing on sub vis until you find the one that is opening the file and closing it, that is where you make the modifications. The function you showed in your image is unlabled and I don't know where to find it to look at it. Code is always better than screen dumps.

The best I can do is a little brainstorming. It occurs to me that you might get what you want from a vision system or a hybrid system. Maybe a low res camera could be used to send the sensor to the correct place for its more detailed work. I know that isn't what you asked for, sorry. Mike

Sounds interesting. I wonder if there is ever a reason NOT to use it?

Well, that is a new one on me in my little circumscribed corner of the LabVIEW world. What is "the TDMS?" Mike

Don't show the data on screen and if it is really the refresh rate then the problem will go away. It could simply be that opening and shutting the files repeatedly (a big no no) is slowing you down. You haven't shown us the write operation so there is no way to tell, you just show an indicator for a single datum. You have to look at the file writing vis and put the file open and close functions before and after the loops not in them. Opening and closing depend on the OS which has its own adgenda. Once the connection is established you just keep appending data to the open file. Writing once a second this way should not be a problem until the OS starts to get grumpy about the file size. Nothing you are describing requires writing the data to a file continuously - maybe you shouldn't do it. As a last resort you can gather it into larger chunks and write it periodically. You do not want to be putting millions of data points into a spreadsheet. You need to decimate in some sensible way. At this point it would be helpful to know what you think you will see in the data, and what decisions you will make. Maybe you only need to look at the data taken 2 or 3 minutes before and after a peak. Maybe you only want to get a spectrum analysis of the data. Huge amounts of data are lots of trouble so it all has to be useful or your efforts are wasted. It sounds like you might not need even 1 hz for long measurements. If you know the nature of your pressure fluctuations then you can use Nyquist to set an appropriate sampling rate. If your fastest pressure cycle is 30 seconds then sample onece every 3 seconds. If your fastest cycle of interest is really short then you are going to miss something at 1 Hz. You should sample a minimum of 3 times your cycle period, and 10 is much better. Assuming you really do need massive amounts of data written to disk you could keep a big circular buffer and process the data as you go, triggering captures of the data only when it is really necessary. Again do not open and close the file for each write operation. There is nothing to stop you from post processing the amount of data you would get in 45 minutes at 1 Hz. When I say post processing, I mean after the acquisition, but before writing to the file. LabVIEW was built to do this. It won't even take that long if done properly. When you have over 2 million data read most of it is garbage you will never look at. You need a way to decimate it and find the information of interest. Decimating data is wholely another topic. Here is an analogous example. If you ever have heart palpitations they will want to put a monitor on you and record your EKG for 24 hours. Ever wonder how the heck they find anything in all that info? It only works if the patient marks the record when they think they feel weird. No one is going to sit and watch 24 hours of EKG looking for rare and intermittent events. It is similar for your work. You know a visual record of 45 minutes of data is not useful. For shorter periods visual observationis a great way to spot interesting events, but there are real limits to this. (You should really not show any of the data on screen while it is being read.) You need to decide how you are going to find the information of interest in all that data. Throwing some away is a good idea if you can figure out how not to lose something important. Anyway don't prejudge the problem and try and shoehorn it into the PC form. I don't see that have the need for any parallel operations at all. If you need to acquire this much data and you really want it all written to a file, you should be unloading a buffer now and then to reduce the number of write operations. Also, I wouldn't write it to a file at all, I would write to a database. It is much faster and the db handle large amounts of data much better. That too is a whole other ball of wax and has its own learning curve. You need to look at the acquisition vis - start taking data even if it isn't the actual signal (hook up to a function generator or something). Lose the simulate signal and the Producer Consumer. They are a dead end. Mike Here is your floating average vi rearranged to operate on a pre-existing array. You can use this to post process your acquired data. Download File:post-48-1164219804.vi

I looked at your code and you have gone too deep. All you are trying to do is aquire data at a very SLOW rate. Orders of magnitude slower than what LabVIEW is designed to do. You want to find the average (still undefined exactly how this is to be done). You want to write the average to a file. There are basic functions to acquire data, calculate an average, and write the results to a file. None of these requires the complication of a Producer Consumer format. Save the Producer Consumer for later. I made you a vi that would acquire the data all at once, calculate the average overall and as a running average, and wirte to a file. You really don't want to over do this. If LabVIEW does nothing it makes what you defined extremely easy. Rather than pursue the Producer Consumer take a look at the acquisition example programs. If you can get a DAQ card and the Signal Accessory you can really make some headway learning the basics. When you start doing actual tasks in the lab or the field or analysis with real data, then perhaps the other architectures will be handy. Remember there are other architechtures, not all tasks require (or are appropriate for) the PC form, there are state machines, queued state machines, and user event driven PC, to name a few popular ones. There are good examples of all these at ni.com. Mike Download File:post-48-1164212953.vi

"-Read data at high speed (500-800 Hz), calculate an average value." How do you propse to calculate this average? Is it a running average of the data taken before and after a particular reading? Is it the average of all the accumulated data? "-Write to a file the average values at 1 Hz frequency." Why do you want to do this every second? Why not acquire al the data and post process the data? What do you gain by writing the data every second? You can ceratinly stream data to disk, but what is the point? LabVIEW was setup to make this much easier by letting you gather lots of data into and array at very high speeds (1.25MHz for an analog channel on an E Series DAQ board), then after it is done analyze the data, store the results, and present the analysis. The issue with writing to files is OS related. You are fighting a headwind if you write to files all the time; so make sure that is really what you wwant to do before you do it.. I haven't peeked at your VI yet, but I will. I am not sure if the PC architecture is the right one for what you are doing. Maybe you don't need any special architecture at all. ProducerConsumer is used to mediate between inputs or requests (often GUI) that may come in batches that the consumer cannot manage immediately. That PC allows tasks to stack up and be dealt with as resources are available. Merely reading some channels, doing a little analysis and saving the data to a file doesn't require any special effort.

Tha's what I said! "The upper loop will not send the boolean to the lower right loop until after you manually stop the upper loop." Anyway, you needed to have that revelation about when data is passed by loops. The same is true with the walls of sequences. The way to think about structures and dataflow is as follows: All the input tunnels on the border have to get data before a loop or structure (formula nodes, event structure, all of them) will start. The loop has to finish its work before the output tunnels are filled and can pass data to subsequent nodes. Every tunnel on a border represents a copy of the data, so be careful about wiring large gobs of data (huge arrays or clusters) to border if it is not necessary. I am playing around with a vi for you that is an event driven producer consumer. This uses a system of queued eunmerated phrases (called ENUM controls). The queue functions as a FIFO. You load a series of commands in the queue - a while loop with a case structure in it responds to the queued commands by selecting what case it runs each time the loop increments. You can enqueue commands in the event structure so a cursor pick commands those cases to be run in order. You can also have decisions made in the cases that enqueue further commands, or have other loops running that enqueue commands. I'll say more when I send the vi. Mike

I think you could get rid of the sequence frame and it would work the same. All the sequence does is make shure the subvi's run 20ms after the case is called. Maybe that is important but I can't see why the subvis shouldn't just go for it as soon as the case is called. You should really turn on the light bulb and watch. Put a breakpoint right after the stop button and it will switch to hightlight mode every time it get to that point. Run it like that with and without the sequence structure to see what I mean. I think your documentation is great and I do the same myself. Often writing the doc helps me get clear on what exactly I am trying to do. However, you don't have any documentation on the main vi to describe the progress through the procedures. I haven't got it in my mind what you want to do yet. I tend to think in flow charts. One of the reasons I like the event driven producer consumer is it is a clear outgrowth from a flow chart for me. If I can get straight how I think you want yours to run I can try to make you a model. I didn't find the example I was after. Mike

I can't run it becasue DBitOut.vi is missing, so I have to make comments without running it. First thing, lose the sequence frame. It adds nothing. The data flowing through the wires accomplishes the same thing. I suspect some of your questions will be resolved when you get a better intuitive grip of dataflow. Example: The large upper and lower left loops will not function until the data from the DAQ Board # is delivered to them. The upper loop will not send the boolean to the lower right loop until after you manually stop the upper loop. A single sequence frame is used to make certain a group of functions have fhinished their work before proceeding, such as intializations before full operation of equipment. You wantto let LabVIEW decide when to run things as much as possible; that means avoiding sequences for the most part. I like your use of the Tab control to gather like functions. Have yoo tried using hightlight mode yet (the light bulb icon)? This is tedious, but it will start to show you how the data progresses around the Block Diagram (BD). Also, the pause button, step through/step over, and the use of breakpoints and probes are all excellent tools for figuring out glitches. You have a combination of machine operations, some of which need to be completed as a group without interuptions, and you have user inputs the program should respond to. There is an architecture called User Event Driven Producer Consumer that can do a sweet job of this. I will try and find a simple example to send you. BUt you need to learn how to use the Eent Structure, this will be very helpful. Can you resend with the missing file while I try to locate a decent simple example? Mike

Of course there are always limits to everything: 100S/sec * 3600sec/min * 60sec/hr * 24 hr/day = 518,400,000 samples That will gag an Excel file if such is your intended destination for the data. A brute strength approach to DAQ often runs into problems. Better have the right OS, database, and analysis software if you take this path. :thumbdown: :thumbdown: Frankly, if you are graphing more than 100 to 1000 points you are wasting points. Beyond that you are going to be more interested in mathematical and statistcal properties of the data not the points themselves: time and frequency domain metrics like slope and frequency, extrema and inflections, mean, median, standard deviation, local extrema, spectrum, etc. Once again (this is what Mike always says, and the regulars must be tired of reading it), I recommend that you tell us what you want to do in more detail. What are you reading and why? What decisions do you need to make based on the information? You can get really good answers to those questions here beyond mere progamming tutorials. Mike