Motorized door control using L5108RELVP issues

We're controlling several large motorized sliding doors in a seaside home, using the dry contact outputs of several L5108RELVP units, on a Cbus network.

For example, OUT1 (maintained short between C and N.O.) causes door to open, while OUT2 and 3 are OFF. OUT2 for close (OUT1,3=OFF). OUT3 puts door into auto mode whereby it uses it's own local presence sensors to open or close the door (OUT1,2=OFF). These states are then applied to each respective set of RELVP outputs by way of scenes stored in the DLP switch adjacent to the door and triggered by 3 different values for a dedicated group address on the trigger application (i.e. 1=OPEN,2=CLOSE,3=AUTO,4=MANUAL=OUT1,2,3=OFF). Four buttons on the adjacent DLT trigger these four respective scenes, in turn controlling the door appropriately. This regime has worked famously for the last 12 or so months, up until one of the door controller boards was replaced recently, due to corrosion.

Ever since this replacement we seem to be getting consistent triggering of RELVP outputs on different units. For example, pressing the CLOSE button on the DLT switch for this sliding door (with the replaced controller) now causes the front door strike to activate in addition to the gas fireplace. Both of these appliances are triggered from RELVP outputs, situated on different floors.

We've tried replacing the RELVP connected to this door controller, with the same result. We've also connected the terminal block going back to this controller, to a different RELVP on the Cbus network, again with the same result. Isolating the door controller from the RELVP seems to make all these issues go away. CIS tech support have since confirmed that the RELVP outputs contain no snubbing circuitry that might couple any sort of RFI back onto the door controller, so that theory's also out the window. Granted, we may be dealing with an RFI issue coming directly from the recently replaced door controllers, as the remaining original controllers all seem to work normally. However, there is one issue that still troubles me...

Going from OPEN mode to AUTO, whether it be from the DLT or from the manual overrides at the RELV outputs, causes that respective door motor to violently "oscillate" or thrash backwards and forwards to such an extent that the belt driven by the motor has known to dislodge itself. If this tried manually, with no Cbus, just by shorting the relevant wires together there's no problem.

Has anyone seen anything like this before and if so, was there a workaround?

 

The fact that it was all working fine up until the door controller board was replaced makes it seem pretty clear to me that the problem is not with the C-Bus Relay unit itself. It's much more likely to be a wiring faut or faulty/incompatible controller.

If you have multiple doors like this is it possible to swap door controller boards, to see if it's a controller fault?

Is the door controller a single unit for the whole site or is there a separate controller per-door?

If you've still got the old controller lying around, can you put that back in to see if the problem goes away?

Are these door controllers interlinked in any way?

It's also worth just monitoring the C-Bus traffic using Diagnostic Utility or Toolkit Application Log to make sure that the C-Bus commands that are being sent on the network are the ones you're expecting and no more. If any changes were made at the same time, to logic programming for example, then an error may have been introduced.

 

The fact that it was all working fine up until the door controller board was replaced makes it seem pretty clear to me that the problem is not with the C-Bus Relay unit itself. It's much more likely to be a wiring faut or faulty/incompatible controller.
That's my resoning too. However, the door guys demonstrated with their own 4-pole rotary switch and the door seems to work fine.

If you have multiple doors like this is it possible to swap door controller boards, to see if it's a controller fault?
That's what I've proposed and hopefully what we'll do on site at the up coming troubleshooting meeting. Problem is, the owner hesitates doing this as it takes a couple of hours due to the way the doors have been built-in.

Is the door controller a single unit for the whole site or is there a separate controller per-door?
Separate door controller per door.

If you've still got the old controller lying around, can you put that back in to see if the problem goes away?
According to the owner, it appears that the door guys have since changed suppliers and no longer supplying the former types. We are questioning C-Tick and CE approvals if the boards are coming from OS. My suspicion is that the newer boards are putting out some form of RFI which seems to somehow be affecting the RELVP's only??

Are these door controllers interlinked in any way?
No they're not.

It's also worth just monitoring the C-Bus traffic using Diagnostic Utility or Toolkit Application Log to make sure that the C-Bus commands that are being sent on the network are the ones you're expecting and no more. If any changes were made at the same time, to logic programming for example, then an error may have been introduced.
I've already monitored message log using Toolkit and nothing appears when these random events take place. This makes me even more inclined to believe that it's rubbish put on the network, seeing as Toolkit can't interpret it. Tech support recently introduced me to the Diagnostic Utility which I plan using when I'm out there next.

Would it be too out there to suspect that the door controller, if not internally filtetred properly or incorporating underspeced components, is putting out some form of RFI which is inducing or injecting noise onto the Cbus, possibly even via the mains. I'm assuming there'd be some sort of variable speed drive for the motor being controlled etc.. If so, do you think putting a harmonic filter between the GPO and the door controller may improve things? I'm even thinking one of those high grade "Dynamic Active Tracking" surge protection power boards may even do the trick (in reverse), just to prove a point.

 

I would start with the basics. I'd mount 4 switches in a grid plate and wire those into the 4 inputs of the controller. Check the behaviour of the controller with these switches. Use these 4 switches to simulate the relay contacts of the ELV relay unit, manually operating them in the same way you've programmed the ELV relay to operate.

I just wonder if the new controller's inputs are floating, i.e. may not have internal pull up or pull down resistors, so under some circumstances it's inputs can flap around with electrical noise. It's clutching at straws but maybe the door manufacturer's rotary switch has some internal resistors that keep the inputs pulled in the correct direction when the switch contacts are open.

It could even be something weird like the old controller being configured to use toggle switches and the new one being configured to use momentary switches.

I assume you're not doing something silly like running the switch cables between the ELV relay and the door controller through the same conduit as the C-Bus cable? I assume that these cables enter the ELV relay unit at opposite ends?

I'm still suspecting a wiring fault, such as having the common connection wired on the output of a relay contact, or similar.

 

I would start with the basics. I'd mount 4 switches in a grid plate and wire those into the 4 inputs of the controller. Check the behaviour of the controller with these switches. Use these 4 switches to simulate the relay contacts of the ELV relay unit, manually operating them in the same way you've programmed the ELV relay to operate.
Check! we did this both with the raw wires, then with powered 12V Omron relays, driven by the RELVP relays, for a layer of isolation between the Cbus contacts and the actual controller. Alas, the same result prevailed..!

I just wonder if the new controller's inputs are floating, i.e. may not have internal pull up or pull down resistors, so under some circumstances it's inputs can flap around with electrical noise. It's clutching at straws but maybe the door manufacturer's rotary switch has some internal resistors that keep the inputs pulled in the correct direction when the switch contacts are open.
Interesting notion. Still doesn't explain why their 4 way switch works without a glitch?

It could even be something weird like the old controller being configured to use toggle switches and the new one being configured to use momentary switches.

I assume you're not doing something silly like running the switch cables between the ELV relay and the door controller through the same conduit as the C-Bus cable? I assume that these cables enter the ELV relay unit at opposite ends?
Not that we've done this, but I'm a little confused as to why ELV Cbus network cable running alongside a Cat5 cable dedicated to switching dry contacts would be a "silly" thing to do? Aren't they both ELV and hence according to AS3000 be fine together?

I'm still suspecting a wiring fault, such as having the common connection wired on the output of a relay contact, or similar.
Ok, this may shed some light on the topic... The door guys have since replaced the power supply to this door controller. Miraculously, all the earlier "gremlins" we spoke off, seem to have disappeared. This makes me wonder whether these issues were caused by an unsuitably screened/protected/filtered switch mode power supply? As for the "thrashing" issue, well we're still trying to get the bottom of that one but we've pretty much narrowed it down to being door controller related.

Thanks Newman for your insightful tips and suggestions.

 

If, inside the rotary switch, there were resistors that tied unconnected inputs to a particular level, then they would not be left floating at any time, regardless of whether that particular connection was the currently-selected one or not.

Whilst from a safety perspective it is fine, it requires a little more though than just that. For example, if you had high speed switching signals on any cables, and these were bundled with the C-Bus cable, then these switching signals could couple on to the C-Bus network.

 

Not likely a problem IMHO. C-Bus is pretty well immune to noise in that noise is very very unlikely to result in valid commands on the bus. At worst, noise could block C-Bus messages from getting through for a period of time, but that's not the case here, where it appears that relays are reacting as if there was a valid command. The twistedness of the pairs in both data and C-Bus cabling also helps minimise coupling, so I wouldn't think that bundling the two together would ever create problems.