Jump to content

peper

Members
  • Posts

    2
  • Joined

  • Last visited

LabVIEW Information

  • Version
    LabVIEW 2018
  • Since
    2009

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

peper's Achievements

Newbie

Newbie (1/14)

  • First Post Rare
  • Conversation Starter Rare
  • Week One Done
  • One Month Later
  • One Year In Rare

Recent Badges

0

Reputation

  1. Hey, Thanks for your reply. I do agree with you that choosing very specific names for the methods lower the risk of name "conflict". However, in a scenario where actor framework modules would be reused in different projects by different programmers, over a long period of time, it is difficult to enforce that. Moreover methods name will probably become quite long and LabVIEW doesn't like that. I think developers will be tempted to use much shorter and generic names for the methods, like in the example below: "Controller" inherits fom "ReaderMsgReceiver" and from "WriterMsgReceiver" both interfaces declaring a generic "UpdateState" method but with different connector panes. This method basically informs the "controller" of the state of the "writer" and "reader" modules. Note that the concrete "reader" and "writer" modules are not present in this example for the sake of clarity (not sure if it's clearer though:)). They will use the "send" method of the "UpdateState Msg.lvclass" and "HandleDataPacket Msg.lvclass". I have attached the code and indeed LV mentions a connector pane conflict, which makes sense. I don't really see an easy fix for that situation... suggestions are welcome Thanks Regards EDIT: re-reading your answer I am not sure I'm following you on this: "Also., from a design perspective, your Controller should NOT be implementing (inheriting) the updateStatus capability - that rests with the Writer." Could you elaborate? Besides I have also attache an example with the concrete reader and writer modules with some comments. ActorTestInterface.zip ActorTestInterface (with concrete actors).zip
  2. Hi all, I have this simple actor framework architecture where my root actor, called "controller", launches two different nested actors called respectively "reader" and "writer". Typically: "reader" acquires data from a DAQ "writer" writes the data to a TDMS file. "controller" sends the different commands to "reader" and "writer" (like start/stop acquisition or start/stop recording) and routes the data acquired by "reader" to "writer" "reader" and "writer" both send back their respective state to "controller" (like acquisition in progress, writing in progress,...) In order to decouple "reader" and "writer" from "controller", I mimiced the LV2020 shipping example (Actors and Interfaces) and created an interface for "writer' and "reader" (one interface per actor). I then made "controller" inherit from both interfaces. Then, in each interfaces, I created a method called "UpdateStatus" and created the messages that will be sent by "reader" and "writer" to "controller" The problem is that the "UpdateStatus" methods do not have the same connector panes in the two interfaces and hence LV tells me that I have an error. One obvious fix would be to have different names for the methods of the interface ("UpdateReaderStatus" and "UpdateWriterStatus" for instance) but it is not always possible. Am I missing something? Because it seems that AF modules programmed with the interface technique will be difficult to reuse if rmethods renaming is necessary. Thanks in advance for your comments! Regards,
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.