No, the LonWorks devices PCD2.F240, PCD3.F2400 and PCD7.R582 are no longer available.

The production of the LonWorks interface devices PCD2.F240, PCD3.F2400 and the LonWorks memory device PCD7.R582 was discontinued at the end of 2021 and the devices are no longer available.

As a replacement, we recommend the usage of BACnet.

Yes, it’s possible to connect up to 16 MP-Bus devices per MP-Bus line and the PCD supports the MP-Bus light protocol.

Belimo has enhanced the functionality of the MP-Bus in that way that, in some conditions, it’s possible to connect up to 16 devices on the same MP-Bus.

The devices which support this feature are named MPL/MPX or/and Belimo MP-Bus light.

SBC has adapted their Belimo PG5 FBox library to support up to 16 devices per MP-Bus line.

On Fupla, on the FBox selector window the FBox which supports the address range 1 to 16 are selectable from the category ‘MP-Bus’, ‘MPX Devices 1- 16’.

This means, that a PCD could handle up to 128 Belimo devices, if on all 8 possible MB-Bus lines of the PCD, only MPX devices would be connected.

MP and MPX Addressing
The 16-address feature was introduced since the library version 2.7.527

Remarks:
1.
The Duplex Driver Fbox for the PCD2.T500 module supports only the MP address range (1-8).
2.
The Single Driver Fbox supports the MP address range (1-8) as well as the MPX range (1-16) by respecting the following rules.

• You can use addresses up to 16 if you have only MPX devices on the MP-Bus.
• You can mix up old MP and new MPX devices as long as all devices are in the address range 1 to 8.
• You can use 2 buses, one for the old MP devices (1-8), One for new MPX devices (1-16)

Consequently:

• If more then 8 (up to 16) devices should be connected on a MP-Bus line, then only MPX devices can be used on this the MP-Bus line.
• You cannot mix up old MP devices with new MPX devices using addresses in range 9 to 16 on the same bus.
• In other words, as long as one old MP device is on the bus the address range is limited to 1-8.
  
  

Yes, it’s possible to connect up to 16 MP-Bus devices per MP-Bus line and the PCD supports the MP-Bus light protocol.

Belimo has enhanced the functionality of the MP-Bus in that way that, in some conditions, it’s possible to connect up to 16 devices on the same MP-Bus.

The devices which support this feature are named MPL/MPX or/and Belimo MP-Bus light.

SBC has adapted the Belimo PG5 FBox library to support up to 16 devices per MP-Bus line.

On Fupla, on the FBox selector window the FBox which supports the address range 1 to 16 are selectable from the category ‘MP-Bus’, ‘MPX Devices 1- 16’.

This means, that a PCD could handle up to 128 Belimo devices, if on all 8 possible MB-Bus lines of the PCD, only MPX devices would be connected.

MP and MPX Addressing
The 16-address feature was introduced since the library version 2.7.527

Remarks:
1.
The Duplex Driver Fbox for the PCD2.T500 module supports only the MP address range (1-8).
2.
The Single Driver Fbox supports the MP address range (1-8) as well as the MPX range (1-16) by respecting the following rules.

• You can use addresses up to 16 if you have only MPX devices on the MP-Bus.
• You can mix up old MP and new MPX devices as long as all devices are in the address range 1 to 8.
• You can use 2 buses, one for the old MP devices (1-8), One for new MPX devices (1-16)

Consequently:

• If more then 8 (up to 16) devices should be connected on a MP-Bus line, then only MPX devices can be used on this the MP-Bus line.
• You cannot mix up old MP devices with new MPX devices using addresses in range 9 to 16 on the same bus.
• In other words, as long as one old MP device is on the bus the address range is limited to 1-8.

Under certain conditions it’s possible that the configuration of the DALI devices with the F-Box ‘Dali Cfg Manger’ doesn’t work correctly.

Definition or changing of the DALI address of the DALI device, setting up the DALI parameters in the DALI device doesn’t work properly, then new values are not stored on the DALI device.

Description of the error:
Under certain conditions it’s possible that the configuration of the DALI devices with the F-Box ‘Dali Cfg Manger’ doesn’t work correctly.
Definition or changing of the DALI address of the DALI device, setting up the DALI parameters in the DALI device doesn’t work properly, then new values are not stored on the DALI device.

This behavior happens, if the transmission of the configuration telegrams from the PCD to the DALI devices takes to long time.
This situation could occur if the cycle time of the application program on the PCD is to long or if the PCD does use need some cycle time for other tasks (like BACnet communication)

To tests if the configuration is written correctly in to the DALI device, just read out the DALI parameters from the device after the writing of the parameters and compare this value with the previously written  value.

Solution:
We have fixed the problem in that way, that we do now handle the configuration telegrams directly in the PCD2.F2610 or PCD3.F261 DALI communication module.

The FW of the F2610/F261 module have to be at least the version 1.03.23.

The DALI configuration F-Box was also adapted to support the new firmware of the F2610/F261 module.
Use at least the ‘Dali-F26x’ Library version $2.7.358 or higher.

Technical reason:
The DALI specification does define for the configuration telegrams which have to be send to the DALI devices, that this configuration telegram have to be send two times to the DALI device.

The time delay between the first and the second configuration telegram has not to be longer then 100ms.

If the delay is > 100ms then the DALI devices does not accept the new configuration and does use the old parameters.

The RS-232 S-Bus communication may doesn't work at all with PCD2.F2xx0 or PCD3.F2xx modules when communicating over converters (like modem or optical converters) to other devices. On PCD2.F2xx0 and PCD3.F2xx with Firmware less or equal V020 the handling of the RTS signal is wrong.

Symptom
Due of a Firmware error on the PCD2.F2xx0 and PCD3.F2xx module (with Firmware of the PCD2.F2xx0/PCD3.F2xx module: less or equal V020) it may be, that the S-Bus communication over converters (like modem or optical converters) to other devices does not work.

The S-Bus communication works fine, if no converters are used in between.
Also other communications protocols then S-Bus like "Mode C, Modbus" works fine on the PCD2.F2xx0 and PCD3.F2xx module (with and without converters in between).

On the print screen below, the signal 1 is RTS and signal 2 is the dataflow.
With PCD3.F121, the RTS signal behaves correctly, with PCD2.F2xx0 or PCD3.F221 not.

Communication with PCD3.F121


Communication with PCD3.F221


Workaround to use the RS-232 S-Bus communication over converters:
For the PCD3:
Instead of using a PCD3.F221, use the PCD3.F121.

For PCD1.M2 or PCD2.M5:
Instead of using a PCD2.F2xx0, use the PCD7.F121S.

Solution
The Firmware version 1.xx.xx of the module PCD2.F2xx0 or PCD3.F2xx will solve this bug with the handling of the RTS signal. Please contact your local SBC Support center.

When reading values from some specific M-Bus devices with the M-Bus modules PCD2/3.F27xx, the M-Bus driver may show the error "Missing value" even though all values are correctly returned by the device.

Symptom
When using the M-Bus modules PCD2/3.F27xx (with the framing protocol), the M-Bus driver may display the error "Missing value" even though all values are correctly returned. The problem concerns only few devices; so far the following concerned devices are known:

• Janitza, electricity counter
• EMU Professional, electricity counter
• L&G Ultraheat 50, heating counter

Reason
This problem occurs because the PCD firmware (older than 1.16.66) looses some bytes if the reply telegrams is longer than 240 bytes (and the framing protocol is used).

Solution
This problem is corrected in the PCD firmware version 1.16.66 and later. This firmware is e.g. contained in the BACnet firmware package available on the Support Site (under "Communication Protocols" --> "BACnet")

The M-Bus communication between the "Hydrometer M-Bus Receiver 868" (alternatively called "MB-Receiver") and the PCD2.F2710 has been analyzed and it was found that the device does not conform to the M-Bus specification (SN EN 13757-2). Therefore it can not be used together with the PCD2/3.F27x(0).

During our analysis it was found that the power consumption variation of the "Hydrometer M-Bus Receiver 868" while receiving data is higher than specified in the M-Bus specification. This leads to the fact that the communication between the F271x and the "Hydrometer M-Bus Receiver 868" receiver is not working.
Note that the manufacturer is explicitly specifying that this device is only to be used with "his" M-Bus master, see screenshot below.

Detailed information
Analyzed Radio Receiver: Hydrometer M-Bus Receiver 868
The device takes the power from the M-Bus communication lines; current consumption is around 20mA (instead of max. 1.5mA). So far, this is no problem as long as the device is counted as ~13x load. But when sending data on the M-Bus lines, the current consumption of this slave changes by more than 10mA, and this change is seen as incoming data on the M-Bus master side.

The M-Bus standard SN EN 13757-2 specifies:
Voltage variation of 1..15V shall not change the bus current by more than Nx3uA/V. N must be specified, values in the range from 1 to 4 are allowed. Max. change with SBC M-Bus master: 12V*4*3uA/V = 144uA.

Conclusion
The "Hydrometer M-Bus Receiver 868" does not comply with M-Bus standard. (and its manufacturer specifies that this Receiver has to be used only with their master devices). Therefore it can be (by chance) that it works with third party master devices. With the F27x modules the functionality is not guaranteed (guaranteed functionality would require a hardware redesign of the F27x to support the special device).

Remark
In Germany the "Hydrometer M-Bus Receiver 868" is distributed by Hydrometer while in Switzerland it is distributed by Techem and in France the same device is distributed by the company Sappel under the name "IZAR".

In order to read data from "CALEC aquameter energy master" devices using the F27x modules (except PCD2.F2700 or PCD3.F270) the M-Bus FBox library 2.6.117 or later is required.

Symptom
When trying to read data from a "CALEC aquametro energy master" device using e.g. a PCD3.F271 and the M-Bus FBox library (older than version 2.6.117) from Engiby a timeout is the result. This is only the case with the aquametro device, other M-Bus devices can be read correctly.

Reason
The Engiby M-Bus FBox library (older than version 2.6.117) does not read correctly from the CALEC device if the framing protocol (used for the modules PCD2.F2710 or a PCD3.F271) is configured. On the other hand data are read correctly if the character mode is configured with an F270(0) (to be selected with "RS 485/F270" as Serial line type in the M-Bus driver FBox).

Solution

• Update your M-Bus library to version 2.6.117 or later (please request the library directly from Engiby)
• If it is not possible updating the FBox library it is also possible accessing the "CALEC aquametro" using a  PCD3.F270 (or a PCD2.F2700) and configure it to use the character mode (see screenshot below) in the FBox "MBus Driver":
  

There is a possibility to update the firmware of a PCD2.F2xxx or PCD3.F2xx, in this FAQ it is explained how to proceed.

In general the procedure is the same like you would update the firmware of a PCD3. Connect the computer via USB to the PLC and start the PG5 2.0 Firmware Downloader. Change the file for the download to the required .bin file and start the download in USB PGU mode.

Problem

When more than one PCD2.F2xxx or PCD3.F2xx is plugged in the PLC there can appear some error messages.

Solution

In this case you have to specify the Slot in which the Module is plugged which you want to download the firmware into. This is made in the Options of the Firmware Downloader “Select SPI Slot…”

When choosing in which Slot you want to download the firmware you can make sure that the right module is updated, if “No Options is selected it will try to download the firmware to the first PCD2.F2xxx or PCD3.F2xx which is found on the I/O Bus.


Remark
The minimal system requirements are:
PG5 2.0.200
PCD Firmware 1.16.48
 
Modules supporting a firmware update:
PCD2.F26xx
PCD2.F27xx
PCD3.F26x
PCD3.F27x

In the M-Bus library for the SBC Energy Meters (which can be installed for PG5 1.4, PG5 2.0 and PG5 2.1) the following modifications have been applied.

Modification in the SBC MBus library 2.7.006 (March 2013)

• Added support for PG5 2.1
• Removed the option "BACnet"
  

Modification in the SBC MBus library 2.6.113 (December 2011)

• Added outputs of the FBox: total active power and total reactive power is now provided

Modification in the SBC MBus library 2.6.104 (July 2011)

• A negative reactive power measured by SBC M-Bus Energy Meters was displayed incorrectly
• Support of the new modules PCD2/3.F271(0), F272(0) and F273(0)
  If you use such a module, please configure the "Serial line" in the driver FBox to "M-Bus/F27xx" and ensure you have the firmware 1.16.52 or later on the PCD.
  With older library version, you don’t have this option and you can only use the modules PCD2/3.F270(0) with the mode "RS485/F270".

• With the M-Bus library 2.6.013 the driver sent M-Bus resets repetitively
• With older versions than 2.6.014 the SBC M-Bus Energy Meters were not always correctly connected.

• There exist two libraries for M-Bus:
  - The "full version" from Engiby
    which supports all the M-Bus Energy meters from SBC, but also from other manufacturers
  - the "SBC version"
    which supports only the M-Bus Energy meters from SBC.
• The "SBC version" is available from the support site;
  for the "Engiby version" please contact Engiby in order to obtain the last version. www.engiby.ch 
• Please do install the "SBC version" or the "Engiby version" but not both in parallel; this could lead to inconsistent file combinations.

Some M-Bus devices (so far only observed on a MBus water counter from the company Allmess / Actris) are very sensitive against inter-character delays.

Symptom
Some M-Bus devices connected to a PCD2.F2xxx or a PCD3.F2xx (or on the ports listed below under "Remark") are not answering to all requests. The same device does work fine when the M-Bus gateway is connected to another port (e.g. on port 0 of the PCD2.M5). 

Reason
The reason for this phenomenon could be that the M-Bus device is very sensitive against inter-character delays in the telegrams.

Solution
In order to avoid the inter-character delays a new feature has been implemented in the firmware of the PCD (the freeze bit, see FAQ 100916). The M-Bus library 2.5.203 from Engiby does work with this mechanism and thus avoids the inter-character delays in the telegrams.

Remark
With firmware 1.10.16 it has been observed that such inter-character delays are present in telegrams sent on the ports listed below even when using the freeze-mode mentioned:

• PCD2.M5xxx: port 2 and port 3
• PCD3.Mxxxx: port 0 and port 3

In order to avoid these inter-character delays, please use firmware 1.10.51 for your PCD2.M5xx0 or PCD3. This firmware can be downloaded from the according product section on the support site www.sbc-support.ch.

A hardware conflict on a PCD2.M5xxx between a PCD2.W3x0 plugged to I/O slot 3 and the modules PCD2.F2xx0 and PCD2.R6000 leads to the fact that the communication- and memory modules do not work in this constellation. If the PCD2.W3x0 is removed from the I/O slot 3 the installation is working correctly.

Symptom
In case a PCD2.W3x0 analogue input module is plugged in the I/O slot 3 (base address 48) the communication modules PCD2.F2xx0 and the memory modules PCD2.R6000 do not work.
The LEDs on a communication module PCD2.F2100, a PCD2.F2210 or a PCD2.F2810 are lit 50% red and 50% green (blinking). The file system of the PCD2.R6000 (SLxFLASH:/) are not visible over e.g. FTP. Only PCD2.M5xxx with hardware version older than C345 are concerned.

Reason
The reason for this behavior is a conflict between the PCD2.W3x0 (PCD2.W300, PCD2.W310, PCD2.W340, PCD2.W350, PCD2.W360) and the PCD2.F2xx0 or R6000. This conflict exists only if the PCD2.W3x0 is plugged on the I/O slot 3 (base address 48).

Solution

• This conflict is no longer present with hardware version C345 of the PCD2.M5xxx (the according filter of the I/O bus has been adapted in order not to lead to this conflict).  
• In case it is not possible to replace the system immediately (or send it to the repair service for having this modification done), the problem can be solved by not using a PCD2.W30x in the I/O slot 3. If the communication module or the memory module is plugged into I/O slot 3 the installation will work correctly.

When more than 1 displays of the same type (PCD7.D23x and PCD7.D290) are connected to a RS 485 port (Bus terminal) of a PCDx.F2xx module, the communication doesn't work. Only one of the displays is available, the other one(s) is (are) not accessible!

The ports 100 to 131 available on the PCDx.F2xx modules have different timing properties and are therefore not appropriate for PCD7.D23x and PCD7.D290 in bus terminal topoloy!

Workaround:
Use another RS 485 port (onboard or with F1xx).

The diagnostic flag TBSY of the "Character Mode" (used for sending characters over a serial line) is not handled the same way on a PCD3 compared to "older" systems like e.g. PCD2.M170.

Symptom
If the relevant port is assigned in MC mode, the diagnostic flag TBSY is indicating that the serial port is busy sending characters. This is the case on e.g. a PCD2.M170.
This behaviour is not the same on a PCD2.M5xxx or a PCD3.Mxxxx, especially not when using a PCD3.F121 or a F2xx(x) modules. On a PCD3/PCD2.M5 the TBSY flag is not any more high during the whole time the port is busy. Instead, it is only high a short time at the very beginning of the send task.

Reason
The reason for this difference is a new manner to access the UART of the port. On older systems the characters were directly written to the UART while on the PCD3 a buffer is placed in-between. Instead of indicating the "send-state" of the UART like on older systems, the TBSY represents the state of this buffer (the size can be found at the end of this FAQ) on the PCD3 or the PCD2.M5.

Solution
This difference shouldn't lead to problem is most cases. However, in some applications the state of the TBSY is used to control e.g. the RTS signal of the line (using the instruction SOCL). In this case the communication (working on a PCD2.M170) won't work any more on a PCD3 or a PCD2.M5.
In this situation one of the following workarounds could be applied:

• Instead of assigning the port in MC0 it could be assigned in MC4 (MC4 is usually described as "MC for RS485"). In this mode the UART is managing the RTS autonomously (and therefore there is no more need to set the RTS by the user program). Note that in this case the SOCL commands are to be removed from the program!
• The duration while the RTS is to be set could be calculated beforehand (based on the amount of characters to be sent) and loaded into a timer. While this timer is high, the RTS can be set using the SOCL command.
  Note that this solution is not really a "nice" one and can only work with very low baud rates.

Notes

• All firmware versions of the PCD3xxx and PCD2.M5xxx do treat the TBSY as described in this FAQ.
• The buffer size is depending on the port used:
  PCD3 port 1 and 2: 24 characters
  PCD3 port 0 and 3:  2 characters
  PCD2.M5 port 0 and 1: 24 characters
  PCD2.M5 port 2 and 3:  2 characters
  

No, the LonWorks devices PCD2.F240, PCD3.F2400 and PCD7.R582 are no longer available.

The production of the LonWorks interface devices PCD2.F240, PCD3.F2400 and the LonWorks memory device PCD7.R582 was discontinued at the end of 2021 and the devices are no longer available.

As a replacement, we recommend the usage of BACnet.

The problem may be related to a loose contact on the PCD3.K010 connectors used to connect the PCD3.M/Txxx CPU's and the PCD3.Cxxx expansion modules.

In this case, various error patterns may occur, such as

• - If an input is set to 1, then several inputs are set to 1 at the same time.
• - If an output is set to 1 in the application program, then the output is not set on the output module.
• - The status of the inputs is not correctly recognised in the application program.

The affected PCD3.K010 modules have a manufacturing date of 2028 (year 2020, week 28).

If the symptoms described above occur and a PCD3.K010 module with fabrication date 2028 is used, replace the PCD3.K010 module with a new PCD3.K010 module.

Order new PCD3.K010 modules and create an RMA request with the error description and the remark: CRABBMS-430 and select the option 'Advanced replacement'.

The date of manufacture can be seen on the white sticker on the PCD3.K010.

Yes, it’s possible to connect up to 16 MP-Bus devices per MP-Bus line and the PCD supports the MP-Bus light protocol.

Belimo has enhanced the functionality of the MP-Bus in that way that, in some conditions, it’s possible to connect up to 16 devices on the same MP-Bus.

The devices which support this feature are named MPL/MPX or/and Belimo MP-Bus light.

SBC has adapted their Belimo PG5 FBox library to support up to 16 devices per MP-Bus line.

On Fupla, on the FBox selector window the FBox which supports the address range 1 to 16 are selectable from the category ‘MP-Bus’, ‘MPX Devices 1- 16’.

This means, that a PCD could handle up to 128 Belimo devices, if on all 8 possible MB-Bus lines of the PCD, only MPX devices would be connected.

MP and MPX Addressing
The 16-address feature was introduced since the library version 2.7.527

Remarks:
1.
The Duplex Driver Fbox for the PCD2.T500 module supports only the MP address range (1-8).
2.
The Single Driver Fbox supports the MP address range (1-8) as well as the MPX range (1-16) by respecting the following rules.

• You can use addresses up to 16 if you have only MPX devices on the MP-Bus.
• You can mix up old MP and new MPX devices as long as all devices are in the address range 1 to 8.
• You can use 2 buses, one for the old MP devices (1-8), One for new MPX devices (1-16)

Consequently:

• If more then 8 (up to 16) devices should be connected on a MP-Bus line, then only MPX devices can be used on this the MP-Bus line.
• You cannot mix up old MP devices with new MPX devices using addresses in range 9 to 16 on the same bus.
• In other words, as long as one old MP device is on the bus the address range is limited to 1-8.
  
  

Yes, it’s possible to connect up to 16 MP-Bus devices per MP-Bus line and the PCD supports the MP-Bus light protocol.

Belimo has enhanced the functionality of the MP-Bus in that way that, in some conditions, it’s possible to connect up to 16 devices on the same MP-Bus.

The devices which support this feature are named MPL/MPX or/and Belimo MP-Bus light.

SBC has adapted the Belimo PG5 FBox library to support up to 16 devices per MP-Bus line.

On Fupla, on the FBox selector window the FBox which supports the address range 1 to 16 are selectable from the category ‘MP-Bus’, ‘MPX Devices 1- 16’.

This means, that a PCD could handle up to 128 Belimo devices, if on all 8 possible MB-Bus lines of the PCD, only MPX devices would be connected.

MP and MPX Addressing
The 16-address feature was introduced since the library version 2.7.527

Remarks:
1.
The Duplex Driver Fbox for the PCD2.T500 module supports only the MP address range (1-8).
2.
The Single Driver Fbox supports the MP address range (1-8) as well as the MPX range (1-16) by respecting the following rules.

• You can use addresses up to 16 if you have only MPX devices on the MP-Bus.
• You can mix up old MP and new MPX devices as long as all devices are in the address range 1 to 8.
• You can use 2 buses, one for the old MP devices (1-8), One for new MPX devices (1-16)

Consequently:

• If more then 8 (up to 16) devices should be connected on a MP-Bus line, then only MPX devices can be used on this the MP-Bus line.
• You cannot mix up old MP devices with new MPX devices using addresses in range 9 to 16 on the same bus.
• In other words, as long as one old MP device is on the bus the address range is limited to 1-8.

Under certain conditions it’s possible that the configuration of the DALI devices with the F-Box ‘Dali Cfg Manger’ doesn’t work correctly.

Definition or changing of the DALI address of the DALI device, setting up the DALI parameters in the DALI device doesn’t work properly, then new values are not stored on the DALI device.

Description of the error:
Under certain conditions it’s possible that the configuration of the DALI devices with the F-Box ‘Dali Cfg Manger’ doesn’t work correctly.
Definition or changing of the DALI address of the DALI device, setting up the DALI parameters in the DALI device doesn’t work properly, then new values are not stored on the DALI device.

This behavior happens, if the transmission of the configuration telegrams from the PCD to the DALI devices takes to long time.
This situation could occur if the cycle time of the application program on the PCD is to long or if the PCD does use need some cycle time for other tasks (like BACnet communication)

To tests if the configuration is written correctly in to the DALI device, just read out the DALI parameters from the device after the writing of the parameters and compare this value with the previously written  value.

Solution:
We have fixed the problem in that way, that we do now handle the configuration telegrams directly in the PCD2.F2610 or PCD3.F261 DALI communication module.

The FW of the F2610/F261 module have to be at least the version 1.03.23.

The DALI configuration F-Box was also adapted to support the new firmware of the F2610/F261 module.
Use at least the ‘Dali-F26x’ Library version $2.7.358 or higher.

Technical reason:
The DALI specification does define for the configuration telegrams which have to be send to the DALI devices, that this configuration telegram have to be send two times to the DALI device.

The time delay between the first and the second configuration telegram has not to be longer then 100ms.

If the delay is > 100ms then the DALI devices does not accept the new configuration and does use the old parameters.

Those M-Bus cards have a short-cut protection on the bus but when the CPU isn't anymore power supplied and the F27x(x) card still has 24 V supply there is no short cut protection anymore!

Reason:

The 36 Volts from the M-Bus will destroy some components on the concerned serial port of the card!

Solution:

Use the same power supply for the CPU as for the PCDx.F27x(x) card or if for some reason a different power supply has to be used be aware that in case the CPU isn't power supplied that the M-Bus is NOT short-circuited!

The RS-232 S-Bus communication may doesn't work at all with PCD2.F2xx0 or PCD3.F2xx modules when communicating over converters (like modem or optical converters) to other devices. On PCD2.F2xx0 and PCD3.F2xx with Firmware less or equal V020 the handling of the RTS signal is wrong.

Symptom
Due of a Firmware error on the PCD2.F2xx0 and PCD3.F2xx module (with Firmware of the PCD2.F2xx0/PCD3.F2xx module: less or equal V020) it may be, that the S-Bus communication over converters (like modem or optical converters) to other devices does not work.

The S-Bus communication works fine, if no converters are used in between.
Also other communications protocols then S-Bus like "Mode C, Modbus" works fine on the PCD2.F2xx0 and PCD3.F2xx module (with and without converters in between).

On the print screen below, the signal 1 is RTS and signal 2 is the dataflow.
With PCD3.F121, the RTS signal behaves correctly, with PCD2.F2xx0 or PCD3.F221 not.

Communication with PCD3.F121


Communication with PCD3.F221


Workaround to use the RS-232 S-Bus communication over converters:
For the PCD3:
Instead of using a PCD3.F221, use the PCD3.F121.

For PCD1.M2 or PCD2.M5:
Instead of using a PCD2.F2xx0, use the PCD7.F121S.

Solution
The Firmware version 1.xx.xx of the module PCD2.F2xx0 or PCD3.F2xx will solve this bug with the handling of the RTS signal. Please contact your local SBC Support center.

When reading values from some specific M-Bus devices with the M-Bus modules PCD2/3.F27xx, the M-Bus driver may show the error "Missing value" even though all values are correctly returned by the device.

Symptom
When using the M-Bus modules PCD2/3.F27xx (with the framing protocol), the M-Bus driver may display the error "Missing value" even though all values are correctly returned. The problem concerns only few devices; so far the following concerned devices are known:

• Janitza, electricity counter
• EMU Professional, electricity counter
• L&G Ultraheat 50, heating counter

Reason
This problem occurs because the PCD firmware (older than 1.16.66) looses some bytes if the reply telegrams is longer than 240 bytes (and the framing protocol is used).

Solution
This problem is corrected in the PCD firmware version 1.16.66 and later. This firmware is e.g. contained in the BACnet firmware package available on the Support Site (under "Communication Protocols" --> "BACnet")

The M-Bus communication between the "Hydrometer M-Bus Receiver 868" (alternatively called "MB-Receiver") and the PCD2.F2710 has been analyzed and it was found that the device does not conform to the M-Bus specification (SN EN 13757-2). Therefore it can not be used together with the PCD2/3.F27x(0).

During our analysis it was found that the power consumption variation of the "Hydrometer M-Bus Receiver 868" while receiving data is higher than specified in the M-Bus specification. This leads to the fact that the communication between the F271x and the "Hydrometer M-Bus Receiver 868" receiver is not working.
Note that the manufacturer is explicitly specifying that this device is only to be used with "his" M-Bus master, see screenshot below.

Detailed information
Analyzed Radio Receiver: Hydrometer M-Bus Receiver 868
The device takes the power from the M-Bus communication lines; current consumption is around 20mA (instead of max. 1.5mA). So far, this is no problem as long as the device is counted as ~13x load. But when sending data on the M-Bus lines, the current consumption of this slave changes by more than 10mA, and this change is seen as incoming data on the M-Bus master side.

The M-Bus standard SN EN 13757-2 specifies:
Voltage variation of 1..15V shall not change the bus current by more than Nx3uA/V. N must be specified, values in the range from 1 to 4 are allowed. Max. change with SBC M-Bus master: 12V*4*3uA/V = 144uA.

Conclusion
The "Hydrometer M-Bus Receiver 868" does not comply with M-Bus standard. (and its manufacturer specifies that this Receiver has to be used only with their master devices). Therefore it can be (by chance) that it works with third party master devices. With the F27x modules the functionality is not guaranteed (guaranteed functionality would require a hardware redesign of the F27x to support the special device).

Remark
In Germany the "Hydrometer M-Bus Receiver 868" is distributed by Hydrometer while in Switzerland it is distributed by Techem and in France the same device is distributed by the company Sappel under the name "IZAR".

In order to read data from "CALEC aquameter energy master" devices using the F27x modules (except PCD2.F2700 or PCD3.F270) the M-Bus FBox library 2.6.117 or later is required.

Symptom
When trying to read data from a "CALEC aquametro energy master" device using e.g. a PCD3.F271 and the M-Bus FBox library (older than version 2.6.117) from Engiby a timeout is the result. This is only the case with the aquametro device, other M-Bus devices can be read correctly.

Reason
The Engiby M-Bus FBox library (older than version 2.6.117) does not read correctly from the CALEC device if the framing protocol (used for the modules PCD2.F2710 or a PCD3.F271) is configured. On the other hand data are read correctly if the character mode is configured with an F270(0) (to be selected with "RS 485/F270" as Serial line type in the M-Bus driver FBox).

Solution

• Update your M-Bus library to version 2.6.117 or later (please request the library directly from Engiby)
• If it is not possible updating the FBox library it is also possible accessing the "CALEC aquametro" using a  PCD3.F270 (or a PCD2.F2700) and configure it to use the character mode (see screenshot below) in the FBox "MBus Driver":
  

There is a possibility to update the firmware of a PCD2.F2xxx or PCD3.F2xx, in this FAQ it is explained how to proceed.

In general the procedure is the same like you would update the firmware of a PCD3. Connect the computer via USB to the PLC and start the PG5 2.0 Firmware Downloader. Change the file for the download to the required .bin file and start the download in USB PGU mode.

Problem

When more than one PCD2.F2xxx or PCD3.F2xx is plugged in the PLC there can appear some error messages.

Solution

In this case you have to specify the Slot in which the Module is plugged which you want to download the firmware into. This is made in the Options of the Firmware Downloader “Select SPI Slot…”

When choosing in which Slot you want to download the firmware you can make sure that the right module is updated, if “No Options is selected it will try to download the firmware to the first PCD2.F2xxx or PCD3.F2xx which is found on the I/O Bus.


Remark
The minimal system requirements are:
PG5 2.0.200
PCD Firmware 1.16.48
 
Modules supporting a firmware update:
PCD2.F26xx
PCD2.F27xx
PCD3.F26x
PCD3.F27x

In the M-Bus library for the SBC Energy Meters (which can be installed for PG5 1.4, PG5 2.0 and PG5 2.1) the following modifications have been applied.

Modification in the SBC MBus library 2.7.006 (March 2013)

• Added support for PG5 2.1
• Removed the option "BACnet"
  

Modification in the SBC MBus library 2.6.113 (December 2011)

• Added outputs of the FBox: total active power and total reactive power is now provided

Modification in the SBC MBus library 2.6.104 (July 2011)

• A negative reactive power measured by SBC M-Bus Energy Meters was displayed incorrectly
• Support of the new modules PCD2/3.F271(0), F272(0) and F273(0)
  If you use such a module, please configure the "Serial line" in the driver FBox to "M-Bus/F27xx" and ensure you have the firmware 1.16.52 or later on the PCD.
  With older library version, you don’t have this option and you can only use the modules PCD2/3.F270(0) with the mode "RS485/F270".

• With the M-Bus library 2.6.013 the driver sent M-Bus resets repetitively
• With older versions than 2.6.014 the SBC M-Bus Energy Meters were not always correctly connected.

• There exist two libraries for M-Bus:
  - The "full version" from Engiby
    which supports all the M-Bus Energy meters from SBC, but also from other manufacturers
  - the "SBC version"
    which supports only the M-Bus Energy meters from SBC.
• The "SBC version" is available from the support site;
  for the "Engiby version" please contact Engiby in order to obtain the last version. www.engiby.ch 
• Please do install the "SBC version" or the "Engiby version" but not both in parallel; this could lead to inconsistent file combinations.

Some M-Bus devices (so far only observed on a MBus water counter from the company Allmess / Actris) are very sensitive against inter-character delays.

Symptom
Some M-Bus devices connected to a PCD2.F2xxx or a PCD3.F2xx (or on the ports listed below under "Remark") are not answering to all requests. The same device does work fine when the M-Bus gateway is connected to another port (e.g. on port 0 of the PCD2.M5). 

Reason
The reason for this phenomenon could be that the M-Bus device is very sensitive against inter-character delays in the telegrams.

Solution
In order to avoid the inter-character delays a new feature has been implemented in the firmware of the PCD (the freeze bit, see FAQ 100916). The M-Bus library 2.5.203 from Engiby does work with this mechanism and thus avoids the inter-character delays in the telegrams.

Remark
With firmware 1.10.16 it has been observed that such inter-character delays are present in telegrams sent on the ports listed below even when using the freeze-mode mentioned:

• PCD2.M5xxx: port 2 and port 3
• PCD3.Mxxxx: port 0 and port 3

In order to avoid these inter-character delays, please use firmware 1.10.51 for your PCD2.M5xx0 or PCD3. This firmware can be downloaded from the according product section on the support site www.sbc-support.ch.

Due to the different electric properties of the RS232 driver mounted on the PCD7.F121 produced between June 2009 and September 10 2009, these modules do not work at all or not correctly when mounted on a PCD2.F2xxx or a PCD3.F2xx.

The reason for the different electrical properties is that the driver is delivered by a new manufacturer. We did not notice this malfunction in our production because the F2xx modules are delivered separately from the PCD7.F1xx modules, as they are mounted afterwards by the customer.

Identification of concerned PCD7.F121

PCD7.F121 applied on PCD2.F2xxx and PCD3.F2xx which were delivered between June and 10th of September 2009 (production date 0923 to 0936). These modules are equipped with ICs from manufacturer Sipex and have hardware version B without modification 1.

Not concerned products

• Any PCD7.F121 not applied in PCD2.F2xxx or PCD3.F2xx

• PCD7.F121 with production date before 0923 (generally equipped with an IC from the manufacturer Max)

• PCD7.F121 delivered after 10th of September2009, equipped with IC from Max or Sipex but with version B1


If you have concernde moduls, contact your local representation to exchange them.

Yes, Modbus is supported by the firmware of recent Saia PCD® systems (on all ports, including the ones on F2xx modules since beginning of 2011) or by a dedicated FBox driver.

General
There are two possibilities to use Modbus on SBC CPUs (Classic versions).

• The new FBox library for Modbus "Modbus SBC Version" which takes advantage of the Modbus implementation directly in the Saia PCD® COSinus firmware.
  Available for PCD1.M2, PCD3 and PCD2.M5 with firmware version 1.10.16 or more recent (for using on F2xx modules, in minimum FW 1.14.23 is required).
• The Modbus FBox Library from our partner ENGIBY which is available since several years (www.engiby.ch) and supported also by PCD systems previous to the PCD3, PCD2.M5xxx and PCD1.M2xxx families (e.g. PCD2.M1x0, PCD2.M480 or PCD1.M1xx).

Remarks

• In order to use the firmware implementation of Modbus on PCD2.F2xxx or PCD3.F2xx modules, the following prerequisites need to be fullfilled:
  - minimal PCD firmware: 1.14.25 (1.14.23 does support the F2xx modules, but
    communication errors can occur)
  - minimal hardware version of the F2xx(x) module: version D (delivered since beginning 2011) 
• The FBoxes for "Modbus SBC Version" are available for download from the support site since July 2009.
  In PG5 2.0.110 and later the "Modbus SBC Version" is installed by default. Please note that a licence is required for this library.
  

When more than 1 displays of the same type (PCD7.D23x and PCD7.D290) are connected to a RS 485 port (Bus terminal) of a PCDx.F2xx module, the communication doesn't work. Only one of the displays is available, the other one(s) is (are) not accessible!

The ports 100 to 131 available on the PCDx.F2xx modules have different timing properties and are therefore not appropriate for PCD7.D23x and PCD7.D290 in bus terminal topoloy!

Workaround:
Use another RS 485 port (onboard or with F1xx).

If the communication on both ports of a PCD3.F281 does not work then it's possible that the PCD3 does contain a FW which not does recognise the PCD3.F281 module.

Symptom
The communication on both ports of the PCD3.F281 does not work at all. The firmware installed is 1.08.23.

Reason
The firmware does not recognize the Belimo MP Bus module.

Solution
To solve the problem please install PCD3 firmware version 1.10.16 (the first firmware solving the problem was  version 1.08.51).

There are various possibilities to plug flash memory modules (PCD7.R500, PCD7.R550M04, PCD7.R551M04, PCD7.R560 and PCD7.R561) on the CPUs.

It’s possible to plug the PCD7.R500, PCD7.R550M04, PCD7.R551M04, PCD7.R560 and PCD7.R561 modules in the following slots:

• M1 and M2 of the PCD3.M5/6 CPUs
• Memory module holder PCD3.R550 in the slots 0 to 3 of the PCD3.Mxx0 CPUs
• Memory module holder PCD3.R560 in the slots 0 to 3 of the PCD3.Mxx0 CPUs
• Communication module PCD3.F1xx only in the slot 0 of the PCD3.Mxx0 CPU's

The "backup user program" functionality does work on any of the above mentioned slots if the module PCD7.R500, PCD7.F551M04 or PCD7.R561 are used.

The Sasi S-Bus Master F-Box indicates a diagnostic error and is red. The data is transmitted but obviously not properly.

Problem
The S-Bus communication is not working properly if the baudrate is 9600 baud or higher and a PCD3.F2xx module is involved in this communication. With a baudrate 4800 it works well.

Reason
The PCD3.F2xx module is not as fast as a "normal" S-Bus port like per example Port 2 on the PCD3. If there is an S-Bus communication running with e.g an PCD3.F2xx as master and a PCD3.Mxxx port 2 as slave, the communication will probably report diagnostic errors with baudrates higher than 4800.
If the PCD3.F2xx module is the slave, it is less critical but can lead to problems as well.

Solution
To avoid this problem the turnaround delay TN of the other station (not the one where the PCD3.F2xx is plugged) has to be set to 3ms.

It was not possible before the MP-Bus library 2.5.300 which was distributed with PG5 1.4.300.

Problem
Since the new PCD3.F2xx modules where developped it was possible to have up to 8 MP-Bus Masters in a project. With the old MP-Bus Belimo library it was not possible to have more than one master in a Fupla file.

Solution
With the new MP-Bus library >=2.5.300 it is now possible to have several MP-Bus Masters in one project. The master now have a name "Channel" and the differnet F-Boxes refer to this "Channel".

Restriction
If an old project is converted to the Belimo MP Bus Version 2.5.300 / 2.5.301 it could be, that compiling is not possible anymore due to a conflict. In this case install the version 2.5.302 or higher (FAQ 100 957).

There are error messages displayed for each old FBox that it should be replaced.

Problem
After installing the new version of the Belimo library which allows to have more than one MP-Bus Master in a Fupla file, it is not possible anymore to build the old projects.

Reason
The MP-Bus Belimo library 2.5.300 and 2.5.301 had an incompatibility with older MP-Bus Versions. The library 2.5.300 was distributed with PG5 1.4.300.

Solution
Please update your MP-Bus FBox library version to version 2.5.302 or higher. The latest version of the FBox library can be downloaded from the support site in the section "Product information" --> "Software" --> "PG5" --> "FBox libraries".

For BCU1 protocol not all communication interfaces of a PCD3 or a PCD2.M5540 can be used. On the other hand there is no problem using the newer FT1.2 protocol which is supported by all RS232 interfaces of the PCD3 and the PCD2.M5540.

Supported communication interfaces for EIB/KNX driver
The table below shows the supported communication interfaces for connecting an EIB coupler to PCD3-, PCD2.M5540 and PCD1.M2120 systems. On other systems (e.g. PCD2.M170) all RS232 interfaces can be used for connecting an EIB/KNX coupler.

Remark
We strongly recommend using FT1.2 (also known as BCU2) for new projects as this implementation is more performant (due to a higher baudrate supported and telegram oriented transmission control rather than character-oriented transmission control which is used by BCU1). The table above represent functional tests; there is no relation to the communication performance.

Two series of PCD7.R500 which where produced in 2007 do contain a wrong configuration information on the EEPROM of the PCD7.R500.

The series can be identified easily by the article name "PCD7.R5" (written on the white label on the module) and fabrication date 0727 or 0735.

Saia-Burgess Controls AG has delivered two series of PCD7.R500 modules which do contain wrong configuration information in the EEPROM of the PCD7.R500.This wrong configuration information can lead to malfunction of the file system access of the PCD3 and on the communication module of the PCD3.

Behaviour of the malfunction
If the PCD7.R500 module is placed together with a PCD7.R5xx, PCD3.R5xx, PCD3.F1xx or PCD3.F2xx module on the slots M1, M2 or the I/O card slots 0 to 3 of the PCD3, then the file system of the PCD3.R5xx or PCD7.R5xx is no more accessible from any external device (e.g. a Web-Panel) neither from the application program. Also the communication ports of the PCD3.F1xx or PCD3.F2xx on the I/O card slots 0 to 3 don’t work at all.

Bad module	Good module

Corrective measure
Saia-Burgess Controls AG has reprogrammed all PCD7.R500 on stock in Murten with a correct configuration. All correctly programmed modules do have the article name “PCD7.R500” on the white label of the PCD7.R500 module.
In case you have received a PCD7.R500 module affected the above desribed wrong configuration, please contact your local Saia-Burgess Controls AG representative.

There is a problem in the Belimo library distributed togehter with PG5 1.4.200.

Symptom
All MP-Bus F-Boxes are green but no values are beeing transmitted.

Reason
There is a problem in the Belimo library 2.5.140 which is installed together PG5 1.4.200

Solution
A correction for this problem has been implemented in the MP Bus library version 2.5.142. The easyest way for resolving the problem is updating to PG5 1.4.300 or higher (the latest PG5 version is available on the supportsite www.sbc-support.ch in the section "Product info" --> "Software" --> "PG5").

Depending of the PCD type and the used port it's possible to use the XON/XOFF protocol.

Symptom
A SASI (Assign Serial Interface) in mode MC2 (Character mode with Xon/Xoff protocol) fails. The error flag is set after the SASI instruction.

Reason
The XON/XOFF protocol is not supported on this PCD or port.

List of supported ports
PCD3.M5xxx: the mode MC2 is supported on port 0 (Com/PGU) and also on the PCD3M5340 in RS422 on port 3 (S-Net/MPI).
PCD2.M5xxx: the mode MC2 is supported on port 2.
PCD1.M2xxx: the mode MC2 is not supported.


Remark
Please note that on the PCD2/3.F2xx modules, the XON/XOFF mode is not yet supported (which is not correctly documented in the manual 26/789).

In some cases it can happen that the PCD3.F180 (produced between 2006 and Febrauary 2007) works well for a certain time but suddenly stops communicating. This behaviour is related to the hardware version of the PCD3.F180.

Symptom
The PCD3.F180 (produced between 2006 and Febrauary 2007) works well for a certain time but suddenly stops communicating. In some cases it is also possible that it doesn't work at all.

Reason
The base print of the PCD3.F180 was designed in a way that the ground signal was not properly stabilized. This problem has been corrected in February 2007.

Solution
As solution a bridge between the PGND and the GND terminals of the PCD3.F180 can be installed. Therefore please connect the pin 0 with pin 4 on the terminals on the front of the module.

Remark
Modules produced after February 2007 are not concerned by the problem explained in this FAQ and therefore no additional bridge is required.

The diagnostic flag TBSY of the "Character Mode" (used for sending characters over a serial line) is not handled the same way on a PCD3 compared to "older" systems like e.g. PCD2.M170.

Symptom
If the relevant port is assigned in MC mode, the diagnostic flag TBSY is indicating that the serial port is busy sending characters. This is the case on e.g. a PCD2.M170.
This behaviour is not the same on a PCD2.M5xxx or a PCD3.Mxxxx, especially not when using a PCD3.F121 or a F2xx(x) modules. On a PCD3/PCD2.M5 the TBSY flag is not any more high during the whole time the port is busy. Instead, it is only high a short time at the very beginning of the send task.

Reason
The reason for this difference is a new manner to access the UART of the port. On older systems the characters were directly written to the UART while on the PCD3 a buffer is placed in-between. Instead of indicating the "send-state" of the UART like on older systems, the TBSY represents the state of this buffer (the size can be found at the end of this FAQ) on the PCD3 or the PCD2.M5.

Solution
This difference shouldn't lead to problem is most cases. However, in some applications the state of the TBSY is used to control e.g. the RTS signal of the line (using the instruction SOCL). In this case the communication (working on a PCD2.M170) won't work any more on a PCD3 or a PCD2.M5.
In this situation one of the following workarounds could be applied:

• Instead of assigning the port in MC0 it could be assigned in MC4 (MC4 is usually described as "MC for RS485"). In this mode the UART is managing the RTS autonomously (and therefore there is no more need to set the RTS by the user program). Note that in this case the SOCL commands are to be removed from the program!
• The duration while the RTS is to be set could be calculated beforehand (based on the amount of characters to be sent) and loaded into a timer. While this timer is high, the RTS can be set using the SOCL command.
  Note that this solution is not really a "nice" one and can only work with very low baud rates.

Notes

• All firmware versions of the PCD3xxx and PCD2.M5xxx do treat the TBSY as described in this FAQ.
• The buffer size is depending on the port used:
  PCD3 port 1 and 2: 24 characters
  PCD3 port 0 and 3:  2 characters
  PCD2.M5 port 0 and 1: 24 characters
  PCD2.M5 port 2 and 3:  2 characters
  

In case a PCD3.F1xx module doesn't work several reasons are possible. This FAQ supplies a summary of these possible reasons.

Symptom
The communication on port 1 of the PCD3 does not work. In case the port is configured as PGU port (e.g as modem port or as serial PGU port) the PCD does not even go in run and shows a history entry ("Modem Port init fail" or "PGU port init fail").
If the port is not used as PGU port, the error led will be lit during startup of the PCD3.

Possible reasons

• The PCD3.F121 is defective or incorrecty wired.
  
• The port has been assigned with a "Sasi Slave" FBox and the interface has been spedified as RS232
  Refer to FAQ 100420 for further information.
  
• On the same PCD3 another intelligent module (e.g. a PCD3.Rxxx) is mounted.
  Refer to FAQ 100636 for further information.
  
• The hardware version of the PCD3 is <D and more than two PCD3.Cxxx are connected to the PCD.
  Refer to FAQ 100549 for further information.
  
• The module is a "pilot module" (delivered during the pilot phase of the PCD3.F1xx modules) and is not correcty programmed. In this case the module identification is missing and the module needs to be replaced.
  
• A PCD7.F120 is mounted on the PCD3.F121
  Refer to FAQ 100646 for further information.

When mounting a PCD7.F120 into a PCD3.F121 / PCD3.F2xx or when using a PCD7.F120 on a PCD2.M5, the communication doesn't work. The reason therefore is an incompatibility between the PCD7.F120 and PCD3.Fxxx (or PCD2.M5) modules and the old .

Symptom
After having mounted a PCD7.F120 into a PCD3.Fxxx or on a PCD2.M5, the communication doesn't work. No communication is possible using the relevant port.

Reason
The PCD7.F120 does require a power supply which is not present on the PCD3.Fxxx modules or on the sockets from PCD2.M5xxx / PCD2.M48x CPUs. This power supply is not present because the new communication module PCD7.F121 (which supports baud rates up to 115 kBit/s) doesn't require a power supply any more.

Solution
In case you are concerned by this problem just replace the PCD7.F120 by a PCD7.F121.

Remark
All modules PCD3.Fxxx ordered as RS232 module are delivered together with a PCD7.F121 (In fact, the PCD7.F120 has been replaced by the PCD7.F121). The only situation where a problem can occur is in case an (old) PCD7.F120 from an existing PCD system is mounted into a PCD3 or a PCD2.M5 / PCD2.M480.

There is a problem when placing a communication module PCD3.F1xx and a memory module (PC3.Rxxx) on the same PCD3.

Problem
If a communication module is per example on slot 0 of the PCD3 and a memory module is per example on slot 1, it is possible that one of them will not work. If one of the modules is removed, the remaining one will work correctly.

Reason
There is a problem in the firmware. As soon as more than one intelligent module (e.g. PCD3.F1xx, PCD3.F2xx, PCD3.R5xx or PCD3.R6xx) are plugged on the PCD3.Mxxxx the detection of the module can fail.
This problem will be corrected in firmware version 031 (but is is existent also in version 030 / $31).

Solution
As long as firmware 031 is not released the two modules will not work properly together. A workaround could be to put the memory module PCD7.R550M04 directly on the communication module. Open the memory module PCD3.R550 and remove the card PCD7.R550. Open the communication module PCD3.F1xx and plug the card on this module.

If the PCD3 is equipped with the interface card PCD3.F180 the error "no card echo" can be forced into the "single-master box" during the interface initialize process.

Symptom
The error message "No card echo" is present in the Single master box.

Reasons
This error message can have several reasons:

• Wrong PCD3 slot is used. Only slot 0 can be used with the card PCD3.F180

• Wrong channel definition. Channel 1 has to be used

• Gateway function is defined on the Channel 1

• Wrong terminal used for MP-communication to the actuator

• Physically not existing MP-interface card. Please verify the plugged PCD7.F180 card into the module

• Incompatible firmware into the PCD3 is used (i.e. Version $-26 will not work)

• The module is concerned by the problem described in FAQ100693

• Defect MP-interface card

For the correct handling of the new flash modules PCD3.Rxxx an and the PCD3.Fxxx communication modules an "I/O module check" has been implemented in the firmware. Unfortunately this check can cause problems on older hardware versions if more than two PCD3.Cxxx modules (extension cabinets) are used.

Symptom
The communication module PCD3.F121 as well as memory modules PCD3.Rxxx do not work when more then 2 extension cabinets PCD3.Cxxx are connected to a PCD3.
It is possible that the same PCD3 was working correctly but after an update of the PCD firmware this symptom appeared. In this case with the firmware update a new I/O module check has been introduced (please refer to the table below to find out in which versions this I/O module check is implemented).

Reason
An I/O module check has been introduced for the correct identification of the modules. In this way it is possible to avoid e.g. flickering outputs of an output module if a modem is (unintentionally) configured on this I/O slot. Also flash modules can be identified properly before accessing their content.

Unfortunately this check does not correctly recognize the modules plugged in to the PCD if the PCD is equipped with an old CPLD (Complex Programmable Logic Device) version as soon as more than two extension cabinets PCD3.Cxx0 are connected to the PCD.

Solution
Upgrading the CPLD version will solve the problems as the modules will correctly be recognized by the firmware. The upgrade of the CPLD corresponds to the hardware modification 8 on the PCD3 CPUs.

Hardware version D or above
The hardware version D has a correctly programmed CPLD and will therefore also detect intelligent I/O modules if more than 2 PCD3.Cxxx extensions are connected to the PCD3 CPU. No further action is to be taken.

Hardware version
These CPUs need to be updated to hardware modification 8 (CPLD update). Once this is done these PCD3s will support all PCD3.F1xx on slot 0 and also newer intelligent modules like per example the new flash moduls PCD3.Rxxx.
The update can be done with the "Firmware download Assistant in the following ways:

In principle, it is possible to use RS422 as physical layer for Serial-S-Bus communication. But note that the S-Bus full protocol is not fully applicatively due to the reason described below!

Configuring a serial port to use RS422
In order to switch the communication module (PCD7.F110, PCD3.F110, PCD7.F520 or PCD7.F530) from RS485 to RS422, the following code lines are to be used:

As commented, this code is placed into the startup program block XOB 16 and will cause the port to work in RS422 mode. This means that it is only possible to use this port after the XOB 16 has been executed.
Please note that either the port is to be configured as PGU port or a SASI has been applied on <portnr> before executing the code above!
For further information, please refer to the S-Bus manual, 26/739.

Restriction for S-Bus full protocol
Given the situation that a program is to be downloaded to the PCD over such a port, we are faced with the following scenario:
Before downloading the code, PG5 will restart the PCD. This restart will reset all communication ports (and the concerned port will not be in RS422 mode any more). This leads to the fact, that PG5 won't get any response any more (and cannot send to the PCD, either). The PCD is to be restarted manually for establishing the communication again!
The same problem occurs after every restart command executed by PG5! This is why the RS422 is not really applicatively for real S-Bus full protocol actions. However, there is not problem in using all command except of the restart (and of course the S-Bus reduced protocol will not cause any problems).

On some PCD3.F150 modules the label with the connection diagram do not correspond to the manual. It is wrong.

The correct connection diagram is in the PCD3 manual. See attachment for future information.

The PCD7.F121 is the successor of the PCD7.F120. The main difference are higher baud rates supported by the PCD7.F121 (up to 115 kBit/s).

Why was the PCD7.F120 replaced?
When introducing the systems PCD2.M480 and the PCD3 systems also support for higher baud rates has been introduced. Unfortunately the PCD7.F120 couldn't handle the maximal baudrate supported by the new systems.
In order to take advatage of the higher baud rates also a new module for the RS232 interface had to be introduced. This new module is the PCD7.F121.

Is the baud rate limitation the only difference?
No, there is another difference between the modules. The PCD7.F120 requires a special 9V power supply from the device on which it is mounted. The PCD7.F121 doesn't require this additional power supply any more.

In January 2024:
the COSinus BACnet FW 1.28.59 was put on the support homepage.  

In April 2022:
the COSinus FW 1.28.51 was introduced into production for the systems:

- PCD1.M0xx0/M2xx0, PCD2.M4x60, PCD3.Mxx60 and PCD3.M6880.

In February 2019:
the COSinus FW 1.28.37 was released as maintenance version for the systems:

- PCD1.M0xx0/M2xx0, PCD2.M4x60, PCD3.Mxx60, PCD3.M6880 and PCD3.T665/T666/T668.

In June 2017:
the COSinus FW 1.28.16 was introduced into production for the systems:

- PCD1.M0xx0/M2xx0, PCD2.M4x60, PCD3.Mxx60, PCD3.M6880 and PCD3.T665/T666/T668.

the BACnet and LonIP FW 1.28.51/1.28.59 was put into production, which do support the BACnet Revision 14.
To support the BACnet Revision 9 it's necessary to use the PCD and the BACnet FW 1.26.xx.

Attention:
The firmware 1.28.xx or later can be used only on the following PCD's with 8 MB onboard firmware memory:
PCD1.M0xx0/M2xx0, PCD2.M4x60, PCD3.Mxx60, PCD3.M6880 and PCD3.T665/T666/T668

The table below does show the hardware dependencies in relation with the COSinus firmware versions

Do use at least the PG5 firmware downloader version 2.1.311 or newer (included in PG5 patch 2.1.311 or newer) to prevent the loading of the FW 1.24.xx, 1.26.xx or newer to a not compatible PCD

Firmware 1.28.59 (only BACnet firmware) (January 2024)

Main corrections

• BACnet: MI/MO/MV objects, invalid values for Alarm_Values and Fault_Values are rejected
• BACnet: BI/BV/BO objects, present value of can only be 0 or 1
• BACnet: COMMAND object, present value writing returns an error if bigger that the number of actions
• BACnet: Trendlog objects, property value check is done according to specifications
• BACnet: Limit COV subscription to 3000 and send PDU-Error if length of response is too big
• BACnet: Disable I-Have response when state is disable / disable-init
• BACnet: Calendar Object Date List, don’t allow wild card in this property entries
• BACnet: writing invalid array to Array properties returns correct Error code
• BACnet: Pulse Converter Object, send out-of-range PDU-Error if count processing is < 0
• BACnet: Controller goes to HALT with SWTO error
• BACnet: MS/TP Controller goes to HALT with SWTO error
• BACnet: Schedule accepts Sundays in Week and Day
• BACnet: GetEnrollmentSummary: correct reply if list is empty

Firmware 1.28.51 (April 2022)

Main corrections

• All PCD’s: Saia PCD Modbus diag does not work if diag flag > 9999
• All PCD’s: SNTP and hardware RTC is diverging from more than 2 seconds, then History message ‘RTC Fail error’ is generated
• All PCD’s: SNTP Time synchronization does not work with DHCP
• All PCD’s: E-Mails send from PCD could contain unwanted characters like 0 or others
• All PCD’s: S-Monitoring values for S-Monitoring bar graphs are sometime wrong
• All PCD’s: S-Monitoring Year graph scaling displayed wrongly
• All PCD’s: TCP, open data mode protocol, communication is blocked after rejection of 32 connections
• All PCD’s: LonIP CSF is locked when an error occurs
• PCD2.M45x0: SRXM does not support FB parameters as operand 3 and 4 for source and destination
• PCD1.M2220-C15: Watchdog LED does not follow Relay when PCD goes in STOP or HALT
• PCD3.M6880: Data exchange between CPU 0 and CPU 1 does not work reliable if STL instruction is used
• BACnet: Calendar state not updating after add/remove list element service
• BACnet: Exception schedule writing to certain array index fails
• BACnet: Schedule crashes with SWTO error
• BACnet: MS/TP client properties are not written if many values change simultaneously
• BACnet: Problem reliability & out of service, reliability is not written when oos is high
• BACnet: Web CGI commands to read BACnet platform tags like ..AddFW,Version,BACnet don’t work
• BACnet: Web scheduler/calendar templates do not work
• BACnet: PCD3.M6860 no BACnet communication on ETH2 if router is used
• BACnet: Rev 4 not working with Name based Client
• BACnet: Rev14 does not allow high limit value below 5 on analogue input

Firmware 1.28.37 (February 2019)

New features

• All PCD’s: FW extension to close all open FTP connections
• BACnet: Calendar objects have been extended with a synchronization mode. Each server calendar object can be configured as Slave or Master calendar
• BACnet: New mappings for alarming counters have been added to Notification-Class objects.
• BACnet: The PCD will now accept AcknowledgeAlarm service requests, which use complete wildcards as timestamps.

Main corrections

• All PCD’s: On S-Bus data mode, if S-Bus CRC contains a S-Bus DLE as last character then S-Bus telegram is incorrect and not accepted from S-Bus recipient. (Since FW 1.28.20)
• All PCD’s: Not all bytes are transmitted when working with MC4 or MC5 mode on F2xxx module
• All PCD’s: RS485 driver keep holding bus after a while
• All PCD’s: Http request ‘is modified’ is not handled correctly on the PCD Web-Server which lead to the effect that web project is not loaded correctly on the browser
• All PCD’s: PCD can crash when breakpoint is updated during conditional RUN
• All PCD’s: PCD can crash on download in run since FW 1.28.27.
• All PCD’s: PCD can crash on download in run when Graftec is used
• All PCD’s: PCD crashes when using browser to access the default page of PCD with "Display Root Content Enabled = YES"
• All PCD’s: RCOB does not start COB when it was stopped before with SCOB
• All PCD’s: Profibus communcation using onboard FDL port. The FCS test for SD2 telegram was not implemented correctly.
• All PCD’s: When S-Bus IP Nodelist is used it’s possible that the communication using nodes does no more work after execute a download in run
• All PCD’s: XOB parameter as Registers does not work if 16bit addressing was used
• All PCD’s: LonFT10: SNVT_obj_status and SNVT_obj_request can be used in user profiles
• PCD3.Mxx60, PCD3.T6xx, PCD1.M2xx0, PCD2.M4x60: usage of I/O media mapping slows done the cycle time 2 times in comparison to FW 1.26.xx
• PCD2.M4x60: Download LonIP config not possible
• PCD2.M4x60: RTC gets sometime corrupted data when PCD7.F7500 is used on PCD2.M4x60
• PCD2.M4x60: RTC Time is wrong after several days of run
• PCD7.D443WTxR: uBrowser use alphapad.teq even if screen is rotated by 90°
• PCD7.D443WT5R: History entry Memory ‘Lost -1’ written in the History
• BACnet; Event Enrolment does not work correctly with external reference devices.
• BACnet; When using BACNet Webvisu the memory used increase each time the scheduler is edited.
• BACnet; PCD crash when BACnet Webvisu edit scheduler.
• BACnet; BACnet WebVisu does not display correct value for the WeeklySchedule value.
• BACnet; ACK Required bit in notification message is not set according to the related NV ack_required bits
• BACnet: The PCDAlarmStatus mapping property does not work correctly.
• BACnet: Mappings, which changed to the value 0 directly after a program download, are not updated correctly on the BACnet property.
• BACnet: The Priority-Array mapping does not work correctly after startup.
• BACnet: Initialization of Puls converter count with input reference gives error
• BACnet: Fix issue with weekly scheduler.
• BACnet: Fix issue with WeekNDay entries
• BACnet: The Restore functionality over BACnet does not work, when the PCD has been reset over factory reset.
• BACnet: The Action property in the command object does not handle NULL datatype and priority entries correctly, if they are used in the ActionCommand. Additionally, the Action property can now be read via index.
• BACnet: Priority_Array entry 16 will be overwritten on startup with the last Present_Value mapping
• BACnet: Out of Service -> Value for PV overridden after reboot by Input ref
• BACnet: The Log_Buffer to csv conversion for trend-log objects does not skip time change entries
• BACnet: Unmapped Priority-Array property array entries are not stored persistent
• BACnet: BACnet configuration on the PCD is not deleted when "unlinked" from PG5
• BACnet: Change Client Time_Of_Restart mapping to Unix time
• BACnet: Client mapping - Threshold is not implemented correctly
• BACnet: Mapped Reliability properties within analogue objects does interfere with the objects functionality. When the Reliability is mapped, the mapping has not full control over the property value.
• BACnet: The program download fails, when the BACnet config contained notification-class objects with event-counter mappings
• BACnet: BACnet Trend-Log(-Multiple) data can’t be retrieved as csv data
• BACnet: The SubscribeCOVProperty service can’t be executed on complete Priority_Arrays

Firmware 1.28.16 (June 2017)

New features

• All PCD's: When push button is pressed while power on then do not update FW from FS in order to execute a delete all.
• PCD1.M0xx0/M2xx0, PCD2.M4x60, PCD3.Mxx60, PCD3.M6880 and PCD3.T665/T666/T668:
  Enhancement for HTTP server to transparently support sending compressed files.

Main corrections

• All PCD's SBUS parity mode, correction when NAK character is received as first byte of response.
• All PCD's: When download new Ethernet-RIO Program with the option ‘Delete all backups’ it can happen that the RIO is not commission and no goes no more in ‘data exchange mode’ until the PCD reboots.
• All PCD's: When RIO name is not in upper case the RIO file is not updated until a restart is executed.
• All PCD's: When RIO file is downloaded with download changed RIO file then RIO file is not sent to RIO until a restart is executed.
• All PCD's: Ethernet Frame Padding Information Leakage fixed (CVE-2017-9628)
• All PCD's: The Modbus CSF CloseSRPort does not free the port then a open/SASI call give an error and the port does not work.
• PCD1.M2xx0 PCD1.M22x0 PCD2.M4x60: PCD can crash while power down when XOB 0 is programmed.
• PCD1.M2xx0 PCD1.M22x0 PCD2.M4x60: MC0 mode with start/stop flag working again.
• PCD7.D443WT5R: Alarming does not work since 1.28.00 FW.
• PCD7.D443WT5R: When watchdog timeout occurs PCD7.D443WT5R does't reboot and stays locked.

Firmware 1.28.11 (Arpil 2017)

New features

• All PCD's: Support of BACnet Revision 14

Main corrections

• All PCD's: Various Open Data Mode fixes: Read Timeout enhancement, Client Connection timeout and Client Keep alive with anonymous port issue fixed
• All PCD's: Modbus RTU on all ports but specially on the F2xx module has been corrected to handle the response timeout processing in the case that the response is just occurring at the moment of the timeout.
• All PCD's: Battery status shows FAIL also if battery module is missing.
  All PCD's: Various minor issues fixed
• PCD1.M2xx0 & PCD3+: 38400/115200 baud settings adjustment
• PCD2.M4x60: PCD7.F7500 initialization

The BACnet stack is a dedicated task on the PCD controller which runs in parallel to the PLC task which processes the PG5 application program.

Normally, there is no given function to know in the PG5 application program if the BACnet stack is running or not.

With the following workaround it’s possible to check in the PG5 application program, if the BACnet stack is running or not.
Similar function is implemented in the DDC Suite BACnet device FBox.
Take care the BACnet stack firmware needs more time to boot on the controller as the ‘normal’ PCD firmware.
So, at startup this function could provide a wrong information.

The workaround is:
1.
The PG5 application program toggles cyclically a Flag where the Flag is mapped to a BACnet BI object ‘PCD-Input reference’
2.
If the BACnet stack is running, then the BACnet stack copies the ‘PCD-Input reference’ of the BI object to the ‘present-value’ property of the same BI object.
3.
In the PG5 application program the BI object ‘present-value’ is connected to a counter and if the BACnet Stack is running, the counter will be incremented.
If the BACnet Stack is not running or stops, then the counter will not be incremented.

The PG5 2.2 demo project is attached to this FAQ.
The project can be used on PG5 2.2, PG5 2.3 or newer versions.

Due to an error on the PG5 2.2.230 BACnet compiler, PCD resource addresses changes (Reg-ister/Flags/DB’s/Text address change of existing symbols) on existing PG5 projects are not detected from the PG5 BACnet compiler and therefore the changed PCD resource addresses are not taken in account in the PCD after the download of the modified program.

Concerned products:
All PCD’s with FW 1.28.xx or later where BACnet revision 14 is used and where modified PG5 2.2.230 projects are loaded to the PCD.

The error doesn’t occur if:

• the PCD doesn’t contain a BACnet program.
• BACnet revision 9 features are used on PG5 2.2.230.
• PG5 2.3.xxx is used
• PG5 2.1 / PG5 2.0 or PG5 1.4 is used.

Error description:
Due to an error on the PG5 2.2.230 BACnet compiler, PCD resource addresses changes (Reg-ister/Flags/DB’s/Text address change of existing symbols) on existing PG5 projects are not detected from the PG5 BACnet compiler and therefore the changed PCD resource addresses are not taken in account in the PCD after the download of the modified program.

Detail information:
The PG5 BACnet compiler generate a checksum (CRC) over all PCD resources. This CRC is checked by the PCD firmware after the program download or the restart of the PCD to detect if the BACnet configuration has changed.
If the CRC has changed, then the PCD firmware forces the BACnet stack to reload the BACnet configuration in the PCD.
If the CRC has not changed then BACnet configuration is not loaded again in to the BACnet stack.
The error consists in the fact, that on PG5 2.2.230, the BACnet compiler doesn’t uses the PCD resource address for the CRC calculation and therefore a PCD resource address change of already existing PG5 resources doesn’t generate a different CRC.

The change of PCD resource addresses (Register/Flags/DB’s/Text addresses change of exist-ing symbols) could occur at any time to all, from PG5 automatically allocated PCD resources, if an existing PG5 2.2.230 project is modified or if the user changes manually allocated address of existing PG5 resources.

Error behavior:
The above described error lead to the situation that after the download of a modified PG5 ap-plication to the PCD, the BACnet Stack on the PCD uses still the old PCD resource address of PG5 resources instead of the new one.
This error could invoke a malfunction of the application program running on the PCD for PCD resources which are used/handled from the BACnet stack.

This behaviour could result to the situation that the application program on the PCD doesn’t work correctly and could create/provoke a randomly unexpected/unwanted functionality of the PCD application program.

Error correction:
The error will be fixed in PG5 2.2.234 or newer PG5 2.2 versions.
PG5 2.2.234 or newer should be available at the beginning of 2018.

Workaround for PG5 2.2.230:
The recalculation of the CRC can be forced by the user, if after each build something is changed manually in the BACnet configurator.
For example, a text string for the ‘Description’ or the ‘Location’ item on the BACnet configurator where the name could added with an underline ‘_’.
The new calculated CRC will then force the BACnet stack to load the new configuration.

Example to force the recalculation of the CRC:
Old Value for Location was ‘Murten’                  New Value for Location is ‘Murten_’

Yes, it’s possible to suppress alarm notifications on BACnet by controlling the communication.
This is an official BACnet mechanism and available with BACnet firmware from 1.24.41 (or newer) and since PG5 2.1.420.

To suppress the alarms it’s necessary to modify the BACnet communication mode of the device as described below.

In general, the communication of the BACnet device is controlled. There are 3 options:

• (0) Standard communication (default).
  All requests will be answered and device will also send COV, Alarm or Event-notifications if necessary
• (1) No communication.
  The device will not answer to any request and does not send any COV, Alarm or Event-notifications.
• (2) Reduced communication. The device will answer all requests, but does not send any COV, Alarm or Event-notifications.
  This mode is usually selected if device is under maintenance and alarm notifications should be suppressed.

To control the communication mode as described above, 1 additional register must be defined and set to the corresponding value. A 2^nd register can be used to get the current communication status.

In the example below, a “ComState” and “ComDisable”  register has been defined. The “ComDisable” has to be controlled by application, e,g. via a maintenance switch at the cabinet or a software switch.

The “ComStatus” will show the actual communication status and is a read only.

Finally those 2 register have to be mapped within BACnet Configurator into Device object, property “Communication Status” and “Communication Disable”:

Good to know: DDC Suite 2.7 has implemented this mechanism into BACnet Device FBox for easier use.

If this two new items are used with a BACnet FW < 1.24.41 then BACnet does not start

With the update of the BACnet Device Fbox from the Version 205002 to 205003, this Fbox creates a monitoring Object for BACnet, which needs symbols.

This symbols are not created automatically if the 'update Fbox' functionality of PG5 is used.

Symtom:
After an update of the BACnet Device Fbox, BACnet does't work anymore.
The error output of the BACnet Device Fbox is always high.
All Fboxes switch to a fallback mode without using BACnet.

Reason:
The reason is because of the missing symbols for the new monitoring object inside of the Fbox.
During the update of the Fbox, these symbols aren't created automatically.
Because of that, the control function of this Fbox does switch off BACnet because of the missing feedback.

Solution:
Add manually the symbols with a rightmouse click on the Fbox and click on "Add predefined symbols".
Click "ok" if a small window appears.

When you use BACnet Schedule objects you have to know that the Present Value will be set back to "Schedule Default" at midnight.

This is defined in the BACnet Standard.

The FAQ describes how to deal with that.

The Present Value property will be assigned the value of the Schedule_Default property at 00:00 of any day,
unless there is an entry for 00:00 in effect for that day.

If a scheduled event logically begins on one day and ends on another, an entry at 00:00 shall be placed in the schedule that is in effect for the second day, and for any subsequent days of the event's duration, to ensure the correct result whenever Present_Value is calculated

If you have to analyze an Ethernet Network, you have to connect the monitoring PC between the communicating devices. The easiest way to realize that is with a hub (which are no more available) or with a switch with a special monitor port.

The monitoring PC can only see the TCP/IP communication on his own Ethernet port.
§Ix101493§
When B is talking with C, A cannot listen to it because a normal switch do not forward each communication to all ports but only on the port where the dedicated receiver station is connected.
The solution is to use a switch with a monitor port. Any communication over this switch is mirrored on this special port  like a hub.
You have to connect your analyzing PC to this monitor port and you will get all the traffic which go over this switch.
Recommendation:
We recommend to buy a Netgear ProSafe GS 105E switch.
This smal switch has 5 ports, one of them is the monitor port.
It is easy to configurate with a Web-interface.
§Ix101491§
To analyze the TCP/IP traffic, we recommend to use the Wireshark software. See also FAQ 100569.

When you are creating a BACnet configuration, you have to define a unique BACnet Name for each Object in the project. Furthermore there is a line to write in a description for more detailed informations.

The length of the BACnet object name and the description is restricted from the compiler to 255 signs each. You can find more information about restrictions and rules in the attached pdf. file.

Beim Erstellen der BACnet Konfiguration müssen der Object Name und die Description von BACnet Objekten mit Informationen gefüllt werden. Der BACnet Name muß in der Konfiguration einmalig und eindeutig sein. Die Description sollte zusätzlich beschreibende Informationen enthalten.

Die Länge des Object Name und der Description wird durch den SBC BACnet Compiler auf 255 Zeichen begrenzt.
Wird ein Name oder eine Beschreibung mit mehr als 255 Zeichen gewählt verwirft der Compiler diese ab Zeichen 256.

In case the "PCD input reference" is used in the BACnet configuration and a persistent value is written in runtime over BACnet (with BACnet firmware 1.16.41), the PCD might no longer be able to read the configuration on next power up. As result the PCD remains in HALT and writes e.g. "BNt FAIL AI00006" into the history.

Symptom
In case the "PCD input reference" is used in the BACnet configuration and a persisten value is written in runtime over BACnet (with BACnet firmware 1.16.41), the PCD might no longer be able to read the configuration on next power up. As result the PCD remains in HALT and writes e.g. "BNt FAIL AI00006" into the history.

Reason
When writing a persistent value to BACnet and if the "PCD input reference" is used, the configuration stored in the flash memory is destroyed with firmware version previous to 1.16.59 (e.g. 1.16.41).

Solution
In case you use the "PCD input reference" and in case your BACnet configuration contains over 100 inputs (e.g. 60AI and 50 BI) please update the BACnet and PCD firmware to BACnet FW 1.16.59 and PCD FW 1.16.57 or later. This firmware can be downloaded from the support site.

Remark
Please note that the PCD only writes the error message into the history, but PG5 shows a message saying "Everyting is OK".

In january 2013 a new firmware package for BACnet (to be loaded to the PCD3/7.R560 or PCD3/7.R561) was created (containing BACnet firmware 1.16.77). The main reasons for this new firmware are listed in this FAQ.

Changes between BACnet firmware version 1.16.75 and 1.16.77 (January 2013)

• Correction for simultaneously COV and COV-P subscriptions to Output objects with Prio Array
  

Remark
Please note that the BACnet 1.16.77 is to be used together with the PCD firmware 1.16.69 (or a more recent 1.16.xx firmware) in order to work correctly.

Changes between BACnet firmware version 1.16.73 and 1.16.75 (November 2012)

• BACnet Properties were not correctly updated after a Restart of the PCD
  
• In some cases the PCD sent a Whois each 5 sec. without reason
  

Remark
Please note that the BACnet 1.16.75 is to be used together with the PCD firmware 1.16.69 (or a more recent 1.16.xx firmware) in order to work correctly.

Changes between BACnet firmware version 1.16.67 and 1.16.73 (August 2012)

• Media Update (Mapping) was too slow --> corrected
  
• Download over Ethernet was slow --> corrected
• Several corrections for the Priority Array and "Out of service" handling
• Update of "Program state" property was not working
• Trendlog Objects "Total record count" could be wrong
  

Remark
Please note that the BACnet 1.16.73 is to be used together with the PCD firmware 1.16.69 (or a more recent 1.16.xx firmware) in order to work correctly.

Changes between BACnet firmware version 1.16.64 and 1.16.67 (V9, May 2012)

• If there was an invalid BACnet trendlog buffer in the file system the BACnet stack did not start up
• The Binary Input Object was not work correctly if the Polarity was set to 1
• The COV-P on the program status of a program object was not working

Remark
Please note that the BACnet 1.16.67 is to be used together with the PCD firmware 1.16.57 (or a more recent 1.16.xx firmware) in order to work correctly.

• The change of polariy of a BI object was not working in versions before 1.16.64
• Improved memory allocation method (with BACnet firmware 1.16.xx up to 1.16.64 the BACnet task could run out of memory if COV subscriptions were used)
• If a persistent value was written over BACnet, the property "Unsolicited COV" got lost and thus the COV-U was no longer configured on next power up 

Remark
Please note that the BACnet 1.16.64 is to be used together with the PCD firmware 1.16.57 (or a more recent 1.16.xx firmware) in order to work correctly.

Changes between BACnet firmware version 1.16.55 and 1.16.59 (V6, February 2012)

• The amount of memory used by BACnet (in relation to the maximum amount of memory available) is monitored on the PCD status page
• In case the "PCD input reference" is used and a persistent value has been stored over BACnet, the configuration could no longer be read on next power up, see FAQ 101712

Remark
Please note that the BACnet 1.16.59 is to be used together with the PCD firmware 1.16.57 (or a more recent 1.16.xx firmware) in order to work correctly.

• The timezone format has been updated to be compatible with the format used by PG5 2.0. 
  The previously used format is still supported by the firmware
• In case the "PCD input reference" is used and a persistent value has been stored over BACnet, the configuration could no longer be read on next power up, see FAQ 101712

Remark
Please note that the BACnet 1.16.55 is to be used together with the PCD firmware 1.16.55 (or a more recent 1.16.xx firmware) in order to work correctly.

• Conforms to BACnet Standard 2008 (rev. 5)
• BACnet BitStrings can now be mapped to Flag arrays:
  
• Added "PCD Input Reference" in order to improve Out-of-Service behaviour:
  The "PCD input reference" is copied to the Present Value as long as the Out-of-Service is false; if it is true, the Present Value can be written over BACnet and this value will be copied to the PCD media linked to the Present Value.
• Corrected the performance issues which were present in firmware 1.14.26
• In some cases (depending on the size of the project) it was not possible to download a project (and a NAK response was returned)
• With a specific project a Bus Error could have happened with BACnet firmware 1.10.62.

For more information about the changes, please refer to the online help of the BACnet Configurator distributed with PG5 2.0.200 or later.

• Improved the speed of searching if the configuration has a dynamically configured program object or not.
• Loop object has been enhanced so that it can be specified whether the built-in PID calculation algorithm or the DDC Suite FBox PID calculation algorithm shall be used.
• COVs were sporadically not generated in a system with high load and many IOs changing at the same time. 

Remark
Please note that the BACnet 1.16.41 is to be used together with the PCD firmware 1.16.27 (or a more recent 1.16.xx firmware) in order to work correctly.

In April 2011 a new firmware package for BACnet (to be loaded to the PCD3/7.R560 or PCD3/7.R561) was created (containing BACnet firmware 1.10.62). The main reasons for this new firmware are listed in this FAQ.

Changes between BACnet firmware version 1.10.50 and 1.10.62 (April 2011)

• The polarity was not correctly initialized at startup if a PCD resource is mapped to it.
• The PCD media was not updated when the polarity was written over BACnet.
• Improved the speed of searching if the configuration has a dynamically configured program object or not.
• Loop object has been enhanced so that it can be specified whether the built-in PID calculation algorithm or the DDC-Suite FBox PID calculation algorithm shall be used.
• COVs were randomly not generated in a system with high load and many IOs changing at the same time.

Changes between BACnet firmware version 1.10.24 and 1.10.50 (May 2010)

• Increased robustness in case of telegram losses during the "Upload/Merge" procedure.
• The BACnet task is now restarted after the download of a new configuration.
• In some cases the Scheduler Object did not write to the referenced objects. 

Remark
Please note that the BACnet 1.10.62 is to be used togehter with the PCD firmware 1.10.61 (or a more recent 1.10.xx firmware) in order to work correctly.

There's the possibility to configure a "Restart Notification Recipient" list in the BACnet configurator.

You have to add manually the address of the BACnet device you want to alarm in case of restart of the local PLC. This address is added in the “Restart Notification Recipients” list as shown in the below attached picture. With this setting the PCD will inform the BOW after a restart.
Please makte sure that the device you want to alarm supports this Restart Notification (available since standard 135-2004 addendum b).

Remark
There's a parameter in the BACnet telegram (list of values -> propertyValue -> last-restart-reason) that indicates the restart reason. It's "1" for a cold start (power on the PLC) and "2" for a warm start (restart after progrm download).
It is possible to enter BACnet device ID's or adresses. Take care that if you enter a recipient based on a adress, the MAC-Adress is atually the IP Adress of the recipient.

A short list of the most common messages one may find in the PCD history when BACnet fails (e.g. Bnt FAIL TL00001).

The string written to the PCD History upon a BACnet failure is composed of 2 parts. The first 2 characters denote the object that caused the error. If these characters are #s, the error is a general stack error ( in general, due to a misconfiguration.)
The rest of the string expresses the numeric code of the object or the error that has caused the failure.

Object identifying characters
The first two characters can be found in the list below and indicate the object that caused the error:

## - Expresses a general stack failure. It is not caused by an object, but rather by a misconfiguration or other error.
AI - Expresses a problem with the numerically denoted Analog Input object
AO - Expresses a problem with the numerically denoted Analog Output object
AV - Expresses a problem with the numerically denoted Analog Value object
BI - Expresses a problem with the numerically denoted Binary Input object
BO - Expresses a problem with the numerically denoted Binary Output object
BV - Expresses a problem with the numerically denoted Binary Value object
MI - Expresses a problem with the numerically denoted Multi-state Input object
MO - Expresses a problem with the numerically denoted Multi-state Output object
MV - Expresses a problem with the numerically denoted Multi-state Value object
AG - Expresses a problem with the numerically denoted Average object
CO - Expresses a problem with the numerically denoted Command object
CA - Expresses a problem with the numerically denoted Calendar object
EE - Expresses a problem with the numerically denoted Event Enrollment object
LO - Expresses a problem with the numerically denoted Loop object
SC - Expresses a problem with the numerically denoted Group object
TL - Expresses a problem with the numerically denoted Trend-log object

Examples

• 'Bnt FAIL ##00001' -> 'Unknown error'. May occur at start-up because the is no configuration on the flash card.
• 'Bnt FAIL ##00013' -> 'Bad configuration'. Occurs because the configuration file on flash is broken.
• 'Bnt FAIL TL00001' -> May indicate the failure to configure object Treng-log 1. This may be caused by assigning the storage of trends to a file on the wrong media. (Trend-log file is to be created on an SD card on slot 1, but there is no card in the slot.)
• 'Bnt FAIL ##00091' -> Indicates the failure of a Trend-log object that has been configured to use a ring-buffer. The reason for this failure is an attempt to write to the property STOP-WHEN-FULL. To solve the problem one must move the log file from the blue flash-card to an SD-card. A trend-log object that logs using a ring-buffer is not allowed on the blue flash-card.
  

When using the FBox "Motor 2-speed 2.0" (or the "Motor 3-speed 2.0"from the FBox family "DDC Controls" with the option BACnet activated, it can happen that the motor does not change to speed 2 (but shortly is switched off before re-using speed 1).

Symptom
When using the FBox "Motor 2-speed 2.0" from the FBox family "DDC Controls" with the option BACnet activated, it can happen that the motor does not change to speed 2 (but shortly is switched off before re-using speed 1).

Reason
In case the option BACnet has been selected, the feature from "HMI Super" has not been deactivated.

Solution
The versions listed below correct this wrong behaviour. Please update your library and then rebuild and download the program again.

• PG5 1.4.300: DDC Suite library version 2.5.150 
• PG5 2.0.110: DDC Suite library version 2.6.150

Firmware versions before the version 1.10.51 were not supporting retries during the "Upload/Merge" process of the BACnet configurator. In case a telegram got lost during upload of the BACnet configuration (from the PCD to the PC) the transfer was been aborted.

Symptom
During an Upload (for the function "Upload/Merge" of the BACnet configurator) all of the sudden the transfer of the configuration stops. This phenomenon is observed when a telegram is lost. This telegram loss is random, dependent on the network load.

Reason
Firmware versions before the version 1.10.51 were expecting a communication without telegram losses. In case a telegram was lost (due to network problems) the transfer was interrupted by the PCD firmware. Because of the interruption the BACnet firmware was not notified, but it remained in a state of waiting for the completion of the upload process.

Solution
The firmware version 1.10.51 (for the PCD3 or the PCD2.M5) together with the BACnet firmware 1.10.50 are more robust and can cope with telegram losses during the upload of the BACnet configuration. Please update the firmware of your PCD and the one on your PCD7.R56x to the mentioned (or later) firmware versions.

Remark
Please note that the firmware version of both, he PCD and the BACnet module must be updated.

If BACnet is enabled in a DDC Suite project a BACnet flash module must be installed because the I/O are treated differently by the DDC Suite FBoxes.

Symptom
The outputs of controlled with DDC Suite FBoxes are not working. In the DDC FBoxes, BACnet is enabled, but no BACnet flash module (PCD7.R65x or PCD3.R56x) is plugged.


Reason
If BACnet is enabled, code generated by the DDC suite is adapted to the BACnet feature (outputs can e.g. be written with priorities with a BACnet Operator Station BOW). If the BACnet task is not running (e.g. because no BACnet module is plugged or because the BACnet firmware stored on the PCDx.R65x is not compatible with the PCD firmware) the program will not work correctly.

Solution
Only enable BACnet in the DDC Suite if there is an according module plugged to the PCD.

In the system catalogue there is a schematic of a PCD connected to a BACnet/IP network which could lead to a missinterpretation. Although BACnet is supported by a PCD3 or a PCD2.M5xx0 and LON on IP will be suppored in future, it won't be possible to run both stacks on the same PCD at the same time.

Why is it not possible to run BACnet and LON at the same time?
This limitation is caused by the rather high usage of ressources (performance and memory) from both these firmware extensions. While there is no problem to run one of these firmware extensions, the currently available PCD systems do not support both firmware extensions at the same time.
It is intended to provide a solution for BACnet and LON on the same PCD but this requires a new PCD system in future.

Why is this schematics printed in the System catalogue?
The aim of this schematic is to show that both protocols are supported, but not to indicate that both protocols can be used at the same time. If the PCD is running the LON stack, the other communication could e.g. be Ether-S-Bus.

How can I realize a gateway from BACnet to LON with PCD systems?
The currently only solution is the realisation with two systems, which could e.g. be connected with Ether-S-Bus.

In case a BACnet firmware module has been installed on a PCD3.Mxxx0 or a PCD2.M5xx0 and a timezone has been configured, the time stamp of an S-Web alarm has an offset to the PCD time.

There could be the same behaviour when you are using the SNTP (Simple Network Time Protocol).

Symptom
The time stamp of an S-Web alarm does not have the same time as the PCD time (read e.g. with PG5). The offset is depending on the time zone configured in the BACnet configuration. The firmware installed on the PCD3 or the PCD2.M5xx0 is 1.10.16 or earlier.


Reason
Once a time zone is configured in BACnet or in the configuration of the SNTP, the local PCD time is calculated based on the hardware RTC (Real Time Clock), with taking this timezone into consideration (--> the time shown in the Hardware Configrator corresponds to the local time). On the other hand, the alarming time stamp is based on the hardware RTC (which corresponds to the UTC).

Other reason
The default Container "MB_tmz_en" is set to 1. If you want that the time of the alarms corresponds to the time of the PCD this Container should be set to 0.

Solution
In order to have the S-Web alarming working with the same time (local time) as the user program, please update your firmware of the PCD and your BACnet firmware to the versions contained in the "Latest BACnet Firmware package".
The PCD3.Mxxx0 or the PCD2.M5xx0 firmware required is 1.10.51 (the same version number for both, PCD3 and PCD2.M5xx0).
In case if you are using SNTP protocol without BACnet you only have to update the PCD firmware.

On the Cimetrics BACnet OPC-Server there exist for any BACnet device an item named “DEVICE_ONLINE_STATUS”.

The value of the item “DEVICE_ONLINE_STATUS” is:

- 0 if the OPC-Sever is not able to communicate with BACnet to the PCD.

- 1 if the OPC-Sever is able to communicate with BACnet to the PCD.

The verification of the "Present Value" of a BACnet object during runtime allows to know whether the BACnet module is plugged in the PCD and if the BACnet stack is running.

If you want to verify during runtime whether the BACnet module (PCD3/7.R56x) is plugged in the PCD2/PCD3 then you could follow the following steps:

• Define a new BACnet object "binary output" on the BACnet configurator of PG5
• Map the "Present Value" of the new object to a PCD resource
  (for example a flag with the name "Bacnet_is_running")
• Do define on the priority Array 16 of the new object a symbol reference.
• Map a PCD resource on the Value and the Flag field of the symbol reference
  (for example the Value with the flag "Value_1" and the Flag with the flag "Enable_BACnet")
• On the PCD application program do set the different flags on the XOB 16 as following:
• Set to low (0) the flag      "Bacnet_is_running"
• Set to high (1) the flag    "Value_1"
• Set to high (1) the flag    "Enable_BACnet"
• On the application program do verify the status of the flag "Bacnet_is_running".
  If the flag is set to low (0) then the BACnet module is not plugged in the PCD
  If the flag is set to high (1) then the BACnet module is plugged in the PCD and the
  BACnet stack is running.

Behavior
During the startup of the PCD the flag "Bacnet_is_running" is set to low (0).
If the BACnet stack is running then he will set the flag "Bacnet_is_running" to high (1) by coping the status of the priority Array 16 to the PCD flag "Bacnet_is_running"

Note
Since the BACnet stack needs some time after the startup of the PCD to update a first time all values, wait for about 10 seconds after the startup of the PCD before that you do check the status of the flag "Bacnet_is_running" on the application program.

Since BACnet objects vary heavily in the amount of properties and features it is not possible to define a number of supported BACnet objects per CPU. However, this FAQ contains a rule of thumb for the amount of BACnet objects that can be defined on a PCD3 or a PCD2.M5xx0.

As a rule of thumb it a PCD2.M5xx0 or a PCD3 CPU (with FW 1.10.xx or later) can handle up to 1200 BACnet objects. This applies if the 800/1200 BACnet objects consists of a mix of different BACnet objects.

Please note that in case a PCD2.M5xx0 or a PCD3 CPU does handle between 800 and 1200 BACnet objects then it is to be verified carefully whether the CPU is still able to treat the other tasks of the application (the cyclic treatment of application program and/or non-BACnet communication tasks) in every situation.

In case the CPU has less than 800 BACnet objects to treat the CPU performance is usually sufficient to treat the user program and other communication tasks.

Why is it that difficult to define the maximal amount of BACnet objects per CPU?
The BACnet related tasks to be executed by the CPU vary heavily depending on the BACnet object and the features configured for this object. A Binary Input (BI) without intrinsic alarming does not generate a lot of CPU load compared to an Analogue Value (AV) with intrinsic Alarming enabled. Additionally the required memory of e.g. a Calendar object or a Trendlog object is far higher than for binary/analogue values or inputs.

There are various possibilities to plug flash memory modules (PCD7.R500, PCD7.R550M04, PCD7.R551M04, PCD7.R560 and PCD7.R561) on the CPUs.

It’s possible to plug the PCD7.R500, PCD7.R550M04, PCD7.R551M04, PCD7.R560 and PCD7.R561 modules in the following slots:

• M1 and M2 of the PCD3.M5/6 CPUs
• Memory module holder PCD3.R550 in the slots 0 to 3 of the PCD3.Mxx0 CPUs
• Memory module holder PCD3.R560 in the slots 0 to 3 of the PCD3.Mxx0 CPUs
• Communication module PCD3.F1xx only in the slot 0 of the PCD3.Mxx0 CPU's

The "backup user program" functionality does work on any of the above mentioned slots if the module PCD7.R500, PCD7.F551M04 or PCD7.R561 are used.

Several tools are available for BACnet testing purposes. This FAQ lists some free and commercial tools we recommend.

System integrators are often forced to build the BACnet configuration for the Saia PCD® systems long before the foreign BACnet systems (B-BC, B-OWS etc. from other manufacturers) are up and running at the plant. Actually most programming and configuration work is done at the office, where testing with "real" systems is often impossible. But, fortunately, there are several BACnet tools available that allow tests even without any other BACnet systems. Here are some tools we can recommend for BACnet testing and trouble-shouting (listing in alphabetical order):

BACbeat (Polarsoft Inc.)
Fexible, yet easy to use program for evaluating, analyzing and testing BACnet systems. Commercial tool, which runs under Windows only. Single and multi-user licenses available.
Details at www.polarsoft.biz/bacbeat.htm

BACnet OPC Server (Cimetrics)
OPC server for Windows 2000/2003/XP usable with every OPC client (DA 1.x/2.x). Commercial usage requires license (dongle). Without dongle, the software runs in a limited mode, which stills allows searching for OPC clients and monitoring some objects!
Details at www.cimetrics.com

BACnet Explorer XML (Cimetrics)
Automatic discovery of BACnet devices, objects and properties, displayed in an handy tree-diagram. Allows reading and writing property values. Point lists can be saved in XML files.
Details at www.cimetrics.com

BACnet Watcher (HHO Automation)
Hardware-based BACnet Analyzer that acts as a web-based B-OWS. Very helpful for testing purposes during configuration and commissioning BACnet systems.
Deatils at: www.hho-inh.de/bacnetwatcher.html (german language only)

BAS-o-matic Protocol Analyzer (Cimetrics)
This is a protocol analyzer for IP-based networks with a focus on BACnet applications. Commercial tool, license dongle needed. See Wireshark for a free, open-source alternative to BAS-o-matic.
Details at www.cimetrics.com

Wireshark Protocol Analyzer (Open Source)
Free, open-source, industrial-standard protocol analyzer with support for hundreds of IP-based protocols. Good BACnet support, but also for Ether-S-Bus, HTTP, FTP, Modbus/IP and many more protocols used by Saia PCD® systems. Highly recommended by Saia Burgess TCS!
Details and Download at www.wireshark.org

(To be continued)

Priority 6 is reserved for time operations for BACnet objects like minimum on time or minimum off time.

The BACnet properties "Minimum On Time" and "Minimum Off Time" use the field of priority 6 and overwrite the content inside if an on or off delay is used.

Therefore you should not use this priority.

This is not possible because it can cause effects between the BACnet Objects.

It’s only possible to use every PLC resource once.

Some manufacturers (like Siemens) use proprietary BACnet Objects.

These Objects are not defined in the BACnet Standard and are manufacturer specific.
 
They cannot be imported.

You can ignore the error messages and work with the Standard objects which are imported correctly.

There are some problems with EDE files of a few manufacturers, because they are not in the right format.

You can check the right format you have a look at the EDE export of a Saia Burgess BACnet Project.

If you save a project in the BACnet configurator the EDE files are automatically generated in the PG5 Documentation Files folder.

We support the Version of Layout 1 or 2.

The import file has to be a .csv file of the Version 1 or 2.

If you have an Excel file with 4 tables (Siemens uses this format) you have to extract the 4 .csv files and import the _EDE.csv file.

Take care that the Version of Layout is containing a valid number.  If this line is empty try to put in a 2 with a Text Editor  and import again.

If the .csv file does not contain _EDE at the end of the filename you have to select *.csv while importing.

Probably the property of the referenced Object is not setup to be writable.

You can write the result a BACnet Schedule Object to one or more Objects. These Objects are inside of the property "List of Object Property Reference" and can be inside your controller or can be in external controllers.

The Objects / properties  inside of the "List of Object Property Reference" have to be defined as writable in the BACnet Configurator, even if you write to Objects inside of your own controller. If you write to Objects in foreign controllers they have to be writable as well.

In general the firmware versions of the PCD and the BACnet firmware must match (be compatible).

Symptom
It is not possible downloading a BACnet configuration to the PCD with a PCD3.R56x or a PCD7.R56x plugged. The download of the program is aborted with the following message:
"NAK Response, failed to write downloadable files. Missing Flash memory?"


Reason
In case the BACnet firmware (stored on the PCD3.R56x or PCD7.R56x) is not compatible to the firmware installed on the PCD3, it is not possible downloading the BACnet project to the PCD.

Solution
Make sure that firmware on the BACnet flash module is compatible to the firmware installed on the PCD3 (when e.g. using PCD3 firmware 1.08.23, a BACnet firmware 1.08.xx is to be used).
You can find the latest firmware package (PCD and BACnet firmware as well as the according BACnet configurator together) on the support site (see link below).

Remark
The PCD3 (and PCD2.M5xx0) firmware 1.10.16 and later will indicate an incompatible BACnet firmware in the PCD history with the message "Incompatible BACnet FW"