mross

QUOTE (scls19fr @ Apr 7 2008, 04:28 PM) I apologise if I am incorrect, this is starting to sound like school work. We prefer not to answer these things for folks who ought to be working them out alone for school credit. Can you show us a little of your own attempts at coding this so we have an easier chance at making useful suggestions? I am not going to try to model this if you have already done it. And if you haven't already done it, then I shouldn't be doing it for you. IMO. Mike

QUOTE (Doon @ Apr 7 2008, 03:45 PM) I am having a hard time with this. What is better about this than a local varialble? Not to mention the trouble that can be caused by multiple event structures (theory to me since I have never had to resort to such a thing). Also, NI says don't use multpile event structures, so I don't. I have always lacked the curiousity to find out why they say that. Mike

QUOTE (scls19fr @ Apr 7 2008, 09:28 AM) You need to understand a basic principle of LabVIEW called "data flow." A VI does not proceed acording to a sequence of commands as is common with text based programming languages. With data flow every item, functaional block, or sub VI begins to function only whan all the wires to the item have brought data. IF one wire is nver activated then the function will remain idle until the data is produced. This is true also of loops. If you ignore what is inside of a loop it is similar to every other fcuntion on a block diagram - it has wires that bring input data and wires that carry away output data. Of course controls, indicators and constants can only have one type of wire. A control and a constant are only outputs. An indicator is a sink (or receptacle) for data - and has only input wire coming to it. A loop must receive data on all its input wires or it will not run. Only when the loop has stopped running will ot produce data on its outputs that are sent to the next wired function. You can turn on highlighting to examine how date flows at slow speed using the light bulb icon at the to0p of the block diagram. You should do this. You should attach pictures of your code or attach the VI itself to get the most informed responses. Without that I am guessing, but I will try to say why your second loop does not run. The wire from the Stop of the first loop must stop the first loop before that wire can carry the stop information to the second loop. But still the second loop may never run if all the input wires on it have not brought data. If the loop is never run this is the only reason. In data flow any loop will run if all the input wires are activated and the data is received. Next you will need to notice that a loop never puts data on a wire until it is completey finished looping. If you make a local variable of the Stop button and place that in the second loop, then the second loop will read the local variable each time it loops as data flow allows. Since there is no wire from the Stop button, then the loop wil activate as soon as all other inputs are filled. Use the highlight button. It is instructive. Show us your code to get better answers. Mike

QUOTE (xcgeek @ Mar 26 2008, 07:34 PM) Ignoring the mechanical parts, it doesn't sound bad at all for an expert. Everyone eats a project one bite at a time, you are working with a handicap. LabVIEW is a data flow programming language which is wonderful, but your intuition and thinking is all wrong for it. It takes a while for it to dawn you all the ramifications. LabVIEW is very gentle in terms of getting syntax right. In many cases syntax is never an issue. This save a lot of time for the new user and the old. Much of the helpful information is online and that always takes time to get in synch with. If you have the subscription service then you can call for help and the NI engineers are very kind and excellent. (Lets see you get that from those other languages.) I couldn't possibly guess how long it would take anyone. Not my forte. No one makes me count time like that so i can't guess well. QUOTE 4. It seems like there are a lot of tutorials and sites like this to help, is it reasonable to think that you can get help for specific questions and problems quickly, or are unforeseen roadblocks a real possibility. Many thanks for any help you folks can provide. The forums at NI, LAVA, and this one are all responsive. All are searchable. You can get lot's of help . Sometimes the quality of the questions makes a difference. I personally think you need to explain the decisions you will be trying to make with the DAQ you take. Explaining the problem at that level can get you some really interesting solutions. If you go at it asking very specific things...what if those specific things are off track? I certainly have not regretted learning LabVIEW. I find it fascinating (though I find the documentation of functions too dense and too much left unsaid at the same time). A hard core programmer has different hammers to choose from, but I am happy with this one. Enjoy, Mike

QUOTE (professor_rumsdiegeige @ Mar 20 2008, 08:24 AM) There is a pallette of array manipulation functions. You need Index Array. This is probably the most basic data manipulation function in LabVIEW and it has been present from the start. You need Index Array.

QUOTE (carleton_hanson @ Mar 12 2008, 11:02 AM) Sounds like the scanning business you propose is not needed and the root problem is FFT "not working." You should solve the FFT. I don't ever mess with that so someone else will have to chime in. If you unpack the write to sprdsht vi you can pull the open and close out of the loop. However, I don't understand why you are writing to the spreadsheet every loop iteration. Why not keep the data in an array (shift register and build array) and write it out when you are done so there is no file accessing at all while doing the AI Read. Mike

QUOTE (Eugen Graf @ Mar 11 2008, 04:21 AM) Eugen, I can also edit directly the values in a table indicator. Add it can be changed at will between indicator and control function. Actually it looks like all the same options are available for table controls and table indicators. I can't tell the difference other than the data sink, data source function which pertains to how it can be wired up in the context of a VI and its runtime function. It seems like you are not talking about a run time use. I can't detect any particular advantage to a control other than that it is a data source (for saving). And no particular advantage to a table indicator other than to receive data without having to resort to a local variable or property node write the values You said, "Of course you can double click on the table (or klick on the edit button) and pop up a new window and enter new values from there." I am using 8.5 - I don't seem to get this action you describe. When I double click I just move between the front panel and block diagram. And I couldn't find an edit button at all. I obviously am missing something that you are trying to explain. Mike

QUOTE(Eugen Graf @ Mar 10 2008, 05:09 PM) OK Eugen, I'll bite. For what reason is a table control (getting data from a local variable or a property node) better to use as an indicator than a table indicator. The difference isn't obvious to me. Mike

QUOTE(mcguirpa @ Mar 10 2008, 04:11 PM) Controls are data sources and indicators are data sinks. YOU DO NOT WANT TO MIX THEM UP. If you right click on the control, select Visible Items, and check Digital Display, you will see there is now an digital control that is synched to the slider. If that isn't what you want then you should investigate making you own custom controls. Mike

QUOTE(lizimunro @ Mar 6 2008, 07:10 AM) Aristos is correct - lose the sequence frames. They just make it hard to look at. My instinct would be to decouple the read operation from the string processing completely. This would definitely be easier to debug. I would probably create a queue where the Elements are a cluster of an enum and the resultant string data. A successful VISA Read would Enqueue the Element including the string result. An unsuccesful Read would Enqueue error information for possible use in the Processing loop. The Processing loop would be a separate While Loop (not nested) where the data would be dequeued and processed. To build sucessful string processing code you would need some data to simulate the expected results from the Read operation. When this code is able to perform properly, THEN you put it in a while loop and feed it a series of data blocks and make sure that works. Then you bring in the Queue and Case statement and process the data as it is produced. If you are not aware of how queues work this implementation is equivalent to a FIFO buffer (1st In 1st OUT). The Read operation can produce as many bocks of data as it can, as fast or slow as it can, and the processing loop just takes it one step at a time. If it finishes all the queued blocks it just waits until the next one arrives. In side the Processing loop you have a case statement containing the processing code and at least one other frame fro processing a Stop command which would be generated in the Read loop and Enqueued there. I would try to show this, but I can't really run your read function without your hardware. Maybe you could show us some real or simulated strings from the Read operation. Also, your start test button doesn't do anything. When you run the VI the loop starts running immediately without allowing time for you to choose a different duration and test type. If you really want to change the Test Type and Duration after the VI is running you should investigate the use of User Event structures. I would advise you do that anyway, they are too important to remain ignorant about, particularly if you are creating GUI Front panels that the operator is expected to interact with during run time. Mike

QUOTE(Jerry_June @ Mar 1 2008, 02:52 AM) You will need the runtime engine to be on the computer or there is no way it can possibly work. If you have a Java app you need the JRE - same thing. You can install the engine as a separate step (it is cost free) or do as Ton said build the .exe so that it installs the engine. Another option is to use VI Server functions to run it over a network. Mike

QUOTE(lraynal @ Feb 26 2008, 05:15 AM) Of course at some level of complexity you get problems, but not at this level. You may notice that there is not a lot of conversation on this topic. This is because it is not usually a problem. There are extreme cases and choosing the correct architecture is definitely the solution. Keep in minid that quite a lot of the work is not done by the PC. The DAQ and I/O are configured and then the PC just fires these tasks off. You have a very efficient engiine running on the DAQ board to deal with the gathering of data, and writing to and reading from the I/O. The PC can't keep pace with data rates greater than 1KHz on its own clock. The whole point of PC based DAQ hardware is to enable these functions without causing hardship for the PC. The general principle is to set up your loops so that you don't repeatedly configure and release DAQ resources. For a DAQ operation you would group and configure the board resources outside the loop, and inside it you perform the read and write operations. As long as the loop is running the hardware has only to do the work it was optimized to do and the PC only the work it was designed to do. An example of a wrong-headed design would be to put a single point acquisition in side a loop and run it over and over again. Instead you might run a buffered acquisition and sample the buffer periodically while the acquisition continues uninterrupted. This principle is followed within the Express VIs, other higher level VIs, and other code you may copy for reuse. You only need to concern yourself with how this is done if you can't locate the exact code you need and you must create it yourself. Reading and writing using some add on hardware is what this whole business is about so you can generally find what the code you need already in use. There are some general guidelines about what operations should be placed inside a loop and what should not. You should become familiar with these. Mike

QUOTE(newprogrammer1 @ Feb 14 2008, 04:34 PM) Each "hardware" will require something different to command it. There are different methods to cable between the PC and the hardware: Serial communication, USB, GPIB, VXI, ethernet, wireless, etc. You may have no choice or you may select among several choices. There will be some sort of language or protocol for successful communication. You must know this to proceed. There is a great amount of variety in the sophistication and quality of the driver software that comes with a "hardware." Although is is very possible and also common to use LabVIEW for this purpose, it is not practical to answer your question without more details. At least tell what motor and motor drive is to be used, the cabling system, and the language or protocol. If you can obtain LabVIEW driver software from the motor drive manufacturer this may simplify the task. If no driver software is available you will have to write and communicate your own commands starting from scratch. This can be a very big job. I command several motor drives for which there were no LabVIEW drivers available. I used serial communications to send simple commands and did not try to create an entire command set, only the half dozen commands that I need. The protocols include, Modbus and a couple of non-standard protocols. In each case the commands themselves are radically different even if the method, the protocol, used is the same. For instance motor drives from two different manufacturers could both use Modbus, but there commands sets have no common words. Good luck, Mike

Bhima, You may first wish to create a backup of the current file system, if that does not already exist. There may be better ways to do this, but I think all you need is to save it in 8.5 and save all suv-VIs to raise it up. To clean it up: Open the top level VI. File/Save As Duplicate Hierarchy Give it a new location GO Since you don't like the reproduced Hierarchy you can now move the new file set around as you desire. You can call up the top level VI and manually direct it to the new locations. Use View/VI Hierarchy as an aid if you like. If you want new names for the old sub-VIs there is no simple way to do this. You just have to rename and make the top level VI call them all up. VI Hierarchy is a good help for this sort of thing. Mike

I don't get the point of more than one user event. Whatever the event may be I already can test the currrent conditions and fire any number of different tasks based on the the event and conditions. I looked at the vi and without some problem to solve it just looks like much ado about nothing. I am open to education here. Presumably, new functionality was devised that is useful, but I don't get it. I think I need a practical example. Mike

QUOTE(Natu @ Jan 19 2008, 01:41 PM) Natu, I see that this is the first time you have used the LAVA forums. Welcome. It would be worth your while to read the LAVA guidelines: http://wiki.lavag.org/Forum_Guidelines In particular note the section on Homework Hustlers. These forums are a regular stop for students wishing to get solutions to academic problems without expending the effort to do the work themselves. Their questions often look like the question you have posted. In the guuidelines there is a link to an article on how to ask a good question in an online forum. I actually have a vi (that could be used similarly to the AND, OR, NOR primitives) which functions as an RS flipflop. However, in putting it together I realized that it is not a very good thing to want. Essentially, Q' follows R, and Q follows S. [ http://thalia.spec.gmu.edu/~pparis/classes...01/node115.html ] When the inputs are TT orr FF the states returned are undefined and no change. This means that an RS flipflop is esentially trivial as a LabView function. So why would a person want such a thing? So if you could explain the real problem you are trying to solve with LabVIEW, then perhaps we can help you. It is very likely that there a better way to do what an RS flipflop does in LabVIEW-which expalins why there is no such function in LabVIEW. Finally, it is always better to have tried to work it out on your own some of the problem and show this work to the LAVA members. National Instruments provides so much helpful information in the program help, and online that these are always a good places to look for information. M

QUOTE(Natu @ Jan 19 2008, 01:41 PM) What have you tried so far yourself? Mike

QUOTE(longzoo @ Jan 18 2008, 09:23 AM) You could use a chart instead of the graph. Turn on the x scroll bar and set a long chart history. Then you can scroll back through data that is no longer on screen. If you wanted to automate the chart presentation a little you can monkey around with the chart properties on the fly using property nodes. Chart propertiy nodes have more options than you can shake a stick at. Mike

QUOTE(wiggie @ Jan 16 2008, 09:24 AM) Remeber that it is plotting exactly what you are telling it to. You have to give it the right data in the correct format to get it you show what you want. If you just give it a 1D array of magnitudes, the graph will simply plot them spaced evenly and apply a defeault increment for the x axis. You need to tell it how to scale the x axis in some way. The old way was to use the Waveform Data format which is a cluster of the 1D data array, and a scalar each for the X0, inital x value, and the increment for the x axis, dX. The context help for the graph shows you that. Anytime you have regular x axis increments beteen data a simple 1D array is all you need to produce a plot. Then you can change the plot scale usning the graph properties. You access this by right clicking the graph on the FP and selecting Proerties. Go to the Scale tab and tell it the offset and multiplier. If you leave Autoscale ON then the graph will put the last datum on the right edge of the graph. Alternately, you can create the Waveform cluster which contains the X0, inital value (offset), and the x increment, dX (multiplier). Then you don't need to change the properties and you can control the offset and multiplier programatically. I assume you can still create multiplots from wavform data, but they just don't spell it out in the context help anymore (LV keeps changing). If you send me a set of real data, I can make an example vi. That is actually simpler than trying to verbalize all the permutations. Just take an indicator of the data array, make it default to the current data, drop it in a new vi, name it, and send it to me. Mike

I can't tell much about this becasue I can't see the data and graph on the front panel (FP) and you don't say what is wrong with the frequency axis display, only that you don't find it to be proper. Given that, the first question has to be - how do you know it it isn't proper? Did you check it by some other means? Or is it nonsense? Is the data array transposed? Nevertheless, I can make general comments. Without wishing to be rude, if you give it data formated the way the plot needs to be, you will get what you want. The reason you don't have what you want is becasue the data is formated wrong. You need to show and explain to get specific help. If you activate the Contex Help (Ctrl-H in English LabVIEW) and pass your cursor over the icon on the block diagram (BD) the context help will show you the data forms that will produce a graph. If you just give it 1D data, it will assume a regular unit interval and put all the data on the Y axis. You get coordiate pairs like this (0, m0) (u, m1) (2u, m2)... The waveform data form gives you a method of specifying the regular intervals by providing a starting x value and an interval length. The x axis is then implicit and you only provide the Y data to go with it. If you give it 2D data it will put up a multiplot with a unit interval between each like pair or more of data. you get one plot (0, m0) (u, m1) (2u, m2)... and another (0, n0) (u, n1) (2u, n2)... You must give it two rows of Y data. If you don't want regular intervals between each point -then you need to get involved in an XY plot. If you give it two columns of Y data, then you need to transpose the array. Imagine that you gave it 2 data sets with 10 elements each but they were columnar instead of rows, you would get 10 plots with 2 points each. Transpose that and you get 2 plots with 10 points each. One way to learn this is to create fake data in a constant or control that has a known result and tweak it until the graph does what you want. Then give it real data in the same format. Mike

QUOTE(smm @ Jan 7 2008, 09:43 AM) Just a comment to help you get help. Please hit the enter key every now to create paragraphs and thus make your post more readable. I wanted to give up just looking at it. I glanced at your vi and think there is one principle you need to know immediately. The way your state machine is constructed, none of your functions is wholly parallel. The case structures within the outer while loop will execute in parallel, but they will stop each in its own time, and the while loop will wait until all the cases are completed before proceeding to the next iteration of the while loop. It is more common when running parallel operations to have a while loop for each process. Here is the principle I mentioned: All of the structures - case structure, for loop, while loop, sequence structure, event structure, etc. - they will not operate untill ALL their input tunnels have received data, and they WILL NOT stop and pass data untill ALL of their output tunnels have received data. This means that if anything happens to hang any of your case structures the whole vi will grind to a stop and wait for that data to be produced. This is becasue the outer while loop is going to wait for each and every one of its output tunnels has received data before it wil recycle and produce new inputs for all the cases to run again. This is the principle of data flow. Data flow is what makes LabVIEW work in so many ways that are easier than the usual text based programming language which is sequential. But data flow requires a shift in thinking that can be slow in coming. If you learned a text language in the past and are just now learning LabVIEW without any gurus nearby, it can be a very important point to hear about data flow the first time. Another style comment needs to be made that is we usually try to fit the entire block diagram (BD) into one screen so that no scrolling is necessary. This is done by the creation of sub vi's. Your "Cool Mode" case would be a good example of where to create a sub vi. The sub vis add depth to the code rather than height and width. Sub vis are opened up by double clicking on them. You have created a vi that is unmanagable with out the use of the Navigator Window. It is fair to say that the navigator window was created partly to help out with small monitors, but also to compensate for badly built vi's that are too large in screen area. The use of sub vi's does not hamper execution at all. In a sense sub vis are a fiction for the programmer, each time you change the BD or front panel (FP) the vi is recompiled behind the scenes. There is essentially one big program running behind the scenes and you are absolved from worrying about that, at least for mundane programming. I don't mean that as a slight since for 6 years I have never had to concern myself with the behind the scenes business - all my own work with LabVIEW is mundane by that definition. Sub vi's are your friends. They will make debugging much easier to accomplish than a large BD. Mike

QUOTE(Lars915 @ Nov 19 2007, 12:44 PM) I have a MODBUS motor controller so you might be interested in the programming for that. I think there is a CRC, twos compliment and all that, whichmust be dealt with. Otherwise MODBUS was simple enough for me to manage.

I would use an Event Driven Queued Producer Consumer. If you want an example, ask. You might want to mention the make and model of thermal chamber and the manner of communication to it. If it is an older chamber the com maybe serial. This is automatically non-trivial and you may get some help specific to that protocol on this list. At any rate, you will be forced to learn the command protocol for the chamber and this may not be a fast job. If you are lucky the chamber has a beautiful set of LabVIEW drivers to use. In that case it won't be so bad. That odds of that are probably slim. I have worked with two chambers, Tenney/Lunaire and Cincinatti Sub Zero. Both designed and manufactured in the 90's and not so easy to work with. Both have pretty bad documentation, the CSZ is notable in its crappiness. The CSZ GUI is seriously crapulous (they say they are better now since getting rid of the Eurotherm controller). Usually these companies have some old dude who can help solve specific problems. If you have an older Tenney/Lunaire I could give you what I was using for a while. It was saddled to a PC that no else could stand to use anymore. It was painful to use and I didn't have the inclination to keep working on it. Tenney did have a better PC interface that the free one they gave me, but I didn't have enough need to justify buying the good program. Whatever chamber you have it maybe that for a few hundred someone has already written something that does what you want. I can promise you that a few hundred is less than you will spend writing something. If you have to start from scratch you may be in for some long nights for a couple weeks. It will be interesting though, and you will learn something that could be handy. Mike

QUOTE(hviewlabs @ Nov 15 2007, 07:44 PM) Hi Stan, I am with you. If you don't have the vocabulary, then you can't manage the complexity that is possible in reactive systems. During an intial state an event occurs which triggers an action that transitions the system to a new state that endures. States have duration, this is their essence. What goes on during the state is exceedingly broad, it could be randomness - like white noise, or it could be no occurrences outside a range, or a count not having been achieved, but the common factor is a time duration. The other words event, action, and transition do not have duration in all instances. Also the context is important. From the POV of a program, we often model events, actions, and transitions as having zero duration or at least a duration not worth consideration. An event is a concurrence of states or other events, but may or may not have duration. An action implies some intent which may or may not be successful, but a state does not have this property. A transition has an associated transfer function. A state does not. A transition in a program may be viewed as instantaneous. So events, actions, and transitions are distinct from states. We can talk about a state of change or a transition state, but this just blurs what a state is in the context of programming. Mike PS - I have two references that are worth looking at. David Harel's (The Weismann Institute of Science) paper, "Statecharts: A Visual Formalism for Complex Systems," and "State Machines and Statecharts by Bruce Powel Douglass, PhD. (i-Logix). I think Stan or Paul Sullivan gave me these.

Here is an example of an even driven, enum queued, producer consumer that I put together for someone else. It is a basic example that shows 4 parallel loops fired by user events or running automatically. http://forums.lavag.org/index.php?act=atta...ost&id=7435 This is a good example showing the power of dataflow programming. In the 4 consumer loops you could put what ever function you need and it will run uneffected by the other loops. One note, I ususally have an Initialize and Shutdown case in each parallel loop, and a case to Wait for User Input. In the example the Manual case is equivalent to Wait for User Input. Initialization can be for runnig for finding home positions, performing start up self self checks, and so on. I may strip this VI down and make a template of it for my own use. One big difference between C and LabVIEW is dataflow. I am not sure from reading your questions and comments if you have the essence of dataflow. Intuitively you will opererate much differently when you a have incorporated dataflow into you thinking. When you talked about being able to insert a line of code anywhere, and that you couldn't do that with labview, it was a red flag for me that we could be talking past each other somehow. I sometimes sketch out what I am trying to do on paper. A flow chart is usually all I need to get going in an organised way. My comment about starting with the details is partly becasue I don't think you are ready for the big picture yet. It will be more efficient if you run into walls doing simple tasks first. Jason is exaclty right about not avoiding the connector pane and bringing together bunches small Vi's rather than writing it all in one big blob of code (which would definitely benefit from a zoom function). I used to be addicted to the Birdseye View VI, but now NI has given us the Navigation window (View/Navigation Window 0 or Alt V , N or Ctrl-Shft-N) You will like this. I find that when I have a big monitor I don't use the Navigation Window and I had fortgotten about it until just now. At any rate your request for a zoom function is a warning to me that you aren't really into the dataflow mindset and you haven't learned the value of creating sub-VI's. If you use the bottom up approach you will be able to do useful coding, and learn enough to get the big picture right soon enough. Also a bunch of small VI's are easier to debug as you can test the function completely removed from the larger top level vi. There will be some things that seem inefficient compared to C, but I think you will quickly appreaciate the de-emphasis on syntax ;-) I don't use RT, no advise there. You were talking about time constraints. Don't underestimate how long it will take to learn this. Fortunately, it is fun. LabVIEW really lends it self to bottom up programming. Using MAX you go in and get the hardware functioning first, then you can have some confidence that the debugging later on is concerned with software only. With LabVIEW you do not have to wait at all before runing you hardware. I do hope you have introduced yourself to MAX (Measurement and Automation eXplorer). With this you get the hardware operating; later when coding since you are certain the hardware is up and running correctly, you can quickly make functioning Sub-VIs to use that hardware. Other subVi's to analyze data can then then be developed with the exact data and format so you aren't wasting time working with fictitious data imagined in the planning phases. A big time saver. There is no maximum level of sub VIs as far as I know, if there is it must be very deep. The Block Diagram is just a developer interface layer and the compliation flattens this out and optimizes for you to a great extent. The things that make VI's slow are outlined in a number of places online. It makes interesting reading, but save it for later. Here are two things to avoid. Putting in front panel indicators (especially large array indicators, and clusters) in for and while loops that run without any pausing, and forcing LV to create many copies of large arrays are most common mistakes. Everytime you put a wire on a structure border you are creating a copy. If you can initialize arrays to be used in a loop before the loop runs that is good. If the array size is ambiguous then LV must remain prepared to supersize it. Avoid Global Variables for a while. Be careful with Local Variables, don't go crazy with them. Shift registers are your friends. Property Nodes are slower than Locals. Mike PS. If you hit Add Reply you will complete the posting a be required to start anew. I can only assume that you did not do this.