What Goes Into the Class Data of Hardware Classes?

[FireFist-Redhawk]

Morning all,

I have a little experience with classes. I have database VIs that use the factory pattern and I know how to use dynamic dispatch to my advantage with them in regards to mdb files vs SQL server. I am thinking about making my SmartMotor driver into a class-based driver (currently the top inputs and outputs are the motor ref). I'm wondering though, what would go into the class data of such a class? The motor ref of course, but what else? What goes into the class data of hardware classes besides the hardware ref? Maybe like model and serial and other properties of the specific device, and they get all get bundled in at the Initialize function? If anyone has any examples I'd love to see them.

In my specific case, the Initialize outputs an array of motor refs because you can also wire them in series and send commands to them either globally or to a specific set of motors in the chain. I've not yet come across a situation where I'm controlling multiple motors though so I always index the array once I get it. Headache, but I do love the scalability of them nonetheless. One other thing that I'll mention for my case: SmartMotors are essentially servo motors with an embedded microcontroller and a basic coding language and editor for making programs to put onto the motor(s). I2C/Ethernet capable, bunch of features. More info about them here if you'd like.

Spoiler

[LucianM]

You put in class private data whatever might be relevant for the methods. I would not save the serial number unless it is needed by at least one method that could be called later. For serial number you can create a method which reads from the hardware and returns the serial number as an output without saving it in private data.

Start developing the class, put initially the reference in private data and you will see later what other data is needed. If a method depends on another, that's a sign that some data has to be added to the class.

[rolfk · Accepted solution]

Just as Lucian says. I would add that you do not necessarily need to add anything that you may ever need in other methods. Something like the serial number could be a property of the class. Whenever you need that value anywhere in your driver use this property accessor. If the property implementation then gets the data from an internal private data element initialized when creating the object, or reads it directly from the device and possibly caching it in the private data or just rereading it each time, will be all a private implementation detail that you can change at any time later on.

Thumb of rule, if the information is used a lot in the driver then initialize it once and just use the property to read that value everywhere, if it is potentially used frequently in a part of your driver that may never be called in typical applications, then read it from the device the first time you need it and cache it in the private data and if it is rarely needed other than for informational purpose, just read it every time it is needed.

But if you create a property to access this information, and consequently access the information using this property, which can be private, protected or public, you won't need to change the driver later on except for this property accessor, when you discover that it should be rather cached as your driver suddenly needs it a lot.

The principle should consider the communication link. Most communication links are relatively slow, so rereading information repeatedly over a "slow" link can slow down your driver a lot. On the other hand you don't want to slow down initialization of your device by reading a ton of information from it that may never really be needed, whenever you create the driver class. Besides you can put in zillion of data into the private class data, but you will be cursing yourself later if you have to maintain such a beast. Keep it lean and simple and don't optimize prematurely. If you plan for it (by using consequently property accessors for instance) you can still change it later on when real world testing shows that it gets slow to use, without causing a complete driver rearchitecture.

Last but not least be vary about device state information. Caching that can be a bad idea depending on the nature of that information. For instance information like if a device is in error state, the motor moving etc, are clearly dynamic and should NEVER be cached. They need to be queried the moment your driver or the user wants to read them. Other information can be semi-static. For instance you could have a measurement mode that can be altered directly through a command or also indirectly through some other commands that implicitly change this mode. If you decide to cache this mode in your driver you need to be very careful to consider such dependencies and force a mode read update whenever you call another function that may potentially change this mode in the device. Any cached information needs to be kept in sync with the device, so if you can't be sure that you can guarantee that, then don't cache that information!