M1XIN problem

In the RP software also check your logs. Download all and read through them. It can give you a clue about the XIN . Then go to status in RP and see what status your panel is in.
 
Not sure if I agree with that...if the panel doesn't see the zones but the panel sees the XIN correctly on the bus, nothing is going to be in RP, nor would zone state changes, the log isn't big or robust enough to record all of that. The only thing RP and the log would see is if the expander was dropping offline and/or rebooting.
 
As a background/aside, coming from the world of access control and automation panels where the programming can be anything under the sun based on I/O, the way to prove what is factually functioning in the field and what is not, is to meter the inputs for voltage based on state, and not via the software, and (not relevant in this case) check the outputs for an appropriate state (either dry or wet).  You move simple first, rule out the field components and connections, then to major hardware. While not popular, the majority of issues (barring a 1-5% field failure) are cabling or external components before major hardware. As I said, a ground fault/loop is notorious for causing all sorts of maladies on inputs. The programming and software is always going to be irrelevant.
 
In my specific case, we commonly deal with an EC doing cabling and installation of components on large installs and we are "parts and smarts". How do you tell the parties involved (barring communication issues) where the issues are when the entire system hasn't been fleshed out or programmed via software links. You got it, once proven to not have a ground fault or fault to other cabling, you connect to the host system and start metering voltages of inputs and disregard the host system and software.
 
OK....I will work on these options.  I have ordered a replacement, but in the meantime, maybe I can find the problem.  I will post back with my results.
 
Back
Top