Day 3: RS-485 / Modbus Pre-Commissioning

This module introduces candidates to the practical pre-commissioning of RS-485 networks and Modbus RTU field devices used within BMS installations.

Candidates will work with a live training network connected to the JACE controller and will configure, connect, prove and fault-find Modbus field devices.

The emphasis is on the responsibilities of the BMS pre-commissioning engineer. Candidates are not expected to engineer the Modbus integration. The network, device definitions and required Modbus points will already have been prepared within the JACE by the software engineer.

The candidate’s responsibility is to prove that the physical network and its field devices are correctly installed, configured from issued information, communicating and associated with the correct devices and points within the BMS.

The module progresses from a known healthy network through to deliberately introduced network faults that candidates must diagnose using a structured fault-finding process.

• Explain the basic purpose of an RS-485 network within a BMS.
• Recognise the basic physical arrangement of an RS-485 network.
• Identify Modbus RTU field devices from project information.
• Understand the purpose of Modbus slave addressing.
• Obtain required device settings from issued project information.
• Configure field devices with issued slave addresses and communication settings.
• Understand the purpose of network termination.
• Identify the physical end of an RS-485 network.
• Confirm that the required end-of-line (EOL) termination has been installed or enabled.
• Understand the purpose of a reference conductor where required.
• Connect a prepared field network to the JACE.
• Establish whether the expected Modbus devices are communicating.
• Carry out networked-device point-to-point verification.
• Distinguish between a healthy network and a network requiring investigation.
• Recognise common RS-485 and Modbus communication faults.
• Establish the physical network route.
• Use network segmentation to narrow the location of a fault.
• Rectify training faults and restore the intended network arrangement.
• Confirm that all expected devices communicate following rectification.
• Record defects and blockers identified during network pre-commissioning.

It is important that candidates understand the boundary between pre-commissioning and integration/software engineering.

For this course, the pre-commissioning engineer is responsible for:

• Physical RS-485 network readiness.
• Field device identification.
• Device addressing.
• Applying issued communication settings.
• Required EOL termination.
• Establishing communication.
• Proving physical device identity.
• Basic verification of associated points.
• Physical network fault finding.
• Recording defects and blockers.

The pre-commissioning engineer is not expected to:

• Create the Modbus driver.
• Engineer the Modbus network within Niagara.
• Interpret manufacturers’ register maps as part of integration engineering.
• Create or map Modbus registers.
• Configure data types.
• Engineer byte or word order.
• Develop control logic.
• Develop graphics.
• Modify the software engineer’s integration simply to make an incorrectly installed network work.

These subjects belong within later BMS commissioning and integration training.

RS-485 provides a means of allowing multiple field devices to communicate over a common network. Candidates should understand the physical concept rather than detailed communications theory.

A typical network may consist of:

Candidates should understand that:

• The network has a physical route.
• Multiple devices share the same communications network.
• Each device requires appropriate communication settings.
• The installation should follow the intended network topology.
• The physical end of the network must be identifiable.
• Network termination must follow the manufacturer/project requirements.
• A reference conductor may be required depending upon the equipment/network design.

The candidate does not need detailed mathematical or electronic theory behind RS-485. They need enough understanding to install, prove and fault-find the network correctly.

Before touching the network, the engineer should establish what has been designed.

Information may be obtained from:

• BMS I/O schedule.
• Equipment schedule.
• Network schedule.
• Installation drawings.
• Software engineer’s commissioning information.
• Device documentation.
• Existing JACE configuration where appropriate.

The candidate should establish:

• What devices should be present?
• What address should each device have?
• What communication settings have been issued?
• What network should the device be connected to?
• Where does the network start and finish?

These are issued settings. Candidates should not randomly change communication parameters until something starts communicating.

Each Modbus device requires a unique address appropriate to the configured network.

Training example:

• Sensor 1 = Address 11
• Sensor 2 = Address 12

Candidates should understand the effect of common errors such as:

• Duplicate addresses.
• Incorrect addresses.
• Incorrect baud rate.
• Incorrect parity.
• Device settings that do not correspond with the issued information.

The candidate should be able to physically inspect a device and establish its configured address/settings using the manufacturer’s intended method.

Before attempting communication, candidates prepare the network.

1. Identify the network.
2. Confirm the expected devices.
3. Apply the issued device addresses.
4. Apply the issued communication settings.
5. Establish the physical network end.
6. Confirm the required EOL termination is installed or enabled.
7. Confirm any required reference conductor arrangement.
8. Connect the network to the appropriate controller/interface.

End-of-Line Termination

Candidates should understand that termination is part of preparing the network for commissioning.

The course will not teach one resistor value as universally correct. The correct termination arrangement must follow the applicable manufacturer’s instructions, network design and project requirements.

The same principle applies to screen and reference conductor arrangements.

Once the network has been prepared, communication should be attempted.

Candidates should not automatically begin dismantling the network and checking every device connection before attempting communication.

The JACE may show:

• Device 11 – Online
• Device 12 – Online

If all expected devices communicate correctly, this provides significant evidence that the physical network is functioning.

A healthy communicating network should not be unnecessarily disturbed.

If devices do not communicate correctly, structured investigation begins.

Candidates are provided with the required network information. The software integration within the JACE has already been prepared.

Each candidate must:

1. Identify the correct physical devices.
2. Identify the required addresses from the issued schedule.
3. Configure the first sensor.
4. Configure the second sensor.
5. Apply the required communication settings.
6. Identify the network end.
7. Confirm the required EOL arrangement.
8. Connect/enable the network.
9. Attempt communication.
10. Confirm that both expected devices appear online within the JACE.

A communicating device is not, by itself, complete proof that the correct physical device has been associated with the correct BMS device.

Two identical sensors may both show believable room temperatures.

Both readings appear reasonable. That does not positively establish which physical sensor is Device 11 and which is Device 12.

Candidates carry out point-to-point verification on the two Modbus sensors.

For Sensor 12:

1. Locate the physical sensor.
2. Confirm its issued identity/address.
3. Locate Device 12 within the JACE.
4. Observe the live temperature.
5. Apply a safe controlled change to the physical sensor, such as gently warming it by hand where appropriate.
6. Observe the temperature response within the JACE.
7. Confirm the Device 12 temperature responds.
8. Confirm Device 11 has not been mistaken for Device 12.
9. Allow the reading to return towards normal.
10. Repeat as required for Sensor 11.

This is the network equivalent of conventional hardwired point-to-point verification.

The candidate is proving device identity and association, not engineering the Modbus register.

Candidates are now introduced to network fault diagnosis.

Possible symptoms include:

• Entire network offline.
• Single device offline.
• Several devices offline.
• Devices downstream of a particular point offline.
• Intermittent communication.
• Unexpected device identity.
• Device online but associated with the wrong physical location.

Potential causes may include:

• Incorrect address.
• Duplicate address.
• Incorrect baud rate or parity.
• Missing EOL termination.
• Incorrect intermediate termination.
• Open A/B conductor.
• Reversed polarity.
• Reference conductor issue where applicable.
• Incorrect physical connection.
• Problematic device affecting network communication.

The engineer should diagnose from the symptoms rather than randomly altering settings.

Before segmenting a network, establish its physical route.

Where available, obtain the network installation drawing produced or used by the installation electrician.

If suitable information is unavailable, the engineer may need to physically walk the installation and establish the logical network order.

Knowing the route dramatically improves fault-finding efficiency.

Network segmentation allows the engineer to progressively reduce the section being investigated.

Consider a 30-device network.

Step 1: Temporarily reduce the active network to Devices 1–10. If Devices 1–10 communicate correctly, the engineer has established that the problem is likely further downstream.

Step 2: Extend to Device 20. If communication now fails, attention can be concentrated on Devices 11–20.

Step 3: Divide that section into 11–15 and 16–20, continuing until the affected device or cable section has been identified.

There is no fixed requirement to segment networks into exactly five or ten devices. The engineer should select sensible break points based upon:

• Physical network route.
• Accessibility.
• Number of devices.
• Installation arrangement.
• Available drawings.

Temporary Network End

When the network is shortened during fault finding, consideration must be given to the new temporary end of the active network and whether temporary termination is required in accordance with the applicable network requirements.

After testing, the intended network configuration and final EOL arrangement must be restored.

Where the candidate cannot complete network pre-commissioning, the issue must be clearly recorded.

Defect Example

Modbus Sensor 12 configured with incorrect slave address. Issued address 12; device found configured as address 14. Address corrected and communication restored.

Installation Defect Example

RS-485 A conductor open circuit between Sensors 06 and 07. Devices 01–06 communicating. Devices 07 onwards unavailable. Cable requires rectification.

Blocker Example

RS-485 network installation incomplete beyond Sensor 08. Devices downstream cannot be commissioned until BMS installation works are completed.

Avoid comments such as “Modbus not working.” The record should allow another engineer to understand what has been established.

Detailed completion of commissioning records is covered later in the final documentation module.

Obtain issued information → Address devices → Apply issued communication settings → Confirm EOL termination → Attempt communication → Prove device association → Fault-find only where required → Segment logically → Rectify → Restore → Verify all expected devices

The module deliberately stops before Modbus integration engineering. Advanced integration, register mapping, data handling and software development remain suitable subjects for a separate follow-on BMS commissioning and integration course.