mross

The 'bv' sound, known to the technical minded linguist as the "rasberry noise" can be approximated by placing your lips on you forearm or significant other's belly and blowing forcefully. I heard there was a cheer performed at niweek by a team of developers that featured this sound. I missed it so I am not sure if they used the arm or belly method. The cheer was designed to build up interest in the new license agreement for LV9.0. Mike

Phew, I knew that. Will I be OK if I use LV now and then? Mike

I don't know about canned LV functions for this, but isn't xml just text with a particular format? If that is the case then it is a matter of learning to use the string parsing functions, match pattern, scan from string, and so on. I would also look in to open G software, this is just the sort of thing that shows up as open source. Mike

Attached is a vi I use exactly as you describe. At the point which the manual input is needed, I wire the output of this sub vi to the functions that use the information. Data flow proceeds to this point and the "Sub-VI Node Setup causes this VI front panel to appear. You can change the entries until you click the stop button, then the while loop stops and the information iis passed to the top level VI and it proceeds with its data flow as before. Mike Download File:post-48-1161694557.vi

You just need a VI that is a control wired to an indicator. The control can be of a cluster of controls, numerics, booleans, enums, and strings can be part of the cluster for various types of data. Place a while loop around the control and indicator and a stop boolean to stop the loop. You put both the control and indicator into the connector pane. Drop the new VI in the top level VI. Wire the output indicator of the new VI to whatever will use the data, unbundle the cluster if you used that. Now right-click on the icon for the new VI and choose sub vi node setup and choose to call open the front panel when the VI is called. When you run the top level VI the sub VI front panel will come forward when data flow reaches it. The top level VI will wait until the sub VI returns data before procedding. You fill out the sub VI, press stop and the data is passed to the top level VI. There are other levels of complication that cn be useful. YOu can initialize the data VI to always look the same when it is called. You can build into it an error cluster which provides an easy way to sequence the sub VI in the top level. I will send you an example when I get to work. Mike

You might really miss the wires when it comes time to debug or reuse the code. Property nodes are really for changing properties. Even though "value" may be a property, notice all the other stuff - that's what a propety node is mostly used for. Locals obscure what is going on when you look at the code. One of the main reasons for graphical programming is to give an intuitive feel to the data flow. Honestly, I find it inconceivable that I would get rid of wires. Very bad juju. There are other ways to clean up code. You should be making good use of Create SubVI to clean up. I try and make my Vi's so I don't have to scroll much past the borders of the screen. Good architecture and sub vis make this possible. Learn about some of the architectures like Event Driven Producer Consumer, etc. And you can bundle and unbundle clusters of the various types of data. You should avoid clustering datat that are unrealated in their function just for cleanliness' sake. I would say don't do it with locals until you have used LV for a while. And pretty code is the least of your worries to start with. Mike

Joe, It might be important for us to know why you need such an accurate wait between iterations. If this is not just an excersize, then maybe we can help you with the real goal you have in mind. That metronome is only intended for rough timing and that's why it doesn't go to smaller increments. Data acquisitions are clocked to a "Timebase." The maximum timebase will depend on the hardware you have. For instance my E-series DAQ card has a maximum rate of 1.25MSamples/second. So I could easily take readings at 10kHz, 100KHz and perhaps 1MHz depending on how many channels I need to sample. It is possible to do custom work at these speeds, but usually we just pull out some application specific vi or function that does it for us. This way we never have to write code that operates that low down in the system. Not that you can't do it, but it would be very untypical. So tells us what you are up to. Mike

As I recall the User Guide/Operators Maunal for the NI PCI 6602 counter timer card had an extensive discussion of the basic counter timer functions. You should be able to find that online if you look. If you search in the LV Example code there are vi's to do all the basic functions. Use the Find Examples function under Help. You need to go to these sources and look at the documentation. I am sympathetic, I recall that this information is cryptic, written perhaps for an audience that has used other counter timer instruments, not for someone starting new, an innocent. Counter timer use is a little obscure, and not everyone has used them with much sophistication. The NI forum for counter timers has been a dead zone for years, though that could have changed. I quit paying attention to it due to inactivity. You will need to call up the vi's and investigate the help files they contain. Start your context help (Ctrl-H) and bring you cursor over the icon for the vi. \ To this day I dislike the way these Help/VIdocumentation files are written. They can be real head scratchers. There is no wasted words to make it easy to comprehend. That is where your subscription comes in handy. After you have tried to figure it out, then you can call NI for some assistance. I am generally impressed with the level of help I get from NI over the phone. It may be useful to ask for someone with experience using counters. I know that is not very helpful. But you will need to look at all that information and try it out before it is any use to troubleshoot your problems. Mike

Did you just want someone to give you the program or do you have some code to show us what you have tried so far? This forum makes it very easy to share code and that is the tradition when asking for advise. It helps also to know what DAQ hardware or other pertinent equipment you are using. Mike

You could use an open source diagramming software. I get by pretty well with Dia. If you want fancy pictures of equipment you can get an open source photo editor to operate on digital photos of the equipment, these are then placed in the diagram as images that are scalable by dragging. You wouldn't have a nice pallette of these images but you could put together an image catalog in a separate diagram and then copy and paste from it when placing them in the network diagram. Unfortunately, creating new shapes in Dia for use as pallete (stencil) options is not easy or well documented, but it is better than making pallettes for Visio. Dropping in images is simple, but you would have limited options for connecting grips, and so on. For all its difficulties, I really like DIa and use a lot but not for what youare talking about. I make illustrations in specs to document mechanical designs and to make functional block diagrams and similar. I don't have to follow anyone else' guidelines as to appearance. Just Google Dia and you find it. I suppose you could make non-functional VIs in LabVIEW and wire them up. The capbilities for making icons in LV are limiting (pre-8.0 at least - I haven't upgraded yet) Mike

Here's a hint. You don't have to loop through an arrray to do simple arithmetic - just use the arithmetic functions they will operate on arrays using a scalar input. Mike

I see Christopher has given you some help. I did have one idea you might like to know about. You can tag your North and South data when you collect it by clustering it with a boolean where N = 0 and S = 1. Then when you need it you unbundle the boolean to pick the case you want. You are not limited to booleans and only two potentials, you can bundle an enum with unlimited choices instead, and therefore unlimited case selections. Clustering is useful whenever you want two unlike but related pieces of information to travel together. Mike I think the concepts you need are Shift Registers and Enabling Indexing of loops. Take a look at the example attached. The Shift Registers allow you to watch the data build. Enabling indexing puts the same collection of data on the output border of the loop for display when the vi is stopped. Both functions are accessed by right clicking the loop border. I threw in an initalization sequence frame that runs as soon as the vi is started to clear the graphs and to reseet the stop button. Mike Download File:post-48-1160014207.vi

Your graph will display data if you turn on autoscaling for the y axis. You haven't really stated the problem so I can understand it, the example code is a big mess with no effort made to document it, or make it neat for reading. Also, it sounds a like like school work. For those reasons I am not going to be very specific with my help. If you make it hard for us to even read the code or understand its goals then it is much less likely you will get useful advise. Please understand that good advise actually takes work to think up and present. You should be willing to work fairly hard in order to get hard work from us. If you have worked hard I can not tell. It just looks like a big sloppy mess. Sending us code is a good first step, but it needs to be quality work to the best of your ability. An extreme minimum of effort on your part is that we should not have to move icons around just to see where your wires go. Your code is unreadable. Consider this methodology: Take the problem one step at a time. First generate good data. And check the data before moving on to the next step. There is no point in trying to graph nonsense. You give no clues as to what the data should look like so I can't guess if it is the generation of it that is a problem or the display. I suggest you place probes or indicators much earlier in the dataflow so you can see if you are doing anything like what is needed. Or scrap the whole vi and start over with simples steps. Mike

I can't answer in detail right now, but you can't have two differnt x scales for the same data. The time ticks have to vary if the encoder ticks are uniform, or the encode tick scale has to vary (instantaneously) if the time ticks are constant. They are not both uniform and that is just the way it is. You can take two sets of data at different times under similar condtions and look at two different graphs. Or you can digitize the encoder along with the torque and extract two graphs from that, one in the time domain and one in the angle domain. It would be plointless to grapoh encoder v time, but you could do that. Digitizing the encoder is not likely to work with an el cheapo DAQ system. Especially if it is a high count encoder. You need to know your resolution to plan this out and not waste time. Maybe you can't even use an external clock with DAQ I have never thought about USB-DAQ before. You should check. My feeling is still that you need to clock with the encoder and estimate time. But nothing definitive can be said about what needs to be done without knowing what decisions will be made using the information. If this is just an experiment to see how LV works that is fine, then let's not labor over - it just play around and see what comes of it. But if this is real work then you need to figure out why you want the data, then it is possible to take it the best way. Gotta go, Mike

I said: What exactly are you measuring and what sort of decision do you need to make based on the data? This is very important to give you a useful answer, and I am not fond of spending time explaining the wrong solution. You said: This should be answered above Actually, you never said what decisions you need to make. I chose the wording of the question carefully. But your answer never addressed that, only some specifics about the acquisition. Your task is probably not to acquire data, it is to make some sort of choice after analyzing the data. What its that choice? You said a few rpm/sec. I assume you don't mean an acceleration and that you do mean it will be turning slowly at a a low speed so that you don't anticipate any problems acquiring the data fast enough? Assuming the second, you might be surprised how much horsepower it takes to digitaze an encoder pulse train. At some point you may want to quantify how accurately you need to measure these things and whether you have the equipment to do it. You said: Speed is not calculated, just torque vs ticks displayed. The user needs to be able to select torque or time from an x-axis listbox. This will update the display of the acquired data plot. If you do not need to know speed then you do not need to gather your torque data in the time domain. Just use the encoder to clock the acquisition. Then you have torque versus angular position. If you did want an estimate of speed over a rev you could count pulses from the encoder during some period and return speed from that using counter/ timers on the card (it never hurts to tell us whatdaq card you are using, the version of LV, and so on. You would be surprised what interesting suggestions/warnings you might get from this info.) For getting data clocked by an encoder I use Acquire N Scans D-Trig Ext Scan Clk.vi as a basis. A digital trigger starts the acquisition (use the Z pulse of the encoder), tell it how many readings to take (maybe the same as you ticks per rev) and you will have what you originally asked for voltage with respect to encoder ticks. I usually calculate average speed before or after the acquisition step to put in the records for the test. That is a straight forward counter timer function with the encoder gating a counter. Lastly: The user needs to be able to select torque or time from an x-axis listbox. This will update the display of the acquired data plot. This sounds like the cursor function that is provided with the graph indicators. Did you need something more than that? But earlier you said torque versus ticks, and now you are talking about time on the x-axis. Can you clarify?

What exactly are you measuring and what sort of decision do you need to make based on the data? This is very important to give you a useful answer, and I am not fond of spending time explaining the wrong solution. You need to decide what the encoder is for. Is it a rotary encoder? Are you intending to measure voltage as the encoder rotates? Is the encoder a linear encoder? What is the encoder resolution? Do you need to calculate very fine average speed between encoder ticks? Do you really want your data taken in the time domain? In other words clocked by the daq card clock? Or is what you really want the voltage at a particular rotational position or at a linear position (depending on the encoder), the angle or length domains? Specific to your questions: Item 1. If you acquire the voltage to a chart, then you can retrieve the chart history and each reading will be paired with a timestamp. Item 2. The only reason to time encoder ticks is to calculate speed between ticks. You can do this with timers best. It is usually silly to digitize an encoder pulse train and way too much trouble if that isn't what you really want. It is not a given that useful information is gained by knowing the average between ticks (a pseudo instantaneous speed). It is much easier and often better to know the average speed over many encoder ticks since most motors vary a bit or a lot as they rotate. If you want to digitize the encoder that is trivial if you have a fast enough daq card. Better than a timestamp is often to get the start time and just count time between readings by clocking with the on board clocks, each reading is separated by a known increment of time and you can calculate the absolute time from the start time. What good is an absolute time reading anyway? I always like accurate increments, but could care not much less about the exact absolute time. Item 3. A chart graphs voltage v timestamps. If you need XY format that is another story and not as easily done. If this is strictly theoretical, I will pass. I am more interested in real world applications or at least hypothetical real world situations. Mike

No, it is very hard to read. Now we are annoyed. Perhaps "annoyed" is also not a native speaker. However, native or not, no care was taken to organize the thoughts, and no effort was made to puctuate in a manner to enhance understanding. To the original author: at least learn to hit enter and create a paragraph every now and then. If what you write is too hard to comprehend, then not much help will be recruited. M

I needed a little utility to run a servo so I wrote it up using the forms I described earlier, and annotated it for your reading pleasure. Download File:post-48-1158345079.llb

As a general rule you may not want to put much inside an event structure, or you may get the behavior you have noticed. At least avoid putting while loops inside or vi's that have while loops. The event won't stop and the loop won't iterate until all the event border outputs are filled. That's dataflow. Investigate the use of queues. Use the event structure to enqueue integer numbers (or enums) that correspond to cases in an separate loop. For example: A user event occurs and within the event an enqueue function puts a 1 in the queue, in the other loop is a dequeue function, when the number 1 appears in the queue it is dequeued to run the case called 1. Within that case you could queue up further numbers, 2, 3, 4 that correspond to other cases. Every time the dequeue and case loop interates another number is dequeued and its case runs. The queue functions as a FIFO in this basic manner. If at some point another user event occurs it then enqueues another number which waits its turn unitl all the prior queued numbers are dequeued used. You can queue up most anything that can be in a wire. Whatever you wire to enqueue pops out at the dequeue. A typical use is to have an Enum instead of just an integer to fire a case structure. All the Enum really does us give an verbal map to the numbers that are really the otuput of an enum. There are other details to using the queue like obtain queue, destroy queue, etc. The most common use for this would probably be the event driven producer consumer design pattern. You will love this once you get the hang of it. Mike

All it takes to multitask is to have two loops running at the same time or to run a sub-vi while the top level vi continues on its merry way. You don't have to concern yourself much with the details of mutithreading. LV takes care of it for you. Do not over-think this part of it. One option: you can implement a waveform chart to receive continuously aquired data and extract the "History" using a property node. Then you can investigate the History for the particular blocks that interest you. The accquisition continues as the analysis is performed, then you call the history again and investigate the next block of data after the previous set. Everytime you fetch the History this buffer has grown to include the newer data. The chart acts as a buffer for the data. There is a time stamp for each point and you can work out how to use the timestamps as indexes for retrieving the data. Does that make sense? I may be able to put together an example if you need it. It will take me a little while to do that. My collegue has used this method with very good results for realtively slow acquisitions like you describe, but not running them for nearly as long a time. I have not used this method myself since buffered acquisitions serve my needs for very finite acquisitions. My co-worker's acquisitions are more variable in length from test to test so the chart is useful from the user side. You don't need this to respond to user input as my co-worker does, but you need it the read the History after every 10 minutes. The details to work this out shouldn't be too hard to manage. This brings up another subject. 6400 samples/second * 60seconds * 10 minutes = 3.84E6 samples. You should make sure you really need that much data before you do this. The speed of acquisition is not too great, but the cumulative size of the data is starting to get cumbersome. I can offer better advise if I know better what you are trying to do. What are you measuring? Why? What descisions do you want to make based on the data? Do you need to visually investigate the data? Or is all to be analysed mathematically within the code? What characteristics of the data interests you? Maxima, minima? Inflections? Slope? Anomalous events? Is there some reason why you need so much data? How many 10 minute sets will you need? At some point you may need to consider aquiring less data or you will need to decimate the data. If your interest is to visually investigate the data, then your sample rate is much too fast. It is much better to be specific about what you are trying to accomplish. The devil is in the details. Mike

You mentioned neater looking, that is certainly very good. Easy code re-use was mentioned. Each subvi is a standalone program. If you think ahead, many times you can make a specific sub vi genreally applicable. Code testing is easier becasue you can test the subvis without all the surrounding code. Simnilarly debugging a large application is easier when you know exactly what small protion of the vi is hanging. You can have the front panel of a subvi active and watch it as the higher level program runs. When you learn to build in error clusters that pass through subvis you have a vary clean and useful way to sequence "code snippets" and to pick up erruntime errors for later review. And so on. The advantages at this level are unlimited. If you are smart in naming subvis, and creating icons, descriptions and tip strips you get some very handy documentation. Context help pops up for all sub vis showing the in and outputs their type and representation. This can be enhanced with descriptive text. Sub vis can save data for reuse during runtime and can be shared among running vis, like a global with processing capability, there are other permutaions of this use. See functional globals or "LV2 style gobals." Maybe best of all is very easy, very independent (of the spawning vi), parallel processing. Imagine you want to write a lot of data to a slow output line. You may not want your program to wait for that. So you have a sub vi that writes serially to a port. The top level vi calls the serial writer by passing it a dataset. The top level vi and the serial writer go on about their business with out interfering with each other. All you had to do to make that happen was wire the data to the subvi. When the subvi completes it can pass data back to the top level or not. The sub vi can generate error dialoges, warning dialoges, display graphs or other user interfaces. For example I have a test executive that is mostly machine controls and test selectors. When I run the tests I often want to see the results graphed, but I don't want to take up space on the front panel with a graph that does not need constant monitoring. So I have a sub vi containing the graph on the FP and maybe some processing on the BD (block diagram). Right clicking on the sub vi onthe top level BD reveals the "sub vi node setup" and one option is to show the FP when running. I can make the FP pop up for a finite duration or I can make it wait for a button press to stop. If the sub vi was not visible when called then it goes away when it is completes or when I tell it to stop. So it is not only the BD that is simplified but also the UI. Once you get uesd to this it will be like clouds parting after a monsoon. Mike

I think you need to have all the plots wired up first then you can assign the scales to them. At least I encountered a similar sounding situation when I made the example - when I had only Plot 0 and Plot 1, I could not assigned y axes to Plot 2 and Plot 3 until I had them all bundled up and demonstrably plottable. It would be helpful if you posted code to look at. You can be sure that if you have vaild data for plotting that you can assign different axis scales. Mike

Check out the attached vi (in 7.1). I used a random number generator which is kind of stupid looking, in terms of results plotted to a log scale. The marker points are the same data plotted to the different y scales. Plot 0 (scale by facor of 10) is set to one scale and Plot 1 Scaled by a factor of 100) to the other. I got the info on how to make the 2nd y axis from the help system. I used the graph properties to adjust the scales and the other business like showing dots and increasing the line size. There is a scaling parameter in the properties that will help you adjust 5dB 10DdB however you desire. The tricky part is getting the data into the form that the XY graph likes. The thing to remember that with XY you are plotting ordered pairs and the graph has to have the right format of incoming data to see what pairs are ordered. 2 corresponding arrays are bundled to make a plot. The plots are arrayed to make a multiplot. The markers are single ordered pair plots. The context help will remind you if you bring your cursor over the XY graph icon. MikeDownload File:post-48-1156943525.vi

You run the result into a greater than function. If it is greater than 19 you want it to put 0 in the SR. The output of the greater than is T or F. T = SR = 20. Wire that to a Case Statment and wire the SR itself to the Case as well. In the False case you wire the SR to the right side and then to the right border node of the SR. In the T case you put a 0 numeric constant which you then wire to the same output node of the F statement. Each time the loop runs it tests the value for twentyness and either passes the value or replaces it with 0. Notice that you have the loop conditional set as Stop if True and the default of the Boolean control is up True. Either change the loop conditional, or change the default value of the Boolean. Mike