jgcode

I must have missed this earlier in the thread... I'll have to try and track down the reasoning tomorrow.

I think there is cross-talk between the two implementations "8.2, 8.6" and 2009!

Hi iyeager

I haven't looked at your code - but it sounds crazy if you are having to make 15 different apps of the same thing!

Changes in names, settings etc... should be handled using configuration files (or the like). In this case you could even look at the features of MAX and whether they may help too.

This way you only have to build one app and you can easily switch hardware around simply but just importing/exporting a new configuration.

Cheers

-JG

In fact I see the DVR as being completely superfluous: if you're just going to copy the value in to or out of the DVR... <snip> ...Its fraught with race conditions since there's no locking mechanism in place.

Yes, good point - but I think the 'race condition' issue is just a use-case issue rather than a design flaw.

All transactions that occur inside the IPE are atomic, so you are safe if you create a 'Singleton' methods for everything you want to do and its done inside the IPE.

If this is not flexible enough then don't use it, instead pass a DVR around whereby the developer has the choice to implement the lock-and-unlock paradigm and select and run methods where required.

But I have also seen the 'same' race-condition is other's code when an API is created for a DVR'd Class - which is why I see it as a programming\use-case issue rather than design flaw.

This is also (one of?) the reasons why NI would not allow wiring a DVR to a Class Method (PN only not IN) for fear of creating issues with unaware developers. Whilst I would still like the feature, I have seen it done 'accidentally' by experienced developers, so can now definitely see where NI are coming from.

why not have the value in the LV2G instead of the DVR (the path value that is)?

The advantage of the patten is that the code required is much simpler and cleaner than using a traditional FGV.

When I used to use FGV\AE\MFVIs a lot (pre-LVOOP) I implemented them as follows.

• I don't like placing enums (methods\commands) down on the BD
• The enum should be private so private methods cannot be called
• If the enum gets updated, I don't want it affecting application code
• So I wrap each method call to the FGV in a wrapper VI
• This means I can also defined the data inputs/outputs of the method, rather assume user has intimate knowledge of the FGV
• I usually like to maintain an interface to the FGV which is a Cluster input and Cluster output so that I don't fill up the connector pane
• So in the wrapper VI I have to bundle up inputs and unbundle outputs

All the above work in not required in the AQ's 2009 implementation, no enums, bundling, or wrapper VIs.

To handle reuse between different singleton methods I create method VIs of the DVR'd Class.

AQ's 2009 post really is not a singleton.

I am not really fussed whether it is technically a singleton or not, only that if the pattern fits my use case, then I like to use it.

Something else to consider--by stringing the error wire through all sub vis you're probably imposing artifical data flow constraints on your software, limiting the compiler's ability to create parallel clumps. As far as I know, NI tweaks and improves the compiler with every major release. Adopting general coding practices that optimize compiled code for one release might turn around and bite you in the backside with the next release. Wouldn't a better overall strategy be to wire your code for clarity and logical soundness first, then go back and apply optimizations if they're needed?

This is a good point but as this topic focuses around the use of Classes wouldn't the dataflow and hence parallelism be predominately defined by the Class in/out terminals of the method VI (making the Error in/out terminals irrelevant)?

Might be helpful if you post some code of what you have done sjukheter.

...

Has anyone actually measured the cost of wrapping everything in error cases?

Nothing in comparison to dynamic dispatch.

Well, yes I am keen to know too. I aside from the DD comment above, you are have overhead calling the subVI on a static method anyways.

Does the error case really matter?

Or is it a big overhead?

I would like to know the answer to that in the Dev Environment and in the Run Time Environment (if it is different).

As for me, in terms of Classes, right now I can't be bothered not including Error in/out terminals - except for Private and some Protected VIs.

The last thing I want is to update a Public method and find I don't have Error in/out terminals - that would cause a change in the Public API and I would want to go through my code and relink, I would rather just do that in the first place.

And I have never found an application has bogged down because of it.

Plus if I am chaining methods then I can keep them in a straight line for Class in/out and Error in/out and each VI in the API matches.

But... is there a worthwhile reason to change?

Ok, back on a PC - here it is...VI Server is the issue.

Hey man! The answer is out there somewhere coz I am sure I have read it on LAVA. But I am on my phone so I am no help at the moment. Anyways, maybe AQ will chip in and set the record straight.

[8.2 vs 8.6 SEQ FGV] I am pretty sure AQ has posted this already on LAVA. From what I recall he said there was an issue with the 8.2 implementation that prompted the fix for 8.6. And that he did not recommend using the 8.2 version. I guess he is the best person to answer.

FWIW the 2009 DVR implementation rocks. I really like the simplicity of it.

Hi all,

Is it possible to change values of front panel control while Dialog pop menu is active? I mean without clicking 'OK' button of the dialog menu and wait for it to disappear.

I am using 'One button Dialog' function.

I am developing automatic testing with dialog menus - sometimes I need to change to change my front panel values.

Thanks for your time..!!!

-Sharon

Hi Sharon

The default Dialog primitives are modal, so you would have to create your own Dialogs that would be e.g. floating, to do the above.

Ease enough, just means more work for you

Steve, you don't have to modify the templates as AQ added this feature in 2009.

Static and Dynamic 'templates' are generated in C not G. Accessor methods are G. You can find them and replace them (this has been posted before) or you can use the Custom Hooks to alter them (introduced in 2009).

Cheers

-JG

Seems like some people are going around in circles.

Mark, you use the term "truely decoupled" which implies that there are different levels that describe decoupling. Of course what John is saying is the higher level of decoupling. I have not disagred with that.

What also has been said is that applications can benefit from a level decoupling depending on requirements. I simply presented 'an example'.

Therefore, comparing the two directly does not make sense.

Ooh a t-shirt, I want one!!

Does that mean you already have??

Been there

So... I have no idea what your point is?

All I said above is that I 'hope' NI can't do it and if they can then IMHO I think it means it's not 100% secure - which you just agreed with above??

The other thing I said is that 'I think' Locked VIs get skipped because when I tried mass compiling these they still take ages to open in a new version leaving me to believe that each time onload the compile would happen but it would never save the changes due to the Locking property - which leads to a loading performance issue. That's the reason I gave up on Locking for distributing code.

Again happy to stand correct.

Happy to stand corrected... Well wouldn't LabVIEW need access to your block diagram in order to compile it? Meaning password protecting your VI's isn't completely secure? If I PP a VI - I want no one to access it - not even NI!

When you do this, how much code do you have on the UI block diagram?

About this much:

Get all the references, then its just handling events (sends message to engine) and receiving event (normally data to update screen etc...)

Trying to keep it simple: with skinablism - minimise duplicate code

More complicated stuff is done via references - configuring graphs etc...

Is the UI still your 'top level' vi in the dependency hierarchy, or is it more of a 'bolt on' component that can be easily swapped out?

Nope,

In the case above the engine can run the UI thread (or another higher-level VI could run all threads, but old habits).

If you want to change the UI then drop and new one in and delete the old one.

Of course you could do it more spectacularly (e.g. dynamically instantiated etc...) (code to switch between the UI's at Run Time etc...) but this project did not need it, nor could I be bothered (I just want to decouple the UI further).

As per your 'slave loops' it easier to program on the separate thread just be double-clicking to open it.

The untold power of mods!!

The untold power of mods!!

@Ben [Time] You obviously missed Jeff's NI Week 2010 speech then

Hey Cat, good luck with the surgery and lets us know how you go.

Hi Mross

What are the sizes of the array wired into the for loop? The smallest number determines the number of iterations. I am willing to bet one of them is equal to zero or one??

Cheers

-JG

Is this homework?

The end result is that the OS Open Document is called and everything works swimmingly

Good job!

Hi Martin

Please post what you find - this is something I haven't played with but sounds really interesting!

Cheers

-JG