LabVIEW
PID tuning array instance
@AndrewIons01 wrote:
I am reading the OO approach to this code and am stuck. I have made an object called "Camera Data in" which contains the IMAQdx session, error and camera activate.
I would then like to open the camera session. I see this at the moment, what do I do?
You put your code there. 😊
Put data, like camera session reference in the class's private data.
You might consider doing a course. I'm not sure if there's a free one though.
Search LabVIEW like a graph! Hi Wiebe
The camera Data in.ctl the class calls on is this here.
What does this do exactly? I have put the IMAQdx open camera vi into the code but something feels wrong about it, am I doing this incorrectly.
Best Wishes
Andrew
@AndrewIons01 wrote:Can I ask, assuming I am successful in making a OO version of my code how will this help us solve the issues I have had with the PID.
It won't do anything for the PID.
Well, if the camera stuff lives inside a camera class, the main will be cleaner. You'd have a better overview.
@AndrewIons01 wrote:Will this approach allow you to run the code, simulating the camera, allowing you to observe how this code works?
If you have a camera class, it will just be a group of VIs with a private data cluster.
If you give the camera class a parent, a 2nd child will allow you to switch between the camera and the simulation.
For now, you're learning encapsulation.
A simulation class will be polymorphism.
@AndrewIons01 wrote:
What does this do exactly? I have put the IMAQdx open camera vi into the code but something feels wrong about it, am I doing this incorrectly.
Use Unbundle\Bundle By Name to get\set the data from the private data.
That's the point of the private data. The session should not have to 'leave' the class. The session should only be used inside the class methods.
Hi Wiebe
Is this any better?
In which case, can I use an identical approach for the other parts of the code:
1)Camera configuration
2)Background Removal
3)Ref image Capture
4) Main acquisition
5)Shutdown
Best wishes
Andrew
@AndrewIons01 wrote:Is this any better?
Yes, much better.
But why keep 2 errors?
I'd use the 'standard' VI error in\out. The internal error will make things harder, and you want things to be easy.
If the error in is wired to the IMAQ VI, the case structure becomes pointless. The IMAQ VIs will skip execution if there's an error in anyway...
@AndrewIons01 wrote:In which case, can I use an identical approach for the other parts of the code:
1)Camera configuration
2)Background Removal
3)Ref image Capture
4) Main acquisition
5)Shutdown
Yes, exactly!
When done this way, you'll end up with a nicely grouped set of VIs.
This will have only marginal benefits over VIs with a cluster input. Still there's a benefit. The cluster can be unbundled outside the class. This is more flexible, but this flexibility will bite you. You can't unbundle the class data outside of the class VIs, and that's the point of encapsulation. Less flexible, so less room for messing up.
Imagine and entire application where the cluster of data is used (unbundled\bundled) all over the place. Now, the implementation changes. The entire application will need to be revised (and tested). If the class changes, everything relevant lives in the class, and as long as each method does what it's supposed to do, everything will work.
The same goes for inheritance\polymorphism.
If you do make a simulation child (or a parent with two children), the entire application will work as expected as long as the simulation child does what it's supposed to do.
@AndrewIons01 wrote:
Okay sure thing, I will change this error, I would like to give the user the ability to select either 1,2 or 3 cameras to run and be able to allow them to select which one is Cam1 Cam2 or Cam3. this is why I kept the case structure. Is this possible with this new approach?
Of course.
The init of the class can have a camera input, to specify camera 1, 2 or 3.
