jgcode

Did I explain my problem well enough?

I like to use libraries when appropriate.

In the first part of your question (not RT issues) - yes .lvlib file will be loaded along with the called VI(s) but can you go into detail about what problems this is causing you?

Very cute.

Well done mate!

No last night it said 'Forbidden' (whatever http.status that is) - so I wanted to check if others had this issue.

This morning it's working. So it could have been an issue on my end (mobile). Either way, all good now

Thx.

Link doesnt work for me?

Is that a euphemism?

Ha! Looks like more like language barrier issues.

Not quite what you are probably thinking...

I'll take any opportunity to razz you up

I too used the action engine approach also. I eventually split out the sub-frames into separate VIs

You did what!?!

...Lol

Typically, I keep my actual data disconnected from the FP. If it's a control we're talking about, I use an event to update internal state data and then reference that where necessary; if it's an indicator, internal state data will occasionally be pushed to the front panel. I use locals over property nodes if I don't need to enforce execution order, but to be honest, everything has its place. I didn't mean to hate on locals, necessary, but they just leave me feeling icky.

I do the exact same thing - separating data from UI.

I just like don't have issues with using locals to update a control when it comes time to push state data to the FP.

I expect that you still bend or break your rule, though... That's what rules are for.

There is one particular use case where I use them for the wrong reason but it's hidden - but yes you are right! However, normally I don't and don't need to break that rule

In general, I avoid Locals.

Whats wrong with locals?

I usually prefer them over references to update a control.

However, I the rule I use is: one per control on each diagram (in the case of e.g. a state machine).

The Shared Variable API is a bit more polished IHMO and recommend using it over DS as well - better error information etc... Although for reasons that escape me, I have used DS over SV-API for particular use cases in the past.

Well done!

Thanks Jim

DSC module uses totally different Shared Variable type than LabVIEW base. So, if you want to use functions for monitoring SV value changes, you cannot use LV base functions like "Read Variable" on the same variables. But you can use the DataSocket functions like "DataSocket Read".

I am not sure if that entirely true - you should be able to convert one datatype to another e.g. using a transitionary string and making sure the URLs are correct (as they are different).

Poor naming perhaps but I retain that right as a LabView programmer and not a computer scientist

You can't do this.

If creating plugins like this the Parent Class is the 'interface' so you should design it to use DD to add new behavior from Child Classes - as opposed to case structures as you mentioned.

Is a Control or View an Instrument?

I would say no - so maybe you should look at a different type of relationship.

For example setting the e.g. view with the instrument data rather than inheriting from it etc...

If I use the latter, is the connection closed implicitly, or what? And if this implies Open/Read/Close how much overhead do Open and Close this bring?

I haven't used it for a while - but if I remember correctly after the first read/write, it's a pretty similar speed.

Should be pretty easy to test tho.

This package will be available for download through VIPM in a few days and contains new VIs for working with LVOOP data created by drjdpowell.

The API has been designed with optimization improvements available in 2012 in mind.

The palette has been approved by asbo

[NEW] 3484610 - New LVOOP Data Functions

Kind regards

Jonathon Green

OpenG Manager

Thanks everyone for their input - especially James for his donation of VIs.

This OpenG Review is now closed. Please start a new thread to discuss new changes to this VI. Please PM me if there are any issues with this thread.

I have added a new version to the LAVA-CR - v1.1.0.39 which contains the following new features:

- New (): Added 'New Templates' feature

- New (): Added 'Methods Sandbox' feature

- New (): Added 'Refresh Icon' feature

There are now in built templates I use - you can pop-up on a Class and select New Template to add a template to that Class

If there are other common templates, please post and I can look at adding them

By placing your own templates in the Templates Folder...

...You can script new Class Methods with them

Pop up on a Class and select Methods Sandbox

This UI will allow you to quickly script either the inbuilt or custom templates to create new Methods:

The last feature allows you to pop up on a Class Method to quickly refresh a Method's icon without having to open the Class Properties Dialog and refresh all icons

I have added a new version to the LAVA-CR - v1.0.0.23

This version supports LabVIEW 2011 and integrates into the LabVIEW Project Provider API

The previous version was broken in 2011 as the Icon Editor API was not supported due to a switch to PPL 2011, so this functionality will not be included at the moment.

I started playing around with the Provider API with Create Child Class which was a good plugin to start with.

Along the way I found out that there was a limitation preventing me from releasing individual packages under one 'banner' so I will just be upgrading this package with new functionality in the future.

And therefore won't be updating the Create Child Class package I posted - it will be done in this package.

I've also moved the Rename LVOOP Labels code into this package as it more intuitive to use with the Provider.

I need to brush up some stuff (examples etc...) but it this package is ready for feedback so please post

So, in summary v1.0.0.23 supports:

• Rename LVOOP Labels
  
• Create Child Class
  
• Clone Method
  

Right-click on a Class or Class Method VI to access the plugins:

Go to Tools>>LVOOP Assistant to access other stuff:

It also uses the Preferences code I OpenG'd up

Enjoy!

Not keen on the document idea which would basically be just a list of links that someone has to maintain.

Actually you could add links, text, pictures or even code.

And the Community could maintain and add to it as opposed to an individual someone.

Currently code in the CR is reviewed which I don't see the point of (too formal as you say) and a dedicated forum seems a bit of overkill?

In the past I've used .NET and the VI mje describes.

I also using scripting to update a VI pre-build with the info programmatically.

I generally use the latter approach for tools but it would work in an exe, it's just I have re-use code for the exe.

I have posted a LabVIEW Project API and a build script on LAVA (sorry no link on mobile too) that you could look at as an example.

I was thinking we could just make a new category in the code repository? That's essentially what we're talking about, after all, it just happens to be a specific implementation instead of reuse code.

I guess the choice will depend on if you want to track the code and related posts (comments etc...) or just the code.

Sweet.

I wonder if we could get an "area" on Lava for these so they are all in one place and easy to find

I suggest starting a document in the new knowledge base section - it would definitely suit this use case.

You can turn a thread into a document but I would recommend creating a new document that contains links to these posts.

You missed out! This was mentioned in the LAVA upgrade thread when we first switched over to the new board software.

Yes I did.

Or,

No I didn't (but then have forgotten )

Either way I like it! (unless I forget it again...)