PaulG.

QUOTE (Chris Davis @ Mar 19 2008, 09:10 AM) No. The OLPC is designed for kids and is subject to the obligatory "drop" test.

I have not had experience on your specific robot, but I would think the only thing you would have to worry about is a LabVIEW-compatible motion controller. Many manufacturers sell LV SDK's for their controllers. I found this link with a Google search (FANUC LR mate robot LabVIEW): http://sine.ni.com/cs/app/doc/p/id/cs-810 It's been done and it's a start.

No good can come from this.

I stayed away from automatic tool selection for years, but a couple of years ago I forced myself to give it a couple of weeks and I never looked back. Coffee in one hand, mouse in the other. Nirvana.

QUOTE(eaolson @ Feb 29 2008, 10:21 AM) The "correct" answer was indeed C. BTW this is an excellent post and discussion. My first intuitive and logical response was A, the top tone measurement would execute first. However ... this is one of those NI "trick" questions. These pop up from time to time on certification exams. Some of us seem to have forgotten the (unwritten) First Rule of NI Tests and Certifications: The "correct" answer is not necessarily the answer you think is right, but the answer NI wants to hear. Queue's response made sense. NI writes LV as a dataflow language. And the only way to be certain of any order of code execution is to force the code execution using the data flow paradigm. Good question, great discussion and I'm convinced that "C" is indeed the "right" and only "correct" one. There is no way to be certain which portion of the code will execute first.

Use the Reshape Array primitive. You can use the Build Array or Initialize Array an n-dimension array in the beginning of your code then reshape it as needed.

Been there. I've done exactly what you are doing. Some of my earlier ap's ran for days at a time and I couldn't always be around to put out a fire. But for some reason I indeed woke up around midnite worrying about one of my programs ... and ran to work around 1 AM just in time to avoid a "moisture overload". Stick with a basic state machine design. You can think of 99% of just about anything that can happen and code accordingly. And if you get nervous ... plan on spending just one evening with your project ... if you want to live in peace ... LV is automation, and it's very cool ... you can do this. :thumbup:

QUOTE(Justin Goeres @ Sep 27 2007, 11:03 AM) No problem here either, George. You have something else going.

QUOTE(yen @ Sep 24 2007, 03:01 PM) Nope. I'm of the opinion that if you ever need to see a psychic they will contact you first.

QUOTE(Ben @ Sep 19 2007, 10:26 AM) Unless I'm misunderstand all the hype at NI, LV is quite capable NOW of performing as well if not better than that "other language", especially in RT applications. And in my own experience I've gotten deterministic data without RT, with most of the limitations in performance coming from limitations in the Windows environment.

QUOTE(NormKirchner @ Sep 18 2007, 03:53 PM) I'm thinking: "Peltier cooler".

QUOTE(Gary Rubin @ Aug 30 2007, 09:23 AM) :laugh: And the French laugh at US?! :laugh:

Tools>Options>Alignment Grid = 12 pixels.

QUOTE(george seifert @ Aug 28 2007, 10:45 AM) Maybe I'm wrong but after looking through Tools>Options>Menu Shortcuts I don't see that it can be done with a combination of keystrokes.

QUOTE(Ben @ Aug 24 2007, 06:26 AM) :thumbup: I thought I was the only other LV programmer in the world who didn't cause other developers' heads to spin around and spit up green soup when I started playing around with the SDE. And I, too am looking forward to using the State Chart. So many tools ... so little time to learn how to use them. (sigh)

QUOTE(dsaunders @ Aug 23 2007, 04:14 PM) That's not funny. Well, it's kinda funny in a dark, haha Pulp Fiction-esque "bring in the gimp" sort of way ... I've had to work with code that someone thought would be cool to fit on dual 19" monitors. The case statements stretched about 2K pixels wide. As we said when we were kids: "About as funny as a heart attack".

STOP POSTING STUFF LIKE THIS!!! Every time someone posts a link about a bigger monitor someone writes a block diagram to fill it up.

Ben: QUOTE(Ben @ Aug 22 2007, 03:48 PM) I've seen some great Visio/UML drawings that came close. And the mid-level subVI's broke down well into UML's as well. I've created an HTML out of the UML and made it part of my VI documentation. The trick: EVERONE involved with the project has to CARE about the documentation and know how to use the tools available and willing to put forth a little effort. The devil is in the details: accurate and complete signal lists, block and/or UML diagrams, defined states, well-documented VI's, i.e. the basics. An accurately documented 1000-state QMH would be a lot easier to deal with than a 20-state "self-documenting" "string state machine". PJM: Categorizing states is something I started doing a long time ago. I agree is does make for an easier read. But I've inherited way too much 3rd and 4th and 5th party code. Categorizing states is "survival".

QUOTE(orko @ Aug 20 2007, 03:13 PM) Where? When? What caliber and how many rounds?

QUOTE(LV Punk @ Aug 15 2007, 01:43 PM) There are so many ways to beat the crap out of a dog, too.

QUOTE(Dan Bookwalter @ Aug 15 2007, 10:56 AM) What I did: SHOW him. I don't know if you have the same luxury, but I had an unused copy of LV lying around in my lab about 9 years ago. I loaded it up, bought a "How to" book on LV and started playing with it. Within a week or two I was writing code that was automating a lot of my instruments in my lab. Within a month I had automated some of our entire testing processes. The boss was quite impressed. And I've been a LV guy since.

QUOTE(Ben @ Aug 15 2007, 08:49 AM) NOOOOOoooo!!! Not THAT!!! This example of a "queued message handler" (NI's design name, not mine) with 60 states is somewhat of a monster. Many QMH tools have been written by some of our associates that make managing something like this a lot easier (I see you have one or two in place) but this would still be a little too out of control for my tastes. The QMH is fine for a design that needs only 2-10 states and you need it fast. Anything bigger than that and architecture a little more robust and predictable is in order. I've tried a number of architectures but I always go back to the typedef enum in an array feeding a case structure. Worksforme.

Let's make sure we know what we are talking about. There is some confusion in the LV community. When I hear "queued state machine" I think of a state machine that uses queues to queue and dequeue state elements. And when I hear "queued message handler" I think of a state machine that uses string states in an array that are inserted and removed. What are we talking about? Pardon my confusion, but one of the so-called strengths of the "string state machine", i.e. queued message handler is that it "self-documenting".

QUOTE(silmaril @ Aug 14 2007, 10:43 AM) As much as I like Firefox's speed and security you can't beat IE for functionality. I'm still trying to add and tweak all the ad-ons on Firefox just to get stuff to work. It's a real pain. That's what we get for "free"

QUOTE(TiT @ Aug 9 2007, 03:50 PM) BRILLIANT idea. :thumbup: A CLD exam is in my very near future ...