PaulG.

QUOTE(Aristos Queue @ Feb 15 2007, 02:18 AM) I agree. I think a lot of us are making this far more complicated than it needs to be. Caveat: thorough and accurate documentation of what the sw is supposed to DO is critical before any one of us sits down and codes one vi. An application may change dramatically, but LV is perfect for scalability, even when the scope of the project itself grows exponentially or if more engineers are taken out or brought in mid-stream. Yes, Q, the fact that every vi is independently runnable is one of LV's greatest strengths. I think that typedefs and nothing more than a "demo" or "simulation" boolean and fake inputs into our vi's are all the tools we need to self-validate and test our code - along with THOROUGH AND ACCURATE documentation. Did I mention we MUST have thorough and accurate documentation? Quote me: "An accurate UML diagram is worth a dozen 'bugs' in Bugzilla".

This is not a 'bug', but a real annoyance. I like all of the labels on my controls visible inside my typedef cluster constants in my block diagram. Autosizing does not "size to fit" to the labels, only the controls themselves. So I turn off the AutoSizing and make the border fit to include my labels ... but when I apply changes to my typedef the constant on my block diagram automatically defaults back to "size to fit" and I lose my labels again. Am I missing something in the options or is this normal behavior?

This got freaky right after " ... prostitutes ... " :question: I've always wanted to read the legendary "5th dimension" thread from start to finish ... but I know how it ends.

Cylon jazz. Cool. :thumbup:

I tend to agree. I've spent literal weeks trying to debug a poorly drawn (not drawn by me, of course ) LV block diagram that I would have been better off just deleting entirely and starting from scratch.

Didn't mean to redirect the conversation. UML is fairly new to me. I might be dangerous with any UML tools. PaulG. looking up UML and UML tools. "I'll be back".

First place I looked: Wikipedia, Unified Modeling Lanquage Not really a "tool" but a quick summary of UML, pros and cons. A real eye-opener. I have a feeling you and I are going to have some discussions regarding this. I'm all for GOOP. It makes sense and my attitude and style have naturally been leading me in that direction. However, UML, at first glance, seems to be a little more complicated than it needs to be. I'll withhold judgment until I've worked with it for a while. Until then, expect me to ask a lot of questions and have a few opinions.

:thumbup: Good call. I just started working for Chris a few weeks ago. I consider it a real opportunity. :worship: /suckup mode

Woo Hoo!!!! Best football game I have ever seen! The outcome was even better, but I want to see OSU vs. MI for the title. Woo Hoo!!!!

Another funny one ... the scene from the movie Airplane!, where the plane is cruising towards the radio tower, the DJ says "This is Wsomethingsomething, where disco lives forever!" Then CRASH! The plane knocks over the tower ... :laugh:

Disco? Did someone say "disco"? For me disco is more fun now than it was when it was supposedly "cool". Just a few weeks ago I discoverd the Windows "dancers". They're cute little guys/gals/couples who dance on your desktop to your music. Kenny is the 'disco' dancer. I'm more of a jazz guy but in my collection of music tracks I have bit of disco. Watching Kenny dance to one of my all-time favorites the O'Jay's (club epic version of) "Love Train" is a hoot!

In case this has not been mentioned: I like the new file saving features. I can rename a vi without having to remember to delete the old one. Sometimes I want to rename a vi into something a little more descriptive. Sure reduces the number of 'old' vi's in my directory.

I like using the "disable code" structure as a cool little "scratch pad" in my block diagram. If I need something in there I can either drag it into my code or drag copy and paste. It's especially useful when working with mulitple property nodes on mulitple controls and indicators.

Classic example of some nerd at NI using a $20 word when a $.10 word would have worked a lot better.

Uh, umm, he he ... I've made similar comments myself. Don't be too critical ... some of us are STILL cleaning up code written by FORMER employees who knew just enough LV to be dangerous. A sense of humor goes a long way in these situations.

Our application is an ultrasonic NDT application. I think I have a lot to work with this morning. I have to have some visual display during acquisition. However, the visual representation only needs to be just that. I can decimate the array and display only the decimated portion. I can cut it down by a factor of at least 20, refresh the display only once per second, interpolate the graph and it looks fine. Also, the data analysis happens after each series of scan pulses so I don't have to worry about that ... for now. Thanks for your help. PaulG.

I managed to get my 20 usec of data at 1GS/sec at 1K pps. I made some modifications, put a "0" wait state in the iteration counter loop, put some millisecond timers from where the DAQ starts to where it stops, and with 2 seconds (2000 triggers) of 1Kpulses I'm down to 2003 milliseconds and it's very consistent. That's as close to real time as I need. And that's acquiring the data and replacing the data subsets in an array. But once I try to display it, even only every 500 milliseconds it goes up to 2300-2400 msec. Displaying the data is a major roadblock. I suppose I could try displaying a decimated array but I don't know how much that will buy me. Would a power video card help with this by taking some of the display work away from the PC? Video cards are cheap, and this would be a lot cheaper than another day or two (or three or four) of development time. PaulG.

It's a Gage 82G. The board has 2 MByte FIFO-style memory and it is capable of acquiring multiple records. Most likely it will only run for about 2 - 3 seconds at this rate at the most then process the data, then run again for 2-3 seconds. I need to do this for up to 30-60 minutes without crashing or running out of memory. I don't save all the data, just process certain portions of it utilizing array offsets later in the code. PaulG.

Speaking from experience: I don't think you need to spend a lot of time and money coming up with documentation methods for your LV programs. I would highly recommend adopting a "state machine" as a standard LV program design for all top-level vi's and 2nd-level sub-vi's. 99% of anything you want to do in LV can be accomplished in a state machine, and they are inherently self-documenting. Simply mandate as "policy" all programmers utilize state machines and that all sub-vi labels are "visible". Also, mandate as policy all enum state machine controls will be strict type def's. When you "print entire documentation" of the "master" vi and all subsequent sub-vi's and controls you have a sufficient and basic documentation package. I have an application that contains over 600 vi's. It was written utilizing a state machine in the primary and high-level sup vi's and was documented in this way. It's very easy to pick up where someone else left off when making changes. I inherited the first revision (1.0a) and the only trouble I had making revisions was when a previous programmer didn't utilize these basic guidelines and I had no idea what he was doing. I've had to rewrite just about everything he did into this format. But now I'm at "1.9". 2.0 will be perfect and easily sold to ISO or anyone else who requires documentation. And if I get hit by a truck tomorrow the next guy could step right in and cover for me.

What would be the best way to acquire 20usec of data at 1 GS/sec (20K points) in 1Khz pulse per second intervals? The board I am using seems to be capable, but the bottleneck appears to be in LV/Windows. Do I need RT for this? I have been at this for quite some time. I'm using a state machine, the vi "free runs" from one state to the next utilizing the external trigger (1K) signal. There is no display and all data points are placed in an array that I dimension before the DAQ sequence starts with "replace array subset". My board is capable of "multiple records" but that seems to have little effect on performance. Most of the commands to the digitizer utilize code interface nodes. Have I hit the proverbial wall and need to brush up on my C? Thanks. PaulG.

Exactly. I've cleaned up code I inherited from a lousy LV programmer. He was also a lousy C programmer.