Got those "This VI doesn't match other VIs in the method" Blues

[PaulOfElora]

Fantastic! Thanks so much for all your work helping me understand this! I think I'll implement pretty much exactly what you gave me - paul

[PaulOfElora]

Yeah, Kevin, I've had a mental block on that from the get-go.  I kept looking at the TMSC node backwards, not sure why.  Thanks for your repetition & patience! paul

[PaulOfElora]

Just found a maybe relevant little nugget over at lava. Candidus wrote:

"Here is another idea: Maybe you even don't need parameter accessors. Make the argument a class that you use as a base for your parameters, let's say Parameter.lvclass. This class has a dynamic dispatch VI, Configure.vi. Derive classes from Parameter.lvclass, overriding Configure.vi. These different implementations of Configure.vi encapsulate the parameter access."

This sounds pretty cool.  Think it's one more level of sophistication up from where my neurons can grasp at the moment, but might be educational to pursue.

[Yamaeda]

---

@PaulOfElora wrote:

Just found a maybe relevant little nugget over at lava. Candidus wrote:

"Here is another idea: Maybe you even don't need parameter accessors. Make the argument a class that you use as a base for your parameters, let's say Parameter.lvclass. This class has a dynamic dispatch VI, Configure.vi. Derive classes from Parameter.lvclass, overriding Configure.vi. These different implementations of Configure.vi encapsulate the parameter access."

This sounds pretty cool.  Think it's one more level of sophistication up from where my neurons can grasp at the moment, but might be educational to pursue.

---

Wait with that. 🙂 As a step up you can use the 'other class as input', or a container-class which contains other classes. In your factory idea it could be good to have an Instrument-container, keeping a list of all instruments (thus a list of instrument classes). In that class you can have functions to get all instruments of a specific class, get instrument by name and so on. 🙂

[PaulOfElora]

Sorry, Yamaeda, can you clarify "use the 'other class as input'" for me?

[PaulOfElora]

Oh I think I know what you mean - include the other class in the containing class' data cluster, right?

[PaulOfElora]

Yamaeda - that's exactly the scenario I'm looking at with this HAL, trying to "future-proof" this system as much as possible.  It's possible that future configurations may have more, or fewer child class components than currently. For example, for "this year's model", I'm using a motion controller that has some limited digital & analog I/O capabilities that I'm using.  But 5 years from now they may decide to put that functionality in a different, separate I/O controller.  Actually, as I describe this I'm beginning to think that this "reconfigurable system topology" scheme is overly ambitious for me, at least right now - I do need to get this system up & running sometime before I retire!  Think I'll rein in my ambitions a bit!

[PaulOfElora]

Sebastian - just to clarify - in your Zebra Configure vi's up front - these are just accessor vi's, loading specific parameters into the class data - you're not actually doing any actions in them, right? thanks, paul

[Sebastian.Weber · Accepted solution]

Hi!

Correct, those are pure accessor VIs, no code inside.

The reason is that there are different places in my code where the connection to the device can be established, but configuration is read at startup, only. There's also some kind of repair mechanism to re-establish the connection if it was lost.

So it makes sense to have a VI for configuration only, which is calles once at startup, while the actual connect VI just opens the interface.