Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 01/26/2010 in all areas

  1. I just got a notification from IPB (the makers of the LAVA site script engine) that there is a new version of The downloads script (Code Repository) currently in Beta. There are some new things in there. Here's an excerpt of their announcement which indicates the most usefull features in my opinion: Having multiple files is great. Now we can have files for various LabVIEW versions or even one zipped *.zip version and a packaged version *.vip.
    1 point
  2. OpenG's configuration files are your friends... Use "Read/Write Panel to INI" for the values. Use the Read/Write Variant in a for loop for the rest.
    1 point
  3. Is CBS moving in on this story?! All taxpayers across the globe should pay attention to squandered tax dollars, but more importantly, we should all pay extra attention to the carbon footprint left in Copenhagen by the "elite" Global Warming/"Climate Change" hypocrites.
    1 point
  4. In addition to what Francois has suggested you should note that you will most likely perform an extra step when the Stop button is pressed. The button will most likely be read before the action in your case statement is processed. Remember, just because something is on the right of the diagram doesn't mean it will execute after the stuff to the left of it. You probably want to include some artificial data dependency to force the read of the Stop button after you process your action. Remember to initialize your controls when the program starts. If you actually press the buttons before starting the program it will immediately start the economy wash cycle. Speaking of button controls I don't recall if the requirements in the sample exam included it but it is generally a good idea to disable the controls while you are in a wash cycle. In addition, using this architecture you are able (albeit you have to be real fast) to press both buttons at the same time. The selection most likely would need to be mutually exclusive. Remember to document everything, including constants. Overall your code is clean and easy to read. I would avoid saving your code with the block diagram maximized. You want to try and make it fit in a single screen. When I deselected the "Maximize window" only a portion of the code would be visible at any one time and I would have to scroll around to see the code. Speaking of monitors and displays, I know that in earlier versions of LabVIEW if code was saved on the second monitor and then opened on a system with a single monitor you couldn't see the code until the window was maximized. I have not tested to see if this is still a problem or not but as a result I always save the final code opened on the primary monitor. If you have the time and would like to really impress the folks grading your code try to align the code in each case so that when you cycle through the code you don't see it jumping around. This sample exam generally ends up with multiple cases all having essentially the same code. The final code looks especially clean when you can cycle through the cases without seeing the code jump around. (I know, this is extremely anal but it is impressive when it is done. I doubt you would ever lose points for not doing this.) Nice job. I would suspect that this code would pass the exam. Good luck with the exam.
    1 point
  5. Still none the wiser then...lol The correct translation is "Great minds discuss ideas ; Average minds discuss events ; Small minds discuss people."
    1 point
  6. I'm not a CLD and never took the exam, so take what I'm saying with a grain of salt. Let's start with ameliorations I would suggest: 1- You've put a "Wait Until Next Millisecond" and you use a 75ms timeout on your Get Queue primitive. If you were to remove it altogether, you'd still have the 75ms timeout to slow down your loop, except when you have something waiting in Queue. 2- That gets me to your use of the Queue repetitively for each of your actions. You parse the same string to the queue unless the time is elapsed, in which case you reset and move on. That works OK in this case, but in real life, you'll want to start a process, say "Main Wash" and you can't do that repetitively until it's finished. In fact, you call "Main Wash" a hundred times before it moves to the next action in the list. There are probably ways to salvage your design to make it call each car wash action only once while keeping track of time and position switches. 3- Probably minor, but your Queue wire is bent around a Case Structure for each car wash actions. It would probably be better style to try straightening it. 4- Your Default case executes the same code if your queue reads an empty string (timeout), "Wait" (which I haven't found in your program) and any other command that is not an handled state. You could add an "unhandled state" diagram that would correspond to your Default frame. If the queue is empty, you could use a "Idle" state (or Wait) and put an Event diagram to really wait for the user to take action of one of the switches to change state. With timeout = -1, you wouldn't have to worry about the processor running to fast when Idle and you could wait for an event to happen. As a collateral to using an Event diagram, you would have a more expandable program. For example, take your call for activating a car wash selection: With two choices, it doesn't clog your diagram, but what if you want to add a third one on the fly... or a fourth. You never know what the car wash owner will ask next! 5- I would have added an empty SubVI for each action: Wash, Soap, etc. just to show the routine is being executed in the right frame. To convert your program from example to real-world, only the content of these VIs would have to be filled in. Positive points: 1- Indeed, the code is simple. You make good use of subVIs for repetitive tasks. That definitely shows you've thought about it before starting to code. 2- You've documentation all subVIs (descriptions, tip strips, frames, wires). 3- Code is clean and a lot of space to breathe. Apart from some minor wire bending, the code is easy to read. Finally, if you had some loose time left, I would document with a little more meat and make sure the tip strips are differentiated. All your wash state indicators have the same tip strip... (Do what I say, not what I do... most of the time I don't do that myself, except during exams!!! ) Good luck getting the CLD! Keep us posted.
    1 point
×
×
  • Create New...

Important Information

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