Methods to break down large VI so that it runs faster

[krwlz101]

Sorry, forgot about those.

Yes, those are parts of the front panel that I havn't written code for yet.  I wanted to get a little feedback before I went too much further so that I wouldn't have to recode anything I didn't have to.

Application and panel close events seem to make sense.  I'm assuming the logic for this is to prevent unexpected results coming from someone not stopping the program first?

As for the shift registers, looks like I'll just initialize them.  I guess I can't see any reason why not to in this case.

As for producer/consumer loop.  I looked at those when I layed out planning for this re-write, but didn't go there because I felt I didn't fully understand the mechanics of notifiers.  Now that I have some structure put together, it might be a great time to implement a producer/consumer loop and learn about those as well.

As far as looking better, thanks very much (I'll admit, I'm a little proud looking at the before and after), and that is a direct result of reading the style guide at least three times before re-starting this project.

You guys have been great, thanks again.

Message Edited by krwlz101 on 03-11-2010 11:07 AM

[Ben]

---

krwlz101 wrote:

...

You guys have been great, thanks again.

---

Thank you for posting that, and yes they are great aren't they?

Ben

[JÞB]

---

Ben wrote:

---

krwlz101 wrote:

...

You guys have been great, thanks again.

---

Thank you for posting that, and yes they are great aren't they?

Ben

---

Yes we are!

[krwlz101]

So,

I don't think I'm getting this producer/consumer thing.  

In concept, I should be producing the state I want for a given event in the producer loop.  The consumer loop takes states out of the queue whenever it is finished with it's current actions, then executes those states.  Correct?

My FP is only occaisionally updating, and I'm not quite sure where I went wrong.

[Yamaeda]

I'm not all experienced with the producer/consumer yet, but 3 small things that i reacted on:
- What's your initial state? You're not queuing anything (which might not be an issue)
- The Consumer only consumes Queue elements! It pauses if the queue is empty! Your state shift register gets redundant, you should enqueue your next state instead, just like it's the state extracted from the queue that you'll consume. (this means the queue will need to be wired to the case structure (just to use it, not to the selector))
- You can wire the queue to the stop button (in the consumer), which then stops if there's an error. This error is created by destroying the queue in the Stop button event. 🙂

/Y

Message Edited by Yamaeda on 03-11-2010 09:56 PM

Message Edited by Yamaeda on 03-11-2010 09:58 PM

Message Edited by Yamaeda on 03-11-2010 10:03 PM

[krwlz101]

How do I destroy the queue?

EDIT:  Nevermind.

Message Edited by krwlz101 on 03-11-2010 03:15 PM

[Yamaeda]

Ah, slight edit! It's ofcourse not the queue you wire to the stop button, but the error out of the dequeue element. 😉

[JÞB]

I like the Idea of a discrete stop command.   When the queue gets destroyed the dequeue element vi does output a default element and that can cause odd behavior. 

And this is a good first pass a both queues and P-C loops

Look into the queue examples.  the trick is to only queue commands in the producer loop.  the consumer loop should only respond.  

as far as the FP loock-ups.  I'm thinking that you are queueing multiple sysparam commands when you change values of multiple params.  your flow (for the moment) goes immediatly to solveODE.  this seems a touch "bulky."

An  "Accept changes&solve" boolean would seem appropriate. 

Looking at it from this perspective.  Some of your states are related.  I would combine Read-Solve-display. and have 3 states.  Update function, RSD and Stop.  But your really catching on FAST!

Message Edited by Jeff Bohrer on 03-11-2010 03:43 PM

[krwlz101]

Jeff,

I was originally going to use some sort of accept changes and solve boolean,  The reason I decided against it was the fact that I would want to see both the current values, and the "go to" values, so I was sure that the graphs I was looking at corresponded to the inputs I was looking at.

Figured if I went right to solve, then I wouldnt need duplicate indicator/controls. Perhaps I should use a "Update Sys Param" button to open an input window.  It seems to be a little redundant, but might make the code run smoother.

[JÞB]

---

krwlz101 wrote:

Jeff,

I was originally going to use some sort of accept changes and solve boolean,  The reason I decided against it was the fact that I would want to see both the current values, and the "go to" values, so I was sure that the graphs I was looking at corresponded to the inputs I was looking at.

Figured if I went right to solve, then I wouldnt need duplicate indicator/controls. Perhaps I should use a "Update Sys Param" button to open an input window.  It seems to be a little redundant, but might make the code run smoother.

---

A nice idea!  for a few reasons

• it modularlzes the code 
• Removes the excess events
• presents the data to change in a user friendly fashion
• Its scalable.

Hint-

Type def a "super cluster" and store it in an AE. (if you feel ambitious you can even persist the values to a config file)