Toggle input on remote network with DLT

Discussion in 'C-Bus Toolkit and C-Gate Software' started by 5th Floor, Oct 2, 2017.

  1. 5th Floor

    5th Floor

    Joined:
    Oct 1, 2017
    Messages:
    6
    Likes Received:
    0
    Location:
    California
    Toggle group on remote network with DLT

    I work in a large building with C-Bus equipment and Powerlink G3 controllers. There are 5 networks in the project and a dedicated server to run Toolkit, SchedulePlus and LCS software. (We moved in here 4 years ago and our Clipsal / Schnieder / C-Bus support ghosted us about a year later. None of us has been formally trained in this.)

    I've been able to define a C-Bus group that energizes Powerlink breakers on three separate networks, but can only toggle it through the PC (Schedule Plus software).

    How can I get DLTs on different networks to toggle a C-Bus group on another network? They seem only able to control the Lighting application on whatever network they''re installed in. We have a NEO keypad that enables/disables DLTs on other networks through the Enable Control application, but I can't suss out how it does.

    For more info, our networks are A,B,C,D and E. The C-Bus group is in the Lighting application on A and is linked to an input on a Powerlink in that network. The DLTs are on the networks B and C where the breakers actually are. (I followed a legacy setup on that one!)
     
    Last edited by a moderator: Oct 2, 2017
    5th Floor, Oct 2, 2017
    #1
  2. 5th Floor

    NickD Moderator

    Joined:
    Nov 1, 2004
    Messages:
    1,420
    Likes Received:
    62
    Location:
    Adelaide
    Hi,

    As you have noticed, the DLTs (or any key input unit for that matter) can only send messages onto their local network. Higher level devices like touchscreens, logic controllers, or Schedule+ can send routed messages to any network.

    For messages from key units to reach other networks the only way is to set up the network bridges to forward them.

    There are two options in the bridge.. you can send messages to the adjacent network and/or to one other network. You can also filter which messages by application.. there are 2 application address filters. By default the primary application is set to $FF which means it passes everything. If you set the primary application to something other than $FF it will only pass that application (if you want it to pass a second one you have to set that as the secondary application).

    Before you go changing these settings in the bridge you need to understand how/why it's been set up as it has, as if group addresses/applications have been duplicated and used for different things on different networks, all hell will break loose :)

    The alternative is to put some logic in a PAC or S+ on the network that the DLTs are on to receive the message from the DLT and route an equivalent message to the network that it's needed on.

    Nick
     
    NickD, Oct 3, 2017
    #2
  3. 5th Floor

    5th Floor

    Joined:
    Oct 1, 2017
    Messages:
    6
    Likes Received:
    0
    Location:
    California
    Thanks for the reply, Nick!

    Is this forwarding a global setting for the network bridges, or does it need to be done specifically for the Keypad Unit?

    The one NEO keypad in Network B that enables/disables DLTs on Networks A, B, C & D would seem to prove that this is already set up. That keypad has a Primary Application of Lighting and a Secondary Application of Enable Control. (There's also a glitch where a DLT on Network E erroneously sets a scene on Network A, so I know a DLT can do what I need.)

    The Enable Group names and addresses for the controlled DLTs are consistent across all networks, is that part of the solution? Editing the NEO device I see other Enable Groups that don't synch up across all networks, the list looks native to Network B.

    I'm not entirely sure Enable Control or Trigger Control are the way to go since I'm trying to interface with Powerllink controllers that seem only to recognize Lighting Control groups.
     
    5th Floor, Oct 3, 2017
    #3
  4. 5th Floor

    5th Floor

    Joined:
    Oct 1, 2017
    Messages:
    6
    Likes Received:
    0
    Location:
    California
    Oh, look, there's a tutorial on Dual Applications on Input Units!

    http://www.cbusforums.com/forums/showthread.php?t=2221

    I have a feeling I'll be spending some more time on this forum.
    Here's an interesting statement from the C-Bus Networks tutorial

    Application Connect Mode: A mode of operation for a C-Bus Bridge where the selected C-Bus Application(s) on either side of a Bridge are effectively connected
    together.
    Messages on the selected C-Bus Application(s) are routed across the Bridge automatically to the other side.

    That would certainly make all hell break loose if your group addresses weren't assigned with this in mind.
     
    Last edited by a moderator: Oct 3, 2017
    5th Floor, Oct 3, 2017
    #4
  5. 5th Floor

    NickD Moderator

    Joined:
    Nov 1, 2004
    Messages:
    1,420
    Likes Received:
    62
    Location:
    Adelaide
    It's global in the sense that it's a filter on the application address, so all messages on that application will be forwarded.

    It's also important to remember that the bridges are made up of 2 half bridges, so if you want to connect groups both ways you need to set up both sides of the bridge.

    Nick
     
    NickD, Oct 4, 2017
    #5
  6. 5th Floor

    znelbok

    Joined:
    Aug 3, 2004
    Messages:
    1,151
    Likes Received:
    17
    And the downside to this is that if you have used say group 56 on both networks for totally different reasons, turning group 56 on on the local network will also turn on group 56 on the far network - even though that's not what you want - you only want one particular group to turn on.

    I got caught with this - I split my network in two with 0-128 on one and 129-256 on the other. Bridge was forwarding in both direction. Totally forgot that 128-129 boundary and put a volume control for an amp at 130 and lights on the remote network did all sorts of strange things when I was tuning the volume up and down.

    Dual applications may solve the problem - I don't have any real experience with them, but you somehow have to get the secondary app to somehow trigger the group on the lighting app on the remote network.
     
    znelbok, Oct 4, 2017
    #6
  7. 5th Floor

    NickD Moderator

    Joined:
    Nov 1, 2004
    Messages:
    1,420
    Likes Received:
    62
    Location:
    Adelaide
    You said that S+ can already control the output that the DLT can't...

    Can the S+ PC already see the messages from that DLT? (You should be able to see in the log).

    If so then your bridges are already set up to forward messages, so you should be able to write some simple code in the logic engine to map the group in the DLT to the group in the output. From memory the Trackgroup2 function in the logic engine is meant for this.

    Nick
     
    NickD, Oct 5, 2017
    #7
  8. 5th Floor

    5th Floor

    Joined:
    Oct 1, 2017
    Messages:
    6
    Likes Received:
    0
    Location:
    California
    Yes, I'm able to see activity on that DLT through the Schedule Plus View Log. The S+ PC is also running C-Bus, C-Gate and Schneider's LCS, which is mostly how I interact with the system.

    Nick your replies have been very helpful. I'm a bit cautious about diving into the network bridges. (I'm a machinist, not a programmer, unless you count G-code.) Our company has some time booked with a Product Engineer at Schneider N. America so hopefully he can shed light on how the bridges are configured.

    Our network is a star topology, as far as I can tell, so every network should be adjacent to every other? I know that the Trigger Control and Enable Control Applications can pass messages between networks, I'm hoping the Lighting Application is setup so.

    I was able to find the source of a glitch in our setup, where a DLT in the E-network was setting a scene in the A-network. The DLT was setup to use Trigger Group 000 (the only on on that network) to set Action Selector 002. Unfortunately, over on A-network, Trigger Group 000 Action Selector 002 was used to set a scene in that part of the building. I'll ask our helpful Schneider guy if we should re-address one or the other, or just filter the Network Bridge to stop passing Trigger Control commands out of E-network.

    (That glitch went on for years before I discovered the View Log feature of Schedule Plus, and was at least able to correlate the events in E and A networks!)

    Back to my original endeavor. The S+ virtual button toggles a C-Bus group in the A-network, Lighting Application. Through the LCS software, I've set up this group to toggle an Input on a Powerlink G3, which then publishes the state of that input to subscribing G3 panels in the building.

    (And then any Powerlink Zone subscribed to that Input via Remote Source toggles, and any breakers that are a member of that Zone turn on and off! Simple! If you view our network in C-Bus, there are almost zero output units. Maybe 5 dimmers on the E-network.)

    I'm thinking, hoping, that if I set up a DLT button in any network to ON/OFF the Lighting Group address that corresponds to the one setup in the A-network, and the Network Bridges are configured to pass that command to all networks (or at least, the A-network) then the whole chain of command should respond as it does with the Schedule + command. (I've checked that that address is not used in other networks.)

    Confounding my operations is the fact that our building is active 6 or 7 days a week, so I can only really mess around on 3 Mondays a month. (Today is not one.)
     
    5th Floor, Oct 9, 2017
    #8
  9. 5th Floor

    NickD Moderator

    Joined:
    Nov 1, 2004
    Messages:
    1,420
    Likes Received:
    62
    Location:
    Adelaide
    I agree... I wouldn't mess with the bridges without understanding exactly why they are set up like they are already.

    Hopefully your =S= person can sort you out.

    Nick
     
    NickD, Oct 10, 2017
    #9
  10. 5th Floor

    5th Floor

    Joined:
    Oct 1, 2017
    Messages:
    6
    Likes Received:
    0
    Location:
    California
    Just as an update to this adventure, in case future generations have the same situation...

    Our 5 networks don't use network bridges, but instead evidently have some creative logic programmed into them to pass certain commands. I'm able to generate Logic Reports from Schedule Plus and PICED, but have zero Pascal knowledge so I'm going to embark on a Pascal primer tour of the internet. Any suggestions for PICED level Pascal training would be great! I was a quick study with BASIC in the '80s, and Visual Basic 6 in the 2000s, I'm hoping I still get it.

    Trackgroup2, huh? I'll check it out. I'm starting with the PICED Help file
     
    Last edited: Feb 18, 2018
    5th Floor, Feb 18, 2018
    #10
  11. 5th Floor

    5th Floor

    Joined:
    Oct 1, 2017
    Messages:
    6
    Likes Received:
    0
    Location:
    California
    RESOLVED: -ish

    Just to put the cap on this thread, I was able to solve 95% of our difficulties with the help of Schneider North American Customer Care, NickD's comments, and some sleuthing.

    Assigning a button on a DLT located in the A network's physical area of the building to toggle On/Off the group that the virtual button on Schedule Plus toggled had the desired result, circuits up and down the building, in all networks and areas energized and de-energized with the button state. This is done through the Remote Source function of our Powerlink G3 controllers. There's an Input on a panel in the A network that tracks with the A-network, Lighting Control, C-Bus Group ###, and the Zones on panels in other parts of the building subscribe to that Input as a Remote Source. That's the Powerlink method.

    To get this functionality through C-Bus I created two scenes, "Group Power ON" and "Group Power OFF", whose scene components were the 5 C-Bus groups in the Lighting Control Application in each network (A-net/Lighting/Group###; B-Net/Lighting/Group###; ...) This required two button assignments (one for all ON, one for all OFF because scenes are modal) on one DLT in the B-net.

    Regarding our network structure...

    They are 5 segmented networks with no network bridges. Each has a PAC on it but they're empty. To pass information from one to the other, as NickD theorized above, the Trackgroup2 function is used in the Logic Engine of Schedule Plus. The glitch that I mentioned was due to an addressing issue much like znelbok had. Our E-net area was a last minute add-on, and in the rush to program it the Trigger Control group address in E-net matched the one in A-net, as did some of the Action Selector addresses. (I'm a little fuzzy about that, because the arguments in the TrackGroup2 function reference the Enable Control application, not Trigger Control as is used on the DLT buttons. But it's fixed now.)

    Why only 95%?

    The DLT button and Schedule Plus virtual button toggle-a-group setup that operates through the A-net should be able to be set up in any network, as long as I can track an input (on a G3) to a group (C-Bus) and publish that input's state to the relevant G3 Contolers. I tried this in the C-net, but can't get the input to track with the group. That, though, is probably a Powerlink setup glitch and not a C-bus thing. I use Schneider LCS Advanced software to program my 46 G3s and as far as I can see my Clipsal Setup pages are set the same way in the A-net (where it works) and the C-net (where it don't.) 'Nother thread.
     
    5th Floor, May 31, 2018
    #11
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.