Stopping a Ramp command in progress?

Yes, and that's exactly how C-Bus units do it. There is actually a "Terminate Ramp" command defined, but hardly anything uses it, and I don't think it's available via the logic engine.

Yep. Any subsequent on/off/ramp command will cancel any timer or pulse that's running.

Nick

 

If you are using a Comfort system, you are restrained by what it is capable of exposing.

Normal cbus units work in 2 ways:

1. The mainstream. The unit that INITIATES A RAMP runs its own internal ramping engine (in parallel with the ramp that runs in the dimmer.... they start at the same time and run independently - there is NOT a stream of bus messages during the ramp). When the ramp is to stop (for example by taking your finger off the button) then the unit that INITIATED the ramp issues a NEW COMMAND: Go to THIS level RIGHT NOW. And that terminates the ramp in the dimmer and sets the absolute level. This approach means that the unit that initiated the ramp is the Big Daddy Who Is In Charge.

2. The not so common. You can issue a command to start ramping... and then issue a TERMINATE_RAMP command later. The dimmer will terminate at wherever it is (and other units on the bus won't know the exact same absolute level - but they will be close enough for all practical purposes).

If the device you are using to control things on the bus supports either method then you can start a ramp and then terminate or override it at any time - either from that device or somewhere else. COMPLIANT devices will honour all this behaviour.

 

I can't comment on what the Comfort system can do because I don't know it.

But, as a general principle - if the bus control system supports a command set to make things happen - there is no obligation on the manufacturer to support the full command set. Only to support enough commands for the product to do whatever it's useful function is.

So, for example, C-Bus lighting supports a TERMINATE_RAMP command. But cbus key input units manufactured before about 2001 don't support that command. That's OK because they don't issue that command anyhow. And if those older units receive that command they just ignore it.

Likewise, if you have a security system, it may or may not support the command "GET ZONE NAMES". If it does, it will return the name of a zone. If it does not, it just ignores the command.

All this stuff with optional commands, and support for backward compatibility does make things interesting (in the sense of the old curse: "may you live in interesting times").

There is a second aspect to all this. Some devices, and I think Comfort is one of them, support various macro / scripting / logic / programming languages or facilities. So the second piece of the puzzle is if, or how, those capabilities expose a particular bus command. You will see, again for example, in a lot of clipsal product that there is logic, and there are commands to set groups on, off, ramping and so on.

Generally those logic programming commands do not just bang out a bus message. They instead go through an internal object model of what's going on - and only bang out a command if the logic command will cause a change to the view-of-the-truth-as-known-in-bus-land. This helps conserve bus bandwidth. Of course, not every product does this - its at the manufacturers discretion. But its a good practice. This level of indirection also has an impact on what logic / programming operation causes what effect on the bus. Often its clear - but not always!