• Not Answered

Cross Controller communication

I have a question about how data is communicated between controllers when blocks are wired together in an equipment module. Equipment module containing overall logic shown will be assigned to controller One. DEV1 will also be assigned to controller One. DEV2 will be assigned to controller Two. With the input parameters shown wired into the devices, is the information read or written between controllers. Does the logic as shown and assigned create asynchronous writes?

4 Replies

  • Yes, the wire for X_LVL_E... to "DEV2" will be an asynchronous write because it will be across controllers and it should only be "written" when the value is different (value has changed).

    It's been forever since I've tested this but it may cause some errors or bad status if the asynchronous write buffer is full and the value hasn't been written yet and the EM executes again with this configuration. Andre may remember....
  • In reply to Matt Stoner:

    What about the wire on the output of device 1 and 2 going to function blocks below. is this a write or does the wire read the value from device to write it into the function block below?
  • In reply to Daniel Moyers:

    I can't see where they are going but those would be reads to update the parameter/block it is being wired too.
  • In reply to Matt Stoner:

    I can't remember where I put my keys, but somehow I remember this stuff...

    Back in the day... I did some testing and found that DeltaV will did some under the hood magic on wired connections to private module blocks.  Basically, wired connections result in a read by the destination modules.  The CAS_IN  module parameter of the secondary loop in a cascade pair is created as a Floating Point with Status that is wired to the PID1/CAS_IN.  When embedded in the primary loop, this CAS_IN parameter is available for connection.  When wired to from the PID1/OUT, the download script will define the CAS_IN parameter of the secondary loop with the path to primary loop/PID1/OUT, creating an unsolicited read of the value.  

    I think this requires the secondary loop to be private to the host module.  Does not make sense to have multiple host modules wired to the same embedded block.  Exception based writes such as a change of mode or a SP from a sequence would be by exception, not continuous and not wired.  

    Now that is about 20 years since I tested that.  I doubt there would be any change, but I'm going to have to check for an Equipment module.  I'm assuming this diagram is in the Monitor section of the EM.  

    On the controller hosting the EM, you can also check diagnostics to see if there are AWSnt messages being sent.  This is the number written in the last second from this controller.

    If this is 0, it confirms you wired value is not generating Asynchronous writes to the embedded module.

    Andre Dicaire