mross

QUOTE (Dirk J. @ Jul 1 2008, 02:31 PM) Mine and yours together add two to the noise side of all topic SNR.

QUOTE (KatieT @ Jul 1 2008, 12:31 AM) I don't know the answer to your question, but I bet if it can be done it is a fair amount of trouble customizing a tab control. You can play with fonts to expand the tab area. And you can nest a tab inside a tab. ( I don't know if that casues any trouble - nesting things for no really good reason sound like a bad idea intuitively) I have done this with no problems and you could certainly have different fonts in the outer and nested tabs. I will be interested to hear other answers. mike

QUOTE (hakannn @ Jun 9 2008, 04:47 PM) You have written a program in the developmnet mode. The run button must always be pressed to begin a program in the development mode. If you "build an application," then opening the program you will not see the run button - The VI will be running when you first see the front panel. There are a great variety of other options for built applications. They can run with no front panel at all visible, or the front panel can expose fewer menus, and so on. You must have the application buiilder module to do this. Also, you need to understand that LabVIEW is a "data flow" programning language. Nodes do not operate in sequence, they operate when all there inputs receive valid data, and when they stop and only then do they produce output data on their wires. Nodes are loops, VI's, and all the various functions you see in the pallettes. When you run your program the first thing that happens is the Start button produces data, which is TRUE or FALSE. You will not have time to activate this button, it will instantly produce its output based on the setting of the button when you hit Run. If the button is FALSE, then the false case will run which is empty and does nothing. Then the program will be finished. If the botton is TRUE then the true case will run and proceeding by data flow it will execute functions until one of them fails to receive all its inputs at which time it will wait and you will have to abort the VI, or it will finish al its work and then stop. You should look at some examples of Vis before you try any more on your own. I suggest a simple example oregarding the Event Structure. You should turn on the highlighting feature (lightbulb icon in menu on block diagram). This will allow you to observe how the data flow proceeds. You should also use this feature to learn how your VIs are failing and to fix them. Bon chance, Mike

I would only elaborate on item 3. Max is for hardware management. LabVIEW is software deveolpment system. When you write labVIEW code the software is being compiled. When you work witn MAX you are configuring hardware. When preparing to perform data acquisition you start out by attaching the signals and signal conditioning devices to the DAQ hardware. Then you test those signals in MAX to make certain you have the proper cofiguration. Then you can write VIs drawing data from those channels and you know if there are problems the hardware is functioning as is should, and the trouble is on the software side. You can create "Tasks" in MAX which are brought into the VI and are very high level program functions, or you can break these Tasks down into smaller, lower level code bits that can be customized. In this way MAX is a great productivity aid and much more than a mere hardware configuration utility. If you follow this process - wire up the signals, configure MAX, test the signals and acquisition in MAX, export the DAQ task to LabVIEW and create the VI (and sub VIs) which supervise the acquisition and perform other analysis, record keeping, communication, report generation, and so on, functions - If you follow this process you may quickly accomplish your goals. You will find that LabVIEW makes it easy to create and test the small functions of a complex programming task and MAX helps by separating out the hardware layer. Mike

QUOTE (MicrochipHo @ May 5 2008, 02:25 PM) You need to know that things wired to the outside of a loop for input are read only once. And the output of a loop is only sent once when the loop is completely completed and stopped. So your control to direct the lights must be inside the loop to have any effect on the other things inside loop while it is running. In the simplest case it is like the loop becomes a world all by itself while it is running. Also if you wish to have the indicator update more than once it must also be within the little world of the poop. You can represent the pattern of lights many ways. You have choese a numeric control so you are "encoding" the light condition as a number. You could do it with strings, or with an array of booleans like the output, and so on. However you have not said exactly how to decode the numeric input. I give you an example that shows two simple but different ways to decode the numeric control. The first is a simple conversion from number to boolean array. The second is to use a case statement to select a particular pattern of booleans for the output. Notice that the Case structure is not always true and false, in the example the cases are 0. 1. 2. 3. etc. If you wire different types inputs to the contidional terminal of the case structure you get different function for the case structure. Many VI's is are flexible this way - is is called polymorphic function. It is a surprise to me that you have no been tought these basic things in your class. Mike

I did this a long time ago and for some reason I couldn't use the Threshold Array primitive. It may have been improved now and work as desired so you should try it. However, I am thinking it doesn't manage the leading AND trailing edges well. Also, it is possible, if there is enough noise that is faster than the rise and fall, that it will to mess you up (this is not likely). In that case you need to do a running average around each point. I do remember that I used a scheme that subtracted adjacent points from each other and checked the absolute value of this difference to see if it exceeded a threshold. If they difference was negative (1st point greater than the 2nd) then you know it is the trailing edge. So you have a shift register that saves that last point processed by the for loop. On the 2nd and subsequent iterations you get the difference between the earlier and the currently indexed point, and test it for exceeding the threshold, and for the trailing or rising quality, then you build an array of the for loop counts factoring in the scan rate for the acquiaition to get an elapsed time. You can subtract leading and trailing elapsed times to get pulse width if that interests you. Just in case your waveform is not in the time domain... In my own case I was not measuring time but angle of rotation by way of an encoder clocked acquisition. So I needed to know the angle between encoder (external trigger) pulses. If I had 247 of 7200 pulses from the start as the location of a signal edge, then I knew itindicated and elapsed angle of 247 x (360deg/rev x (rev/7200 pulses)) = 12.35degrees. After writing all that, I think the Threshold Array business was clunky for me because I had a big interest in separating out the rising and falling events. So if you care about that you might want to use my method. Mike

QUOTE (farnoosh @ Apr 28 2008, 10:47 AM) LabVIEW was designed originally to make sophisticated data acquisition possible for engineers who do not have a primary interest in programming. It is very good at this, and I fit that demographic very well. I use LabVIEW to run experiemts, to do analysis of the results, and to make graphical presentations. Also, I use it to manage experiment record keeping within a MySQL database. I learned to use LabVIEW alone and with the help of the phone technical support team at NI. Learning a comparable (in function) programming language such as C would have been much more difficult and time consuming. It makes programming fun for me. Mike The support system for subscription plan participants and English speakers is excellent. The community of users and their support for each other is also excellent. The online resources at ni.com are very helpful.

QUOTE (psiam @ Apr 28 2008, 05:03 AM) I could not get any information googling on PIC MPLAB IDE V8.00. You did not provide any definitive information. Impossible to comment. There are some forum guidelines and information on how to ask questions in the most effective way to gain help. http://wiki.lavag.org/Forum_Guidelines http://www.catb.org/%7Eesr/faqs/smart-questions.html Also, it is always better to show any work you have done on your own. Many, many people here put food on the table by writing LabVIEW code. You are asking for a free gift of a serious person's time. It is presumptuous to ask for help from professiionals without putting in some serious effort on your own.

QUOTE (panithan @ Apr 26 2008, 09:32 PM) I have not used the VIs that you show. I do have a VI that I use to make pulsewidth modulated square wave. I run it from 1 to 10000Hz so there is no doubt with the right method you can increase the speed. You should experiment with some other examples for producing square wave output. It may be better to generate the pulses on an analog output channel. When I get to work tomorrow I will look at the PWM VI and see if it could be useful. I assume that for control of the vehicle you will want to command specific numbers of pulses to be generated at varying speeds, and you may want straight forward and reverse travel with manual control - on, off and change speed. Also you may be programming specific "moves" such as spin 180 degrees in one place. It may not be appropriate for this to have only one method of pulse generation. For this reason you need to learn as much as possible about the different ways this can be done. Your current method may have the limitation that it can only make pulses at 1KHz. I am not the best and only source of information on this forum. So you must learn how to interest people in helping you. One good way is to keep showing us your code and a willingness to improve it according the the ideas presented here. For example Tim S suggested you straighten out your wires and organize the code so that the "Flow" can be understood with less trouble. Likewise, I mentioned eliminating the sequence structure. If it is difficult to read your code, you will get less assistance. All that aside, we can't be as helpful without seeing the code you are using. Attaching the VIs (or if it is multiple VIs perhaps a zip file of them) to the forum messages is a good idea. Often you will get back improved versions of the code as part of a reply. Mike Mike

QUOTE (farnoosh @ Apr 26 2008, 12:50 PM) ftp means file transfer protocol and is commonly used to exchange large data files without using email. I am not a good teacher for what you want. I know it can be done but I have not done so myself. You should investigate the use of "VI Server" I think. This allows you to create a window on another PC on the internet (byt the use of the IP address). This window can display the playback of the ECG.

QUOTE (farnoosh @ Apr 26 2008, 09:51 AM) You should always explain a few things about your system: What version of LabVIEW are you using. Also, what data acquisition hardware. What operating system. It is also best show us what you have already tried to do yourself. You get better answers this way, and we like it when we can tell you are doing work yourself. I do not claim to know how much you have worked on this yourself, but it is common for people to ask us to do an entire project or assignment for them and this is not appropriate. There are many online resouces that you can investigate on your own. The ingredients of your task (assuming I have interpreted you short desciption correctly) are as follows. 1) Find out the properties of the signal using a scope or similar. 2) Determine if this signal is appropriate for the data acquisition (DAQ) hardware, and if it is not, then construct the appropriate signal conditioning so the DAQ hardware can read the signal without damage and with an adequate signal to noise ratio. 3)Test the signal acquisition using the Measurement and Acquisition Explorer. 4)Acquire the signal into a numerical arrary of voltage readings. 5)Perform any post processing to this data that is needed: decimation, filtering and so on. 6)Save the data to a file appropriate for the internet receipient. 7)Email it to them, or send via ftp. Mike

QUOTE (Michael_Aivaliotis @ Apr 23 2008, 05:32 PM) Not much to say about that.

To answer your question about motor speed is hard becasue I don't know anything about the motor. But I can guess...suppose for example that you motor has 100 poles, then each pulse will only move the motor through 100th of a rev, and it would take 100 pulses to move it one rev. Really, this is why they are called steppers. They sort of click their way around from pole to pole rather than a smooth continuous motion. If you crank the motor speed up it will go faster. The nice thing about a stepper for you is can position the motor more exactly than is easy with a continuous motor. If your wheel has a circumference of 10 inches and the motor has 100 stops per rev, then one pulse gets you exactly 0.1 inches of motion (subtracing out any slippage between wheel and ground). You would know you grounds speed from this also. 100 pulses per second would be 10 inches a second. You can crab steer a four motor four wheel system by sending unequal numbers of pulses to the wheels. Sounds easy, eh? Mike

QUOTE (mross @ Apr 23 2008, 03:21 PM) Michael, I am good to go now. Thanks for the pointers. I don't know how many SVN newbies you will get for this, but some short and sweet info on the project home page like you gave me might go a long way. Mike Mike

QUOTE (Michael_Aivaliotis @ Apr 23 2008, 02:50 PM) Thanks. You seem to be guessing very well. I haven't a clue about SVN, so I may indeed be asking for help. I have always wanted a place to put the tidbits I write to help people (sometimes years later I want them and they are on some old defunct box sent to on the production floor to do Excel duty or in some hard drive now at the bottom of a landfill), and since I am not usually interested in meeting the C-R standards I thought this might be useful. I had the impression from an earlier forum conversations that this might be one of the functions you envisioned for this. Also I am just curious what Google is up to here. I have found uses for a lot of their bits and gadgets. Finally, I presume there is a long tail for stuff given to Google for safekeeping. Maybe this way I don't have to worry about transferring it from new PC to new PC, backing up, and so on. It is an act of faith, but I am hoping someone who wants to organize all of human knowledge can do the little bit that I want. Mike

QUOTE (panithan @ Apr 23 2008, 02:23 PM) Sounds like fun. It is good of you to own up to being a student right away and that you are going to earn credit for the work YOU do on this. It won't be much of a capstone, if we do it for you. LabVIEW makes you dependent on looking up information in the help section, also we live off of the VI example files - which is where I usually start. You may as well start learning your way around the various resources that ship with the software, and that are available at ni.com. If you start poking around looking for "stepper motor drive," "pulse train" and so on you will certainly start finding things. It is inportant to know what sort of hardware you have installed and what version of LAbVIEW you are programming with. Communicate that to us when you return. Some of us here have an aversion to giving away the farm to people who are supposed to be learning for themselves. However, you can get a lot of help, and very specific help, once you start having some code of your own to show. If you get something down and show it to us you won't be treated as a "Homework Hustler." Here are some other hints. Learn to use the Measurement and Acquisition Explorer (MAX). This provides test panels and even lets you preview the entire task if you have more current versions. You can generate a pulse train and put a scope or meter on the output pins of the DAQ equipment and see that all is well. You will need to look at the spec sheet of the DAQ card to see what the properties of the various in and outputs can be. Find the spec sheet for the stepper, and driver circuitry to see what inputs it needs. It sounds like you only need a TTL output, but it is always worth checking the drive current needs up front. Figure out what if anything needs to be an interface between them. If the DAQ card can't provide the drive current and voltage then you will have to get some interface to amp it up. (See US DIgital for all sorts of economical stuff). Anyway looking up stuff on spec sheets is a way of life and you need to get down to that. I don't want look it up for you becasue you just need to do it. When you are wiring this thing be sure to attend to grounding and fusing things properly. I worked on a capstone project where the EE in charge of that stuff did not. It was a smokey hell at exactly the wrong moment. Surely you won't only drive the stepper one direction. What makes it go back the way it came? Mike

QUOTE (tcplomp @ Apr 23 2008, 01:44 PM) Thanks! I guess the intention is NOT to use the WIKI function at gcode lavacr and to use instead the LAVA cr forum instead for discussing? The gcode accounts will funcition as a storage and librarian utilities for works in progress and not much more? Mike

QUOTE (Michael_Aivaliotis @ Apr 22 2008, 04:13 PM) Michael, I am looking around in Google Code and I have yet to come up with a search, or find any pick, tab, link, or any intsructions on where any lavacr code is. I gather that Gavin put some things in that like "rusty nails" or v 8.5.1. I haven't happened upon the right lucky charm to bring that up. I must not have the referents to work this out easily. Hints? Mike

QUOTE (fuzzycontrolfreak @ Apr 22 2008, 01:23 PM) I think you just need to use a different kind of acquisition. (You should show us your code to get the best answer.) I am not at a computer where I can look at the examples so I have to tell what to try to do. Please forgive me if I leave something out. You want a continuous data acquisition, you want a finite number of scans (N-Scans), you want pretrigger function. When you run this type of VI, the DAQ board is set up and set in motion. It is constantly filling a buffer of the size you define. When you hit the stop trigger it simply reports the last buffer of data - whatever amount you told it. There is no limitation to only one channel and 1D array output. You can monitor several channels and get back the data from them all in a 2D array. There is absolutely no need for you to concern yourself with for or while loops at all. You can probably set up and test this sort of acquisition using MAX (Measurement and Acquisition eXplorer), and that is what you should always do - use MAX to get the acquisition working properly in the test panels. Then create that task and use it. Again, I apologize for the lack of detail, but I was given this WIN XP x64 machine to use and there are no drivers for this OS so I can't even load MAX on it. Mike

QUOTE (orko @ Apr 21 2008, 03:04 PM) Exactly right. And if you run this one you can watch it happening (hence the extra indicator). Also,very instructive to the new programmer.

QUOTE (MicrochipHo @ Apr 21 2008, 11:40 AM) MicrochipHo, Obviously, there are a variety of ways to do this. There are indeed canned functions that perform the function you want and there is nothing wrong with knowing them. There is still something to be learned from doing it the hard way. You can learn a lot more about LabVIEW the hard way, IMO. In a beginning programming class you will often encounter assignments where thay ask you to perform operations for which there are canned routines that save you from actually learning much about basic programming skills and functions. Really, that is the only reason to waste a lot of effort on the following method, but it has its place. In the attached BD you have a loop that runs 10 times. The random number is created between 0 and 1 which is scaled per your method so that the results can be sorted down to the range you want. Then through the use of inequalities and the logical AND you produce the test result of whether the number is in the range you like or not. You get to see how a shift register stores the results of prior cycles of the loop, and how that must be initialized so it starts empty every time you run the loop. You get to see how the case structrue takes the test result and either builds the "in range" values to the shift register, or sends the shift register on to the next cycle unchanged. And you get to see a visual comparison of the raw data and the processed data to make sure the results are as they should be - a good debugging technique. If you turn on the Highlighting (lightbulb icon) when you run this you can get an easy to follow beginning lesson in how dataflow. programming works. http://lavag.org/old_files/monthly_04_2008/post-48-1208803913.jpg' target="_blank">

QUOTE (MicrochipHo @ Apr 21 2008, 11:40 AM) At least you are honest. Generally we don't lay out answers for people doing school work. But we will definitely give help if you have put in some effort yourself. If you are more verbal than mathematical try writing out the process in words, using phrases like: if this is so, then do response 1...if this is not so, then do response 2. This verbal function comes from the Case Structure. in LabVIEW. The responses are put within the Case Structure - True Case for when the test is so, and False when it is not so. In this example when you have tested the number and it meets your criteria you simply wire the same data you tested into the Case structure and out the far side in the TRUE case, but not in the false. The test is performed and the T or F drives which Case will run. All the case needs is the number to pass or reject. If the test is false since there is no data wire across the false case, then that number dies. If the case is TRUE then the data is wired through the TRUE case and you can pick it up on the output side of the Case to be dealt with as needed. Within the TRUE and false cases you can do much more than simply pass the data or not. You could do all manner of complex things to the data in the false case, or all manner of different things in the TRUE case. The outputs can be different data streams. You could do further nested tests. For instance you could sort the false numbers, those which are greater that 24 to return the numbers that are greater than 24 AND greater than 50 but less than 75. Wire that to the output side of the case and you now have two results. The case is "polymorphic" as well. It is not limited to TRUE and false cases. You could wire integers into the ? terminal and the cases would become case 1, 2, 3, 4 etc. Or it can be Error and No Error, and so on. However you set it up, when it gets all its input data, it looks at the conditional (?) input and finds that corresponding case and runs it. Mike

Hi, My sympathies. Serial comm is not the most happy making way to get started with any programming language and LabVIEW is no exception, though it might be easier. You may want to get or use a com terminal program like hyperterminal (comes with windows) or comDebug (freeware). You can send simple commands with a terminal program and prove out the com activity before getting LabVIEW involved. I usually end up doing this when ever I have to work with a new piece of equipment and whatever protocol it uses. Mike

QUOTE (Timmy @ Apr 9 2008, 02:50 PM) Take the derivative?

QUOTE (PaulG. @ Apr 8 2008, 12:09 PM) Paul, Since my hammer of choice is the queued producer consumer architecture, I suppose I simply haven't had a need for more than one event structure. However, to have one event structure in each of several separate loops I would want to be very, very sure there is no intearaction between the loops. In my ignorance, I think I prefer the use of one exectutive loop with one event structure, then if necessary multiple parrallel loops operated by queues, one per parallel loop. This sort of arrangement debugs well. Since I am not curious enough to try (or not able to burn the time to try) the mutiple loop/multiple event structure method, can you tell me what I would see if the same event is firing two different event structures? Is it as simple as both EvntStructs are fired reliably and the separate loops go about there merry separate business? OR do the same events never show up in two differenct loops? Thanks, Mike QUOTE (Doon @ Apr 8 2008, 01:50 PM) I see two problems with local variables 1) You cannot use "push-button" interface with locals. That would mean that one would have to use "switch-buttons" to stop the loop and another local variable to unset the switch so that it looks like a push-button. 2) You end up with a "polling interface" type structure which suffers from potential race conditions. You run the risk of one loop quiting and precluding the quiting of another. Event Structures behave as "invisible queues". This is the result of NI's implementation of the Event Structure. This means that *sequential* event structures are dangerous (e.g., try sequencing two event loops that handle the same controls). I have always surmised that this was a "lesser of two evils" design decision on NI's part, given the intrinsic parallel capabilities of LabVIEW. have a nice day, 8D I was asking about the simplest implementation that began this discussion. That problem needs no more than a local variable to solve it and you live with how the switch functions. For my self I always fire an event with a STOP, or End All button (stop gets used for a variety of things in reality), then I deal with shutting down the various ongoing functions with queues. Mike