Bridging applications and control via PCI using Local SAL

Discussion in 'C-Bus Serial Protocols' started by KevinH, Jul 12, 2006.

  1. KevinH

    KevinH

    Joined:
    Aug 3, 2004
    Messages:
    171
    Likes Received:
    0
    Location:
    Yorkshire. UK
    I have a wireless network with application bridging on the lighting app. All works well. On the wireless side I have an output channel set to group 23. On the wired side if I have group 23 setup in a dimmer channel then I can issue a serial PCI command to group 23 on the local wired network and the wired and wireless group 23 change. If however group 23 is only present in a key input unit on the wired (I remove the group 23 in the dimmer and put it back to a key input) then the PCI command doesn't control the wireless output channel, however the key input on the wired DLT does though.

    The Local SAL option is set on the PCI (bit 1 param 42) and I understood from the PCI docs then that the PCI should appear identical to the DLT key input..... what am I missing here ?

    Kevin

    The PCI options I have set are CONNECT+SRCHK+SMART+MONITOR+IDMON and PCN+LOCAL_SAL+PUN+EXSTAT and the checksum is correct on the latter group
     
    Last edited by a moderator: Jul 12, 2006
    KevinH, Jul 12, 2006
    #1
  2. KevinH

    ashleigh Moderator

    Joined:
    Aug 4, 2004
    Messages:
    2,393
    Likes Received:
    25
    Location:
    Adelaide, South Australia
    What firmware version is your PCI?
     
    ashleigh, Jul 12, 2006
    #2
  3. KevinH

    KevinH

    Joined:
    Aug 3, 2004
    Messages:
    171
    Likes Received:
    0
    Location:
    Yorkshire. UK
    Actually it's a SIM module v 4.2.00

    K
     
    KevinH, Jul 12, 2006
    #3
  4. KevinH

    ashleigh Moderator

    Joined:
    Aug 4, 2004
    Messages:
    2,393
    Likes Received:
    25
    Location:
    Adelaide, South Australia
    PCI or SIm, version 4.2, should be just fine.

    In the document "Cbus Interface Requirements", check the section on initialising the interface - carefully - and make sure you have set the appropriate modes.

    The PCI or SIM will generate messages that pass through A SINGLE bridge that is linking two networks, provided the PCI/SIM is in LOCAL_SAL mode.

    If you want two networks to be joined, make sure you have it symmetric by setting each side of the bridge (or gateway) appropropriately (usually the same).
     
    ashleigh, Jul 13, 2006
    #4
  5. KevinH

    KevinH

    Joined:
    Aug 3, 2004
    Messages:
    171
    Likes Received:
    0
    Location:
    Yorkshire. UK
    Hi Ashleigh - The bridge is I'm fairly sure set up correctly and certainly pressing a key input on either side changes the corresponding group on the other. I have also checked the SIM interface options 3 settings for the SIM by using C-Bus diagnostics via another PCI and interrogating the other SIM and that shows that Local_SAL is enabled and the other settings are as above.

    What is strange is that if I create the group in a dimmer channel it works, its only when the groups is only present in a key input (or not present at all) that it fails. I'm just exploring Diagnostics to see what I can get at in terms of C-Bus messages that might help here.

    Kevin

    <edit> ... Ah hang on a sec..I think I've worked out what's wrong here (my oversight) - I think that when a group is only present in the key unit then MMI info shows the group as non existant and hence my own copy of the state table is blocking the command going out, occasionally after the group changes state I have inconsistent state table info caused by monitoring group changes that allows me local control but the next MMI wipes it out again. If I use a dimmer for the group it would of course work as MMI's match.
     
    Last edited by a moderator: Jul 13, 2006
    KevinH, Jul 13, 2006
    #5
  6. KevinH

    Richo

    Joined:
    Jul 26, 2004
    Messages:
    1,257
    Likes Received:
    0
    Location:
    Adelaide
    Yes, that seems like the likely cause.
     
    Richo, Jul 14, 2006
    #6
  7. KevinH

    ashleigh Moderator

    Joined:
    Aug 4, 2004
    Messages:
    2,393
    Likes Received:
    25
    Location:
    Adelaide, South Australia
    Ah yes, indeed.

    WRT MMI's:

    You can use MMIs as a means detecting current group states, and for detecting errors (two output units report a different state), and discrepancies (outputs disgree with inputs).

    Using MMIs to determine EXACTLY which groups are present in a network is prone to error, because it only reports groups present in output units. If you have other groups being used for magical purposes, the MMI is not your friend, because it does nothing for you.
     
    ashleigh, Jul 14, 2006
    #7
  8. KevinH

    KevinH

    Joined:
    Aug 3, 2004
    Messages:
    171
    Likes Received:
    0
    Location:
    Yorkshire. UK
    Thanks guys - and I believe I'm almost there now. I assume there was some reason that keyinputs don't contribute to MMI info , perhaps a capability/resource one.

    On a related issue AIUI it is not possible for an externally connected 3rd party device (eg via a PCI) to participate in updating that MMI info either - perhaps to artificially maintain a group. This being a PCI restriction/feature. Is there an available 'low cost' Clipsal product that offers group maintenance of say 16 groups within the MMI that could soley be used for that purpose ? Perhaps like a dimmer with no dimmer electronics - just the C-Bus stuff, I am also assuming no software product could do this eg C-Gate ? If not maybe such a device would be useful , and could be engineered fairly readily from a dimmer or similar with the mains voltage parts removed......

    Kevin
     
    KevinH, Jul 14, 2006
    #8
  9. KevinH

    ashleigh Moderator

    Joined:
    Aug 4, 2004
    Messages:
    2,393
    Likes Received:
    25
    Location:
    Adelaide, South Australia
    If you read the sections in the lighting application documentation about MMI Mastering, Discrepancies and error detection / correction it becomes apparent that key units must initiate MMIs (so they can do the checking), and output units populate MMI's (to let the initiating units know what is going on).

    Therefore, you cannot sensibly have an input unit which contributes to an MMI.

    See above. There are no plans to produce such a device, and to do so in a PCI is far from trivial. There are also m ore fundamental issues to resolve, for such a device.

    For example: a PCI is primarily a protocol translation device - it has no inherent knowledge (of itself) of the groups that are of interest to the serial-connected thingy.

    So, which groups should the PCI maintain? If any? And how does the serial-connected device tell it which ones to play about with? And in the event of an update, which device (the PCI or the serial-connected one) is the master in charge of updating / maintaining the state of the group?

    These issues put it firmly in the very-hard basket. The only time that it is essential to contribute to an MMI is for a new output device. In that case, CIS offer the "GOC" - under separate license agreement, and at CIS discretion.
     
    ashleigh, Jul 14, 2006
    #9
  10. KevinH

    Don

    Joined:
    Aug 4, 2004
    Messages:
    429
    Likes Received:
    0
    Location:
    Townsville, Australia
    Kevin

    If you have any output device on the network, it might be useful to take advantage of the fact that all the groups available for 'logic' will provide a contribution to the MMI, even if the group is not associated to affect the state of an output terminal. You could use these groups to achieve your MMI contribution for your group 23.

    Don
     
    Don, Jul 17, 2006
    #10
Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.