mross

Can anyone tell me if there are some VIs for linear algebra and matrix math using extended precision? Thanks, Mike

Shaun and JG, I have been doing this for long enough you would think this little tidbit would have been noticed by me, but I have a habit of not auto-indexing when there are complications. This time I did it and noticed. Thanks for the help, Mike

Howdy all, I am learning to work with TDMS. Maybe that is the source of the problem... I have a for Loop that runs one pass and stops even though i have wire a 4 to the count terminal. I do TDMS open, run some arrays to the border for indexing. In the loop I want to TDMS Write some numbers, several times, then loop and pick up the next index, write, and so on. Outside the loop is TDMS Close and I call the File Viewer. I get no errors. I cannot get the loop to continue past the first iteration when it lets the output data go to the TDMS close and everything stops. I may be messing up the TDMS write somehow - the way it works is a bit perplexing so I keep thinking I have it and then it doesn't like what I did. But like I said no errors. I'd listen to advise. The wires are not pretty in the image as I have been tweaking, the open and close used to be outside the loop. Moving them inside changed nothing. Thanks, mike

I never see the printer ports (Have a USB one, not parallel). I have given up on the Prolific chips sets for serial com converters - maybe that is what you are using?. FTDI seems to be less troublesome. EasySync is their outlet

Shaun, The fellow I work with is taking a controls class from the same prof I did 20 years ago (so I know he is worth listening to). He was reported to have made a provocative statement to the effect: People are always trying to come up with some special algorithm for control, but after screwing around, and around, and around, they always find out the PID would do it better. (my words again) He believe meant that to cover even the asymmetrical case (that should be defined in more detail probably). I suspect he is very good at ferreting out the P, the I , and the D. But that is a weighty statement. I will probably keep it in mind and not give up too soon. Mike

Ned, That first sentence is interesting to me. "PID is designed to drive an analog signal, not a digital one." I will soon be wiring to control fluid temperature by varying two streams, one hot, the other cold. I definitely thought I would use PID, but you have me wondering - my control means is to send RPM commands via Modbus to VFDs in charge of pump motors. The plan is to use cRIO, FWIW. simplePID.vi was recommended to me as a starting point, I haven't gotten that far yet. This is digital output not analog. Do you have any advise? My goal is to be able to change from one steady state temperature to another as fast as possible - including an initial overshoot to cool or heat the plumbing quickly. mike

This has become an exercise in social engineering and language, very interesting. Mark posted the questions below in the thread quoted above, have these been addressed? What is the final data going to be used for? No discussion of the purpose of the result What does the data represent? No discussion of the real implications of the input data. Why do you want to average / smooth the data? No discussion. What does the peak and valley data tell you about the waveform? No discussion. How do you know if the program is doing the right thing? No discussion. Those questions are reasonable in the absence of a clear description of program goals. I imagine they are hard to answer if either the language gulf is too great, or the questioner has no clear idea of the desired results. When trying to solve a problem for a client who has no idea how to solve it, it is possible to provide good solutions, IF a basic understanding of the higher level needs are understood by both parties. That is why the questions above are so important. AND, if either party is unable to answer those questions, then a successful solution is unlikely. Seems hopeless so far. There is one final item - that of premium membership. It still has not happened. I have to say that I hate PayPal. I simply will not put my personal information in their hands. I would have resubscribed as a Premium member just now, but I need another method to make the contribution.

Hello Flower, I am also building a sun tracker so I am interested in your project and progress. Perhaps we can stay in touch about this going forward. Unfortunately, I did not find the attachment you mentioned. It has been a while since I used LAVA - in the past it was necessary to upload vi's to the LAVA storage area where interested people could have access to it. I originally planned to have my tracker stop at sunset (sunset can be in a lookup table or calculated) and cycle to a park position (collector in a horizontal plane to reduce wind loads overnight when it is not necessary to track the sun) until it is time begin the next day. I may decide to park sooner than sunset - also to save power. I will be monitoring Precision Spectral Pyranometer (PSP) and Normal Incidence Pyrheliometer (NIP); when the solar irradiance drops below a minimum value my testing is finished for the day and it is time to rest. I am not using steppers for my project. I report position of the collector platform by using absolute encoders. One is for the solar hour angle from due south, the other the solar zenith angle from directly overhead my location. The motion of my collector comes from linear actuators (worm gear screw jacks). I will just jog the linear actuators into position according to what the encoders report and what the equations say is necessary for the time of day, date and geographic location. In either case (by your method or mine) we must have a decision in our program that depends on a time of day or some other datum which signals time to go to a new day position or a park position. If you can give me access to your vi, perhaps I can help. Michael Ross

QUOTE (jackmax @ May 19 2009, 09:43 AM) Sorry, I can't use LV8.6.

QUOTE (jackmax @ May 18 2009, 10:56 AM) You should show us the VI. There are too many reasons for the buttons to lock so that information is not useful.

Yair, Thanks for that bright and concise philosophical discussion. Not being a student of computer science I couldn't have begun to describe the distinction. I know controls, wires and indicators are not variables in the C, Basic, Fortran sense, but I couldn't have begun to say how they differ. I was taking the similarity more from the English/mathematical word (as apposed to Computer Science) "variable" - a thing that is quantitatively changeable - magnitude, direction. A wire IS variable since it can represent alterable quantity, or in the case of wire representing a string, changeable meaning. Likewise a control or an indicator fit this looser definition. The OED has nearly two full pages devoted to the definition of "Variable." Mike

QUOTE (lovemachinez @ May 14 2009, 10:54 AM) Yes and No. A LabVIEW variable can do similar things compared to a C variable, but it is more interesting and useful becasue it has a visual aspect Tim S answer was just fine, but I will add a more. Nobody ever writes all this down because most people learn it quickly by being shown by an experienced user. When learned this way the simplest things seem obvious. But, if you have progammed a text based language and come to LabVIEW alone and with no guidance, then even these small things are difficult and NOT obvious. I hope the following information is helpful. To make a "variable" right click over the Front Panel (FP) a pallette of menus will appear. In the pallette select the Modern or Classic menu. Then select the first menu item "Numeric." The simplest "Numeric Control" looks like a number in a box with a small up/down button to the left. Pick that with the left mouse button and place the icon on the FP. The front Panel is the Graphical User Interface that the program operator sees and interacts with when the program. (Program = "Virtual Instrument" or VI in the LabVIEW development system) This is a control "variable" that can be edited while the LabVIEW VI is running, or while you are in programming mode. If you go to the Block Diagram (BD) (double-click on the control with the left mouse button OR press Ctrl-E on the keyboard to bring the BD into focus) you will see the Block Diagram representation of the control. All the other selections in the Numeric menu, dials, sliders, and so on, are merely different visual forms of a numeric control - they alll have value, format, and representation (double, interger, etc.) just like the Numeric Control. If you right-click on the BD representation of the Numeric Control a menu appears. Pick "Create," then "Indicator." A new Icon appears and a wire connects the original control with the new "Indicator." If you look on the FP you willl see there is a representation of the Indicator. The variable you have created is a Double Precision variable. In a sense the control, the wire, and the indicator are all the variable. The control is the varialbe in a form that is runtime editable, the wire is the means by which the value of the variable is present through out the program, and the indicator is a visual indication of the value of the variable. If you wish to have an integer variable (int), right click on the control (at the FP or BD) and pick "Representation." You can "declare" whether the variable is an 8, 16, 32 or 64 bit integer, or one of the various unsigned integers, or one of the various precision or complex variables by picking from the Representation menu. If you wish to have a string (like char) variable create a control but select the String & Path menu. You can make Boolean (binary variables) with the items in the Boolean menu. Changing the representation of the control will cause a mismatch with the indicator, the value will be coerced (forced) to the form of the data sink (indicator in this case) and the coersion will be represented by a very small triangle where the wire is attached to the indicator. If you change the Representation of the Indicator to match the Control the "coersion dot" will go away. Good luck, Mike

QUOTE (Michael Malak @ May 13 2009, 07:29 PM) You should look at the capabilities of VI Server. You can start up many new VIs that way. However, you cannot cause new graphs on the front panel of a VI which is how I interpreted your query. You can only hide and show them by various means, or put them on Tabs and change the visible tab - programmatically. Here is a little demo of how to use the Open VI Reference you mentioned. This example was written for a someone else, but it is useful as an general example. It shows how to call and open a VI and its Front Panel independent of the calling VI. It also shows the use of the Producer Consumer architecture which demonstrates parallel loops, queues, and the user event structure. You will need to put all 4 of these files in your C: directory, or you will have to change the paths to the VIs and data file. (the Data Logging VI also has a path to change). Run the top level VI called ProdCons_experiment.vi. Press the INITIATE DATALOGGING button to invoke the data generation and logging VI. Press the PRESENT GRAPH OF DATA FILE button to to invoke the display a graph of the data file VI. This method allows the Top level VI to continue operation independent of the invoked VIs. It is possible to have sub-VIs to show their front panel when called from within the top level VI, but the top level VI then waits for the sub-VI to finish before proceeding. The original purpose of this was to have a datalogger VI write to a file periodically, and to show the contents of that data file on demand. I use this example to remind myself how this is done. Mike

QUOTE (Michael Malak @ May 13 2009, 04:14 PM) You can't "dynamically instantiate" anything without scripting, and that is not where you want to go. We are trying to offer you solutions not pipe dreams. Did you try a tab control? You can put graphs on different tabs and programmatically cause different tab pages to be visible. Or with much more trouble you can move the locations of the various graphs so they are visible on screen, or they are off screen. If you try to manage that with 64 individual graphs you are in for a long, boring, job that will be of limited use to the user. I gave you a way to show absolutely any combination of the 64 plots overlaid in the same graph. Use that and you work is almost done. You could decide that realistically only 4 or 6 graphs provide useful visual information on screen at the same time, and give the user the ability to show any of the plots in any of those graphs. Mike

QUOTE (Michael Malak @ May 11 2009, 07:21 PM) Michael, You didn't ask for this, but I will give it anyway. I think it contains the ingredients of a better solution than 64 little graphs. There are other ways to do this, but this one is basic and shows how arrays are manipulated. The attached VI shows a way for you to overlay any of the 64 channels in one large graph. I made fake data in 24 rows of 40 data each. The rows are like your channels. All you need to do is wire your data array into the same input tunnel as my fake data. The UI lets you enter the channels and turn them on and off "on the fly." You could show all the channels at once, but that is clearly not useful. I show the data itself on the front panel so you can get some confidence that the senseless random data I generated is actually doing what I say it is. Array 2 is the same as the graphed data. On the block diagram the operation is quite simple. Starting from the inside out, the array is parsed using the delete from array function. An index of the desired channel is used to pull out the channel of interest (it is the I16 (16 bit integer) wired to the Index (row) input of the Delete from Array VI). The User Event Structure is triggered every time you enter a new channel or turn a channel on or off (for either it is a Value Change). You press the little LED to turn the channel on off, you enter a channel number from 0 to n in the numeric controls next to the LED (Boolean). When the event is triggered the for loop works its way through the channel array and the LED array element by element. Using the default values - Plot 0 is ON and the channel is #9 (the last one shown), Plot 1 is OFF, Plot 2 is ON and gets channel 1 (the channels start from channel 0). Notice the little square brackets inside the input tunnels of the channels and On/Off Boolean array's wires to the For Loop Structure. This is called auto-indexing. The loop automatically works its way through the array when this is set. (Input terminals with no brackets pass their arrays all at once.) On the first loop iteration channel 9 is indexed from the main array (auto indexing disabled for this one), placed into the build array function and passed to a shift register ( the little box with orange up/down arrow) of the For Loop. On the second iteration the Boolean is false (OFF) so the Case Structure runs the False Case which passes the shift register unchanged to the right side of the For Loop. On the third iteration the Boolean is True so the True case extracts channel 1 from the main array and "builds" it into the array with the results from the first iteration. And so on. The For loop stops because the arrays have been run to completion as set by the array size wired to the Count terminal of the For Loop. When the loop finishes all it work the Shift Register, built from the parsed channels, passes its data to the graph and the results are displayed. Shift Registers are way cool because you can build them with any contents you need - doubles, integers, strings, time stamps, Booleans, clusters of arrays of strings, you name it. Each time you change a channel entry or an ON/OFF LED the whole array is parsed and a new graph written (not terribly efficient if you have a huge array, but OK for medium sized arrays. If you pick the Stop Button the Stop event is run and a True is passed out to the conditional of the outer While Loop Structure. the While Loop stops, the loop conditional True Boolean is inverted and used to reset the Stop switch with a Value Property Node. Nothing more is wired so the VI stops. This is a good example worth studying. You will do this sort of thing over and over if you keep using LabVIEW. If you haven't learned it yet the little Light Bulb Icon turns on highlighting and lets you watch the progress of the VI. LabVIEW is a data flow language not sequential. Nodes only begin when all their inputs are filled, and stop only when all their outputs are filled. If you have never encountered this before you will have to think on it a bit to see all the implications. Good luck and enjoy, Mike