10-26-2017 07:06 PM
Hi All,
I have a quick question about class control setups.
In short, I made a parent class with multiple child class to simplify my work with Keithley SMUs.
However, I have question about setting default parameters for each child class.
Say, I have 2430@23, 2400@24 and 2651@26.
The way I do it now is use accessor at initialization to write address into it.
I would like to figure out if there is a way to embed the child-class specific parameters somewhere so I don't need to write this address every time?
10-26-2017 09:39 PM
@Jals wrote:
Hi All,
I have a quick question about class control setups.
In short, I made a parent class with multiple child class to simplify my work with Keithley SMUs.
However, I have question about setting default parameters for each child class.
Say, I have 2430@23, 2400@24 and 2651@26.
The way I do it now is use accessor at initialization to write address into it.
I would like to figure out if there is a way to embed the child-class specific parameters somewhere so I don't need to write this address every time?
Yes there is- Use a VISA Alias and let VISA abstract away the information you are trying to hide in the class anyway. Yup. the Class VISA Session already has a Child I/O Session.GPIB:Instr that has GPIB.Settings<PAdd, SAdd, ReAdd, UnAdd & REN State> So what would be the benefit of hiding a subset of that in your class?
10-27-2017 04:54 AM
Getting a cluster and then setting it again really rubs my OO hairs the wrong way.
It's some extra work to make (protected) methods for these settings in the parent. But then you'd at least be able to find the places where you set the resource. Exposing the cluster (can't see if it's protected, but still) goes against the entire encapsulation\abstraction principle.
If it's the get\set cluster VI's are public, you're certainly heading towards disaster... The cluster will be used outside the class, and changing the implementation won't be possible.
Since I've started OO, I'll rarely use clusters anymore. Simply because the are not needed anymore.
Might be wrong about this, other might disagree and you've might given it though. Could also say I should mind my own business. Please consider this friendly advice. I'd reconsider while you're ahead of things.
10-27-2017 06:43 AM
Create a method called "Set GPIB Address". You can then build up the VISA Resource String quite easily, initialize the VISA Session, and store it in the parent's private data all within that method. It makes things easier to use.
You definitely should not be reading a private data cluster, update a single parameter, and write it again. That is considered PRIVATE data for a reason. Nobody outside of that class should care what the VISA session is. So keep it all inside.
10-27-2017 09:50 AM
@crossrulz wrote:
Create a method called "Set GPIB Address". You can then build up the VISA Resource String quite easily, initialize the VISA Session, and store it in the parent's private data all within that method. It makes things easier to use.
You definitely should not be reading a private data cluster, update a single parameter, and write it again. That is considered PRIVATE data for a reason. Nobody outside of that class should care what the VISA session is. So keep it all inside.
I'd love to see that method!
Oh, maybe you meant something like this?
crossrulz, the point being (ahem) You can't SET a GPIB address! it is read only and defined in the remote instrument.
10-27-2017 10:19 AM - edited 10-27-2017 10:19 AM
I think Crossrulz mend you build a visa resource string, by replacing the GPIB address in the string:
GPIB::%d::INSTR
The name of the method is Set GPIB Address because it sets the GPIB address in the object.
10-27-2017 10:30 AM - edited 10-27-2017 10:33 AM
wiebe@CARYA wrote:
I think Crossrulz mend you build a visa resource string, by replacing the GPIB address in the string:
GPIB::%d::INSTR
The name of the method is Set GPIB Address because it sets the GPIB address in the object.
I think he meant that too we don't need to set it. We need to discover the address on the projects targeted system then align our project to use that discovered information. I'll stand by my practice of aliasing the VISA Resource as a simple string (Of course, you COULD use an "Alias" string of "GPIB[n]::pd[:sa]::Instr" but that seams unwieldy to me for the developer to translate to a specific resource)
lets try that again the alias string has replaced a "Colon p" with an emoji but that shows just how much nicer it is to document and support a Alias like "MyProj_K2430SMU_1"
10-27-2017 10:33 AM - edited 10-27-2017 10:34 AM
@JÞB wrote:
I'd love to see that method! ...
crossrulz, the point being (ahem) You can't SET a GPIB address! it is read only and defined in the remote instrument.
Fine. My method is actually called GPIB Address To VISA Session.vi
10-27-2017 01:12 PM
To clarify what is going on here is a bit more than what is shown.
The parameters are encapsulated in parent class control
and I left child class control blank to inherit from parent control
The situation is that, at different location. There are a few scenario where I need to change address for the child class. (maybe what I am missing is handling of child-class-control)
1. I am calling a child class that runs a default VISA address
What is done now is like shown in above snips that I alter VISA address while initializing the child class. probably the worst way to do it for sure
2. The default need to be changed because the equipment at the given location is set to a different value, say 200 instead of 24 for existing system. Then I need to alter the VISA address to 200 to make it work.
10-27-2017 01:43 PM
@jals:
I think that is exactly how all of us imagined it.
Mostly as it should be, except he clustering in the private data. The serial cluster is ok. Since it's a "standard" cluster it's almost like a class. The Device_Config is undesirable and redundant.
Give the parent two protected methods: set serial config and set visa resourse (or set GPIB address) and you're done.