View Full Version : reduce CPU Usage
Hello,
I asked about a “HomeGate is not responding” message before.
The cause got an answer to be high CPU Usage.
I used PICED4.7.x then.
The outbreak of the above message seems to have increased when I update in PICED 4.8.x.
The following messages were recorded in the Log file which started Colour C-Touch just after that.
Free Memory: 28.6 MB
Warning : Average CPU Usage : 60.7 %
Warning : Average CPU Usage : 71.6 %
Free Memory: 23.4 MB
CPU Usage : 1.0 % to 97.1 %
Screen Draw: 10ms to 761ms
Free memory: 23.6 MB
CPU Usage: 1.0 % to 53.3 %.
Screen Draw: 20ms to 90ms
Free memory: 23.5 MB
CPU Usage: 8.7 % to 54.0 %.
Screen Draw: 20ms to 90ms
Free memory: 23.7 MB
CPU Usage: 8.6 % to 63.0 %.
Screen Draw: 20ms to 90ms
I use Japanese font for this project.
There is a Web Cam object on three pages.
I did the following changes to reduce CPU Usage.
All the picture files make it bitmap file(from JPEG to BMP).
I do not use stretch of the picture file and Alpha Blend.
If Web Cam object is in back side page, a refresh rate is adjusted to 3600 by Logic.(When display it to 2.0)
The above messages are logged that I changed configuration.
Could you tell me some reason of displayed above Warning Message.
Does it become the cause to raise CPU Usage to use Japanese font?
It is in a difficult to reduce Button Components and Pages.
Please teach me it about a method to reduce CPU Usage.
Any suggestion is helpful for me.
Thank you very much.
Darren
06 May 10, 08:30 PM
Is HomeGate unresponsive on all pages, or just the pages with the web cams?
Hello Darren,
I arranged eight Web Cam components on eight pages.
I reduced Web Cam components from 8 to 2.
As seven Web Cam URL are injected by logic to a Web Cam components.
CPU Usage is reduced as below.
Free Memory: 35.1 MB
Warning : Average CPU Usage : 51.0 %
Warning : Average CPU Usage : 60.4 %
Free Memory: 23.4 MB
I don’t find message regarding HomeGate Killed in logging data.
I want to know whether these warning messages are acceptable level or not.
Trouble happened again.
Detail of trouble is that some module of logic had not been kicked when kicker command received.
I used same program in two different project.
One of them is working in PAC and another one is working in Colour C-Touch.
The trouble happened in both devices.
The program has some Delay functions.
I guess that Delay function gives some damage in program running condition.
I am going to revise a program to remove Delay function.
Any suggestion is helpful for me.
Thank you very much.
Yoshi
Darren
11 May 10, 10:34 AM
CPU Usage is reduced as below.
Free Memory: 35.1 MB
Warning : Average CPU Usage : 51.0 %
Warning : Average CPU Usage : 60.4 %
Free Memory: 23.4 MB
I don’t find message regarding HomeGate Killed in logging data.
I want to know whether these warning messages are acceptable level or not.
Generally we like to see the processor usage below about 50%. Above this, HomeGate tends be be a bit unresponsive.
Trouble happened again.
Detail of trouble is that some module of logic had not been kicked when kicker command received.
I used same program in two different project.
One of them is working in PAC and another one is working in Colour C-Touch.
The trouble happened in both devices.
The program has some Delay functions.
I guess that Delay function gives some damage in program running condition.
If you are having the same problem with Colour C-Touch and PAC, then it sounds like there is a problem with the logic, not with the Colour C-Touch processor usage.
Without more details of the nature of the problem you are experiencing, it is impossible to give any specific advice.
Hello Darren,
Three Colour C-Touch units were installed in this site.
The troubles occur only in Colour C-Touch.
A new trouble was reported.
Though the trouble is simple.
A command of ON transmitted by PC I/F was sent to the C-Bus network, status of button in Colour C-Touch was not changed.
The trouble is occurred only three Colour C-Touch units at the same time on a network.
Status was changed in B&W Touch and DLT in the same network.
I tried to reproduce the trouble at customer site.
I tested ten times and was able to reproduce one time of trouble.
There is the same Web Com object in all Colour C-Touch. When a trouble happened, Web Com object was backside page, and the refresh rate was 3600.
Three Colour C-Touch is things revised by a copy of one Project, and the basic part is the same, but Logic, Scene, and Schedule are different.
A certain Colour C-Touch decreases a performance on the same network by the same timing.
It is thought that this has some problem in the common part of Project data.
Please teach it.
Does the Japanese text label put on a page digest a CPU performance?
If i change Japanese text labels to pixel data and merge it with background of page data, is the usage of CPU improve?
Any suggestion is helpful for me.
Thank you very much.
Darren
13 May 10, 10:26 PM
Three Colour C-Touch units were installed in this site.
The troubles occur only in Colour C-Touch.
A new trouble was reported.
Though the trouble is simple.
A command of ON transmitted by PC I/F was sent to the C-Bus network, status of button in Colour C-Touch was not changed.
The trouble is occurred only three Colour C-Touch units at the same time on a network.
Status was changed in B&W Touch and DLT in the same network.
I tried to reproduce the trouble at customer site.
I tested ten times and was able to reproduce one time of trouble.
There is the same Web Com object in all Colour C-Touch. When a trouble happened, Web Com object was backside page, and the refresh rate was 3600.
Three Colour C-Touch is things revised by a copy of one Project, and the basic part is the same, but Logic, Scene, and Schedule are different.
A certain Colour C-Touch decreases a performance on the same network by the same timing.
It is thought that this has some problem in the common part of Project data.
If I understand correctly, you are saying you have three Colour C-Touch units, some B & W C-Touch and some DLTs on a network. You send a lighting ON command via a PCI and the B & W C-Touch and the DLT show the correct state, but the Colour C-Touch units do not. Is this correct?
Do the Colour C-Touch logs show this message being received?
Does the Japanese text label put on a page digest a CPU performance?
If i change Japanese text labels to pixel data and merge it with background of page data, is the usage of CPU improve?
I have not tested this, so I can not be sure. I will see if I can try this soon, but it seems unlikely that it would have much effect.
Hello Darren,
Thank you very much for your comment.
Your understanding is correct.
I did not turned logging message on in Colour C-Touch.
Because i just focused CPU usage.
This trouble is occurring not only incoming command bat also generated command in Colour C-Touch.
I got a call from customer in last weekend.
He said that one of light have not been turned to on in evening.
I arranged two schedule in Colour C-Touch.
These two schedules are kicked around sunset time.
These two schedules have different offset time by sunset.
So, schedules are kicked different time in evening.
Schedule has only processing to turn on a C-Bus group.
Turned on C-Bus group also kicked “once” logic.
Schedule A C-Bus group B ON once B = ON logic C-Bus group C ON(This is linked to output unit)
Schedule a C-Bus group b ON once b = ON logic C-Bus group c ON(This is linked to output unit)
I also arranged Button Components for showing status of A and a at top page.
When trouble occurred, status B was ON at Colour C-Touch and lights were ON by group C was ON.
But status C was not ON at Colour C-Touch and lights were not ON because group c was OFF.
I will visit customer site today.
I have some plan to chase trouble.
To arrange small logic in Colour C-Touch units,
once GetLightingState("A") = ON then
begin
SetLightingState("B", ON);
End;
once GetLightingState("A") = OFF then
begin
SetLightingState("B", OFF);
End;
To arrange one more Colour C-Touch.
I delete all Logic, Schedule, Scene and Web Com component in this unit.
To start Diagnostic Tool
I want to check difference of response by four Colour C-Touch.
Any suggestion for me is helpful.
Thank you very much.
Darren
14 May 10, 05:49 PM
Yoshi, this is starting to get a bit too complex to resolve by a discussion like this. It might be best for you to send your project archive to CIS Tech Support and ask for it to be forwarded to me. Make reference to this forum post. Give details of what is not working correctly. Provide any logs that you have, with details of when problems occurred.
Hello Darren,
I sent Project data to CIS Tech Support about a week ago.
But I have not got reply yet.
I made this connections to reproduce trouble.
I add simple logic to four Colour C-Touch, one B&W Mk2(with logic) and WISER.
The logic is below.
once GetLightingState("A") = ON then
begin
SetLightingState("B", ON);
End;
once GetLightingState("A") = OFF then
begin
SetLightingState("B", OFF);
End;
I gave the group number sent by SetLightingState for every unit.
This is a part of logging data.
11:14:26 Rx : = Source Unit 16, GA 227 On
11:14:26 Rx : = Source Unit 126, GA 85 On
11:14:26 Rx : = Source Unit 240, GA 97 On
11:14:26 Rx : = Source Unit 251, GA 179 On
11:14:26 Rx : = Source Unit 114, GA 239 On
11:14:26 Rx : = Source Unit 205, GA 96 On
11:14:27 Rx : = Source Unit 104, GA 177 On
11:14:29 Rx : = Source Unit 16, GA 227 Off
11:14:29 Rx : = Source Unit 240, GA 97 Off
11:14:29 Rx : = Source Unit 205, GA 96 Off
11:14:32 Rx : = Source Unit 16, GA 227 On
11:14:32 Rx : = Source Unit 240, GA 97 On
11:14:32 Rx : = Source Unit 205, GA 96 On
11:14:35 Rx : = Source Unit 16, GA 227 Off
11:14:35 Rx : = Source Unit 251, GA 179 Off
11:14:35 Rx : = Source Unit 126, GA 85 Off
11:14:35 Rx : = Source Unit 104, GA 177 Off
11:14:35 Rx : = Source Unit 205, GA 96 Off
11:14:36 Rx : = Source Unit 240, GA 97 Off
11:14:38 Rx : = Source Unit 16, GA 227 On
11:14:38 Rx : = Source Unit 126, GA 85 On
11:14:38 Rx : = Source Unit 251, GA 179 On
11:14:38 Rx : = Source Unit 240, GA 97 On
11:14:38 Rx : = Source Unit 104, GA 177 On
11:14:38 Rx : = Source Unit 205, GA 96 On
Unit 16 PC/IF (send out 227)
Unit 126 Colour C-Touch No.1 (send out 85)
Unit 114 Colour C-Touch No.2 (send out 239)
Unit 104 Colour C-Touch No.3 (send out 177)
Unit 251 Colour C-Touch No.4 (send out 179)
Unit 205 B&W Mk2(With logic) (send out 96)
Unit 240 WISER (send out 97)
At error condition, all of Colour C-Touch did not reply for 227 OFF.
The module is ONCE function. If Colour C-Touch did not get 227 OFF, it can not care 227 ON.
This error occurred once in 10-20 minutes.
All of Colour C-Touch has Japanese font in Font folder in Colour C-Touch.
Colour C-Touch No.4 has blank project. It does not have a Japanese character string displayed in page. It has only small logic for testing.
I tested many times. B&W Mk2 and WISER did not show err in logging data.
I found an obstacle at same time in four Colour Touch.
It seems that one Colour Touch had restarted after the test.
I found this message in logging datea in Colour C-Touch.
Error : C-Bus boradcast Failure, App 56, Time-out
I believe this is not a CPU usage issue.
This network has about 80 C-Bus units.
Voltage of all units are over 30V.
I made small network in my office which has two Colour C-Touch, one B&W Mk2, one WISER, two PC I/F and some switches.
I have not made same trouble.
Can you give me suggestion to chase cause of trouble.
I have to fix this trouble.
Any suggestion is helpful for me.
Hello Darren,
I want to delete Japanese font file from Font Folder in Colour C-Touch.
Would you teach the method?
Thank you very much.
Darren
25 May 10, 11:18 AM
once GetLightingState("A") = ON then
begin
SetLightingState("B", ON);
End;
once GetLightingState("A") = OFF then
begin
SetLightingState("B", OFF);
End;
What group address numbers are "A" and "B" ?
Hello Darren,
The group address numbers are below.
The group number “A” is 227.
The group number “B” for Colour C-Touch No.1(unit address 126) is 85.
The group number “B” for Colour C-Touch No.2(unit address 114) is 239.
The group number “B” for Colour C-Touch No.3(unit address 104) is 177.
The group number “B” for Colour C-Touch No.4(unit address 251) is 179.
The group number “B” for B&W Mk2(With logic) (unit address 205) is 96.
The group number “B” for WISER (unit address 240) is 97.
I think, Only 2nd Colour C-Touch(114) was not able to detect 2nd 227 OFF.
Thank you very much.
Hello Darren,
This is a portion of a continuation of the information which the beginning sent.
Colour C-Touch No.2(114) is restored from the obstacle.
It is 227OFF 12 seconds after the first 227OFF.
11:14:41 Rx : = Source Unit 16, GA 227 Off
11:14:41 Rx : = Source Unit 126, GA 85 Off
11:14:41 Rx : = Source Unit 114, GA 239 Off
11:14:41 Rx : = Source Unit 240, GA 97 Off
11:14:41 Rx : = Source Unit 104, GA 177 Off
11:14:41 Rx : = Source Unit 205, GA 96 Off
11:14:42 Rx : = Source Unit 251, GA 179 Off
11:14:44 Rx : = Source Unit 16, GA 227 On
11:14:44 Rx : = Source Unit 114, GA 239 On
11:14:44 Rx : = Source Unit 126, GA 85 On
11:14:44 Rx : = Source Unit 104, GA 177 On
11:14:44 Rx : = Source Unit 251, GA 179 On
11:14:45 Rx : = Source Unit 240, GA 97 On
11:14:45 Rx : = Source Unit 205, GA 96 On
Thank you very much.
Darren
25 May 10, 12:08 PM
I want to delete Japanese font file from Font Folder in Colour C-Touch.
Would you teach the method?
1. Remove the font from the PICED project \Fonts folder to prevent it from being transferred again
2. Plug a keyboard into Colour C-Touch
3. Press the Windows key to bring up the Start menu
4. Click on My Computer
5. Navigate to C:\Windows\Fonts
6. Delete the font
Hello Darren,
I was able to delete the font file.
I test at customer site on the day after tomorrow.
Did a certain process performed periodically cause errors?
For example, it is refreshment of ARP.
I connect a network analyzer to Colour Touch, and think that I will collect logging data.
Is there any parameter which should be changed? For example, it is "Status Report" etc.
Any suggestion is helpful for me.
Thank you very much.
Darren
25 May 10, 05:42 PM
11:14:26 Rx : = Source Unit 16, GA 227 On
11:14:26 Rx : = Source Unit 126, GA 85 On
11:14:26 Rx : = Source Unit 240, GA 97 On
11:14:26 Rx : = Source Unit 251, GA 179 On
11:14:26 Rx : = Source Unit 114, GA 239 On
11:14:26 Rx : = Source Unit 205, GA 96 On
11:14:27 Rx : = Source Unit 104, GA 177 On
11:14:29 Rx : = Source Unit 16, GA 227 Off
11:14:29 Rx : = Source Unit 240, GA 97 Off
11:14:29 Rx : = Source Unit 205, GA 96 Off
11:14:32 Rx : = Source Unit 16, GA 227 On
11:14:32 Rx : = Source Unit 240, GA 97 On
11:14:32 Rx : = Source Unit 205, GA 96 On
11:14:35 Rx : = Source Unit 16, GA 227 Off
11:14:35 Rx : = Source Unit 251, GA 179 Off
11:14:35 Rx : = Source Unit 126, GA 85 Off
11:14:35 Rx : = Source Unit 104, GA 177 Off
11:14:35 Rx : = Source Unit 205, GA 96 Off
11:14:36 Rx : = Source Unit 240, GA 97 Off
11:14:38 Rx : = Source Unit 16, GA 227 On
11:14:38 Rx : = Source Unit 126, GA 85 On
11:14:38 Rx : = Source Unit 251, GA 179 On
11:14:38 Rx : = Source Unit 240, GA 97 On
11:14:38 Rx : = Source Unit 104, GA 177 On
11:14:38 Rx : = Source Unit 205, GA 96 On
11:14:41 Rx : = Source Unit 16, GA 227 Off
11:14:41 Rx : = Source Unit 126, GA 85 Off
11:14:41 Rx : = Source Unit 114, GA 239 Off
11:14:41 Rx : = Source Unit 240, GA 97 Off
11:14:41 Rx : = Source Unit 104, GA 177 Off
11:14:41 Rx : = Source Unit 205, GA 96 Off
11:14:42 Rx : = Source Unit 251, GA 179 Off
11:14:44 Rx : = Source Unit 16, GA 227 On
11:14:44 Rx : = Source Unit 114, GA 239 On
11:14:44 Rx : = Source Unit 126, GA 85 On
11:14:44 Rx : = Source Unit 104, GA 177 On
11:14:44 Rx : = Source Unit 251, GA 179 On
11:14:45 Rx : = Source Unit 240, GA 97 On
11:14:45 Rx : = Source Unit 205, GA 96 On
It looks like some of the units are not seeing the change of group 227.
The first "off" message seems to have been missed by unit 126, 251, 114, and 104.
The second "off" message was missed by unit 114.
The third "off" message was seen by all units.
Units 205 (C-Touch Mark 2) and 240 (Wiser) saw all messages and responded accordingly.
The units which did not see some of the messages were all Colour C-Touch. Have you checked the Colour C-Touch logs to see if the messages appear in there?
Darren
25 May 10, 06:25 PM
I was able to delete the font file.
Excellent, although I am not sure if it will make any difference unless the font is being used.
I test at customer site on the day after tomorrow.
Did a certain process performed periodically cause errors?
For example, it is refreshment of ARP.
I connect a network analyzer to Colour Touch, and think that I will collect logging data.
We are not aware of anything which will cause periodic problems for Colour C-Touch.
Is there any parameter which should be changed? For example, it is "Status Report" etc.
The C-Bus Status Reports will not affect Colour C-Touch to a measurable degree. If you have several C-Bus applications, all with a 3 second period, it might cause a lot of C-Bus congestion though.
We seem to have established that only your Colour C-Touch units have this problem. Even unit #4 (address 251) which you say has a mostly blank project shows this problem. This seems to indicate that the problem is probably not due to the processor usage causing slow performance. The fact that the logic works OK in a B & W C-Touch and Wiser seems to indicate that the logic is OK.
One remaining possibility is that you have marginal C-Bus network communications. It is possible that the C-Bus signal is OK from B & W C-Touch and Wiser, but not OK from the Colour C-Touch. Each different unit type will be slightly different in its performance, so some unit types will have a slightly different waveform than others. If your C-Bus waveform is just on the edge of the desirable range (amplitude, DC voltage, shape etc) then you could get one device fail intermittently (in this case, the Colour C-Touch), but have another work OK (in this case, B & W C-Touch and Wiser).
The C-Bus Diagnostic Utility network analyser function will normally show you if this is occurring.
It might be worth adding and removing burdens, checking power supplies, removing some units and so forth just in case.
It would also be helpful to see the content of the four Colour C-Touch logs when this is happening. I expect that you will see the messages being received and sent correctly in the logs. If you can see the C-Bus messages being sent in the Colour C-Touch log, but not being received in the C-Bus Diagnostic Utility, it is almost certainly a C-Bus communication problem. If messages fail, you should also see an error message in the Colour C-Touch log.
Hello Darren,
I may caught a tail of trouble.
I guess this trouble depend on MMI message handling in Colour C-Touch.
Below is a history of my test at customer site.
At first, I modified test logic as below.
once GetLightingState("A") = ON then
begin
SetLightingState("B", ON);
counter1 := counter1 + 1;
SetIntSystemIO("cnt1", counter1);
End;
once GetLightingState("A") = OFF then
begin
SetLightingState("B", OFF);
Counter2 := counter2 + 1;
SetIntSystemIO("cnt2", counter2);
End;
If Colour C-Touch was able to receive “A” command and just have a trouble regarding sending message, “counter1” will be increased.
I counted the response packet(“B”) transmitted from Colour C-Touch.
The value was the same as the counter.
It means that Colour Touch was not able to receive a command(“A”).
Please check attached Traffic Analyzer window.
Usually, since the response of Colour C-Touch overlaps, the error is recorded.
However, the error is not recorded when an trouble occurs.
Only the "A" command of ON and OFF was recorded.
Colour C-Touch did not generate the transmitting error.
It means that performance falls and processing is impossible.
I considered why this trouble can not be reproduced in my office.
I focused MMI message. I can make a small network. But I can not make same MMI massages in my office.
Please see attached three MMI data.
I think it has more information than typical network.
I guess this is a reason of non-reproducibility of trouble at my office.
The trouble was counted a few times in a hour of testing.
I changed “Status Report” configuration from 3 to 255(maximum).
The trouble was not counted.
When a MMI interval is 3 seconds, it means that MMI had flowed into the network 1200 times.
When a MMI interval is 255 seconds, it means that MMI had flowed into the network 14 times.
It is 100:1.1.
I will test more hours tomorrow.
Please give me your comment for my guess.
Thank you very much.
Yoshi
Darren
01 Jun 10, 06:59 PM
Unless you are using a lot of Lighting-compatible applications, the MMI interval will not normally be a problem. It is hard to see from the images, but it looks like you have 2 or 3 applications with MMIs. Increasing this period a bit will reduce the network traffic, but at the expense of slowing down the error correction mechanism in the MMIs. I would suggest increasing it to no more than 5 or 10 seconds for lighting. For other applications (heating etc), you could increase it more if you want.
The error rate in the Traffic Analyser log is very alarming. This is a fairly clear sign of serious C-Bus communication problems. You really need to address this before doing anything else.
Hello Darren,
Thank you very much for your quick reply.
I'm sorry, My explanation was insufficient.
On a traffic analyzer's screen, two applications are working.
But only Lightting application is working now.
I still find an error.
The thing with a high error rate is because four Colour C-Touch and one B&W Mk2 have returned the "B" command simultaneously to the "A" command at same timing.
I think that the usual error rate is less than a standard value.
It is a problem that Colour C-Touch cannot return the response of the "B" command in the state where an error rate is high, either.
WISER and B&W Mk2 has returned the response of the "B" command at any times.
I do the test which made the MMI interval 4 to 5 seconds, and report.
Thank you very much.
Darren
03 Jun 10, 12:32 PM
The thing with a high error rate is because four Colour C-Touch and one B&W Mk2 have returned the "B" command simultaneously to the "A" command at same timing.
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.
Darren
04 Jun 10, 03:51 PM
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.
An error rate of 2.6% is not "normal" at all. It is a sign of a serious problem.
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.
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.
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.
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.
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.
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.
ashleigh
09 Jun 10, 01:49 PM
It is possible you have MMI's in several applications, and these together add a large MMI load to the whole network.
In general, the MMI interval should be set to 3 seconds but you can make it a little bigger without any serious consequences.
If you have several applications (eg lighting + heating) and they are both using MMI's, I would recommend setting them each to 5 or 6 seconds.
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.
Darren
10 Jun 10, 02:19 PM
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%):
1295
(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.
Darren
15 Jun 10, 10:55 AM
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.
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.
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.
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.
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”.
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.
As Colour C-Touch is a difficult unit for me.
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.
Darren
22 Jun 10, 05:18 PM
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.
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.
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.
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
?
I consider that When MMI processing in Colour C-Touch takes time, doesn't timeout occur between Local C-Gate Server?
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,
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
?
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.
Hi Yoshi,
The MMI is quite an advanced concept, and you are making a few incorrect assumptions about why it might be the cause of your problems.
For one, the time taken to process an MMI is pretty much independent of the content of the MMI, as the MMI message is the same length regardless of whether the groups are used or not.
We are confident that there is not a problem with processing of the MMI.
Given that you have found a workaround that seems to fix your problem, perhaps it is better to just leave this change in place and move on.
Nick
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[i] == EFFECTIVE STATUS)
call_pickup_status(I, mmi_data[i]); /* 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.
vBulletin® v3.7.4, Copyright ©2000-2012, Jelsoft Enterprises Ltd.