| Posted: Thursday Dec 11th, 2014 03:04 pm |
|
41st Post |
wexfordman
UCM Pi Users
| Joined: | Monday Jan 1st, 2007 |
| Location: | Cork, Ireland |
| Posts: | 546 |
| Status: |
Offline
|
back to top
|
slychiu wrote: I was actually wanting the event log, not the Monitor IO as that tells when the communications failures happens and restore.
Perhaps you can turn on the affected relay before the due time and see if it happens on exactly the same time each day
Have you tried resetting comfort while it is in this state?
Hi
,Event log enclosed. Note that this is the event log from the new board, so anything pre dec 2014 is from its former life in my sisters house:-)
The comms failures, in particularly the ones from this morning at 8am are immediately following me turnin on the velbus heating relay manually.
Again, this relay is not mapped to comfort, so you will not see it as an event.
At the time of writing this,, 11am, the velbus relay 4 was still turned on, but you will note, no further comms failures after the 8am ones
Sunrise time in comfort is 08:29
Regards,EamonAttachment: log_file_11_dec_11am.clg (Downloaded 4 times) Last edited on Thursday Dec 11th, 2014 03:05 pm by wexfordman
|
| Posted: Thursday Dec 11th, 2014 07:27 pm |
|
42nd Post |
Vangelis
Member
| Joined: | Tuesday Jan 31st, 2012 |
| Location: | |
| Posts: | 138 |
| Status: |
Offline
|
back to top
|
Have you tried disabling the mains feed into Comfort so it kicks over to Battery Backup just before the 5pm switch-on? This will rule out any mains interference (understand you have removed the load on the relay - however is comfort powering the relay module?)
It would appear something is crashing the Comfort Bus - enough for it to be irrecoverable sometimes (ferrite beads maybe??)
Have you pulled the Velbus bus feed into the relay module - so Comfort 'thinks' it is issuing a cmd, but nothings listening (might not work if Comfort 'know's' the BUS is not there)
A final connectivity test is to log into Comfort locally (i.e not via ADSL router) - Piece of Cat5 straight from PC to UCM/Eth - Try a telnet to IP on Port 1001 (think that is what Comfort uses) from CMD prompt - should get a blank window - if not then the daemon is not listening - which could be a result of Comfort being in a weird state.
Vangelis
|
| Posted: Thursday Dec 11th, 2014 09:09 pm |
|
43rd Post |
wexfordman
UCM Pi Users
| Joined: | Monday Jan 1st, 2007 |
| Location: | Cork, Ireland |
| Posts: | 546 |
| Status: |
Offline
|
back to top
|
Okay, I turned the heating relay on MANUALLY at about 4pm, at 16:45 comms failure came in,so we have two definate times.
Comms failure this morning with heating relay on, cleared at 8:09 am and did not re appear all day despite relay being left on.
Comms failure again this afternoon at 4:45pm when relay was turned on at 4pm.
I manually turned the Relay off at 17:05pm and comms failure cleared.
event log attatched
Attachment: log_file_11_dec_530pm.clg (Downloaded 2 times) Last edited on Thursday Dec 11th, 2014 10:18 pm by wexfordman
|
| Posted: Friday Dec 12th, 2014 05:42 am |
|
44th Post |
wexfordman
UCM Pi Users
| Joined: | Monday Jan 1st, 2007 |
| Location: | Cork, Ireland |
| Posts: | 546 |
| Status: |
Offline
|
back to top
|
All good up till about twenty minutes ago when I went to turn on the heating again...comms failure.
Here is what I did Manually turned on heating relay comms failure returned.Turned off heating relay, comms failure cleared.Disconnected ac in to the relay and turned it on again....comms failed returned.Turned off relay, comms fail cleared but returned again after about twenty seconds.
That was odd, so I connected the ac back into the relay, turned it on, and turned it off again.....comms failure cleared.
Will repeat it again later to see if I can do the exact same with the same results. Odd that I needed to reconnect the ac to the relay to get it to clear the alarm again.
Last edited on Friday Dec 12th, 2014 05:48 am by wexfordman
|
| Posted: Friday Dec 12th, 2014 08:59 am |
|
45th Post |
slychiu
Administrator
| Joined: | Saturday Apr 29th, 2006 |
| Location: | Singapore |
| Posts: | 5500 |
| Status: |
Offline
|
back to top
|
During the comms failure when nothing is able to communicate, are the D9 (Red) and D10 (green) leds on the UCMs blinking?
D10 Green blinking fast means incoming polls from comfort. The blinking is very fast so it appears to be steady on. It should flicker occasionally.
D9 Red blink means reply from UCM
Another idea is to run the Bus Monitor from Tools
press Bus Analyse button
The screenshot shows a typical Bus monitor screen
|
| Posted: Friday Dec 12th, 2014 12:59 pm |
|
46th Post |
wexfordman
UCM Pi Users
| Joined: | Monday Jan 1st, 2007 |
| Location: | Cork, Ireland |
| Posts: | 546 |
| Status: |
Offline
|
back to top
|
slychiu wrote: During the comms failure when nothing is able to communicate, are the D9 (Red) and D10 (green) leds on the UCMs blinking?
D10 Green blinking fast means incoming polls from comfort. The blinking is very fast so it appears to be steady on. It should flicker occasionally.
D9 Red blink means reply from UCM
Another idea is to run the Bus Monitor from Tools
press Bus Analyse button
The screenshot shows a typical Bus monitor screen
Hi,
The green led is either solid or fast flashing and the red led is pulsing. Same in both ucm modules.
The monitor won't work, as when it fails I have no accessLast edited on Sunday Dec 14th, 2014 06:11 am by slychiu
|
| Posted: Friday Dec 12th, 2014 01:36 pm |
|
47th Post |
Ingo
UCM Pi Users
| Joined: | Sunday Jan 21st, 2007 |
| Location: | South Africa |
| Posts: | 562 |
| Status: |
Offline
|
back to top
|
So just to confirm, D10 (Green LED) goes haywire when the system locks up? What is the D10 LED state like when it's in a normal state?
Maybe you can capture the bus data permanently and when it 'dies' then check to see what device sent the most data - it should be the last lot of entries.
If I remember correctly the second entry indicates the ID of the module in Hex EG. xx 11 xx xx xx xx would be first UCM, ID1. See Chiu's example in previous post. If you know the module then you can try and identify what it's trying to do.
|
| Posted: Friday Dec 12th, 2014 02:59 pm |
|
48th Post |
slychiu
Administrator
| Joined: | Saturday Apr 29th, 2006 |
| Location: | Singapore |
| Posts: | 5500 |
| Status: |
Offline
|
back to top
|
It does not mean the D10 green is hayware
In the normal state it blinks fast so it appears to be steady
D9 red blinking means the UCM is replying so why is there a communications failure?
|
| Posted: Friday Dec 12th, 2014 04:19 pm |
|
49th Post |
Ingo
UCM Pi Users
| Joined: | Sunday Jan 21st, 2007 |
| Location: | South Africa |
| Posts: | 562 |
| Status: |
Offline
|
back to top
|
Sure. I meant if it is so fast that it is steady On (or 'solid' as mentioned earlier) it might indicate a flood problem. Fast blinking can still be seen though. Last edited on Friday Dec 12th, 2014 04:20 pm by Ingo
|
| Posted: Saturday Dec 13th, 2014 04:53 pm |
|
50th Post |
wexfordman
UCM Pi Users
| Joined: | Monday Jan 1st, 2007 |
| Location: | Cork, Ireland |
| Posts: | 546 |
| Status: |
Offline
|
back to top
|
Ingo wrote: So just to confirm, D10 (Green LED) goes haywire when the system locks up? What is the D10 LED state like when it's in a normal state?
Maybe you can capture the bus data permanently and when it 'dies' then check to see what device sent the most data - it should be the last lot of entries.
If I remember correctly the second entry indicates the ID of the module in Hex EG. xx 11 xx xx xx xx would be first UCM, ID1. See Chiu's example in previous post. If you know the module then you can try and identify what it's trying to do.
Hi Ingo,
the d10 led atually looks ok according to what slychui says. I see it a either full green/flickering or pulsing rapidly.
How do I capture the bus data permanently ? My thinking is, if i need to be connected to comfort, then I will loose comms when the issue happens, and so also lose bus monitor ?
I have yesterday ordered a spare vmb4ry, which should be here next week, and I will replace hte new one and see if it makes any difference. Have to say, Im scratching my head here and wouldnt rule out anything. The module could well be faulty, its just beggers belief that it is only between specific times.
|
| Posted: Saturday Dec 13th, 2014 05:09 pm |
|
51st Post |
slychiu
Administrator
| Joined: | Saturday Apr 29th, 2006 |
| Location: | Singapore |
| Posts: | 5500 |
| Status: |
Offline
|
back to top
|
If the red D9 is blinking it means the UCM is replying, which also means that it received the correct message from Comfort, so the UCM must be communicating
Start the Bus monitor before the time that it happens. See what it captures when the fault happens
|
| Posted: Saturday Dec 13th, 2014 07:50 pm |
|
52nd Post |
wexfordman
UCM Pi Users
| Joined: | Monday Jan 1st, 2007 |
| Location: | Cork, Ireland |
| Posts: | 546 |
| Status: |
Offline
|
back to top
|
slychiu wrote: If the red D9 is blinking it means the UCM is replying, which also means that it received the correct message from Comfort, so the UCM must be communicating
Start the Bus monitor before the time that it happens. See what it captures when the fault happens
Will do, thanks
|
| Posted: Saturday Dec 13th, 2014 10:40 pm |
|
53rd Post |
wexfordman
UCM Pi Users
| Joined: | Monday Jan 1st, 2007 |
| Location: | Cork, Ireland |
| Posts: | 546 |
| Status: |
Offline
|
back to top
|
slychiu wrote: If the red D9 is blinking it means the UCM is replying, which also means that it received the correct message from Comfort, so the UCM must be communicating
Start the Bus monitor before the time that it happens. See what it captures when the fault happens
Hi Slychui,
Ok, velbus heating relay was on from about 3pm this afernoon and left on all the time. First failure came in at 16:54 as you will see from the event log. I also have the enclosed bus monitor file for the same period, but not clear on how to interpret it. There are corresponding error messages in it at the same time.
Heating relay was turned off at approx 1823pm.
Regards,eamon
bus monitor file was too large, drop box location is here
https://www.dropbox.com/s/6tc1t5fnnt7ea70/busmonitor2.txt?dl=0
Attachment: log_file_13_dec_1830pm.clg (Downloaded 1 time) Last edited on Saturday Dec 13th, 2014 11:52 pm by wexfordman
|
| Posted: Sunday Dec 14th, 2014 05:49 am |
|
54th Post |
slychiu
Administrator
| Joined: | Saturday Apr 29th, 2006 |
| Location: | Singapore |
| Posts: | 5500 |
| Status: |
Offline
|
back to top
|
The problem seems to be the RS485 bus (KA KB) has interference so that the messages are garbled
The NAK replies means that the checksum is wrong in the message
16: 52: 28: 056 ----< 03 53 4E 35 43 02 <--->SN5C NAK reply from/to Rio/Scs03
16: 52: 28: 072 ----< 03 53 4E 35 43 02 <--->SN5C NAK reply from/to Rio/Scs03
16: 52: 28: 185 ----< 03 12 4E 39 44 02 <--->N9D NAK reply from/to Ucm 02
16: 52: 28: 244 ----< 03 12 4E 39 44 02 <--->N9D NAK reply from/to Ucm 02
16: 52: 28: 306 ----< 03 12 4E 39 44 02 <--->N9D NAK reply from/to Ucm 02
16: 52: 28: 369 ----< 03 12 4E 39 44 02 <--->N9D NAK reply from/to Ucm 02
16: 52: 28: 533 ----< 03 51 4E 35 45 02 <--->QN5E NAK reply from/to Rio/Scs01
after this time, all the messages are NAKs
The switching on of the relay must be causing some sort of interference to the bus
|
| Posted: Sunday Dec 14th, 2014 06:14 am |
|
55th Post |
slychiu
Administrator
| Joined: | Saturday Apr 29th, 2006 |
| Location: | Singapore |
| Posts: | 5500 |
| Status: |
Offline
|
back to top
|
Did you press the Start Button or the Bus Analyse button?
The Bus analyse button gives the polling and reply information which seems to be missing
|
| Posted: Sunday Dec 14th, 2014 09:29 am |
|
56th Post |
wexfordman
UCM Pi Users
| Joined: | Monday Jan 1st, 2007 |
| Location: | Cork, Ireland |
| Posts: | 546 |
| Status: |
Offline
|
back to top
|
slychiu wrote: The problem seems to be the RS485 bus (KA KB) has interference so that the messages are garbled
The NAK replies means that the checksum is wrong in the message
16: 52: 28: 056 ----< 03 53 4E 35 43 02 <--->SN5C NAK reply from/to Rio/Scs03
16: 52: 28: 072 ----< 03 53 4E 35 43 02 <--->SN5C NAK reply from/to Rio/Scs03
16: 52: 28: 185 ----< 03 12 4E 39 44 02 <--->N9D NAK reply from/to Ucm 02
16: 52: 28: 244 ----< 03 12 4E 39 44 02 <--->N9D NAK reply from/to Ucm 02
16: 52: 28: 306 ----< 03 12 4E 39 44 02 <--->N9D NAK reply from/to Ucm 02
16: 52: 28: 369 ----< 03 12 4E 39 44 02 <--->N9D NAK reply from/to Ucm 02
16: 52: 28: 533 ----< 03 51 4E 35 45 02 <--->QN5E NAK reply from/to Rio/Scs01
after this time, all the messages are NAKs
The switching on of the relay must be causing some sort of interference to the bus
Thanks slychui,
It is odd though is it not that this interference issue comes in at specific times during the day. For example, the relay was turned in for a good hour or more without problems, and the naks just started to come in at that time when nothing had changed, and nothing was done to trigger this interference.
|
| Posted: Sunday Dec 14th, 2014 10:59 am |
|
57th Post |
slychiu
Administrator
| Joined: | Saturday Apr 29th, 2006 |
| Location: | Singapore |
| Posts: | 5500 |
| Status: |
Offline
|
back to top
|
The intermittent NAKs started at 15:18 in the bus monitor, but became worse until 16:+ when it happens all the time
If you have an oscilloscope you can use it to see what the KA/KB signal looks like
|
| Posted: Sunday Dec 14th, 2014 09:40 pm |
|
58th Post |
wexfordman
UCM Pi Users
| Joined: | Monday Jan 1st, 2007 |
| Location: | Cork, Ireland |
| Posts: | 546 |
| Status: |
Offline
|
back to top
|
Hi Sychui,
No, dont have an oscilloscope unfortunately. I have been wathcin the NAKS over he last 20 mins, and counted 7 of them over that period. That was with the heating relay off.
Is the presence of NAK messages unusual or would you expect a number of them to come in even in a good system ?
Do you think that the vmb4ry is what is introducing the noise at this stage, and if so, how can it cross the velbus onto the comfort bus ?
|
| Posted: Monday Dec 15th, 2014 06:06 am |
|
59th Post |
slychiu
Administrator
| Joined: | Saturday Apr 29th, 2006 |
| Location: | Singapore |
| Posts: | 5500 |
| Status: |
Offline
|
back to top
|
NAKs can occur occasionally on the Bus, which may be due to noise and interference.
Your problem seems to be interfence caused by the load switching on. It may or may not be due to Velbus.
Can you disconnect the load and turn it on manually eg using a switch so it is isolated from Velbus. Seee if that causes the same problem
|
| Posted: Monday Dec 15th, 2014 11:05 am |
|
60th Post |
Ingo
UCM Pi Users
| Joined: | Sunday Jan 21st, 2007 |
| Location: | South Africa |
| Posts: | 562 |
| Status: |
Offline
|
back to top
|
As a test, I ran my network for most of the night without even one NAK. That Keypad02 of yours looks a bit suspect...
Confirm that you receive NAKs for this device all the time or just when the boiler is On? If it's giving these errors all day then perhaps just remove this keypad for a while (as close to Comfort as possible to rule out induced noise in the KP02 cabling). I think in the absence of a clear culprit you need to try the process of elimination.
|
| Current time is 04:28 pm | Page:   1 2 3 4 5   |
|
