reduce CPU Usage

Having multiple units send commands at the same time will not cause errors on C-Bus. The errors are caused by poor C-Bus communications. Please focus on correcting this first. Until this is fixed, you will not get your system operating reliably.

 

Hello Darran,

I carried out the confirmation that a network error did not cause the trouble about Colour C-Touch.
I arranged different numbers for replied ?B? command. However, I modified this program. I left only the portion which UP the counter which received ON and OFF of "A.".
once (GetLightingState("A") = ON) then
begin
counter11 := counter11 + 1;
SetIntSystemIO("cnt1", counter11);
end;
once (GetLightingState("A") = OFF) then
begin
counter12 := counter12 + 1;
SetIntSystemIO("cnt2", counter12);
end;

Now, The only ON and OFF of "A" commands are transmitted at intervals of 3 seconds on a network.

I tested for 2 hours.
ON and OFF of "A" commands were transmitted 1209 times, respectively.
rx ON, rx OFF
BW& Mk 1209 1209
BF CTC 1187 1187
1F CTC 1188 1188
2F CTC 1189 1189
TEST CTC(blank project)1187 1187

A network was very quiet. In the measurement for 2 hours and 11 minutes, a message total is 5683 and the number of errors is 149.
Network error ratio is 2.6% of the number of message. This is considered to be a normal range.

It is shown by the counter that B&W Mk2 received the all the "A" message. However, it turns out that Colour C-Touch was not able to receive 1.7% of "A."

Since B&W Mk2 has received all the "A", the network did not have any error.

I am going to set the interval of Status Report to about 100 Sec, and to test for a long time.
Moreover, using BRIDGE, divide a network and it is due to be tested it.

I cannot think that the network error has spoiled the reliability of Colour C-Touch from my test data.
Please teach me the reason which can think that a network error exists.

Please give me comment.
Any comment is helpful for me.

Thank you very much.

 

An error rate of 2.6% is not "normal" at all. It is a sign of a serious problem.

This is wrong, for reasons I explained previously. The B & W C-Touch and Colour C-Touch units have slightly different circuitry. If your C-Bus communications are marginal, it is very possible for one unit to work OK and for another to fail occasionally.

Dividing the network may help the situation if the problem is caused by too much burden (combination of number of units and C-Bus Burdens). However, it should be possible to resolve the problem without doing this.

Details are above.

To get the C-Bus network communications working reliably, you need to check the basics:
- number of units
- number of burdens (hardware and software)
- number of power supplies (enough to supply current, but less than 2000mA total)
- amount of cable
- make sure there are no shorts between C-Bus and ground
- make sure there is no electrical noise on C-Bus
- check voltages at various parts of the network

I realise that this is tedious, but with poor C-Bus communications you will not get reliable operation.

 

Hello Darren,

Possibly I solved the trouble.
I checked again the item pointed out by you.

- number of units:80
- number of burdens (hardware and software): 0 (Directions by C-Bus Calculator and C-Bus Analyzer)
- number of power supplies (enough to supply current, but less than 2000mA total): 5 (350 x 5 = 1750mA)
- amount of cable: Less than 1000m
- make sure there are no shorts between C-Bus and ground: NO short
- make sure there is no electrical noise on C-Bus: not clear
- check voltages at various parts of the network: All units were more than 30V.

Abnormalities cannot discover a calculation top by C-Bus Analyzer, either.
MMI data processing of Colour C-Touch conjectured the cause of the problem after all.
I set Lighting and Heating to one in order to reduce the amount of communications of MMI data.
However, this has raised the rate of incidence of an obstacle.
It considered the cause that the amount of information in MMI data increased by setting two Applications to one.
I set the interval of Status Report to 255, and tested it.
The obstacle disappeared.

Next, I divided the network into two using C-Bus BRIDGE.
They are 58 sets in the network 1 at 22 sets and the network 2.
Added change is having set connection of BRIDGE, and Clock of two units to Enable.
I made the interval of Status Report into 5 seconds.
I do not generate an obstacle at all.
C-Bus BRIDGE does not carry out the bridge of the MMI data.
The amount of information of the MMI data of each network has decreased.

I think that Colour C-Touch is not good at processing of MMI data with much amount of information as my conclusion.
I recommend to check the portion of MMI data processing in Colour C-Touch.

Thank you very much.

 

Hello ashieigh,

Thank you very much for your advice.
I want to know functionality of Status Report.
I will ask it at General Discussion.

Thank you very much again.

 

The impact of the MMIs on the Colour C-Touch processor should be very minimal.

I performed a test by plotting the Colour C-Touch Processor usage over 5 minutes. Half way through this time I connected two additional units which caused the MMI rate to triple. As you can see from the graph, it made no difference at all to the processor usage (constant around 13%):



(The tiny rise at the end of the graph is due to the CTC Transfer Utility connecting to Colour C-Touch to do the screen grab).

 

Hello Darren,

Thank you very much for your testing.
MMI in which my trouble has much information is considered to be the cause.
I think that I will not generate a trouble if there is little information on MMI which you used for the test.
I am pleased if you will be able to consider the MMI which I pasted information on the front page.
When a network is divided into two on a C-Bus Bridge, I have not generated the trouble which cannot receive a command in Colour C-Touch.

However, another trouble occurred.
The information on a command that the Scene which Colour C-Touch in network "A" published.
The C-Bus Bridge forwarded it to network ?B?.
But some of status in it was not reflected in Colour C-Touch by forwarded information.
As for the Scene, 28 groups are registered.
The status of group was not updated by MMI.
Because that group was not arranged to C-Bus unit in network ?B?. it was arranged only units in network ?A?.
MMI of network ?A? does not forward to network ?B?.
I have a plan to devide C-Bus units in Lighting into two Lighting groups on the average.
And i will take out a C-Bus Bridge.

As Colour C-Touch is a difficult unit for me.

Thank you very much.

 

I am not sure what you are asking here. Previously you said that increasing the MMI interval seemed to help your problem. I don't know of any way that this would make a difference. If it seems to help, then leave it that way.

By dividing the network into two parts, you have changed the network impedance. To me, this confirms that the cause of your problems is communications problems, most probably due to impedance.

MMI messages do not get forwarded across bridges.

MMI messages are only for use with correcting discrepancies within a C-Bus network. In a C-Bus network which is running normally, the MMIs will do nothing at all.

I think that the reason it appears difficult is that you are having problems unrelated to the Colour C-Touch. This is making everything difficult.

 

Hello Darren,

If the cause of my trouble is depending on highly impedance, it will not solve a trouble in change of changing logical parameter.
As you know I divided the network by C-Bus Bridge.
The impedance of the divided networks were reduced. Moreover, the information in MMIs were also reduced.
I fixed the trouble by C-Bus Bridge.
I carried out test again.
I took out C-Bus Bridge. The network was one, impedance is still high.
First, I tested the interval of MMI again over 5 seconds. I generate a trouble after all.
Next, I changed half C-Bus units into Heating application.

However, I do not generate a trouble.
All of Colour C-Touch worked fine.
I consider that When MMI processing in Colour C-Touch takes time, doesn't timeout occur between Local C-Gate Server?
I solve my trouble by one of whether I use C-Bus Bridge or I use two Lighting applications.
However, I think it desirable for a problem not to occur with one Lighting application, either.

Thank you very much.

 

The impedance will actually increase if you divide a network into two and make no other changes.

The amount of information in the MMIs will not change. An MMI is a fixed length regardless of how many units there are. There is one MMI per lighting application, so reducing the number of applications will decrease the number of MMIs.

Is this what you found:

• Having all 80 units on one application on one network fails
• Having 80 units split between two networks is OK
• having 80 units on one network, but on two applications is OK

?

Colour C-Touch does not use C-Gate, it uses the C-Bus Module DLL. Processing an MMI would only take a millisecond or so on Colour C-Touch.

 

Hello Darren,

Yes it is.

I have experience in programming.
To get a status from receiving MMI, I think that loop processing is there
A maximum of 255 status goes into MMI.
Suppose that extraction of one status takes 1 microsecond.
If 255 effective status takes out information from MMI, the repetition by loop processing will be 255 times.
It is required for 255 microseconds to slip out of a loop.
If 125 effective status is MMI, time until it slips out of a loop is 125 microseconds.
Processing time when effective status receives MMI which is contained 255, and two Application?s MMI of 125 is the same.
255 x 1 = 125 x 2
However loop processing are being carried out, It cannot carry out other processing.
As 125 x 2 is much better than 255 x 1 for other processing.
Is time until it slips out of loop processing a cause of problem?

Thank you very much.

 

Hello Nick,

This is last information for this thread.

I?m managing an another C-Bus network.
It has about 90 C-Bus units.
It does not have Colour C-Touch.
I connected B&W Mk2 and Colour C-Touch temporally for testing.
Those units have blank project.
I was able to reproduce same trouble just I reported.

I know that the length of MMI messages are same regardless of effective status in MMI messages.
I have the knowledge of the C language.

unsigned char mmi_data[256];
unsigned char I;
for (i=0;i<256;i++) {
if (mmi_data == EFFECTIVE STATUS)
call_pickup_status(I, mmi_data); /* This function needs 1 microsecond for processing. */
}

If this type of program is used in Colour C-Touch, Processing time is dependent on the effective status of MMI.

Thank you very much.