Jump to content

BobHamburger

Members
  • Content Count

    123
  • Joined

  • Last visited

  • Days Won

    3

Posts posted by BobHamburger

  1. QUOTE (LV_FPGA_SE @ Aug 20 2008, 09:25 PM)

    Yes, but sometimes a State Machine is just more than the job requires. Sequence structures have their place for very simple VIs.

    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.

  2. 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.

  3. QUOTE (jpdrolet @ Aug 7 2008, 11:28 AM)

    ...if you can keep the user from changing the system time.

    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.

  4. QUOTE (eaolson @ Aug 6 2008, 10:23 AM)

    Darn useful. Two quick questions:

    1. Why the conditional disable structure? Are there targets for which the Tick Count VI isn't valid?
    2. Shouldn't the indicator really be outside the loop? I ask not because I suspect it would impact performance, but because I'm just not really clear when putting indicators and controls in a loop does or doesn't.

    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.

  5. 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. :yes:

  6. It warms the cockles of my heart :wub: 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

    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.

  7. QUOTE (Yair @ Jul 8 2008, 02:47 PM)

    I was thinking of adding that I'm actually a bit surprised and that I would actually expect it to behave the same way on both platforms (either to optimize or to perform the code literally), but I decided against it, since I figured that Bob probably had a reason to say that it worked fine. I guess I should have tested it myself. :oops:

    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.

  8. QUOTE (Michael_Aivaliotis @ May 25 2008, 08:17 PM)

    Well, it's over. landing was a success.

    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.

  9. QUOTE (crelf @ May 19 2008, 09:45 AM)

    The connection uses the refnum, but the refnum does not use the connection.

    Whoa, man, that's deep. :blink:

    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.

  10. 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.

  11. 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.