All groups switch off on one group ramp to zero

Discussion in 'C-Bus Wired Hardware' started by Jannie, Sep 6, 2007.

  1. Jannie

    Jannie

    Joined:
    Aug 4, 2004
    Messages:
    69
    Likes Received:
    0
    Location:
    Cape Town, South Africa
    We've seen a situation on a at least 3 networks that we don't have a solution for.:confused:

    When a specific group (group number is not the same across the faulty networks) is ramped down to zero, ALL groups on the network switches off!

    This can be repeated, i.e. the same group will do this. It will turn off all groups as it reaches zero. You can turn groups on again via input units.

    Currently we just don't use the 'weird' group number (invariably it's the one controlling the hot water cylinders!) But it's not a healthy situation.

    Anyone seen this and have advise on this?
     
    Jannie, Sep 6, 2007
    #1
  2. Jannie

    znelbok

    Joined:
    Aug 3, 2004
    Messages:
    1,151
    Likes Received:
    17
    Can you confirm that on all your output units that this group is not the group assigned to "Area".

    Mick
     
    znelbok, Sep 7, 2007
    #2
  3. Jannie

    Jannie

    Joined:
    Aug 4, 2004
    Messages:
    69
    Likes Received:
    0
    Location:
    Cape Town, South Africa
    Also suspected that, but mostly the Area is set to unused. We did set the area to a unused group number just to make sure.

    But nowhere was the area the same number as the group number triggering the problem.
     
    Jannie, Sep 7, 2007
    #3
  4. Jannie

    NickD Moderator

    Joined:
    Nov 1, 2004
    Messages:
    1,420
    Likes Received:
    62
    Location:
    Adelaide
    Logic assignments in the output units could also do this, although it would seem unlikely that you could have accidentally configured this.

    Have you run the diagnostic software to see if there's any traffic on the bus that can give you any clues?

    Nick
     
    NickD, Sep 7, 2007
    #4
  5. Jannie

    Jannie

    Joined:
    Aug 4, 2004
    Messages:
    69
    Likes Received:
    0
    Location:
    Cape Town, South Africa
    Need to do that, just need a quiet slot when the customer is not around. Because it happens only at 3 (of many) sites and the group number is random, we've not been able to duplicate it on test network.

    I've wondered about a specific firmware rev on a specific unit not maybe causing the problem but have not found any commonalities yet (although it must be there)
     
    Jannie, Sep 7, 2007
    #5
  6. Jannie

    Duncan

    Joined:
    Jul 23, 2004
    Messages:
    925
    Likes Received:
    0
    Location:
    Salinas de Garci Mendoza, Bolivia
    I'll be very suprised if you find some hitherto unknown C-Bus defect that causes this.. given that you've got 3 of your own sites that its happening on its almost a dead certainty that you're programming is at fault. Logic, misused area addresses etc..
     
    Duncan, Sep 7, 2007
    #6
  7. Jannie

    Jannie

    Joined:
    Aug 4, 2004
    Messages:
    69
    Likes Received:
    0
    Location:
    Cape Town, South Africa
    Duncan, while I appreciate your comment, we're not new kids on the block when it comes to C-Bus. We've been doing this for many years and have done numerous, large projects with C-Bus. This problem has been around for quite a long time and it's only now that I bring it to the forum.

    One of the 3 sites I mentioned was actually done by another C-Bus installer. (also one of top 3 C-Bus installers in this province). We did the Crestron systems in that particular project and noticed the same problem there.

    We don't use any C-bus logic, BTW, all logic is done at a higher level.

    Can you expand on the 'misused area addresses' statement please? How can one end up 'misusing' an area address? What are the do nots with areas? We don't use the area function at all, so we normally set the address to unused. Is this wrong?
     
    Jannie, Sep 7, 2007
    #7
  8. Jannie

    Duncan

    Joined:
    Jul 23, 2004
    Messages:
    925
    Likes Received:
    0
    Location:
    Salinas de Garci Mendoza, Bolivia
    Perfect.. :)

    Run up the Diagnostic Software or the Application Log in C-Bus Toolkit.. I bet you nail the problem quickly.
     
    Duncan, Sep 7, 2007
    #8
  9. Jannie

    Jannie

    Joined:
    Aug 4, 2004
    Messages:
    69
    Likes Received:
    0
    Location:
    Cape Town, South Africa
    Maybe I did not give enough info on this problem. It seems that the terminals (on a relay for example) switch off at a hardware level, so I'm not sure if I'll see something on the bus.

    Let's say the offending group is group '1'.

    I ramp '1' down, via a keypad or any other input unit. As it reaches 0, all the relays will switch off, irrespective of their assigned group numbers. If I now query the groups assigned to the relays, I get a C-Bus response indicating the original levels, i.e. if the group was on it still indicates on. But the terminal is switched off.

    Jut as if someone had pushed the override button on the front of the relay, i.e. the terminal and group are now out of sync. Issuing a software off and on restores sync between the input and output units.

    So it seems a group command (ramp to zero) triggers a terminal response shutting the terminals on the relay down.

    Toggling the offending group between on and off does not produce this, only a ramp.

    It's like the units get swamped by the ramp command and then promptly switch its terminals off. The interresting fact is that it is just a specific group that will do this, but not the same group across the different, faulty networks.
     
    Jannie, Sep 7, 2007
    #9
  10. Jannie

    ashleigh Moderator

    Joined:
    Aug 4, 2004
    Messages:
    2,391
    Likes Received:
    24
    Location:
    Adelaide, South Australia
    More info please...

    Is your control pint to the offending network a PCI, CNI, bridge or something else?

    Is the network bridged (using 5500NB) to another network?

    Is there some non-clipsal device present in this network (and if so, what happens if you disconnect it)?

    Have you checked the logic assignment settings of the relay to make sure all logic channels are set to group UNUSED, and the area is set to UNUSED?

    Have you checked the turn-on thresholds for each channel of the relay? - generally unless doing something unusual these should be set to 1%

    Have you substituted a different relay unit for the one that is acting up, and see if the problem follows the unit or the network?

    Can you download the diagnostic software and run it during these operations, then look at the network traffic? You may find some other rogue unit transmitting off commands.
     
    ashleigh, Sep 8, 2007
    #10
  11. Jannie

    Jannie

    Joined:
    Aug 4, 2004
    Messages:
    69
    Likes Received:
    0
    Location:
    Cape Town, South Africa
    PCI in all cases

    In 1 installation there are two networks bridged, the other 2 are single networks.

    Nope, just Clipsal C-Bus2 units, relays, dimmers and Neo and Saturn keypads + some DLT's

    All set to factory default.

    All set to default.

    No, must still do this.

    Will do. I don't think an off command is transmitted though, as other units with the same group assigned won't go down to zero, the keypads will still show the groups as on, for example.

    If we read the group levels, they're still at their previous levels, so no legit C-Bus group commands were transmitted. The Crestron interface (via PCI) also shows no feedback received that the groups changed, only the one that was ramped to zero.

    It's more like the relays perform an internal shutdown, (just as if the override buttons on the front of the relays were switched off), when it sees the ramp to zero command.

    So basically, a legit ramp to zero command on a specific group will shut the relays down. Note only a ramp will do this. Setting the group off won't trigger it.
     
    Jannie, Sep 9, 2007
    #11
  12. Jannie

    ashleigh Moderator

    Joined:
    Aug 4, 2004
    Messages:
    2,391
    Likes Received:
    24
    Location:
    Adelaide, South Australia
    Can you disconnect the Crestron device as well and see if the behaviour is still there?

    (We have heard of dodgy Crestron drivers that cause odd things to happen, under some circumstances, so it is desirable to eliminate that possibility.)
     
    ashleigh, Sep 9, 2007
    #12
  13. Jannie

    Jannie

    Joined:
    Aug 4, 2004
    Messages:
    69
    Likes Received:
    0
    Location:
    Cape Town, South Africa
    I think you might be missing the point that if the problem was caused by a legit command on the bus, all units with one of the affected groups would have reacted to it. This is not the case. Only the output units switch off. Input units still have the last known level of the group.

    Can you elaborate on the 'dodgy Crestron driver' statement please? Which drivers are these? What commands can one issue via the PCI or C-Gate that will cause odd things?

    We've done many Crestron / C-Bus systems and have only seen this problem on 3 of the installations.
     
    Jannie, Sep 9, 2007
    #13
  14. Jannie

    ashleigh Moderator

    Joined:
    Aug 4, 2004
    Messages:
    2,391
    Likes Received:
    24
    Location:
    Adelaide, South Australia
    There are many Crestron driver implementations kicking around.

    To the best of my knowledge none of them have been certified as "C-Bus Enabled".

    Some are know to cause strange things, especially on bridged networks.

    For this reason I ask you to disconnect the Crestron system and see if the problem goes away.

    For your basic troubleshooting from this point on, you need to:

    1. Swap the relay unit and see if the problem follows the unit or the bus.

    2. Remove the Crestron system, temporarily, and see if the problem is still there.

    3. It would help a lot if you can post / attach your Toolkit project.
     
    ashleigh, Sep 10, 2007
    #14
  15. Jannie

    Jannie

    Joined:
    Aug 4, 2004
    Messages:
    69
    Likes Received:
    0
    Location:
    Cape Town, South Africa
    Will do.

    I'm quite concerned that if a manufacturer publishes an interface into their system (C-Bus, in this case) and you use this interface, it can cause 'strange things'. Does not sound like a solid integration point to me.

    Again, I'd like to ask; what commands can I issue over a PCI (using the published commands) that can cause 'strange things' to happen.

    Surely if you publish an interface, the interface can handle the commands you isue. Even if these commands are non-sensical, the interface should handle this and not do 'strange things' like switching off all the terminals on all output units when you issue a ramp command.

    I suspect this is a bug in either the PCI or the output units.
     
    Jannie, Sep 10, 2007
    #15
  16. Jannie

    Newman

    Joined:
    Aug 3, 2004
    Messages:
    2,203
    Likes Received:
    0
    Location:
    Adelaide, South Australia
    The one way to get to the bottom of where the problem lies is, as NickD suggested, to connect the C-Bus Diagnostic utility to a PC Interface connected to the network. Then, capture the C-Bus messages that are being issued when all the lights turn off unintentionally.

    A problem like this can be due to any number of variables so it's best to eliminate them one by one. 9 times out of 10 using the diagnostic utility shows up some other unit on the network generating messages due to the way it's been programmed, an oversight in logic or area address programming, some left-over code that's still running in a Logic Engine, a C-Touch spitting out a Scene, third party devices sending mal-formed commands, etc, etc.
     
    Newman, Sep 11, 2007
    #16
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.