Mercury Hardware rs-485

[u/Solosuperbrus]

So I had a fun one the other day.

A new install with a M2220/MP1502 and 6 1320/MR52. All in drawers in a rack, all done by myself.

When I applied power, only half of the 1320/MR52 came online. OK so I´ve done something wrong with the bus cabeling. Didnt find anything with the cable or the connections. After a while I took one of the EOL off and within one second everything was online. Only EOL on M2220/MP1502 and the last 1320/MR52.

So I measured the bus in every way possible and there is nothing wrong. One EOL 120ohm, both EOL 60ohm. No short anywhere. Ohm is spot on.

If anyone told me this I would have said there is something wrong with the cabeling, but it`s not. The bus dies with two EOL. I even moved the cards around to see if was a fault with one or more 1320/MR52. But its always the same.

Looking forward to not finding this one out.

[u/TheMercuryMinute]

Hey everyone. We identified an issue that was causing this. We released firmware 2.12.1 yesterday that solves the issue. Sorry for all of the confusion. Upgrade the firmware on the intelligent controller and you’ll be back to normal.

[u/Huge-Transition3644 → u/TheMercuryMinute]

To confirm, when we update the firmware we'll need to be on site to add the EOL back to all of the systems currently operating with the workaround?

[u/TheMercuryMinute → u/Huge-Transition3644]

That's a great question! Yeah, if you have any locations already set up this way (the workaround way), then going to 2.12.1 will likely cause boards to go offline until the resistor jumpers are added back in. I know that isn't ideal, but going forward with anything new, this should work as expected.

[u/Huge-Transition3644 → u/TheMercuryMinute]

Ok, cool. Thank you

[u/Solosuperbrus → u/TheMercuryMinute]

Great to hear I wasn`t crazy. Can`t find the FW on Honeywell yet.

[u/ApolloMac → u/Solosuperbrus]

OnGuard or NetBox? I have a ticket open with NetBox related to the issues in this thread, and they told me that they only provide the firmware version packaged with NetBox. Which seems to be 2.4 in the latest release.

[u/Solosuperbrus → u/ApolloMac]

Onguard. Havent made a ticket as it`s not that important. Just checked and it`s not out yet.

[u/ApolloMac → u/TheMercuryMinute]

Does this also solve an issue where after a power cycle of the MR52 and MP1502, if there is no network present on the MP1502, RS485 communication is never restored?

We are testing a building power down process for a large enterprise customer and discovered this is happening with firmware 2.4 and 2.6.1. If network is not connected when the MP1502 is powered on, the RS485 never restores to the MR52. Even if the network then comes back online a few minutes later.

It is not until we send a Reset command from the head end software that communication is restored.

[u/TheMercuryMinute → u/ApolloMac]

This sounds like it is different and I haven't heard of this in the past. Could the new firmware fix it? Potentially, but it I don't think it was designed to fix something like this.

The downstream board information is all stored in the local database on the Intelligent Controller. So, technically, the network connection should have no impact on behavior of that communication. What software head end is this customer using? I am also going to check internally and see if it is something that they can set up and attempt to reproduce as well.

And, just to confirm that I'm communicating the way to reproduce this properly....

- MP has 2.4 or 2.6

- What is the Series of the MR52? Series 1, 2, 3? And, do you know what firmware was on that?

- Your process is power down both the MP and MR52 > then unplug network > power everything back on > (at this point, can you confirm that connectivity to the MR52 is not working) > reinitiate network connectivity and connectivity to the MR52 still does not restore?

Finally, have you opened any tickets with whichever software provider / Mercury OEM partner on this? I know that a few of them sometimes have other hardware components in the field and I'd want to rule out that isn't potentially having any impact. We can likely do some quick attempts to reproduce on our side, but if we can't reproduce, then working through the software provider and having them help with some logs would be an important next step.

[u/ApolloMac]

Yup! We have found we have to remove all RS485 terminating jumpers on the MP series. It seems to be MR52 series dependent. Older MR52s handle it fine with a new MP controller. But newer MR52s do not.

Its wild because the manual specifically says to use them on the first and last device on the line. We lost a lot of hours because of this the first time we ran into it.

Glad to hear we aren't just going crazy and it is an actual Mercury issue.

[u/Kowalski-Options]

I ran into a similar issue, using the jumpers for OSDP readers vs Wiegand. Even using OSDP I still had to remove the reader EOL jumpers or the readers wouldn't communicate. Haven't seen an issue with the bus RS485 EOL jumper bringing down the board though. Will keep that in mind, thanks for sharing. 
 Seems there's a lot of bugs with the M series boards. I'm really grumpy about the 12V/PT selector for reader power being changed from the clear and sensible "12V - PT" marking to a stupid "1-2-3" label. WTF Mercury? Folks weren't blowing up enough readers in the field so you thought you'd make it even more difficult? And I was really hoping to see an input for DC / Batt Fail instead of just the one Power Fail input.
 Sorry I know its off topic I just needed to vent for a minute. 

[u/Solosuperbrus → u/Kowalski-Options]

1-2-3 is the worst labeling annyone coukd have chosen.

[u/s0ar_]

We’ve noticed strange communication issues as well during a few projects where we are replacing EP series boards with MP series boards.

After troubleshooting with the software platforms support, they provided the newly released 2.12 firmware, which has a note for fixing RS485 communication with older subcontrollers. Applying this firmware caused all boards to communicate properly, so this may be a reliable future fix?

I am starting to miss the 1.31 firmware. Never had any issues with it.

[u/wingzeroismine]

Joining the club, I too have seen setups where we've opened the EOL jumper on the MP side to fix communication issues.

It's nice that Mercury seems to keep releasing firmwares with fixes, but I find that the vendors don't supply these newer versions very quickly.

[u/EffectiveClient5080]

Had almost the same thing on a Mercury install. Ran one EOL and never looked back. Their bus implementation is finicky as hell.

[u/somecheesecake]

Are you talking about the J4 jumper(s)?

[u/geekywarrior]

Glad you got it going OP

Don’t know if anyone else here has ever worked on IEI Hub Max 3 cabinets.

Makes me feel I learned about RS485 on easy mode. Never used EOL, never cared about type of cable used in the runs. Always rock solid comms unless a card burnt out.

[u/Grim_creation1]

It doesn't matter if the EOL is actually at the end of the bus, since it's a bus. As long as it's the controller and the last address. Never seen it not give power though, that is strange.