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"