DLT TAGS not updating

Guys,

Has anyone else experienced the DLT tags for a secondary network not saving / updating to the DLT. I am using Toolkit 1.4.0 and DLTs with 2.1.00 firmware but for some reason the tags will not update. When I select P for primary in tool kit the tags download.

Any advise / comments ?

Regards

 

DLT's

Hello Jes,

We have found the same thing - not sure on firmware version though.
In the past we have done the labels the same way you would label up a Scene button. Not the best but it works....

Mark

 

Secondary Application

Hi Guys,

A few things to check first:
Make sure you have the Secondary Application assigned (ie. not Unused)
Make sure you are downloading the labels under the appropriate Application node in the Labelling treeview.
Be careful to get the correct group if your key is assigned to multiple blocks.
Check your Label Variants match up with the labels you are sending.

If none of these options help, could you please provide some more info?
A screenshot of the unit's Blocks tab would be the best place to start.

Cheers,
Mark.

 

Hi Mark,

Thanks for your reply, but I am stil not having any luck. Just as a bit of extra information before I tried to download the secondary application text I did use toolkit's refresh feature to remove all the tags and start again. I am not sure if this has anything to do with it. I have attached a copy of the unit gui and the DLT tag gui for your review.

Regards

 

Trade secrets ??

Ahhh... special.
Do tell, Ashleigh.

Mark

 

Trigger control application ($CA) is reserved for triggering of events such as scenes in C-Bus. For a given scene to become active, a command is sent in the Trigger Control application with a Trigger Group and an Action Selector. In addition to this, the DLT can accept labelling commands on the Trigger Control application so that buttons used to initiate scenes in the unit (and remotely) can be assigned a label on the basis if Trigger group and Action selector.

The label command is a special type of Trigger Control command which only affects products that can display labels, such as the DLT. When a DLT receives a label command on the Trigger control application, it will look for a match of the Trigger Group and Action selector before it applies the label to the unit button(s). Note that Trigger Groups are NOT the same as normal lighting groups.

Irrespective of what the Secondary Application is set to be in a DLT unit, any command received on the Trigger Control application WILL BE TREATED AS A TRIGGER CONTROL COMMAND exclusively.

As Ashleigh says, it is generally frowned upon to set up a secondary application as the Trigger Control application, and it is allowed only to increase the flexibility of the DLT for cases where normal scene control will not achieve a design goal. If a secondary application is set up as the Trigger Control application, any Label commands (and Scene Triggers for that matter) will be treated by the DLT as if they were in fact Scene Labels and Scene triggers, and will apply labels and triggers only to buttons set up to initiate scenes with matching Trigger groups and Action Selector values.

If you are using the Secondary Application to initiate Triggers from Normal key commands (as opposed to setting them up as Scene keys), then the only way you can assign a label is to change the secondary application (temporarily), apply the label, then revert the secondary application to $CA.

DON

 

Thanks for taking the time to explain Don, unfortunately I am still a little confused with the whole concept. The reason I selected the trigger application was because I am using a scene (stored in a B&W Touch screen) to turn on a group of lights and using the same button to activate another scene to turn off the lights as recommended by Tech Support.

Can you advise of either a better way to be able to control a group of lights using 1 button or a way I can change the label on the DLT? I don't feel what I am trying to do is a unique thing, and maybe a way of entering free form text to over-ride label controls should be considered ?

Why can't we just enter the labels 1 to 8 manually??? Surely that can't me more complicated than what we already have

Regards

 

The problem it seems, is that a "scene toggle" with a single key is not a native function in a DLT unit. Scenes are intended to have a dedicated key for each scene selected (allowing up to 8 scenes for the 8 keys over the pages of a DLT).

Scenes can be stored in any unit, and if not in the DLT, the scene can be left 'blank' in the DLT, and as long as the Trigger Group and Action selector are set to match a scene in another unit, the scene will still happen.

Scenes entirely within a DLT can be "modified", by using a key set up for the purpose (again, not the same key used to select the scene), and a "scene toggle" function can then be achieved, but it requires a minimum of two buttons. Note that despite the behaviour of earlier versions of Toolkit, the DLT allows up to 40 Group-level pairs to be set up in total, and these can all be in a single scene if desired.

In all of the above scenarios, labels can be applied to scene keys and scene modifier keys very easily.

To achieve a one-key "scene toggle", you are going against the intended operation of the unit. No fear though, because it can be done. You just have this little issue of the labels to resolve, and you really have to change the application address in order to achieve this with Toolkit at the moment.

Don

 

Secondary Application

I would like to add a few comments to this.. Firstly, I agree with Jes' comments.
I would further add that to my understanding, the use of a secondary application with the new firmware product was founded strongly by the dilemma of triggering scenes from the lighting application, especially when these scenes are stored on a touch screen.
Now that it is possible to use the Trigger Application as a secondary application and thus trigger scenes properly from one key unit, surely this cannot be bad practice?
I would have expected that there should be no issue with this, and that all key units should carry firmware which allows the full utilisation of all of their functions without any hitches.

 

Can you please expand on this.

I am doing a job with DLTS at the moment and I was going to do it the "BAD" way and want to do the "Correct way"

Charles

 

It sounds very complicated when things doesn't work
So, to get around it would be my first priority. The simple solution is not using a trigger application in the scene triggering. Since your scene is in the C-Touch, you can have "lighting" as trigger application instead. Then all application is primary and all should have work.

 

Good and Bad practice

It seems I am not the only one confused. I think perhaps there is also an issue between what is perceived to be good engineering practice versus what is perceived to be a practical (system) set-up.
Before the dual application key units it was considered 'hacking' to trigger scenes from the lighting application. Now that one could possibly assign the Trigger Application as a secondary to a key unit, this is bad practice.
Shouldn't it be considered that there seems to be a real need to trigger large scenes stored on other units from any key unit?
I seem to be getting the point of triggering scenes by creating an empty (effectively duplicate) scene in a key unit. However, either which way, I would like to enter my own text for whichever function.
Also, and especially through the release of the distributed audio equipment, buttons could quickly become scarce on a DLT (or any other key unit) Consequently it would make very good sense to toggle scenes on and off, instead of using one button for each. Add scene editing, and the function of 'switching on' a scene, switching it off, and suddenly three buttons are gone for effectively one setting.
Scene editing is provided for via the Touch Screen, and if I could make a suggestion I would rather scrap that function from the key units in order to free up functionality, for instance for a more flexible labelling function. In my opinion, scene editing via a key unit can only be useful for very small installations where no Touch Screens are provided. And such like installations are not very plentiful, at least here. I appreciate that in terms of engineering, one might want to cram a MIllion functions into the tiniest package (sounds like those mobile phones) but in the end it has to be something useful, not just something that is possible.
In summary, I still don't see the 'bad' in utilising the trigger application for what it is, namely to trigger scenes. If this is something which causes confusion, then this confusion should be cleared up. With the information provided thus far, I would rather see a change to the core functionality, but I am sure that I have not got the whole picture, and I am also sure that functionality provided is a result of some form of market research.

 

Guys,

Can anyone explain why we just can't label the 8 DLT buttons in the unit GUI without all the smarts ? I recon it will be a lot quicker and flexible for all of us creative types.

Regards

 

Ashleigh
First nag, this is the scenario from the other site of the fence,

• All my scenes are in C-touch(s)
• Piced wants scenes triggered from the Trigger Application and complains if you use the Lighting Application
• Need to trigger the scenes in C-touch from a number of different switch’s
• Need to keep the Toolkit pure and clean by having trigger requirements in the Trigger Application.

Are you now saying that because of Toolkit requirements we have to Trigger scenes in C-Touch with the Lighting Application in switches ??


dave

 

Hi, I think, in a proper way, he is saying the opposite:

For best organisation, you have done all the right thing, store the scene in C-Touch, using "Trigger" applications and let all the switches triggering it with Trigger address and action selectors.

On the Switch itself, just don't use "secondary application" for triggering. according to the discussion above, you have to use the simple "scene" function in the switch, assign it with the same trigger address and selector as in the c-touch. that scene needs nothing in its content on the switch side.

That's the proper way.

But this cannot do what you want: toggle on and off a scene with one key!

In a proper scene concept, it is a scene key, not a toggle key. Imagine, you have three scene keys on a group of lighting, you press scene 1 key , then scene 2 key then scene 2 key again, the lighting goes to scene 1 then 2 then off. Now you press scene key 3, the lighting goes to scene3. All fine. But next you press scene 1 key, the lighting goes to off rather than scene 1 because you just toggle off scene 1, not calling it up! Now the whole scene concept becomes a mess.

anyway, if you just have one scene key for one group of light and still want a scene on/off key, it can be done, just not in a proper way.

To do it, you need a trick, one of which is using "lighting" application for triggering a scene in C-Touch. The warning from C-Touch only reminds you that don't use that group address for other things, as it may mess up the whole design. There are a lot people changing programe "on the go" and sometimes they forgot an address was used in PICED when it shows nothing in Toolkit! Otherwise there is nothing wrong using an "lighting" application for triggering. Of course it means the other programmer following up the site after many years may fall into the trap

 

Misunderstanding

Secondary Applications were not introduced to trigger scenes, as the ability to issue Scene Triggers on the Control Trigger Application has always been available in all C-Bus units capable of supporting to scenes except the old 5034Nx "2000 series" units.

Secondary application support was added to support other applications such as irrigation or heating, etc., which otherwise would require a dedicated unit.

There has been a perception that Secondary Application support was required when people tried to use older style key units which did not support Scenes to trigger scenes stored in other units. In order to address this issue, all older style products are being updated at some stage TO SUPPORT SCENES.



Don