PAC Timer accuracy

Hello
I am connecting a curtain controller using a single relay. The controller needs 1 second (+-0.2sec) to drive to opened and 2 seconds (+-0.2sec) to drive to closed. I am using the PAC to turn the relay on for the required time. My problem is that it does not work every time - more like 3 from 10. The GA "CurtainOpenerSignal" is triggered from a bell press button. We only need fully opened or closed.

I originally used the code below........
once (GetLightingState("CurtainOpenerSignal") = ON) then
begin
if (CurtainLastOpened = false) then
begin
PulseCBusLevel("Local Network", "Lighting", "CURT.OP - Rumpus curtain motor", 100%, 0, "0:00:01", 0%);
CurtainOpened := true
end;
if (CurtainLastOpened = true) then
begin
PulseCBusLevel("Local Network", "Lighting", "CURT.OP - Rumpus curtain motor", 100%, 0, "0:00:02", 0%);
CurtainOpened := false
end;
CurtainLastOpened := CurtainOpened;
end;

I thought maybe it was the way I used the timing and tried this.......
once (GetLightingState("CurtainOpenerSignal") = ON) then
begin
if (CurtainLastOpened = false) then
begin
SetLightingState("CURT.OP - Rumpus curtain motor", ON);
Delay("0:00:01");
SetLightingState("CURT.OP - Rumpus curtain motor", OFF);
CurtainOpened := true
end;
if (CurtainLastOpened = true) then
begin
SetLightingState("CURT.OP - Rumpus curtain motor", ON);
Delay("0:00:02");
SetLightingState("CURT.OP - Rumpus curtain motor", OFF);
CurtainOpened := false
end;
CurtainLastOpened := CurtainOpened;
end;

Is this too tight a spec to get from the timer function?
Also I thought maybe relay bounce??
If no ideas I can put an oscilliscope on the relay & check what is happening.

Any help appreciated, regards Jim.

 

I thaught this was going to be a problem... See

http://www.cbusforums.com/forums/showthread.php?t=3032&page=2

Works fine on a minder pulse (1) and pulse (2)

I pointed out to the manufacture that their timing was too strick for it to work reliabily for raw cbus

The manufacture contacted me the other day and told me they have changed the code. the new timing specs are...

Open is 0.6 sec -> 1.7 sec
Close is 1.7 sec -> 2.9 sec

Also, anything less than 0.1 sec is ignored to prevent contact bounce stopping the motor just after it was started


I have not tried the modified motor. You might want to return yours to be reprogramed.

Also the new code fixes the "SONY remote issue..."

Charles

 

are they accepting returns for reprogramming.

I have one that was planned to be used on "raw" c-bus.

Mick

 

I am sure they would. just email them first.

Charles

 

Darren ,

I am intersted to know what cbus timing standard deviation on contact closure time would be if you did 100 *

PulseCBusLevel("Local Network", "Lighting", "CURT.OP - Rumpus curtain motor", 100%, 0, "0:00:02", 0%);

With different network loads. I assume it is dependant on this as well

would it be 2 sec + and - 0.5 sec or 2sec + 0.5 sec only or some other numbers.

Charles

 

C-Bus is not really designed for applications requiring precise timing of signals. The short delays in getting a message onto C-Bus vary depending on how busy the bus is at the time. I have not measured the variations in a pulsed group on C-Bus, but I would imagine that it could vary by +/- 0.5 second or so, depending on what is happening on C-Bus at the time.

 

Thanks for replies!

Thanks for all the replies and the reference. The people I got this from are very, very helpful and respond to emails very quickly. I will try the modified motor & post back how it goes. As well as the code I sent in the original post, I plan to use the scheduler to open at sunrise +30 mins and close at sunrise -30 mins. Will also list the timing measurements I get with the scope. Regards Jim.

 

If they are interested in a more full featured cbus integration they can look at joining www.cbus-enabled.com (it's free). Pass the info on.

 

Would it be +/- 0.5 or just +0.5 why would it be - ?? does the software try to make allowances for cbus command propagation time ??

Charles

 

I have already told them to change the name from cbus input to "automation dry contact control"

Not really cbus !!!!!!

They are thinking of making a controller that would control an entire house of curtains. this could have a real cbus input. I think however they would go for a serial port and send commands this could then be connected to a PAC.
Their motors are very cheap the bus interface would cost more than the motor !!

 

Even if they only want to use serial the cbus-enabled program is a great resource. They can get full documentation on the c-bus protocol, sample code etc...

 

Is the "it's free" comment something new?

I always thought there was a cost involved.

Cheers

Rohan

 

Hi Rohan,

My bad. C-Bus Enabled program membership starts at AU$200.

Sorry for the confusion.

 

Not so long ago the C-Bus enabled program was about getting access to the C-Bus protocol for the puposes of writing an interface to C-Bus. Because the C-Bus protocol is the core of the C-Bus offering it would be necessary to sign a contract of non disclosure to protect the interests and Intellectual Property of CIS. Part of the program was the supply of some hardware (serial sim) for the purposes of serial connection between PC / developers hardware and a C-Bus network. There was a nominal fee (few hundred dollars) for the sim and other test kit. This is now largely in the past. With the development of C-Gate and more recently the compiled C-Bus drivers it is now possible for the majority of product developers to build a high level interface without having to worry about the base level protocol. This is now allowing C-Bus to become integrated with many other systems quickly and efficiently. C-Bus is not, and does not have to be the B All and End All control system in the world. It will however benefit from being relevant to as many control systems and technologies as possible. The Boys of The Brains Trust should be congratulated for exposing C-Bus to the world in this way. It has been a soap box issue of mine for several years now. Just over a week ago I was in the US of A with a company who we are representing here in Australia. They are building a C-Bus HLI to their Multi Protocol Building Management System (BMS) at my request. The senior engineer over there who has had to reverse engineer many many BMS system protocols stated that the way the C-Bus drivers are presented, the fact Toolkit / C-Gate reference is an XML file and in particular the supporting documentation it the best they have ever seen.

Boys take the rest of the day off.

If any of you work in the commercial arena and have a requirement to interface C-Bus to BMS at a high level - call

 

$200 is still pretty cheap, I thought it was more like $2000

Cheers

Rohan