jgcode

If you double click the lines in the error list (the picture that you posted) LabVIEW will automatically show you the errors on the block diagram. The reason you have the errors are that when you use a case structure you must specify an output for each case for every tunnel. At the very least you need to select Use Default if Unwired. See how you go with the above information. By the way, you are missing a subVI in your attachment "multiple time delay match.vi"

This is a great discussion Was there a reason for (not doing) this? (Off the top of my head) Is this related to / is there still a problem wrt LVOOP + XControls and infinite recursion??? - I remember AQ mentioned something in a post about a deep architectural barrier, and a problem but can't find the post.

No, coz the damn mouse is still jiggered.

IMO I think it is very important to have a defined term so it can be mentioned and people know exactly from the get go, the topic (whatever that topic is, design patterns, oop etc...). Alright - cool then in summary...?? We are still LVOOPing regardless of using either the native byValue (original LVOOP) or byRef (DVR with LVOOP) so if it is agreed by the big wigs I am going to call them native object references, or object references for short. Can we get a NI whitepaper? Thanks

Cool - thanks for this, this is exactly what I am after Kudos

Free media from the net - as in bit-torrent Hmmm, I should stick that on the office door!

Far enough, but did anyone internal coin a phase when they put the two together? Also what do you prefer? Did you/where you involved in creating the DVR's?

Hi Paul Thanks for the links to the updated documents above. Do you have any examples of where this may be used in a design pattern? I see that the community scope needs to have static inputs which is interesting.

Just on a side note do people pronounce LVOOP: el-ve-oop or el-voop (as Crelf above) Is there correct way? I may have been saying it wrong for the last few years

Because of the need to stop the task in MAX it might be best to do something in LabVIEW. You could easily update scaling parameter when the user changes the scale. More flexibility, but more work. I would just tell the Boss its not possible to do in real time from MAX.

Cheers - The launcher is very easily solved by calling the UIs as subVIs and using dataflow (sequence structure) to keep everything alive. Your request/issue for Read Only is inline with Jim's above. Maybe an idea for the exchange forum? Also I think I found where this new subVI fits in - I used this badboy to recover the data and retain dynamic dispatching - nice! Is there any other use cases for it?

Is "LVOOP-DVR" is a little long winded Does the LabVIEW community have a name for LVOOP-DVR'ing? Is it too confusing to call it GOOP with Endevo, Sciware, DqGOOP etc already out there? Was there a name that came up at NI Week 09 from NI? Or is it too soon yet to have one? Can we vote on one? With all the flavours it would be to be able to distinguish it when talking about it.

Hi dblk22vball You can easily add scales in MAX, they appear as per below: You can edit them whilst the global channel is running, but you have to stop and restart for the change to take effect.

I don't understand. Are you able to elaborate please? Cheers

What are people doing with Friends Classes? How do they fit into the LVOOP paradigm?

Please do! Hey Kurt I missed your posts on this thread so I have just downloaded your code. The code you posted is quite cool. And very similar to a current project I am working on - I have/had to model a furnace for a client and decided to go with an Active Object - the client runs from source (don't get me started) in LV8.2 so I couldn't use any licensed toolkits when hacking his system. But I basically used your Active Object from Endevo as the template with a LVOOP-SEQ framework and it is working really well. It seems that the DVR would slightly simplify this process. I implemented the process.vi using the JKI State Machine which worked really well, so instead of having a finite State Machine, I had a queued State Machine that could except arguments using a syntax that I am familiar with. I used dynamic registration for the messages coming back. It worked nicely - so good job on the Endevo AO stuff. I actually have to give a user group presentation on this DVRs and stuff, so I have been playing with them all day today. They seem robust, I guess I have to keep using them to figure out how to do this stuff the best. But if anyone else can keep posting up what cool stuff they are doing with them that would be awesome. One thing I did pick up - and correct me if I am wrong - it seems that the reference goes out of memory along with the owning VI. I had a launcher.vi that created the LVOOP-DVR refnum and then passed this to the launched VIs. By the reference seemed to die when the launcher stopped running. I don't have this issue with SEQs.

I have seen these links, don't know if they will help? http://decibel.ni.com/content/docs/DOC-5381 http://decibel.ni.com/content/docs/DOC-4139 Cheers

Check out from around slide 52 improving_performance.pdf Check out from around page 10 17 - Managing Performance and Memory.pdf

Hi Pete Any VI Server reference you explicitly open - you should close. That is good practice to avoid memory leaks. I am pretty sure tho that AQ posted somewhere here, that with property nodes, the references are closes when the owning VI goes out of memory.

Damn straight! I got the PS3 connected to the server via wifi running some open source software to browse my media. I don't think I could live without it. That and torrents of course! The only problem is that the router is on my desk and it jiggers with my wireless mouse. This is a problem when my misses is watching stuff and I am trying to LabVIEW

(Haven't used it for a while) but I believe this is correct too

I find the can is a great place to think and to solve problems as well.

Its worth a mention that, that feature is only available in LV8.6+ Jcarmody is right - If you want to update values on a case by case basis, then pass a single cluster via a Shift Register (or feedback node) and bundle the changed value per case into the cluster. Wiring all those values out through the structure as you have, is just plain ugly and is why you think you will need to add more wires when adding more cases - this is incorrect. LabVIEW used correctly is very elegant.

The output of each numeric is always going to be the default value of a double (DBL) - which is zero, as you have use default if unwired selected on the output tunnel of each one on case structure. You will only return the correct number for the case that iterates last in the for loop.

If I read the problem correctly - this may work?