ahull Posted January 1, 2009 Report Share Posted January 1, 2009 Action is the Class. Quote Link to comment
Aristos Queue Posted January 3, 2009 Report Share Posted January 3, 2009 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 Quote Link to comment
ahull Posted January 3, 2009 Author Report Share Posted January 3, 2009 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. Quote Link to comment
Daklu Posted January 4, 2009 Report Share Posted January 4, 2009 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.) Quote Link to comment
Aristos Queue Posted January 4, 2009 Report Share Posted January 4, 2009 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. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.