Integrating AF & LVOOP with hardware

[BertMcMahan]

---

@AristosQueue (NI) wrote:

> Power detected -> Send email to Jerry

I liked my Turkey-Moving Robot example better. Every kitchen should have individual robots each dedicated to carrying one specific item, right? 🙂

---

Jerry is the name of the turkey-moving robot 😉

[WavePacket]

---

@AristosQueue (NI) wrote:

---

@WavePacket wrote:
...

---

..In fact, Allen is strongly considering the position that all nested actors should talk only to interfaces, never directly to callers, on the grounds that the weight of creating the interfaces is minimal and then ne doesn't have to think about whether reuse is a possibility or not. I think that's going too far, especially for smaller AF projects. We have not had interfaces in LabVIEW long enough to make a preferred policy, but it's the hypothesis ne is playing with these days.

---

So I was thinking a bit more about this and was asking myself a related question, but perhaps from another angle. Are there situations were a nested actor needs to send a message to a calling actor, in such a way that it needs direct access to the the calling actors methods?

We're sacrificing flexibility and reuse, so shouldn't we be getting something in return. If we aren't getting something in return, why would we sacrifice extensibility?  

[WavePacket]

Hi Guys,

I'm resurrecting this thread as I was sketching out some test code for a specific actor. This actor will delegate to some hardware, and I was hoping to use interface based messages. I ran into a nut which I'm not sure how to solve right now.

Let's presume that I have an interface defining all of the messages associated with a hardware actor, and I then begin to write multiple test programs that need this actor. Both the hardware actor and the actor's of these test programs will inherit the interface defining the messages, but, and here's the rub, is that often test softwares will only actually use a subset of the interface messages. However because of the must override rule of interfaces I'll have to implement all methods inside every test program actor (even the unused ones).

Seems like I'm violating the interface segregation principle of OOP, but I'm not sure how to get around it...any thoughts?

[BertMcMahan]

Use multiple interfaces. Group common functionality into each one. For a very simple example: you may have a Multimeter device that could measure Voltage, Current, Capacitance, and Resistance. If your test only measures Current, then it doesn't make sense to have a Multimeter interface, but a Current Measurement interface.

By splitting the above measurements into four different interfaces, now you can only inherit from the ones you need.

[WavePacket]

---

@BertMcMahan wrote:

Use multiple interfaces. Group common functionality into each one. For a very simple example: you may have a Multimeter device that could measure Voltage, Current, Capacitance, and Resistance. If your test only measures Current, then it doesn't make sense to have a Multimeter interface, but a Current Measurement interface.

By splitting the above measurements into four different interfaces, now you can only inherit from the ones you need.

---

Ok, this solution seems nice when the hardware under question is like a multimeter, and therefore its measurements are really the same in every test station. So using this example I'd have 1x multimeter device actor, many test station actors, and many interfaces:

• The multimeter device actor inherits from all the interfaces
• A test station actor only inherits the pertinent subset of the interfaces that correspond to measurements that they are doing. Multiple test stations seem capable of inheriting the same interfaces.

Mind if we also discuss a situation where the hardware interactions are rather test-station specific? This means that multiple test stations seem unlikely to be able to inherit the same interfaces.

As an example, one of my "hardware" actors is a database, and multiple other softwares actors have database needs which are rather specific (i.e., I need this data analyzed in this way, from the previous test). So each test station will have different database syntax.

So I'm kind of at a loss for how to separate the concerns between the multiple software actors and the single database actor in particular. Some options (maybe the nicest option is not even among this list...?):

1. The softwares' actors supply the database queries they need
   • (But as an example, this seems to be analogous to having Multimeter VISA commands being supplied individual test softwares, which isn't a good architecture).
2. The database actor has all the test station actor's queries stored internally like a list in its private data.
   • (But as an example, this seems to be analogous to having all Multimeter VISA commands used in test softwares stored internally to the Multimeter actor, which isn't a good architecture).
3. Multiple "test station" interfaces where single database actor will inherit from all of these interfaces and implement all the test station specific methods. New test stations will create another interface.
   • This still feels like I haven't properly separated the concerns. My database actor will be implementing test station specific code.
4. Database actor simply provides access to the data in the database, and all filtering or analyzing is done in the test softwares.
   • Now that I write this, maybe this is the best architecture I've listed...

Thanks for your time, I appreciate it. Fun to discuss software architecture!

[drjdpowell]

Why do you have a "database actor"?  Databases are a lot more sophisticated than some dumb hardware.  They support multiple clients with transactions and ACID compliance.  Why not use them directly?

[cbutcher]

---

@drjdpowell wrote:

Why do you have a "database actor"?  Databases are a lot more sophisticated than some dumb hardware.  They support multiple clients with transactions and ACID compliance.  Why not use them directly?

---

I have more or less the same question.

You can create (in my opinion) a database interface if you want and inherit from it/them, but I'm not certain if an Actor is appropriate.

Regardless of that, you should write the interface according to what you want the interface to be (sorry for the tautology). So figure out what your database thing (Actor, class, library, whatever) should do, and how you want to interact with it, and then you have to my mind two situations:

• Your test stations naturally fit this interface. Use it easily and pass whatever inputs are required (data source name, channels, time, I don't know)
• Your test stations do not fit this interface. Write an adapter/adapters to convert between the required inputs for the database interface and the required responses for the test stations to work nicely. Don't force the interfaces to fit together - if they look different, try write the both to fit their "natural" (by whatever measure you consider natural) interfaces and then add code between them to fit one to the other.

If you force the database to serve the/a test station, then it will fit that test station only. If you write the database to describe the interface you would ideally want to have with the database (and here, "interface" could be just use the VIPM packaged library provided by JDP) and then write some supporting connective code, at worst you're writing the connecting code each time (and this is only necessary if the connecting code is different, which would imply writing new code in any case anyway). 

[WavePacket]

---

@drjdpowell wrote:

Why do you have a "database actor"?  Databases are a lot more sophisticated than some dumb hardware.  They support multiple clients with transactions and ACID compliance.  Why not use them directly?

---

 I'm happy to discuss "why", though it feels a different discussion than "how can I architect it". The level of sophistication is probably why I'm having trouble architecting it.

"Why" is that there are a few times where I want the asynchronous behavior. For example, there is a software where I want to populate query results as they come. The user is likely interested in the latest results but could infrequently be interested in old data. So I want to present the newest results first, but asynchronously continue to fill in old results as they come back. The query is long enough that I don't want to make the user wait for all results to come back.

Another possibility is that as a test proceeds, I want to asynchronously be asking the database as we go along if the test results are normal (but allow the test to continue until the database responds with a warning). Kind of like an asynch background check of the results.

That's "why" but even if I get convinced that I shouldn't want it, I'd be interested in discussing the "how to architect it."

[WavePacket]

---

@cbutcher wrote:

---

@drjdpowell wrote:

Why do you have a "database actor"?  Databases are a lot more sophisticated than some dumb hardware.  They support multiple clients with transactions and ACID compliance.  Why not use them directly?

---

...

• Your test stations do not fit this interface. Write an adapter/adapters to convert between the required inputs for the database interface and the required responses for the test stations to work nicely. Don't force the interfaces to fit together - if they look different, try write the both to fit their "natural" (by whatever measure you consider natural) interfaces and then add code between them to fit one to the other.

...

---

I'm not exactly sure what you mean by adapters/adapters. Do you mean that the test stations have the burden of writing the code to supply the required inputs to the database interface?

[cbutcher]

---

@WavePacket wrote:

I'm not exactly sure what you mean by adapters/adapters. Do you mean that the test stations have the burden of writing the code to supply the required inputs to the database interface?

---

Hmm, I'd be willing to put it on either end (you could write the code separately from the test stations, but separately from the "database interface/system"), but essentially, yes.

For me, the database code should handle the database, not the test systems. If the interface you want for your database is convenient for the test systems (you might choose an interface that has "Store Result.vi", "Get Configuration Parameters.vi" taking a Test Station identifier, etc) then that's great. There's no inherent reason this shouldn't be the case.

However, if the database interface is more "generic", for want of a better term, then I don't think that's necessarily a problem either. I understand a desire not to make Test System Actors/libraries closely coupled to the database (i.e. containing SQL statements, table names, whatever), but if you don't want either one to match the other, write some separate code to bridge the gap.