Cat

After responding to the poster who wanted to make an executable without the RTE, I had to create an installation for an offsite customer to use. My little 760KB exe turned into a 62MB whopper (zipped, even), which was then too big to email over my !@#$% (sorry) network.

Argh.

we can give them a book with my theory and explain them that they are animal level.

How can you explain anything to animals? When I tried to explain to my cats the other day that I was out of treats and it was too late to go to the grocery store for more, they made it very clear that they really didn't want to hear my excuses.

Also, to add to the testing "gotcha's", make sure you test on a completely clean computer that's never had any NI software installed. You may think you don't need a file because you didn't load it on yourself, but it may already be there from some previous testing.

I was testing an exe on what I thought was a clean computer a while back and everything worked fine. Luckily, for once, the group I wrote it for actually ran it before it went out into the field. It didn't work. It was missing NI-VISA. Turns out someone else had installed NI-VISA on the laptop I used for testing. (I now have my own clean test master disk)

Good luck with this! I remember back in the Good Old Days when the RTE took up one 3.5" floppy...

H,i want 2 buy a spartan 3E starter kit for my project, and i need it with in 15-20 days.

Umm, if you can make it to LAVA, that means you should be able to type "spartan 3E Starter Kit" into your favorite search engine and find a distributor (who may even ship to Bangladesh). I did this and came up with the following supplier:

http://www.xilinx.com/products/devkits/HW-SPAR3E-SK-US-G.htm

They even have a support forum.

Good luck!

Cat

It should be Cyber Monday

Black Friday... Go to a store, with people... Please!!

Cyber Monday is every day! (just doing my part for the economy)

The very LAST place I will be on Black Friday is any bricks-and-mortar retail establishment, anywhere. Shopping is painful enough without all that madness and mayhem.

Well, maybe if REI has a really good sale....

Yes, but simply using LabVIEW on a daily basis doesn't necessarily prepare you for the certification exam either.

I spent my first few years with LV doing a lot of card-level programming but other than some instrument I/O, have done very little of that sort of thing in the past 10 years. Is this something I would need to go back and review for the CLD exam?

I am sure that there are lots of sel taught LabVIEW programmers out there that think they are writing great code. However if you really looked at you would see that it is not very good code.

Someone's been peeking at my code again!

If you just want to climb steep hills (and see gorgeous views) Yosemite Falls will do the trick. The trail is essentially a 3,000 foot tall stairway!

I love Yosemite!

I wracked one of my knees up coming down off of Half Dome with a 35lb pack (this was back in the days when you could still camp up on top) and then had to climb down all those "stairs" of Yosemite Falls. Luckily it was the last day of a 5 day backpacking trip, so I only had to be miserable for a few hours.

Mount Elbert. When I lived in CO years ago a friend/coworker climbed Mt Elbert with her brother and got trapped in a thunderstorm near the summit. They were both nearly killed. They literally ran for their lives down the mountain trying to get away from the energized air around them. She said their hair was standing on end. Challenging enough for ya'?

Everything I've read about that peak says that violent thunderstorms are a daily occurence in the summer.

Mount Elbert is definitely an option. My SO is a Highpointer and he hasn't climbed that one, yet. 4000 feet up over 4.5 miles would definitely be a challenge for me. And I'd be sure to get off the mountain by early afternoon in order to avoid any hair-raising experiences.

I don't have LV9, so I'm assuming your tiff is of the actual block diagram. If so...

Your current code takes temperature data every 200 milliseconds, stores it to an array, and after 5000 samples (~ 17 minutes) writes that data to a file.

If what you want to do is every minute take a sample and then write it to file, you need to wire a 60000 (ms) to the metronome ("Wait until next ms multiple") where the 200 is wired. Then you need to move the file writing code inside of the for/next loop. If you want the data displayed as you go along, you need to move "Temperature Graph" inside the loop, also. Check your delta-x value -- it's not going to be ".25". If you want to wait till the end to write/display, leave those parts outside of the loop, but you still need to use 60000.

Also, check out the file I/O functions. There are a lot newer ones available than you're using.

Cat

November 11th is not only US Veterans Day, but also the anniversary of Armistice Day

I was in England last year during Armistice Day and was overwhelmed at how big of a celebration it is there.

After going almost a couple hundred years without having our mainland attacked by a foreign country, I think that sometimes some of us USAmericans can be a bit too complacent about our (supposed) invincibility and therefore less appreciative than we should be of the men and women who willingly put themselves into harm's way for us. It was very refreshing to see that isn't true everywhere.

Anyway, (belated) thanks to all of you who have served, in whatever capacity.

Cat

http://www.birdandhi..._Turtlehead.htm

Ok, it's not Mount McKinley, but it was certainly at the far end of my fitness spectrum. A short hike (2+ miles), but the last half mile was a killer. Any steeper and we would have needed ropes once or twice Coming down was in some ways even worse than going up. Some parts of it were a semi-controlled slide. I was really glad I finally got around to buying a walking pole. Two hours up and a little over an hour to get down.

We had great weather, so I was an idiot and just wore a tank top and shorts. My legs were all scratched up, but at least I got a late season suntan out of it.

Now on to figuring out what the next challenge is going to be!

Cat

All I can say is, skinning or not, from now on I'm using "Clouds" on all of my GUIs!

I go away for a few days and you all turn my innocent little joke into a series of hideous GUIs. Nice work!

All I can say is, skinning or not, from now on I'm using "Clouds" on all of my GUIs!

I'm staring at that trying to figure out what makes it "sarcasm"

It's looks more like "You're an idiot."

Put it in a Software Desgin Document (SDD). I think having images in your code bloats the VIs. That said, if you don't follow a documented design process, then maybe it's the best you can do.

Our SDD was written 5 years ago and never updated to reflect reality. We are rarely required to do any sort of formalized design documentation -- in fact often no one wants to pay for it. I do rigorously document anywhere I interface with someone else's code, but must admit, should do a better job with my own. That's why I'm trying to figure out the best way to go about it that I will actually impliment and continue to use over the long run. 95% of what I write I write alone, so I've got to be internally motivated to deal with this.

I have 1 program that depending on which location/setting it is used in ( currently only 3 options here) it has a different front panel appearance (ie. BGcolor, text colors, boolean colors, plot colors, line styles, etc.) My world would be much easier if everyone could just agree, but that's not going to happen (which is good in a way because it keeps me employed.) Oh and also for each of these locations, when the user prints the screen I have to change all the controls to another appearance.

I had to do something that sounds similar with a very graph-intensive piece of code. I was tasked with making 1 "uniform" interface for 3 groups that had their own completely different products. So even tho the basic layout was the same, some wanted a black background, some wanted white, some were very picky about what order the colors were for different plots, etc. This problem was compunded by the fact that User X could be running the code and User Y, with very different aesthetic requirements could be using it 5 minutes later.

I ended up building a GUI where each user could go in, mess around with all possible settings, and save their preferences to their own ini file. The users were all a-gaga about it for quite some time and had fun playing around with it. I've noticed lately, tho, that after a year, most of them have migrated to just using the default settings.

Cat

Yes.

Learn something new very day. I wonder if it was always like this. I'll have to dig up that old code and see what was really happening...

This should get you what you need... (In case it's not clear, ActPlot is Active Plot)

Many moons ago I wrote some code where (I thought) this sort of construct did not reliably work. I had to separate one property node into multiple nodes and access them sequentially to get them to always execute in the right order.

Was I imagining things? Does LV automatically execute property nodes in the same top-to-bottom order all the time? If so, it would definitely save me some screen space.

Cat

Swing a bucket of water without spilling it?

That's a definite "Kids, I'm a professional, don't try this at home!" demonstration!

Lacking the SDE, I just paste my SD images into the BD for ready reference.

I've been thinking about doing this. Where do you paste the images? Off to the side somewhere? I'm thinking about wrapping a stacked sequence structure (gasp!) around the SM and putting the SD in frame0. Mostly because I really really don't like a BD being more than one (1024x768) screen.

Things that involve the kids, like the hair/balloon example, will go over well. If any of your daughter's toys are of the dynamic type, see if there's not some physics principle that can be taught from them.

I had the same dilemma with my daughter's girl scout troop -- and unfortunately at the last minute, so I had no time to prepare any props. Software engineering is not very exciting to talk about. So I just talked about engineering and what they needed to focus on in school (they're in middle school), and then told submarine horror stories. The latter, at least, kept them enthralled.

OMG. Paul, did you really have to post that?!?

As usual, there is no "wrong" or "right" answer - only shades of gray......

Not unexpectedly...

1) Responsiveness - if you have any action that takes a long time and your program is capable of doing something else (safely) then it's best to let the user continue to interact rather than locking them out and making them wait. For instance, an app that takes data for a long period (more than seconds) might be quite capable of loading and displaying previously acquired data sets while it takes new data.

Well, I've already admitted to the heresy of being willing to put multiple loop/event structures on one BD (back to the original thread). That's how I deal with the exact example you give.

2) Flexibility - if you have a state machine, for example, that can be queue-driven then you can call it in many different ways. If your state machine is effectively coupled to your UI, that's about the only way you can make it run. Having the "stand-alone" state machine makes it much easier to automate, both for test and deployment.

I've used a lot of state machines but never had the need to use one that was queue-driven. Or maybe just didn't know that's what I should have been using.

Thanks for your input.

Yes, but... (apologies if I'm hijacking this thread)

I've been looking at some code I wrote quite some time ago that has an event structure that passes messages to a queue with lots of code underneath it.

I think the only reason I did it this way was there were a few bits of code I could reuse by just sending different inputs triggered from different events. I would have had to copy the same code to those events, otherwise, or put it in an event with a "value signaling" trigger (jcarmody, I believe this is what you were talking about?). But this was a rare case and usually I have code in events that is unique.

And even tho I'm doing it this way, I still have to be very careful about what controls are enabled/disabled when. My users like to randomly push buttons when they're bored...

But if it wasn't for the code reuse issue, I'm not sure what generally the benefits are to separating the event and the code for the event. I'm not buying the "more elegant" concept (which is subjective, anyway). I look at my event/queue code and see it being less readable since the action and reaction parts are separated. I also see twice as much BD space being used. And I see one loop having to rely on another loop for its stop signal (that's one of my least favorite "rabbit hole"). I don't call that "elegant".

So if there are real hard technical reasons why I should go to using the event-to-queue paradigm on a more regular basis (keeping in mind that I have no issue with using multiple event structures when necessary), please tell me! Old cats *can* learn new tricks.

(And bonus points if you can convince me it means LV will make fewer copies of my Really Big data sets )

Any time your users can kick off multiple simultaneous, long-term events, you're probably going to have to have multiple structures to deal with that. I use multiple loop/event structures often. I've tried both putting the code inside the event structure and also calling it from a queue. I'd have to say I like the code-inside-the-event frame version better for most applications. It takes up less screen space, and in a particularily complex piece of code, I don't have to go hunting around for the right queue handler.