Actor framework - LIN communication

[milan87]

Hello All,

i will need some guidelines here... Perhaps you can give some advice.

In my actor project, i have one actor 'Device'. It is used for LIN communication. Actor receives list of frames and then it sends to the bus via hardware.

But i have two different producer of hardware, with slightly different initialization and send frames.

Now in theory i know that should be two child classes and my actor 'Device', should call one or the another.

But not sure how to implement this.

Should my device have for example case 'init' which will sent down to child actor, which will initialize his own 'init'..?

Or what is good practice, because potentially there will be more devices.

Additional question if someone knows:

If two device has same usb chip (FTDI), and one device is used for LIN, other for CAN, is there a way that my application distinguish these two device.

Thanks

[_T_M_]

Hello,

Have you looked at Hardware Abstraction? What I understand from your description is that there needs to be another class between your Parent and Child classes. It will be an abstract class which will inherit from parent and all your FTDI hardware child classes will inherit from FTDI abstract. You can implement an identifier method in your abstract which based on an identifier choose between correct implementation of the child class. Implementing that child class with dynamic dispatch will select the correct implementation of the child class.

[Jay14159265]

---

@milan87 wrote:

Hello All,

i will need some guidelines here... Perhaps you can give some advice.

In my actor project, i have one actor 'Device'. It is used for LIN communication. Actor receives list of frames and then it sends to the bus via hardware.

But i have two different producer of hardware, with slightly different initialization and send frames.

Now in theory i know that should be two child classes and my actor 'Device', should call one or the another.

But not sure how to implement this.

Should my device have for example case 'init' which will sent down to child actor, which will initialize his own 'init'..?

Or what is good practice, because potentially there will be more devices.

Additional question if someone knows:

If two device has same usb chip (FTDI), and one device is used for LIN, other for CAN, is there a way that my application distinguish these two device.

Thanks

---

For a robust communication to your instruments you should think composition over inheritance. You should have an instrument class object and a communications class object. Your Instrument object should be composed of a communication object. 

You should use the factory design pattern to 'build' instances of the correct instrument class as they are detected on the bus. 

Make factory object that observes USB connections, once a USB connection is found try to communicate with the instrument and based on successful communication, build the correct instance of the instrument. 

[_T_M_]

That really depends on implementation and project complexity.

Inheritance or composition both are good for Object oriented approach. I personally don't like to create too many inter dependencies between classes. For composition one class has to become part of another class' private data. That creates strict dependency when using the class object for another project.

Its better to create relationship on project by project bases other than that all classes should be independent of each other. It saves a lot of hassle later on in large applications.

In Milan's case where there are minor differences between methods its an easier and far less rabbit hole approach to create independent abstract and its child instrument classes. Create FTDI actor which implements abstract class. In abstract's identify method implement concrete instance of abstract class(LIN,CAN etc)

In the same actor method an interface can be implemented to take communication to the parent actor if instrument comms are established.

Hope this helps

[Jay14159265]

---

@_T_M_ wrote:

That really depends on implementation and project complexity.

Based on this comment I'm interested to know your threshold for a 'complex project'. S**t software usually starts by assuming some quick project will only be used for one simple use case then gets extended and crappified into some huge abomination. A good design paradigm in the beginning goes a long way. 

Its better to create relationship on project by project bases other than that all classes should be independent of each other. It saves a lot of hassle later on in large applications.

When you say 'project' are you talking about LabVIEW projects or LabVIEW libraries? So you are advising to design in dependencies across projects but not dependencies within a project? Sounds dubious : ) 

[_T_M_]

I am talking about the overall project not Labview project file. All implementations should be stand alone and well thought out for their use case. By that all I mean is try to reduce unnecessary dependencies where possible. “As an example” If there is an actor for spectrum analyser and an actor for a VNA they can both share a communication class but they both don’t have to be dependent on each other. I don’t want to work on spectrum actor independently just for it to start loading unnecessary dependencies.

I agree with you that a good project is well thought out from beginning. If it wasn’t  for that we wouldn’t be having this discussion. Don’t even know if it’s the beginning of this project 🙂

I don’t have any information of how the project in question is laid out. There are many ways to accomplish this task. 

In terms of an approach, inheritance hierarchy is good enough for hardware abstraction and it works well.

Just trying to help. You have a good day.