PaulG.
-
Posts
822 -
Joined
-
Last visited
-
Days Won
22
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by PaulG.
-
-
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(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)
... LabVIEW applications will be able to out perform application writtien in that other language.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(Gary Rubin @ Aug 30 2007, 09:23 AM)
:laugh: And the French laugh at US?! :laugh:
-
Tools>Options>Alignment Grid = 12 pixels.
-
-
QUOTE(Ben @ Aug 24 2007, 06:26 AM)
I have used and really like the the State Diagram Editor ...: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)
But wouldn't that just be WONDERFUL??? You could finally fit the entire application onto one block diagram. Oh yeah! :thumbup:
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)
Are diagrams ever used to document these critters and if so, could you post a sample diagram ...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(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)
Suggestions ? ...
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)
Here is a screen shot of one of the sub-VI's after scrubbing to protect the inocent ...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)
... It seems to work in MSIE, but I don't like that browser.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"
-
-
A Software Engineering Approach to LabVIEW by John Conway and Steve Watts. Great crash course in Object Oriented Design as it relates to programming in LV.
-
I have some experience working with MicroMo Electronics motion control products and NI Motion. With what I needed to do the MicroMo controller I had was overkill. Their motion controllers are extremely powerful with tons of functionality built right into the unit and I eventually didn't even need NI Motion. I would have a hard time imagining something so complex that I would be forced to use it. Just my $0.02.
-
QUOTE(xtaldaz @ Jul 31 2007, 04:18 PM)
... The only time reentrancy really helps is when you are storing data in uninitialized shift registers and you need to access multiple calls to that subVI in parallel ...You're going to confuse all of us
. Reentrantcy is helpful in many instances, namely any time you have an operation/subvi that is used in multiple locations and/or in parallel data paths. Let's say for example you are performing the same operation on each bit of 16-bit data. Your operation will be in one vi that you make reentrant. This vi is placed on your block diagram and copied, i.e. cloned in 16 locations. 16 clones of the reentrant vi will be in 16 memory locations.The most common reason to make sure a VI is NEVER reentrant is in a functional global where you store data in uninitialized shift registers.
-
PLease help a newbie with a "Basics I" course question
in LabVIEW General
Posted
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.