Jump to content

LVOOP Example Code


Recommended Posts

You missed a key trick -- that enum is a maintenance hazard, and there's an easy way to avoid changing the mechanical action of "Plus 2". Oh, and I renamed your "Data.lvclass" as "DoNothing.lvclass" since its job really wasn't to load the data but just to give the queue something to do on those events. See attached file.

You can actually get rid of the Value Changed event case and the shift registers entirely by just moving those FPTerms outside the event structure -- I didn't make that change in this revision. I could've gone a lot further in the refactoring, but I figured this revision highlighted the enum improvement the best.

Download File:post-5877-1230873647.zip

Link to comment

The modifications you made were the original intent.

I find that this architecture is difficult to implement in "real" applications. The data operated on, in this example, has very specific input and output. When the data operated on is unique the implementation becomes more challenging, similar to implementing automatic selection of polymorphic vi's.

Link to comment

QUOTE (Aristos Queue @ Jan 1 2009, 09:20 PM)

You can actually get rid of the Value Changed event case and the shift registers entirely by just moving those FPTerms outside the event structure...

Since they are all Value Changed events, I'll make the bold assumption you're referring to the X and Y Value Changed event. :laugh:

I'm wondering why you suggested that particular refactoring. How would the compiler treat the current code differently if we pull the x and y terminals out of the event structure? I assume it would do as coded and assign the front panel value to a memory location on every loop? Any idea how that overhead compares to the overhead of monitoring an event?

I only ask because I tend to use these manual "optimizations" as well since I don't know smart the compiler is and from what I've read it's "better" to put something like changing the x and y value in an event rather essentially polling them on every loop. (Obviously there will be very little performance difference in this particular example. It's more a question of style and principles.)

Link to comment

QUOTE (Daklu @ Jan 2 2009, 07:55 PM)

Since they are all Value Changed events, I'll make the bold assumption you're referring to the X and Y Value Changed event. :laugh:
yes.

QUOTE

How would the compiler treat the current code differently if we pull the x and y terminals out of the event structure?

It's not the compiler. If we pull those out, we can get rid of the "DoNothing.lvclass" entirely. And the loop wouldn't wake up to try to do the "Enqueue Element" just because you typed in new numbers.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

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