Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by BobHamburger

  1. QUOTE (Karissap @ Oct 26 2008, 10:36 PM) This will work if there is something in your subVI that is holding data in between calls. The most likely culprit for what you're observing is that you have one or more uninitialized shift registers. What you need to ask yourself is "do I need the subVI to keep data or state information from one call to the next?" If the answer is no, then initialize your shift registers appropriately, and you won't require reentrant execution. This will save memory use. If the answer is yes, then follow Karrisap's advice and go for reentrant execution.
  2. QUOTE (crelf @ Sep 29 2008, 10:55 AM) "Work, work, work, work... hello, boys, did you miss me?" You know, just when I thought that I understood all of the gags, I randomly Googled "Le Petomane". Imagine my delight when I read http://en.wikipedia.org/wiki/Le_P%C3%A9tomane' rel='nofollow' target="_blank">this Wikipedia article.
  3. QUOTE (crelf @ Sep 28 2008, 10:37 PM) Your avatar inspired mine, Chris. 35 years since I first saw the movie, and the whole concept of a Yiddish-speaking indian chief still cracks me up.
  4. It makes me want to stand up and salute something. Anything in uniform. A Good Humor man, an usher, or a nun. (Let's see if anybody can attribute that reference.)
  5. Please visit Bob's LabVIEW Insights for discussion of a nifty little utility.
  6. Here's the latest insight and ramblings on My Blog
  7. QUOTE (LV_FPGA_SE @ Aug 20 2008, 09:25 PM) I have a template for a simple single-loop, queue-based enumerated state machine, and I use it as the starting point for just about every VI that I begin writing. Once I can see more clearly what's needed, I may or may not remove the loop, case structure, and queue primitives to simplify the layout. Over the years, I've found it much easier to start with a more complex framework and pare down what I don't need than to try to add state functionality after I've already started coding. Which leads me to another of my favorite interview questions: do you have a particular application framework that you like to use when you begin a new programming challenge? Nice, open-ended question that really shows you how a candidate thinks in LabVIEW. As far as I'm concerned, I wouldn't miss it if the sequence structure were completely removed from LabVIEW. IMHO, it simply has no place in the dataflow-dependency paradigm.
  8. I always like to ask them when and why they would use a type definition, and then to distinguish cases where a strict type def might be more advantageous. I've had more than one supposedly "experienced" LabVIEW programmer respond with a blank stare.
  9. QUOTE (jpdrolet @ Aug 7 2008, 11:28 AM) Exactly. The variability of the system time is what motivated me to create this utility. I had an application that extensively used the system time to determine time intervals in a number of different contexts, and there were strange faults in these various modules that eventually were traced to the time primitive not behaving as desired.
  10. QUOTE (eaolson @ Aug 6 2008, 10:23 AM) 1. For PXI RT, there is a specific tick count primitive that's tied to the hardware clock. The general tick count primitive is supposed to be also tied to the same time source, but... if that's the case, then why is there another one specifically for RT? It's just hedging my bets. 2. As a functional global, the loop only executes once anyway, so the indicator gets updated exactly once per call. In this case, inside or outside the loop doesn't really matter. The only reason that there's a loop structure in the first place is to support the uninitialized shift registers used to hold numerical values from one call to the next.
  11. Absolutely amazing. I almost wet myself watching this.
  12. Val's latest comments and explanation put things into a clearer light. I write from the perspective of having been an integrator for a number of years, and in my current position I use contractors. I can see that Val's position and concerns are somewhat different from mine (and perhaps a large fraction of the LAVA community), and I hope that my statements weren't taken as overly judgemental. I tend to write with passion, as I have grown to despise the weak and ambiguous language that has come to dominate business communications over the last few decades. It's never my intention to incite a flame war, but I will admit that with my opinions you might occasionally smell smoke. I love a good, hearty debate.
  13. It warms the cockles of my heart to see such enthusiastic and varied responses to this topic. However, I feel compelled to elaborate and add to the chatter. QUOTE (Omar Mussa @ Jul 11 2008, 08:15 PM) I disagree. Style is a necessary component of structure, but it is not sufficient. I have seen too many cases where style was great but architecture was completely lacking. I am working on code right now that is well documented, flows properly left to right and top to bottom, has a consistent icon/connector layout, etc., etc., etc. However, the application is lacking a lot of the attributes I associate with scalable, maintainable code. It has no kind of heirarchical abstraction of lower-level details; VIs are vertically integrated to include everything from bit-twiddling to GUI updates. VIs have tight coupling and poor cohesion, and there's no rhyme or reason for what's inside a given VI or what is does. I have no problems understanding what the code does, but it's almost impossible to modify anything without having a dozen unintended consequences of any change. QUOTE ...various comments regarding obfuscation of details as a means to protect IP... I simply do not understand this perspective. It seems to me that we are developing LV code in one or more of the following contexts: 1. You're an integrator/contractor, so your customer is paying you to develop code. Therefore, either they own the IP outright, or at a very minimum that have an irrovocable right in perpetuity to use the code without further fees or royalties, depending on the contractual details of the engagement. From both a business and ethical perspective, they have every right and expectation that the code you deliver will be crystal clear to them and conforming to the highest standards of which you're capable. 2. You are developing code for internal use by your employer. In this case there are no IP protection issues, and you have an obligation to your peers and employer to ensure that your code is understandable and maintainable, as crelf pointed out. 3. You are developing code to be sold as a toolkit or library. Legally this is virtually the same situation as (1), except perhaps that you can charge deployment fees for each installation. Since your customers will be incorporating your toolkits into their applications, they have a compelling need to be able to validate the correct operation of their code. You in turn have an obligation to make the operation of your utilities visible to them, so that they can perform whatever QA or validation is necessary. 4. You are developing finished applications which are sold as products. In this case, you compile your code and deliver installers and executables, the same way every other software manufacturer does. Your trade secrets are bound inside your .exe's. If you are truly producing unique IP that is worthy of protection, then there are only two legitamate business methods to accomplish this. Either you have your customers execute the appropriate confidentiality agreement, or you patent your work. 99 times out of 100, what most people think is brilliant and original work product ends up being knowledge that was already available in the public domain. QUOTE ( @ Jul 12 2008, 07:08 PM) There is documentation and various backups of all of my code -- all in separate China locations -- but all of the pieces needed to understand the code are functionally separated into "objects" -- like good OO architecture... ;-) If you have them ALL in the "same room" then it becomes far more "doable" for someone else to maintain/extend the current code base. Maybe I'm completely misunderstanding your intent in these statements, but it sounds like you want your code incomprehensible as a means to prevent your customers from using other resources, so they are compelled to keep coming back to you. Personally, I think that the quality of a contractor's work should stand on its own. Customers should be so delighted that further engagements happen as the natural course of the business relationship. If I found out that one of my contractors was deliberately engineering complexity into their products, to try to ensure repeat business, I'd see to it that they never worked for me again. Intentionally making your code obscure, as a means to protect what you believe to be unique, is legally unjustifiable and morally indefensible.
  14. QUOTE (Yair @ Jul 8 2008, 02:47 PM) Well, to the extent that I tested it under Windows, it appeared to work fine. The RT systems were left running overnight and over weekends, and that's when the memory leaks would eventually cause things to crash. We never did long-term tests under Windows.
  15. I've decided to start my own LabVIEW blog, to share random observations and debugs which I believe could be helpful to my fellow LabVIEW jockeys. Here's my very first entry! Feel free to leave feedback, comments, critique, etc. I hope that my insights can live up to the high standards of this community.
  16. Wire up a Property Node to your VISA refnum. Look for Properties>>Serial Settings>>Discard NUL Characters, and set it to False.
  17. QUOTE (crelf @ Jun 13 2008, 10:46 PM) ...and I watched Blazing Saddles for about the 14,000th time this evening. It never fails to crack me up.
  18. QUOTE (Michael_Aivaliotis @ May 25 2008, 08:17 PM) Science Channel has had live coverage from both JPL and U of A. We should have first images in about 90 minutes. I've been a huge space junky since the first launch that I saw on TV (Gemini 4!) No single human endeavor has produced more useful technology or given a bigger return on investment than the space program, and yet we continue to fund it at barely anemic levels. Consider what we could be doing if we spent $80 billion a year on space instead of Iraq and Afghanistan. And don't get me started on the idiocy of retiring the Space Shuttle fleet before we have a replacement manned space vehicle. OK, I'll get off my soapbox now.
  19. QUOTE (crelf @ May 19 2008, 09:45 AM) Whoa, man, that's deep. I agree, Justin's explanation is much nicer. He uses his tongue awful pertie. Seriously, though... an old-time method for determining if a TCP connection is valid is to simply send a periodic small-sized message through the channel on a known, repeatable time basis. If for some reason the "heartbeat" isn't seen for longer than the selected timeout period, assume the connection has been lost, and take appropriate actions to re-establish the channel. I've used this to get around LV's somewhat hard-to-predict and occasionally inconsistent error-handling functions, which return different errors, for example, when you unplug an Ethernet cable vs. when you shut down power on a peer.
  20. QUOTE (TobyD @ May 5 2008, 06:08 PM) This is a little simplistic -- it will only work if the cluster only contains a flat collection of basic LV panel objects. The more generic solution would require recursion, so that any contained structures (clusters within the cluster, arrays, etc.) would be drilled into and analyzed also. For guidance, a good starting point to better understand this challenge (and some great code to learn from) is in the OpenG Toolkit: the Variant Config File VIs perform a lot of these very operations.
  21. That kid in the video looks too much like my son. Disturbing.
  22. Solve the problem in the simplest and most efficient manner possible. Points will be deducted for an architecture that is overly complex or for techniques that are not warranted to solve the problem. Do not embellish or try to show off -- it will certainly backfire. Make sure that your work is impeccably neat and well documented. Make your wires as straight as possible and be sure that they don't go behind any structures. Keep things as simple as they can be.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.