|
I want know if someone have meet this problem: in a big installation I have used a group address that make the off of the all light in building. Sometime not all actuator switch off. There is some way to avoid it. Thank you. |
|
I have experienced similar behaviour in some projects and then it has been caused by malfunctioning actuators. If you control an contactor och some other kind of electromechanical relay it can disturb the actuator and force it to restart. (This is due to the current spikes flowing in some miliseconds to energize the electromagnet in the relay, it is a shockwave going through the acuator channel) Another, rather unknown, fact is that you will have a voltage-drop when executing a central command like the one you are describing. If you have insufficient power-supply that might be the cause. With insufficient power supply i mean 160mA or 320mA in crowdy segments. |
|
When wierd malfunctioning happen, such the one you describe, the very first question to answer is: Is it a stable behaviour? That is: 1) Does it happen every time? 2) Does it happen every time in the same manner? If both answers are YES, then you have a STRUCTURAL problem and the possible reasons are to be searched "on the paper", that is on the project. In this case, for example, you could look at: - Filter tables in the couplers governing the lines involved in the problem, that may block the group addresses involved. A central command should be indicated as such in ETS. - ETS programming of the malfunctioning devices. They could have a wrong flag on the group object(s) or other problems If at least one answer to 1) or 2) above is NO, then you have a RANDOM problem, which is harder to detect and fix. In principle you should test the system while working. This means, for example, placing the ETS PC on various network segments and monitor the messages on the BUS. Possible problems in your case, could be: - Network load, which may cause random message loss (possible if you have a bad programmed device, which sends a lot of packets, especially the visualization workstation during startup) - Insufficient Power (see Mrty's answer above) - Bad conditions of the bus cables and connectors (maybe an unstable contact somewhere, or an old cable with exposed wires). As to the last idea, especially check for possible interference with the power wires. These cannot happen with the green cable, but when you peel the cables to connect the devices, sometimes you may expose an excessive portion of the inner wires. These could be placed very close to some power wire and be prone to electric noise and therefore, random message loss. Always remember that the inner wires, when peeled and "untwisted" are not protected anymore against interference. Even worse, they can even be subject to cross-interference (when they are parallel, before the connector). That's why it is advisable to take out of the green cable, the smallest portion possible of the wires |
|
it's hard to say from your short question what's going on. did you try to monitor those events? whats's happening? do you have any elements that could influence on starting those circuits, like movement or presence detectors? did you try to download again? not just actuators, but line couplers also? There are 12 lines, with line coupler. The command are send by visualisation. There are not any kind of detector. The same problem I had in a bulding with 3 line then I send the passage from winter to summer function and vice versa. The room temperature sensor (about 60) don't all change the function. In that case to avoid the problem I divided the command in more winter/summer object. I'm finding a different solution. Thanks.
(Jul 09 '10 at 06:08)
Fabio
did you mark this group adress as central (pass through)? is this group adress in all filter tables, in all line couplers?
(Jul 12 '10 at 07:49)
Miro
|
|
Another thing to point out. In a large installation, with multiple areas, if you have at least two lines with repeaters, remember that a device of one area connected behind a repeater can't send telegrams to a device of another area connected itself behind a repeater. The explanation is related to a counter which is présent in each telegram. It is decremented each time it cross a line coupler, an area coupler or a repeater. When the telegram is emited, the counter is set to 6. behind the repeater, it falls to 5. Behind the line coupler, it falls to 4. Behind the area coupler it falls to 3. Behind the second area coupler, it falls to 2. Behind the line coupler it falls to 1. And because it falls to 0 into the repeater, it is not transmited to the devices behind the repeater. This is another good reason to extend an installation using line couplers first before to extend lines with repeaters. The purpose of this counter is to avoid the risk of infinite looping telegrams in an installation with a physical loop between two lines. |
|
Just a tip, if you don't already know it. All the group addresses in the range 14/0/0 to 15/15/255 are not filtered by line couplers or area couplers. So to avoid any filtering problem with a telegram sent to the whole installation, it is a good idea to send it to a group address in this range. |