mross

QUOTE (Ernest Galbrun @ Dec 18 2008, 01:05 PM) I see, you didn't try the example before reviewing it. The ni example code does not work as you want, and as I mentioned, but this enhancement fixes the problem. Don't ask me why it works because I couldn't figure out what they were talking about. I was even given code that didn't work right, so tech support finds this mysterious as well. I wish they would add a better PWM example that documents this method. When you say "imprint" a waveform onto the PWM, that makes no sense to me. What it the real world result of this operation? You want the 5000Hz waveform to be turned on and off according to a 50Hz PWM pattern? Why would you want to do such a thing. Mike

QUOTE (Ernest Galbrun @ Dec 18 2008, 04:35 AM) I ran that vi up to 10K HZ and never saw discontinuities. That is faster the the less than 1ms you mention. I have not tried to run it faster, but it will do more I am sure. I was using an DAQ board with AI capability up to 1.25MS/s. Perhaps your hardware is not up to the task. You did not share any information regarding the version of LV or the DAQ hardware involved. It is always a good idea to provide that information when asking for help. Mike QUOTE (Ernest Galbrun @ Dec 18 2008, 04:35 AM) Thank you for the tip ! However, this seems to rather confirm what I was affraid of, that the duty cycle can not be modified very fast (ie <1 ms). I will try to use this method though, and see how fast I can go. I will keep you informed. In the meantime if anyone know if there is some hardware solution to my problem, I would be glad to look in that direction too. I am looking for an analog/PWM or digital/PWM converter, but couldn't find it anywhere... You actually say "modify" the duty cycle faster than 1ms. I don't really understand that comment. If you were producing a frequency of 1KHz then changing it faster than 1ms would be shorter than the actual PWM cycle itself. When you change the duty cycle do you want to to stop in the middle of a cycle or what exactly? If you need faster changes and can plan it out you can use my method and create an exact profile to follow. I wasn't resolving the time less that 1 second, but I am sure it could be done much more quickly than I did it. At some point you would need to use counters on a fast counter board or implenet a hardware solution as mentioned by another. If you pre-program the steps and changes you may be able to avoid the limitations of windows because it is compiled and running on the DAQ board. I can't conceive of a normal use of PWM that requires deterministic control of the pulse train. Perhaps if you explain why you think this is necessary we can figure out a way to produce what you need.

QUOTE (Ernest Galbrun @ Dec 17 2008, 06:02 AM) Yes, the example code gives no clue how to change frequency and duty cycle without an interruption in the pulse train. Here is how to do it. BTW, NI Tech Support was quite happy to sort this out for me - that is where the credit is due. Mike

QUOTE (miab2234 @ Nov 23 2008, 02:15 PM) If you Write an array of ones and zeroes to the Array of Boolean Indicators, the values will reflect the 1 & 0 of the source array. The source can be the result of some process, a constant placed on the Block Diagram, or a Control placed on the Front Panel user interface. The Write function is accomplished by the use of a wire attached from the the source icon to the sinking icon of the indicator array. On the Block Diagram you will see a Constant, Control or other process Source wired to the icon of an Indicator that is an array of like dimension and type to the source. Perhaps you should shows us and example of your own work so we can properly address the specific problem you are having rather than forcing us to be general and unspecific in answering your request. Mike

QUOTE (pabhon002426 @ Oct 26 2008, 08:34 PM) http://www.us.anritsu.com/products/MS2026A...V6hroTHuQ%3D%3D It has a plug an play driver shown on this web page. What have you tried and in what way does it not work for you? Mike

QUOTE (pabhon002426 @ Oct 26 2008, 08:34 PM) http://www.us.anritsu.com/products/MS2026A...V6hroTHuQ%3D%3D It has a plug an play driver shown on this web page. What have you tried and in what way does it not work for you? Mike

QUOTE (george seifert @ Sep 10 2008, 10:13 AM) George, With the introduction (forced injection?) of Word 2007, it is again very necessary to mention what versions of Word are in play. Word 2007 doesn't play well even with previous versions of Word. Sorry, but I have no actual wisdom re your troubles. Mike

QUOTE (EECSintern @ Sep 9 2008, 06:04 PM) You need to get the sensor wired up right. Whatever the test panel in MAX shows is what the voltage really is. In the article linked below look at the business about grounded and floating signal sources. You need to find out how the sensors are grounded. Differential is always preferable if you have a choice. http://zone.ni.com/devzone/cda/tut/p/id/3344 (Field Wiring) Even if you get all this right you can still have problems with noise on the signal lines. I had to put a dedicated ground rod into our lab floor to get my equipment off of the building ground which was really trashy. You need to ground all your equipment properly. Use shielded cable and only ground one end of the shield so as not to create ground loops. Here is another useful article. http://zone.ni.com/devzone/cda/pub/p/id/262 (Five Tips) G/L Mike

You can execute a windows commands using the SystemExec vi. If you give it the string: run c:\ You will get and explorer window of C:\ There are variuos obscure commands and syntax that will cause the explorer window to look certain ways, such as with the folder tree present, and so on. I don't have a reference for you on that, but knowing about it should help. So assemble a string that does what you want and wire it to the SysExec vi and you are good to go. Mike

QUOTE (Cloedu @ Aug 25 2008, 06:00 AM) LabVIEW follows IEEE standard round up the odd whole numbers ending with .5, round down even numbers ending with .5. From message by Lew Drake Process Automation Corporation, and the info LabVIEW mailing list, 4/12/07. This method accumulates less error over time, it is statistically defensible. If you look around on line you will find detailed explanations, no problem.

Thank you, Christian. That was a very informative reply. Mike QUOTE (JiMM @ Aug 22 2008, 07:29 AM) But each frame is documented as a number...what more could you want? Seriously, is there a manual or something that goes with this? Never have redactions been so enticing.

QUOTE (Raymond Tsang @ Aug 21 2008, 05:46 PM) When you get a broken arrow you need to investigate its cause and see if you can fix it. Pick on the broken arrow and you get an error summary. If you pick on an error in the summary it will take you to the instance and location on the BD where the error occurred. The summary will provide information about what is wrong and ways to fix it. This is a very good system and you must try to use it. If you have trouble fixing a particular error. At least copy the information in the error summary and describe the step you took to try and resolve the problem. You will find that this a very instructive way to learn the proper use of LabVIEW. Mike

QUOTE (PJM_labview @ Aug 21 2008, 02:01 PM) I think get it, we have apples and anchors here? FPGA is not compiled code that is optimized to use dataflow. It is just straight up sequences and go to's? QUOTE (Neville D @ Aug 21 2008, 02:47 PM) Heheh... like the 3-button dialog VI.. Neville. That is classic. You could delete the sequence and lose nothing, and it adds nothing functionally. So the value added by the effort to apply the structure and work around inside it is purely theorectical. It is more graphic art than programming. At least it is documented with notes. Come to think of it text notes could replace the sequence, just pull them out to big rectangles and move everything else in font of them. I think subVis would have been more appropriate.

QUOTE (David Wisti @ Aug 21 2008, 01:12 PM) you said: "a wire and a corresponding data type and in/out terminals would take more FPGA space then just the enable string of a sequence structure." Just what is this "space" you are talking about? Screen space? The space of available gates? My first thought is that you mean visual real estate on a block diagram. Is this text programming? Like I said I don't savvy FPGA. I thought FPGA were programmed on a big monitor where wires and sequence structres mean the same thing as they do for regular DAQ equipment and programming. I have no idea what the "enable string of a sequence struture" might be. Mike

QUOTE (Burn01 @ Aug 21 2008, 12:32 PM) If you just subtract one from the other the time stamp is coerced to seconds and the result is in seconds.

QUOTE (David Wisti @ Aug 21 2008, 12:29 PM) Perahps I will expose my ignorance now, but it won't be the first time... Are you saying that wires don't work the same way for FPGA? One generally doesn't "enforce dataflow," one lets it happen, because that is better. Is this no longer true in FPGA and if so how does FPGA work and why should it be treated differently than "regular" LabVIEW programming which benefits from data flow, not sequencing. Mike

QUOTE (TobyD @ Aug 21 2008, 12:13 PM) I don't see why this is any better or worse. The sequence as used by eaolson has none of the problems associated with sequences, it is simple, it obscures nothing, it saves time in wiring, it doesn't take up useless space, so there is no reason to ban it. Making a wrapper is just anal if there is no re-use planned. I am betting we all know a bad use of the sequence structure when we see one, this isn't egregious by any means. I don't use real time so i can't comment about that.

OK. I think you cannot do this without hardware in your PC to get the tracable timestamp. Then you have to synchronize it with the triggering of the acquisition. This is not so easy as far as I know. It would be better if you could take all channels of data using one system or the other. If you use a buffered (not continuous) acquisistion this can be triggered externally (like an osciloscope). If you know the timestamp of the trigger pulse then you can count on the timestamp (to better than 1ms resolution) being the start time of the acquisition. Even if your two different signals and sources have different starting tmestamps you can still synchronize the data after the acquisitions are complete. Even if the acquisition rates are different you can use and xy graoh to show them together. I have seen discussions of this business with the absolute timestamp, but I have never done it myself. It is a difficult complication that I have tried hard to avoid. PCs are bad about timing that is why there is some much function on the DAQ cards themselves. If more than one DAQ card or system is used and close synchronization is needed it takes quite a bit of extra care. mike

This is a complicated subject. How absolute do you want absolute to be? a) NIST traceable? b) How about better than 1ms relative to the original start time and and start time is nailed down and tracable? c)Or maybe just really precise with respect to the start time, but the start time could be off a few ms? Each of these offers some solace from the fact that a PC is really crap for keeping "good" time. Whatever good means. heh heh A not too difficult relative but precise method [c)] would be to get the timestamp and start a counter timer, getting the timer count for the events of interest. The timer can run 20MHZ accurately so to the extent that you trust the first time stamp and its relationship to the starting of the timer you have a very good idea when each of the events occured and can easily add them to the time stamp for a pseudo absolute time. I love that, "pseudo absolute." Really, any DAQ card acquisition is keeping pretty good relative time, it is just a matter of, when exactly did it start? All you have to do is digitize the signal and calculate the time from the start. It is a very good idea to be sure this isn't good enough for your purposes before getting involved in the alternatives. Some of the alternatives are a pain in the butt. If you explain more the brains here can do a better job of explaing the trickier ways to do this.

QUOTE (Raymond Tsang @ Aug 20 2008, 06:23 PM) If you turn on context help Ctrl-H and hover over the BD icon for the XY graph it will show you the data structure needed to produce multiple plots on one XY. graph.

Now you see that there is depth to the "G" (Graphic) code in a LabVIEW VI. When you develop your own code you will regularly create subVIs that are functional blocks that can be run and tested on their own. In this case there is the function, Pm500 Send.vi, which sends a command string with a carriage return on the end of it to a port. I can't begin to guess what a PM 500 will do with the command. But you could test this yourself: If everything is wired properly to the PM 500 and powered up, when you activate this VI it should send the command string and cause something to occur. Then the Status and Byte Count are passed to the PM 500 Send VI (from whatever instrument the PM 500 addresses) and should appear in those indicators when the VI finishes its work. If you get no action or no returned data then you know something is not working correctly. You can see this makes debugging the Send PM 500 operation very straight forward. This is how you want to approach your own creation of LabVIEW code.

QUOTE (electrika @ Aug 20 2008, 01:33 PM) There is no way to tell what is inside a sub-VI by looking at its icon. You can find out for yourself by double clicking on the icon which will cause that sub-VI to open up for editing in LabVIEW, and any sub-VIs in there can also be opened up, and so on, until you have looked at all the under lying code. If the subVI has any output terminals you can add indicators to them to see what is produced by the subVI as it is run. The highlitghing button on the menu (a light bulb) of the Block diagram menu allows you to watch the progress of the program as it operates. These may help you understand what is happening.

QUOTE (shoneill @ Aug 11 2008, 02:39 PM) Not me. If you pull a 1d array horizontally you cannot see very many elements before the screen is used up. On this account I usually pull 1d down into columns to see more.

QUOTE (zorro @ Aug 7 2008, 04:08 PM) Zorro, I don't have much wisdom to pass on regarding DIO. I haven't made any new use of this since version 7. However, I understand that the naming of things is not clear and the documentation does not make learning easy. Perhaps others can point you toward good tutorials and example code for LabVIEW 8.2. My own ability to use DIO came from finding basic example code and trying to use it. I made simple LED indicators for several digital output lines so I could see actual results of using the examples. You need to put a current limiting resistor in series with the resistor. Most LEDs drop 1.8 Volts and the DIO lines are 5.0 Volts. The output terminals can be either input (using digital read function) od output (digital write function). You need to find the diagrams that show what the terminals for the DAQ card and its interface are so you can wire up the LEDs. You should also become familiar with the use of Measurement and Acquisition eXplorer (MAX). This allows to to setup and test input and output with your 6036E card, and to create Tasks that can be placed in your VIs. For DIO you will create digital output channels and tasks. When I am hooking up new signals to my DAQ I always begin with MAX to be sure I can see or generate what is expected before complicating the process with LabVIEW code. You should approach the creation of LabVIEW code in small bits at a time. Your complicated block diagram can be an impediment to learning the basice buiolding blocks you need to succeed. I always try to make the basic functions of my code owok alone befor bringing them into a larger application. For example, the analysis of some digitized data - I would create imaginary arrays of data that are similar to what I expect and then get the analysis and presentation to work right before introducint actual data in the context of a larger project. Similarly I would perfor only single channel analog inputs before expanding to multiple channels. I would get each channel right before proceeding. Soon it may not be necessary to take such small steps, but it will help a lot when you are still learningthe basics of LabVIEQ programming. Mike

QUOTE (eaolson @ Aug 8 2008, 01:37 PM) This is a secret English usage trick: We say in mathematics and other places ",Row Column notation." In almost any instance where there is a two dimensional matrix under discussion rows are discussed first, then columns.