Menu

McQuay Troubleshooting Guide

Troubleshoot McQuay gateway integrations including wrong controller branch, incomplete OPM setup, and point-count tier issues.

Categories:

Overview

This guide covers the most common McQuay gateway failures Chipkin is likely to see: wrong controller-branch assumptions, wrong PCL type selection, incomplete OPM board settings, and point-count surprises discovered after the map is already built. Use it with the McQuay when exposing McQuay HVAC data into BACnet, Modbus, or another supervisory workflow.

Diagnostic Flow

  1. Confirm the exact equipment family and controller-board type.
  2. Confirm whether the setup uses a PCL branch or OPM branch.
  3. Confirm node, baud, parity, and password details.
  4. Confirm the requested point count against the gateway tier.
  5. Only then review target-side mapping.

Symptoms & Solutions

SymptomLikely CauseActionRelated Page
No useful communication startsThe wrong PCL type or board profile is selectedRecheck the exact McQuay controller type before changing downstream mappingMcQuay
OPM settings look close but the job still stays offlineNode, password, baud, or parity is wrong or incompleteValidate every OPM setup field against site documentationMcQuay
A proven McQuay config from another site still does not fitThe new unit is on a different controller branch or retrofit patternCompare controller family and object model before reusing the old templateFieldServer
The map builds but commissioning stops with point-limit messagesThe gateway tier is too small for the requested scopeRecheck total point count and apply the correct point-tier planQuickServer
A repeat project behaves differently than the last oneA previous config was reused without model-specific revalidationCompare the new unit against the prior project instead of assuming they matchFieldServer
Source-side values look right but BAS objects are still wrongThe target-side presentation now needs reviewRecheck BACnet or Modbus mapping after the source side is provenBACnet

The Wrong Controller Profile Was Chosen

McQuay jobs often fail at the very first protocol assumption.

Confirm The Actual Equipment Branch

Confirm:

  • Exact equipment model
  • Installed controller-board type
  • Whether the project expects PCL behavior or OPM behavior
  • Whether the current config matches that expectation

[!WARNING] Repeated no-response or nonsense-response behavior usually means the selected McQuay profile is wrong, not that the BAS target is the problem.

The OPM Setup Is Incomplete

OPM-oriented projects need more than a model name.

Rebuild The Source Settings

Look again at:

  • Node address
  • Baud rate
  • Parity
  • Device password
  • Any site-specific controller notes

If even one of these fields is missing, the project can spend days in avoidable trial-and-error.

The Previous Retrofit Template Was Over-Applied

Some McQuay jobs look similar because the equipment branding matches, but the controller branch does not.

Recheck The Retrofit Assumption

Look again at:

  • Whether the project is a BACdrop replacement, PCL setup, or OPM setup
  • Whether the prior object list came from the same controller family
  • Whether the source side is really serial, BACnet, or another branch entirely

[!WARNING] Do not keep tuning a reused McQuay config until you first prove that the current unit is on the same controller branch as the original reference project.

The Point Count Was Not Validated Up Front

This is a recurring commercial and technical failure pattern.

Separate Scope From License Tier

Confirm:

  • Total requested points
  • Current gateway tier
  • Whether optional points can be deferred
  • Whether the site expects full visibility or a smaller operational subset

If the requested point count is well above the default tier, solve that before deeper troubleshooting.

Quick Diagnostic Decision Tree

  • Start by confirming the equipment family and controller-board type.
    • If that is unclear: stop and collect it before further testing.
    • If it is clear: continue to source settings.
  • Check whether the job uses a PCL branch or OPM branch.
    • If that is unclear: resolve that first.
    • If it is clear: continue to source parameter validation.
  • Check whether node, baud, parity, and password details are all confirmed.
    • If not: rebuild the source setup first.
    • If yes: continue to point scope.
  • Check whether the project is being treated as the same controller branch as a previous McQuay job.
    • If not: re-verify the controller family and object model first.
    • If yes: continue to point scope.
  • Check whether the requested point count fits the deployed gateway tier.
    • If not: solve the tier issue before more mapping work.
    • If yes: continue to target-side validation.
  • Check whether the BAS values are still wrong after the source side is proven.
    • If yes: recheck BACnet or Modbus exposure.
    • If no: the main fault was on the McQuay source side.