Whenever the alarm goes off CQC cannot connect to the M1. To get it to re-connect I have to power cycle the M1 and either cycle the CQC service or pause and resume the driver.
Does this happen to anyone else with an M1?
I was not able to get anything out of the logs today, but I will put it into high and trigger an alarm on the weekend when I have time and the kids are not asleep.
It may be going into a state that the driver doesn't expect. There was one such fix in the betas leading up to 4.0:
Quote:The Elk driver is incorrectly mapping the alarm types to field values. It was assuming that the values returned could be mapped simply through an algorithm, but that didn't really work, so invalid values would result and the driver would croak due to an invalid value being stored. Fix that, but also add the correct exception handling to just put the field in error if we get an invalid value in the future, not to take the driver offline.
That was in 3.4.12, so I would assume you are beyond that at this point, so maybe it's something else.
From experience, it appears to be an unknown reply. I see them occasionally from the M1 in the logs, where it does not know what the reply means and drops the M1 off the system - not sure I agree with that thinking, dosconnecting doe to an unknown. I would rather see ti stay connected, mark the field in error and move on.
09-15-2011, 09:06 AM (This post was last modified: 09-15-2011, 09:34 AM by Dean Roddey.)
Assuming you were in verbose mode, that's not unexpected, it's just some command that the driver doesn't deal with. Unless of course it's being done in some place where it doesn't catch the exception correctly. I think that conversion from incoming message characters to enumerated value only happens in the message reader, where it's handled correctly, but I'll check it.
Actually, it looks like that message is being logged when it shouldn't. It just saying, I got an incoming command that not on my list of things to process. It should be a verbose level logged message, but it's just being always logged. I'll add the verbosity check around it.
Or, I guess, more to the point, what is happening is that the incoming value is being translated correctly to the driver's internal enumerated command type, but in this particular method not all of those are being responded to, and so this message is being logged, when it should only be a verbose level thing.
I checked and there doesn't appear to be any obvious way in which an alarm could freak the driver out. The helper that handles the alarm state change mesage is either catching exceptions when it tries to convert he value, or the conversion isn't of the sort that would cause an exception.
So we'll definitely need to see what state the guy is in.
CQC was connected initially when the alarm went off (09:25:38 - Line 2503) and then timed out at (09:25:59 - Line 2947).
Clearing the alarm has not brought it back on line.
It has managed to connect on its own in this test after a while. The fact that its timing out could mean that the Ethernet Interface is dropping its connection. I will do a few more tests to see if I can gleam any more info.
It appears to be hardware issue. I can't ping the unit either when the alarm is triggered.
There still seems to be an issue with the re-connect. The M1 comes back onto the network and it takes a long time (up to two minutes) for CQC to re-connect. That is probably not an issue for CQC, but rather the interface not replying to the queries it is receiving.
So at the moment I would say there is no problem here for CQC, but I thought I should post the results so others may see the outcome should they have a similar issue.
