Scripting Accessors

[shoneill]

Warning: I'm not a scripting veteran.  I know my way around vanilla Vi Server pretty well, but Scripting is still (kind of) new for me.

 

I am looking into the possibility of scripting a different kind of accessor for a "framework" (I use the term loosely) I am working on.

 

What I'm really not sure about is whether I should try to leverage the VIs present in the "\Framework\LVClassLibrary\" directory.  Most are password protected and I'm unsure as to whether the work will be easier wrangling the existing code to do what I want or just doing it from scratch....

 

I don't need IDE integration, just code which can be run when needed.

[Neil Pate]

 

 

 Most are password protected

 

In LV2014 all the VIs in the NewAccessors directory are not protected.

[shoneill]

Hmm, stuck with LV 2012 SP1 unfortunately.....

I wonder if they still work if I save for previous....?

[Neil Pate]

Hmm, stuck with LV 2012 SP1 unfortunately.....

I wonder if they still work if I save for previous....?

 

Perhaps the VI Server/Scripting API for some of the stuff has changed, but I expect a lot of them would work. Annoyingly a lot of the other VIs  in LVClassLibrary are still password protected.

[hooovahh]

Perhaps the VI Server/Scripting API for some of the stuff has changed, but I expect a lot of them would work. Annoyingly a lot of the other VIs  in LVClassLibrary are still password protected.

In many cases a private method was made public, so there is no reason to password protect a VI.  But in some cases these methods have new inputs or outputs between versions, so back saving would break the code.  You'll then need private methods enabled so you can pick the older version if this is the case.  If we just made all private methods public it would take care of this problem...and create many more.

[smithd]

Hmm, stuck with LV 2012 SP1 unfortunately.....

I wonder if they still work if I save for previous....?

I'm not sure where but I'm guessing GDS has some scripts you can use as a starting point, and the master branch is in 2012.

 

Edit: didn't realize its GPL. May cause issues for you.

[jgcode]

Warning: I'm not a scripting veteran.  I know my way around vanilla Vi Server pretty well, but Scripting is still (kind of) new for me.

 

I am looking into the possibility of scripting a different kind of accessor for a "framework" (I use the term loosely) I am working on.

 

What I'm really not sure about is whether I should try to leverage the VIs present in the "\Framework\LVClassLibrary\" directory.  Most are password protected and I'm unsure as to whether the work will be easier wrangling the existing code to do what I want or just doing it from scratch....

 

I don't need IDE integration, just code which can be run when needed.

 

Hi Shoneill, are you able to provide details of are planning? This code is 2012, open source, and includes a modification of the library references above (creates a wrapper around a delegate class). 

[shoneill]

I'll check them out, especially the LVOOP assistant.  Looks promising.  Open source is way cool.

 

I am looking to script accessors for a RT framweork I'm working on.  We have a fixed-width input pipe and output pipe for registering for changes made within the timed loop of a RT system.  These pipes are 64-bit in width so I need to be able to create accessors for each and every scalar in the private cluster (unbundle.unbundle.arrayindex.unbundle.scalar for example).  In addition to this I need to create an "index" enum for each class for the actual values so that I can auto-create a polymorphic VI for host-to-RT communications for these parameters.  In addition (it's a multi-step process), I need to script the return channel which takes a parameter index as an input and monitors for changes and sends back changed values (handled by a delegate with a U64 interface).  All of this work is highly repetitive and extremely boring and error-prone to do manually.  Each small modification becomes tedious to the extent that I simply don't want to make changes any more.  I'm currently designing a schame to auto-create the entire host-RT-Host pathway for strictly-typed parameter storage on the RT.  The actual logic of what each module is supposed to actually DO is implemented manually (if only that could be automated also!!    ).  At the moment we have a single SGL array as a parameter storage with an associated "God" enum.  Obviously this makes encapsulation almost impossible and links each and every module we have to the entirety of all parameters we have in any module we have ever implemented.  Not optimal.  I am aiming for properly encapsulated objects with standardised in and out to the RT loop (implemented in the parent class).

 

If I ever get to actually implement it, I'll give feedback or maybe even contribute the accessor code if my employer allows it.