It is only possible to determine whether the PCD's circuit board is fitted with a Swissbit micro-SD memory card by visual inspection.

The attached document describes how to know whether the circuit board of the PCD is fitted with a Swissbit micro-SD memory card.

The attached document describes how to proceed if you want to copy csv-Files (e.g., from HDLog) and Webeditorproject files which are stored on the Intflash of a PCD.

This could be useful if you are replacing an internal micro-SD memory card which is used on the circuit board of the PCD and you want to re-use the files stored on the old micro-SD memory card.

Newer PCD types and newer PCD7.D4xx devices have micro-SD memory card (uSD) on the PCB (printed circuit boards)

The following data’s are stored on the this uSD card on the PCD’s PCB:

• Firmware for the PCD
• Device configurator settings (PG5)
• Application program done with PG5
• Webeditor 8 project (PG5)
• DATA (e.g HDLog) created by the application program in runtime
• Setup, Calibration (PCD7.D443, PCD7.D450, PCD.D470)
• Program Backup on internal Flash

In some cases, it is necessary to replace the micro-SD memory card (uSD) of the PCD.

This FAQ describes how to replace the micro-SD memory card (uSD) which is mounted on the PCD controller's PCB (printed circuit boards)  

The attached .pdf describes how to replace the micro-SD memory card (uSD) used on the PCB of the PCD

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 a PCD directly to the internet, but you have to protect your PCD against unauthorised access or cyber-attacks.

To protect the PCD against unauthorised access or cyber-attacks, it’s imperatively needed to take some protective measures.

Information about protective measures can be found on the support hp

If you need a PCD with cyber security levels SL3+ and based on ANSI ISA 62443 then checkout our PCD3.M6893 (QronoX PCD), this PCD was developed for cybersecure applications.

Information's can be found here.

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

If the PCD2/3.W220Z18 card is plugged in to a ‘Power PCD‘ or a PCD2.C1000 or PCD2.C2000 and if all 8 analog inputs channels of the PCD2/3.W220Z18 module are connected to 8 PT100 sensors then the measured PT100 temperature values of the 8 channels are not correct.

‘Power PCD’s’ are:

• PCD1.M2x20, PCD1.M2160, PCD1.M2220-C15
• PCD2.M5540, PCD2.M5440, PCD2.M4160, PCD2.M4560
• PCD3.Mxx60

To solve the issue, use and connect only up to 7 PT100 sensors to the PCD2/3.W220Z18 or do use a PCD2/3.W350 module, if all 8 PT100 are needed.

On the ‘old’ PCD’s like PCD2.M170 or PCD3.M5540 the PCD internal power supply V+ was at 24V

On the ‘new’ ‘Power-PCD’s’ and the PCD2.C1000 and PCD2.C2000 the V+ is 16,5V

The electrical design of the PCD2/3.W220Z18 was done in that the way, that the internal power V+ of 24V was required to handle all 8 PT100 channels.

Since the ‘Power PCD’s’ and the PCD2.C1000/C2000 have a V+ of 16,5V the driver on the PCD2/3.W220Z18 don’t have enough power to handle all 8 PT100 signals correctly.

To solve the issue, use and connect only up to 7 PT100 sensors to the PCD2/3.W220Z18 or do use a PCD2/3.W350 module, if all 8 PT100 are needed.

The battery voltage is checked in the battery module for undervoltage and overvoltage.

New batteries have a too high voltage which causes the overvoltage limit to be exceeded.

Solution:

With the FBox 'PCD3.BAT0', selectable from the ‘System information’ family it is possible to switch off the overvoltage limit check on the battery module to prevent the battery LED from being switched on and the battery error message in the application program from being activated if the battery voltage is above the overvoltage limit.

The battery voltage check is performed in the battery module and the changes made by the FBox 'PCD3.BAT0' are stored in the battery module and not in the PCD3.M5/6, PCD2.M45xx.

As all information concerning the overvoltage limit check are stored in the battery module, it is possible to make the modifications in one PCD 'A' and after the modification, to insert the battery module in another PCD 'B'.

Battery modules with hardware version < C have a factory default battery undervoltage and overvoltage check.

Battery modules with hardware version >= C have the battery undervoltage test function ex works.
The battery overvoltage is not checked.

After the FBox 'PCD3.BAT0' has deactivated the overvoltage limit check, modification 8 is activated on the battery module.

Picture shows a battery module with hardware version A and modification 1 and 3

The modification number is displayed also on PG5 Online configurator, hardware information.

After the usage of the FBox 'PCD3.BAT0' the following information is visible on the PG5 hardware information. (Modification 8 was added)

Modification number 8 is only activated for this purpose 'Overvoltage limit check disabled'.

After changes have been made with the FBox 'PCD3.BAT0', the 24VDC power supply to the PCD must be switched off and on again so that the changes relating to the battery LED, battery error message in the application program and the update of the modification number in the hardware information can be adopted.

More information are available on the online FBox help.

Overview battery module hardware version, modification, under- and overvoltage test.

The FBox library ‘SBC Maintenance’ which includes the 'PCD3.BAT0' FBox can be loaded from this FAQ, over the PG5 update manager and will be installed automatically with newer PG5 versions.

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.16 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.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

1.
On a PCD3.M6860/M6880 it always necessary to update both CPU’s (Main CPU and Extension CPU).

2.
It’s mandatory necessary to update first the firmware on the extension CPU, and after this the firmware on the main CPU. The firmware update can be done over any S-Bus PGU connection.

3.
The firmware 1.26.xx or greater, can be loaded only on a PCD3.M6860/M6880 with hardware version D or greater.

4.
It is not allowed to load a FW 1.26.xx or greater, to a PCD3.M6860/M6880 with an Hardware <D.
The latest FW which may be loaded in such a PCD is the FW 1.24.xx

5
If a firmware 1.26.xx or greater was loaded to PCD3.M6860/M6880 with Hardware <D, then it’s necessary to  load again a FW 1.24.xx to the PCD

6.
If mistakenly the firmware on the main CPU was updated first, then it’s not possible to update the firmware on the extension CPU via the USB port of the Main CPU.
In this case, the update of the extension CPU must be done via the USB port of the CPU extension.

7.
It’s possible to put the extension CPU into the CPU firmware download mode by pressing the Run / Halt button on the extension at the power on of the PCD for 3 seconds. (marked with the red circle on the picture below)
The firmware download mode will be indicated then by two Leeds near to the Run / Halt button which are flashing alternatively green/red (one LED) and yellow the other LED.
To get to this Run / Halt button on the extension, you must remove the housing of the extension.
You will need to remove the battery module and any memory modules from the PCD and loosen the screw on the extension housing.
After, remove the housing.
The Run / Stop button is located next to the Run / Stop switch

In June 2017:
the COSinus FW 1.26.31 was released as maintenance version for the systems:

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

the BACnet and LonIP FW 1.26.31 was released as maintenance version, which do support the BACnet Revision 9.
To support the BACnet Revision 14 it's necessary to use the PCD and the BACnet FW 1.28.xx.

In March 2017:
the COSinus FW 1.26.28 was introduced into production for the systems:

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

the BACnet and LonIP FW 1.26.28 was introduced into production

In June 2016:
the COSinus FW 1.26.15 was introduced into production for the systems:

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

The COSinus FW 1.26.16 was introduced into production for the systems: PCD3.T665/T666/T668.

The BACnet and LonIP FW 1.26.15 was introduced into production

Attention:
The firmware 1.26.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 or 1.26.xx to a not compatible PCD.

Firmware 1.26.31 (June 2017)

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.

Firmware 1.26.28 (March 2017)

Improvements

• Text Ram can now be cleared (all chars are set to blank space) with the cgi interface by writing a zero length string.
• Ping request on ETH2 over rooter from different sub net.
• LonIP Mapper improvement
• Web Server RAM Disk increased
• Error Led not set on IR overflow

Main corrections

• All PCD's: MC0 communication with F2xx module and related communication flags are handled correctly in case of transmission
• All PCD's: Text Ram can now be cleared (all chars are set to blank space) with the cgi interface by writing a zero length string.
• All PCD's: Multiple AlarmLists with similar names will now be "initialized" correctly.
• All PCP's: TCP client keep alive is not working when anonymous port is used.
• All PCD's: Profi-SBus GWY does not wor, Profi-SBus Master/GWY stop working after cable is re plugged.
• All PCD's: PCD crash when use DIGI(R)/DIGO(R) with first parameter as FB parameter.
• All PCD's: Correction for modbus RTU communication over F2xx communication module
• 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.
• PCD1.M22x0: While changing the analog output value, the Watchdog is switching. Switching the Watchdog Relais over the corresponding flag has no influence.
• PCD2.M4x60: Sometimes the Profibus DP module is not initialized correctly on startup.
• PCD2.M5xx0: When Restore program because of a missing or dead battery configuration (SBus/IP,..) is not restored correctly.
• PCD2.M5xx0: 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 occuring at the moment of the timeout.
• PCD2.M5xx0: Sometimes config is lost after download project with self-download tool.
• PCD3.Mxxx0: Battery status shows FAIL also if battery module is missing.
• PCD3.Mxxx0: FTP server processing with long commands resolved.
• PCD3.Mxxx0: 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 occuring at the moment of the timeout.
• PCD3.Mxxx0: Sometimes config is lost after download project with self-download tool.
• PCD3.Mxx60: Profi-SBus/DP/SIO does not work on port 2 on PCD3.M3x60 & PCD3.M5360.
• PCD3.M6860: Ping request from over rooter from different sub net is not respond.
• PCD3.M6860/M880: Profibus/S-IO/Profi-SBus does not work stable.
• PCD3.M6860: Set PCD to HALT if there is no or incompatible media transfer between the two CPU's.
• PCD3.T66x: The RIO Status web page does not allow to clear the diagnostics.
• BACnet: The memory usage of the BACnet FW was increasing for every SubscrobeCOVProperty service, which has been received by the PCD.
• BACnet: A client configuration for Priority_Array properties in commadable objects (e.g. Analog-Value) does now allow reading (ReadProperty/COV) and writing (WriteProperty service to server) at the same time.
  
  

Firmware 1.26.15 (June 2016)

New features

• Support of PCD1.M2220-C15
• Support of PCD2.M4x60
• Support of PCD3.M3160/PCD3.M3360/PCD3.M5360
• Support of PCD3.M6880, PCD3.T668 Standby-CPU-System

Improvements

• PCD2.M4x6x, support Interrupt when reaching the configured ref Value
• PCD1.Mxxx0, PCD2.M4x60, PCD3.Mxx60 PCD7.D4xx: Increase None Volatile Register to 1000
• PCD3.T666/8: Increase the User Program Memory for to 256k
• PCD3.T66x: Support the ESIO manager use tag values for IP address
• PCD2/3.F2xx modules Baudrate: Support 300/600/1200 baud settings for in MC mode.
• S-Monitoring: In bar displays where the current time is visible, the average for the period is calculated not in a optimal way (time slice, ref time, is a bar). New it's displayed in seconds
  
  

Main corrections

• PCD3.M6860/M6880: When update FW on extension using the file system after update the extension FW can stay in an endless loop
• PCD3.M6880: crash wen Timmer/Counter is mapped in the Read Symbols
• PCD3.M6880: PCD can crash with MuKe Error when use the SBus GWY in parallel with modbus TCP
• PCD3.M6880: Standby CPU1 does not always HALT when CPU0 crash
• PCD3.M6880: CPU0 to 1 From Read data communication sometimes stop works
• PCD3.M6880: Add a Transmit Error diagnostic tag "DataTxErrors"
• PCD3.Mxxx0: Battery module on IO slot 3 does not show battery status in history
• PCD3.Mxxx0/PCD1.M2xx0: Some baudrates on onboard ports are not correct
• PCD2.M4x60: RTC read/write locks the PCD for about 30ms
• PCD2.M4x60: Modem does not work because of the not working DCD
• PCD3.T66x: Add ELine CSF library
• PCD3.T66x: Serial com does not work with SASI instruction
• PCD3.T66x: CSF Modbus Server Init gives an error when port 502 is used becasue this port is already open
• PCD7.D443WT5R: Assignation/Configuration of port 1 should return an error because port 1 is not supported
• PCD7.D443WT5R: Remove IO access from the system. PCD goes now in HALT with "INVALIDE OPCODE"
• PCD2.W220 with Pt1000: Significant deviation between singel channels
• BACnet: List Properties (like Date_List, Exception_Schedule, ...) could disappear after a PCD restart, if a WriteProperty request with an empty list value has been received for these properties before the restart. This behavior was only present for persistent properties
• BACnet: The Log_Buffer property of a Trend-Log object could not be read anymore using the ReadRange service, after a Event-Log or Trend-Log-Multiple has been read via ReadRange
• BACnet: Writing a single analog output channel is not working. The output is not changing. Writing output channels over the mapped functionality is working
• BACnet: PCD with BACNet loops with restart if program has "INVALIDE OPCODE"
• Restart Warm does not work
• SBus ELine has sometimes retries
• When create a Text/DB the backup fails until a restart is done
• PCD Crash with BUS ERROR on STXT instruction when text is empty
• Modem does not work correctly
• Modem does not work or PCD crash when modem is configure
• PCD can crash when error occurs in Modbus RTU
• The PCD crash if a BITI is executed with number as FB parameter
• PCD crash when use Profi-S-Bus Master
• Sometimes the program is lost when update FW from 1.24.xx to 1.26.xx
• MOVX/DIVX function where not working on Task or Temporary data when use indexed
• Add config tag value for GWY mode "data_no_secure" to deasble the secure data mode
• Not possible to upload a file through the Web server FTP interface (ftp.cgi or ftp.json) if that file starts with a white space character (either a space or a tab)
• CSF CopyDBBytesToR crash when destination is bigger than last Register
• Diagnostic Flags in S-Bus Master mode are not correct if there are collisions on the RS-485 network
• CSF Backup/Restore Media does give an error on restore when data change while backup/restore
• MOV instruction with type position as FB parameter gives error flag and fails
• Web-Alarm: Fix alarming color with "group color mode" and group bigger than 8

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

The analogue inputs of the PCD3.M90 CPU are able to handle NTC10k temperature sensors.

To be able to read an NTC10k sensor it’s necessary to make the following things:

1.Hardware configuration:
For the analogue inputs which does have connected NTC10k sensors, it’s necessary to set two jumpers on the PCD3.M90 I/O print on the selection of the input type (temperature, current, voltage)

One jumper have to be put on the first two pins (for temperature)

The second jumper have to be put to the pins 3 and 4 (for voltage) as shown on the image below

2.Software:
Although it’s possible to select the sensor type NTC10k in the ‘DDC_M90 An_In’ F-Box, the output of this F-Box doesn’t provide the correct temperature value.
It’s necessary to place one of the two available 20 point linearization F-Box behind the analogue F-Box as shown on the print screen.

On the ‘DDC_M90 An_In’ F-Box do use the ‘default scaling’ for the ‘scaling’ parameter and the ‘NTC10’ or ‘1 : 1’ on the ‘mode selection’ option field.

Relation of the read out values to the temperature which need to be used on the 20 point linearization

On older PCD’s it was possible to set the PCD3.Mxx6x in to the firmware download mode by switching the run/stop switch (below the M1 memory slot) quickly several times during the start-up of the PCD.
On newer PCD’s it’s no more possible to set the PCD in the firmware download mode with this procedure.                 

Reason:

New PCD3 power CPU’s (PCD3.Mxx6x) are delivered from factory with a new booter version.
This new booter version does change the behaviour of the Run/Stop switch on the PCD3 power CPU’s in that way, that it’s no more possible to put the CPU in the “boot” state mode by switching the Run/Stop switch (below the M1 memory slot) quickly several times during the start-up of the PCD.

The “boot” state mode is used to download the FW in to the PCD.

The following systems are concerned:
• PCD3.Mxx60
• PCD3.Mxx67
• PCD3.Mxx80
• PCD3.M96xx

Version number of the booter:
• 1.24.11 or newer

How to detect the booter version of a PCD?
Either with the information on white sticker on the back of the PCD

or from the hardware information of PG5 online configurator.

How to set the PCD in the “boot” state mode?
It’s possible to put the PCD in the “boot” state mode with the help of the Run/Halt
push button (near of the USB connector) as described in the PCD3 manual.

Extract from PCD3 manual:

Remark:

Use the Run/Halt push button to put the PCD in the “boot” state mode.
This works on all PCD’s independent of the booter version.

An update of the booter is not required on old PCD’s

A 2,2 voltage of the battery is sufficient to keep the content of the SRAM memory of the PCD even if the PCD is not powered on with the 24VDC.

At power-up, the PCD checks if the battery or supeCAP voltage is less than 2.2. volt, and tests some patterns and signatures in the SRAM.

If one of those test gives an error the content of the SRAM is deleted, the PCD clock is reinitialized. If a Program Backup is available, a restore is done.

The entry  "memory lost nn" is written in the History of the PCD where 'nn' stands for:

Remarks

• In older FW < 1.10.04 the error message in the history was "Media corruption" instead of "memory lost"
  and the nn code was not implemented
• New restore option since firmware version 1.20.00 and PG5 2.1:  
  On PCD2.M5xx0 and PCD3.Mxxx0, systems where the program is stored on SRAM, it is possible in the device configurator of  PG5 to enable a CRC check.
  The test is done over the program or the program and the ROM Texts/DBs.
  
  In case of CRC error, the program is restored and the entry "memory fail 10" is written in the History of the PCD.
  If there is no program backup, and therefore it's not possible to do the restore, the History entry "memory fail 11" will be written.

Attention:
The firmware 1.24.xx can be used only on PCD’s with 8 MB onboard firmware memory.
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 to a not compatible PCD.

Firmware 1.24.69 (June 2017)

Improvements

• 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 commissioning and don't goes anymore 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)
• PCD2.M5xx0 PCD3.Mxxx0: Self-download tool, sometimes config is lost after download of the project.

Firmware 1.24.67 (March 2017)

Improvements

• New Conversation Table for W380 Ni1000 and PT1000 Temperatur
• S-Bus Serial UART Diagnostics not correct
• Various Open Data Mode fixes: Read Timeout enhancement, Client Connection timeout and Client Keep alive with anonymous port issue fixed
• LonIP Mapper improvement
• Modbus Communication error on F2 module
• Program Restore issue fixed when restore from file system flash card
• New PLC Start configuration after Crash added
• Profi-SBus Master stop working when cable is broken
• Various minor issues fixedOpen Data Mode: Data loss if at the same time the connection was closed by the partner

Maintenance firmware 1.24.30 (Mai 2015)

Main corrections

• Web-Server: WebFTP supports correctly encoded characters like “/”, “&” in the web-requests
• Web-Server: ftp.cgi fails to parse the MIME multipart request when boundary string is enclosed in double quotes
• Web-Server: Enable Web-Server CGI access from SBC.NET
• Web-Server: Sometime a modified file was not recognized and therefore not updated in the browser
• Open Data Mode: Data loss if at the same time the connection was closed by the partner

Firmware 1.24.25 (February 2015)

Improvements

• Enhancements and improvements regarding the communication with the new E-Line modules.

Main corrections

• COPYX instruction: the destination is new indexed when a timer/counter is used as destination.
• STXMX / SRXMX instructions are working correctly.
• I/O modules:
  - PCD2.G200: temperature is correctly calculated when Ni100 L&S is selected
  - PCD2/3.W380: support for hardware revision B conversion factor for current inputs has been updated.
• Correction regarding PCD3.M6860: support for the new hardware version 

Firmware 1.24.09 (September 2014)
New features

• Only for PCD2.M5440 and PCD2.M5540
  Recognition of the new type of 8 MB onboard flash integrated in the PCD2.M5xx0

Main corrections

• STXMX and SRXMX instruction make the PCD to crash and reboot
• Write Periphery Byte (WRPB) doesn't work 
• Data Exchange for W5300 module does not work anymore 
• Modbus error when port is doubled assigned.

Firmware 1.24.05 (August 2014)
New features

• Support of the following modules
  - PCD7.W600
  - PCD7.R610
• Easy update functionalities => FW update & restore of the application including the Web pages from a *.sprg file. 
• LON FT-10
• New SFs and communication driver for the E-Line devices
• New test functions:
  - Backup check (TEST 8)
  TEST 8 give the possibility to check in the application program if a Backup file is present and if it is the correct one.
  - FW check (TEST 40)
  After an unsuccessful FW update, it could append that there is no more FW in the FLASH memory but the system is able to run with the "old" FW until next power off.
  The test 40 function allow to detect such a situation.

Improvements

• BACnet Web interface
• 5 min logging in the S-Monitoring
• New SFs in the system library: MD5 hash and AES, DES, 3DES cipher encryption
• Improve the robustness of the system against Ethernet storm
• PCD Modbus client, allow the reception of server answer also if the reply of the server is to fast
  (< 3.5 character time as defined in the modbus specification)
  Modification doesn't apply for F2xx ports, but only for on-board ports

Main corrections

• Modbus:
  - PCD Modbus client, read binary F-Box does show a error, but the function is correctly executed and the data's are correctly processed
  - PCD Modbus server, 32 bits not correctly written to the PCD medias if several consecutive modbus telegrams are received in the PCD
• When an additional Alarming2 configuration (*.asv file) is present in the PCD, the program is blocked in the start-up sequence
• The XON XOFF SASI mode (MC2) does not work on PCD2.M5xx0 port 2
• If the a Smart RIO or Smart RIO manager is disabled with the tag, the manager still sends the configuration to the RIO
• The Program Restore when CRC Error occurs the program is only restored if there is not already a restore done (manual or automatic)
• The PCD Crash with a Bus Error when it is restarted while sent a SMS
• PCD3.M6860 IP on extension stops when extension reboots
• PCD2/3.W380 linearization works only correct if the absolute value of min and max are equal
• On PCD1.M0/M2, PCD3.Mxx60 and PCD7.D4xxxT5F the memory dump is aborted by reading the SRAM
• On Open Data Mode when the TCP connection timeout elapses, the connection remains open while XBSY flag is reset
• Corrections in relation with S-Monitoring
• Corrections in relation with the E-Line modules
• Corrections in relation with BACnet and LON

Due of an error on the FW the overflow status flag of the onboard analogue inputs does not work correctly.

This flag was set to high in the middle of the measurement range and not if the maximum value was reached.

The error occurs on all onboard analogue inputs independent if the analogue input is used for current, voltage or temperature signals on the following PCD’s.
- PCD1.M2
- PCD1.M2 (PCD1.Room)
- PCD1.M0 (PCD1 E-Controller)
- PCD3.M2x30V6 (PCD3 Compact)
- PCD3.M2x30A4Tx (PCD3 WAC)

Solution:
Use the new FW which does fix the error.
The FW is available on the support homepage and it's possible to update the firmware with the
PG5 firmware downloader tool.
For the PCD1.M0/M2 the error was fixed in the PCD firmware.
For the PCD3 Compact and PCD3 WAC, the error was fixed on the dedicated IO-Board FW

Overview about the FW which does fix the problem:
For the PCD1.M0/M2:

For the PCD3:

No, do not connect the RJ45 connector of a Ethernet Port of a PCD directly to Power over Ethernet (PoE).

The RJ45 Ethernet port of the PCD will be destroyed if connected directly to PoE (Mode B) because our Ethernet port (PCD7.F655 or the integrated Ethernet ports on the PCD1.M0/M2, PCD2.M5 and PCD3 and all Panels with Ethernet ports) are not designed for this purpose.

Possible solution to connect PCD to Ethernet networks where PoE is used:
1.
Split the Ethernet network in a section where PoE is used and in to a section where PoE is not used and connect the PCD in to the section where PoE is not used.
The splitting of the network could be achieved with routers which do have on one side connectors with PoE and on the other side connectors without PoE.

2.
Use a special Ethernet cable where the blue/blue-white and the brown/brown-white wires are disconnected.
(On PoE Mode B; the Pin 4 and Pin 7 of the RJ45 Ethernet connector are used to supply the power of PoE to the card,
On the PCD the Pin 1, 2, 3, 6 of the RJ45 Ethernet connector are uesd for the Ethernet communication)

If on the PCD the FW 1.20.nn is used and if on the device configurator a time zone is defined then it's possible that on the S-Web Trend Macro the time stamp of the trend values are displayed with a time stamp offset.

Symptom
The time stamp of the trend values on a S-Web trend does not have the same time as the PCD time (read e.g. with PG5).
The time stamp of the trend values are time shifted for several hours (depending of the selected time zone configured in the PG5 Device Configurator)
Also other macros could have this problem if the PCD instruction SYSRD 7090 is used in the PCD code to read out the PCD time.

Reason
The problem is because on the FW version 1.20.nn the instruction 'SYSRD 7090' (=> Read UNIX TIME) give back the number of seconds since 1.1.1970 00:00:00 as UTC time and not as local time.
On FW < 1.20.nn the instruction give back the time as local time.

Other reason
The default Container on the Web Editor project 'MB_tmz_en' is set to 1.
If you want that the timestamp of the trending corresponds to the time of the PCD this Container should be set to 0.

Solution
In the FW 1.22.nn and later the timestamp is again in local time and a new instruction is introduced 'SYSRD 7190' which gives back the value of seconds in UTC.
The FW 1.22.nn will coming out end of June 2013

In the history of the PCD, different memory lost code can be displayed.

The number beside the memory lost message does give a more precise description why the memory was cleared.

See the table below to know the reason for the memory clearing.

Due of a firmware error on the COSinus FW 1.20.25 it’s not possible to communicate over RS232 on the

port 0 of the PCD2.M5440

and

port 1 of PCD3 CPU’s, but only on PCD’s without Ethernet port.

The error is fixed since the FW 1.20.31.

Also the FW 1.16.69 doesn’t have this error.

PCD’s equipped with a Ethernet port doesn’t have this error.

The concerned PCD’s are:

• PCD2.M5440 (port 0 / RS232)

• PCD3.M6440/M5440/M3230 (port 1 / PCD3.F121)

• PCD3.M3020 (port 1 / PCD3.F121)

• PCD3.M2030V6 (port 1 / PCD7.F121S)

• PCD3.M2230A4T5 (port 1 / PCD7.F121S)

Communication over RS485 works fine.

In January 2014 the COSinus FW 1.22.28 was introduced into production for the systems PCD1.M0xx0, PCD1.M2xx0, PCD2.M5xx0, PCD3.Mxxx0, PCD3.Mxx60, PCD3.T665/T666 and PCD7.D4xxxT5F.
The FW 1.22.61 is the latest maintenance firmware for PCD's with 4 MB firmware memory.                 

Firmware 1.22.61 (February 2017)

New features

• Re-trigger ODM Read Timeout on each read CSF
• ODM Generate Disconnect event even if Server calls the disconnect

Main corrections

• Sometimes configuration is lost after download project with self-download tool
• PCD crash when use DIGI(R)/DIGO(R) with first parameter as FB parameter
• If PCD2/3.W220 with Pt1000 is used a Significant deviation between channels
• Improved HTTP session handing: Session cookies have now httpOnly flag set
• BUS ERROR on STXT instruction if text is empty
• Add config tag value for GWY mode "data_no_secure" to deasble the secure data mode
• PCD crash sometimes on download when Smart RIO are not present
• If broadcast data exchange is used the output telegram is send to only one RIO after a reboot
• The diagnostic Flags in S-Bus Master mode are not correct if there are collisions on the RS-485 network
• CSF CopyDBBytesToR crash when destination is bigger than last Register
• When create a Text/DB the backup fails until a restart is done
• W380 shows wrong values for PT1000 and PT1000L&S
• When starting an application with an alarm list name too long (> 25), the PCD halts with a BUS ERROR
• On PCD7.45x_EM, P-Web panel, Alarm list not loaded after URL jump on a GWY station
• The ACCU not set High at the begin of the XOB
• MB display, red cross if picture filename is empty
• MB display, when scrolling in a Web Editor trend, there was some curve drawing issue
• Updates on the HDLog trends are not displayed on the Microbrowser App

Firmware 1.22.48 (March 2015)

Main corrections

• FTP error due of username
• cgi access trough SBC.NET
• Solved problem when downloading .sprg file in PG5 with download HTTP
• History Message CALL LEVELS shows wrong numbers in the text
  Program address is displayed in the level field
• Fix Profi SIO communication on PCD3.M90, port 10

Firmware 1.22.46 (October 2014)

New features

• Support of the PCD7.R610 module
  - only as file system memory for the PCD.
  Not supported are on the PCD7.R610:
  - Easy update functionalities => FW update & restore of the application including the Web pages from a *.sprg file.
  -> this functions need the FW 1.24.xx

Main corrections

• When an additional Alarming2 configuration file (*.asv file) is present in the PCD, the programm is blocked in the start-up sequence.
• The default GWY is not update correct if the IP address is received from the DHCP server. Only the Global Routing table is updated.
• Backup/restore doesn't work always on PCD3.M90 or OEM (Zxx) systems 
• Program Restore with CRC Error
  The program restore when CRC Error occurs the program is only restored if there is not already a restore done (manual or automatic)
• Improving Performance of PLC in case of Ethernet-Bombarding

Firmware 1.22.28 (January 2014)

New features

• SBC Logo change
• Security Update
• Per default, FTP, Web-Server and S-Bus over IP are deactivated
• IP filtering
• New password mechanism for web-server access
• SFCs for AES128 encryption/decryption
• Dynamic password for FTP (service key)
• FTP Passive mode
• Support new Analog Input Module W380
• Support PCD2.G200 for PCD1.Mxxx0 & PCD2.M5xx0
• Mapping of the PCD3.Mxx60 Interrupt Inputs
• SF to convert time std<->unix time
• Modbus Master, intercharacter timeout on the slave answer as parameter

Main corrections

• FTP data connection error, when downloading many files (more than 150 files) the data connection channel can not be open anymore
• File System compression error if automatic compression is used.
  When the auto compression is active and a "big" file is transfered over FTP (download time > 5 sec), the compression is aborted due to remaining open file.
  After abortion, the compression check is no more executed when downloading file(s)
• Interpreted texts are not working properly
  Correction of bugs with $bxxxx.yyyyy, @xXnnnnn, $AXnnnnn
• PCD1.M2110, does allow to access 10 S-Bus or Modbus slaves, now its possible to access 10 slaves independently of their addresses (was 0..9 address range till now)
• Corrections in relation with BACnet and LON.

Firmware 1.20.25 (March 2013)

Main new Features / Extensions

• Following new systems are supported:
  PCD1.M0160 ;PCD1 EnergyPlus Controller
  PCD1.M2110R1 ;PCD1 Room Controller
• Following new modules are supported:
  PCD7.R550M128 ;128MB memory card
  PCD7.R582 ;128MB memory card with LON/IP
  PCD2.F2150 ;BACnet MS/TP com. module
  PCD2.F2400 ;LON FT-10 com. module
• Support up to 16384 Flags and 16384 Register
• S-Monitoring
• Download in Run
• File System improvements (e.g. date)
• BACnet extensions (e.g. MS/TP)
• LON extensions (e.g. FT-10)
• Access to config parameters via TAGs

Improvements

• Introduce "first time init data" in the restore process
• Improve the reliability of the file system 

The external MPI adapter which can be connected to the MPI Port of the PCD does need to be supplied with 24VDC.

Depending of the hardware version of the PCD, on some FW this 24VDC supply on the MPI doesn’t work.

The table below does show the dependency between the hardware and the firmware in relation with the 24VDC supply on the MPI port.
Classic PCD

xx7 PCD

If for example a Scada system communicate over S-Bus slave gateway port or S-Bus PGU port with a slave station via a master gateway port then after a programm download to the gateway PCD (or if the gateway PCD is restarted) the S-Bus slave gateway port or the S-Bus PGU port of the gateway SPS is blocked.

In order to communicate again through this ports a system reboot (powerup) of the gateway SPS is needed.

This problem could occur on all communication channels between the PC and the PCD (USB, serial, TCP)

Remarks:
This problem appaers when the gateway station is also communicating with its slave station over the gateway master port!

Solution:

Update the firmware of the gateway SPS to the version 1.16.74 or later.

This FAQ explains under which circumstances, which texts are writeable/editable during runtime.

Non-Saia PCD® COSinus Systems (PCD1.M1xx, PCD2.M1xx)
 
With Flash or EPROM Memory plugged
-          Texts < 4000 are not writeable in runtime
-          Texts >= 4000 are writeable in runtime

 With RAM Memory plugged
-          Texts < 4000 are writeable in runtime but PG5 recognizes if one of these texts has changed*
-          Texts >= 4000 are writeable in runtime


Saia PCD® COSinus-Systems
 
PCD3.Mxxx0 and PCD2.M5xx0
-          Texts < 4000 are writeable in runtime but PG5 recognizes if one of these texts has changed*
-          Texts >= 4000 are writeable in runtime
 
PCD3.Mxx60 and PCD1.M2xx0
-          Texts are configurable in the Build Options, define First Writeable Text.




*If one of these texts have changed, PG5 will give a message when you want to go online with PG5 indicating that the 
 program is not the same. Also these texts will be overwritten when the program is downloaded again. 

It is correct that the indication of a low battery will appears earlier due to more accurate prediction on a new Saia PCD® COSinus system than before on a PCD2/1.M1xx.

There are two main reasons to explain this fact:
 
- The supervision function was improved
The new battery supervision function sets the battery under a very small load to predict the end of battery capacity. In term of battery capacity, this additional load is negligible, but allows the system to warn before the battery is really empty. That gives enough time to exchange the battery and preventing memory lost. This is not the case on the previous generation, where only the voltage was supervised.
 
- There is more memory to support
The recent systems have much larger memory; the resulting standby current to be supplied from the Battery increased short the time duration.
 
Summary of working principle with the Lithium Battery
System with passive battery supervision applied on the following PCD’s:
PCD1.M130, PCD1.M135, PCD2.M110, PCD2.M120 and PCD2.M150
The voltage of the battery is supervised.
SBC advise to change the battery all 1 - 3 years.

System with active battery supervision since 2001 applied on the following PCD’s:
PCD1.M2xxx, PCD2.M170, PCD2.M480, PCD2.M5xxx, and PCD3.Mxxxx 
If the 24VDC power is switched on, then the voltage of the battery is measured during short time all 12 seconds where the battery is submitted to a small discharge.
This allows to warn the application program before the capacity of the battery reach its end.
We estimate that in this case the battery has still two days of reserve capacity for the changing of the battery.
In most recent PCD's the battery change can be done from end-user keeping the 24VDC power supply of the PCD switched ON.
If during the battery change, the 24VDC power supply of the PCD remains switched ON then there is no lost of the SRAM content (means that the PCD medias does retain there values)

A lost of the SRAM content (PCD medias like registers, flags and the application program [application program only if there is no application program stored in the Flash memory] does occurs only if the 24VDC power supply is switch off during the battery change.

The specifications in the manual concerning the typical life time of a Renata battery is still correct (1-3 years).

Today, on April 2013 we are able to give more precise lifetime expectancy for the battery for PCD’s produced since July 2012:

However SBC advices to preventable change of the Lithium battery all 5 years

Note that these values are set conservatively; longer lifetime of the battery can be achieved in the practice.

For PCD’s produced before July 2012, above mentioned times could be shorted by 20% due to larger SRam standby current.

The value of standby current is verified on each device during the production.

On the PG5 device configuratior it’s possible to activate/deactivate the RS485/RS422 Bus termination of the port 3 (D-Sub #2 connector; RS485/RS422) of the PCD3.M5340.

If the Bus termination is activated then the following resistors are used.

For RS485 and RS422:

Remark for the RS422:
The following resistors are always used, independent if the bus termination is activated or deactivated on the device configurator.

Due of a firmware error it's possible that on the history of the PCD3.M5340 there is an entry "Resistors Fail".

Symptom
When trying to enable the termination resistors of port 3 of a PCD3.M5340 (produced beginning of 2012) the entry "RESISTERS FAIL" is entered in the PCD history.

Reason
If this error is shown in the PCD history, then it isn't possible to use the RS485/RS422 termination resistors for the port #3 of the PCD3.M5340 (RS485/RS422 port on the 9-pole D-Sub connector) due to a firmware restriction.

Solution
Please update the PCD firmware to version 1.16.60 or later. This firmware can e.g. be found in the lates BACnet firmware maintenance package.

Remark
The communication on the port #3 is possible without problems given the termination of the bus is realized externally.

If the "MDLS144/288 Data9600 onbit" modem is connected to a "non Saia PCD® COSinus" system (PCD1.M1, PCD2.M1) then it's possible to establish a modem connection to those systems but if the same modem is connected to a "Saia PCD® COSinus" System (PCD1.M2, PCD3, PCD2.M5) then it isn't possible to establish a connection.

The reason of this behavior is the difference how the FW of the PCD does handle the modem.

In general the FW does send the as first step the "modem reset sting" and after this the FW does check the status of the DSR / CTS signal before in a second step the "modem initialization string" is send to the FW. 

• On the "non Saia PCD® COSinus" systems the DSR or the CTS signal have to be high before to go to the second step.
• On the "Saia PCD® COSinus" systems the DSR and the CTS signal have to be high before to go to the second step.

Solution
To use the "MDLS144/288 Data9600 onbit" modem on "Saia PCD® COSinus" systems its necessary to set the DSR to high during the first step of the modem initialization.
To do this it's necessary to adapt the "modem reset sting" on the device configurator/HW-settings on Saia PG5® .

The "modem reset string" has to be changed from:
AT&F\r
to:
AT&F&S0\r

Remarks
The "modem initialization string" remains the same.
The modification could be used on "Saia PCD® COSinus" system as also on "non Saia PCD® COSinus" systems.

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 case user program is restored from flash with a PCD3 or PCD2.M5540 with firmware 1.16.xx it is possible (depending on the device configuration) that the restored user program is not complete.

Symptom
The user program of a PCD3 or a PCD2.M5540 is no longer running correctly (one of the program blocks is no longer executed) after it has been restored from flash. This phenomenon can occur with firmware 1.16.xx and if no extended header is present in the device configuration (this means that no IP address, no modem configuration and no gateway is configured).
In case this problem is suspected on a PCD, it can be verified by creating a "diagnostic file" and checking the beginning of the user program section. If there are "UNEXPECTED OPERAND" and "INVALID OPCODE" in the first section, this PCD is concerned by this problem:


Reason
The reason is that during the restore of the program the space required for the extended header is not correcly reserved with firmware versions 1.16.xx.

Solution
Please update the firmware of your PCD to 1.16.52 (available on the support page) or later.

If you need to order separetly the onboard battery module of the PCD3.M5/6 CPU (which is normally part of the standard delivery of a PCD3.M5 or a PCD3.M6) please use the following article number: 4 639 4898 0

Due to an error in the PG5 device template file of PG5 2.0.200 it’s not possible to switch on/off the digital outputs of the PCD3.compact CPUs. (PCD3.M2030V6, PCD3.M2130V6)

Problem
Due to an error in the PG5 device template file of PG5 2.0.200 it’s not possible to switch on/off the digital outputs of the PCD3.compact CPUs. (PCD3.M2030V6, PCD3.M2130V6)

Solution
Either use a version of PG5 2.0 more recent than 2.0.200 or copy the attached file "pcd3compactfamily.saiaxml" into the folder:
c:\Program Files\SAIA-Burgess\PG5_20\DeviceTemplates\ and restart PG5 2.0.

Due to an error in the PG5 device template file of PG5 2.0.200 it’s not possible to switch on/off the relay outputs of the PCD3.WAC CPUs. (PCD3.M2230A4T5, PCD3.M2330A4T1, PCD3.M2330A4T3, PCD3.M2330A4T5)

Problem
Due to an error in the PG5 device template file of PG5 2.0.200 it isn't possible to switch on/off the relay outputs of the PCD3.WAC CPUs (PCD3.M2230A4T5, PCD3.M2330A4T1, PCD3.M2330A4T3, PCD3.M2330A4T5).

Solution

• Please use PG5 2.0.210 or higher
• or copy the attached file "pcd3wideareafamily.saiaxml" into the folder:
      c:\Program Files\SAIA-Burgess\PG5_20\DeviceTemplates\
  and start PG5 2.0 again
  

On download of a big program with PG5 2.0.200 to a PCD1.M2xx0 or PCD3.Mxx60 the error message "Command not accepted: NAK response" can be returned by the downloader.

Symptom
When downloading a big program with PG5 2.0.200 to a PCD1.M2xx0 or PCD3.Mxx60 and in the option "Halt the PCD" before download is activated, the error message "Command not accepted: NAK response" can appear and the download is aborted.
§Ix101355§

Reason
The problem in this case is that the commanded restart of the PCD does take longer than PG5 expects. The restart is commanded in order to bring the PCD into a defined state during the download.

Solution
Please update your PG5 to version 2.0.210 or later.

Remarks

• In case it is not possible to use version 2.0.210, the following workaround could be applied:
  Activate "Stay in run" before download in the Download Program to solve this problem.
  §Ix101356§
  It isn't possible to select the option "Delete Backups from all Flash Cards" if the PCD is not halted (and the download is not possible if the PCD is halted before download due to the above described problem.
  In order to work around this trouble, just select "Backup to Onboard Flash" and "Backup to Flash Card" (if you have plugged a module e.g. in M1 slot). This way the backups will be deleted automatically before the new backup is created.
  
  
  
  

When updating the PCD firmware from 1.14.xx (or earlier) to firmware 1.16.27 the user program, its backup as well as the PCD configuration is lost.

Symtom
When updating the PCD firmware from 1.14.xx (or earlier) to firmware 1.16.27 the user program as well as the PCD configuration is lost.

Reason
The reason for this loss of the user program and the user program backup is that the onboard flash is reformatted. This task is executed right after the firmware update and is required for the generation of an internal (hidden) file system where the new user program backups can be stored.

Solution
In order to avoid data loss of the installation please execute the following steps for updating the firmware:

• For security reasons always update the firmware by an USB connection (and not over the network)
• Before updating the firmware, execute an "Upload all..." of the PCD (from the Online Configurator menu "Online"):
  
• Download the firmware 1.16.27 or more recent. Note that after the download the Error LED is lit and the Run Led blinks for some seconds; during this time the onboard flash is reformatted
• Download your *.im5 file you created with "Upload All..." 

Additional information

• Thanks to this reformatting the new "user program backup to file system" can be executed.
  This backup also includes the media content (R, F, T, C) and the configuration of the IP Enhancements (DHCP, SNTP) and the configuration of the FTP and HTTP server of the PCD. See FAQ 101622
• Additionally, the "Extension Memory Backup size" is now always 256 kByte, independent of the hardware. The available memory for the user program is not reduced by configuring the "Extension Memory Backup size". See FAQ 101623
• The S-Bus and IP configuration remain valid even if the user program is lost
• PG5 2.0.150 with patch 3 or later shows now a warning if the user program and/or the user program backup is lost before the firmware download starts
  

In July 2012 the firmware 1.16.69 was introduced into production for the systems PCD1.M2xx0, PCD2.M5xx0, PCD3.Mxxx0 and PCD3.Mxx60.

This FAQ lists the main differences between this firmware and the version 1.14.23 (and 1.16.69).

The main reasons for the introduction of the version 1.16.69 are the following improvements and corrections.

Firmware 1.16.69 (July 2012)

New features

• Support of PCD7.R582 module

Main corrections

• 'Resistors fails' error on the port 3 of the PCD3.M5340 (FAQ 101722)
• Wrong 'ESIO' history entry for smart Ethernet RIO’s see (FAQ 101778)
• Sporadically wrong temperature values on W745 Module if used without F-Box
• Not possible to read values from specific M-Bus devices (FAQ 101762)
• Restore from Flash (PCD3/7.R500) does not work if performed in PG5 (FAQ 101779)
• The mapped input data from the IO's are not cleared correctly
  During start-up of the PCD, instead of clearing the correct media some other random medias where set to 0
• Different enhancement and corrections on Modbus

Firmware 1.16.52 (November 2011)

New features

• Support of the M-Bus modules PCD2.F27x0 and PCD3.F27x
• Support of firmware download to F2xx modules

Main corrections

• The restore from flash works correctly also if no extended header is present (see FAQ 101680)
• Configuration of analogue modules PCDx.W525 in the Device Configurator lead to “No Response” on program download
• S-Bus password could not be set in Parity mode over a gateway station
• Heavily disturbed FDL networks could lead to a BUS ERROR of the PCD 
• The onboard digital outputs (from PCD1.M2 and PCD3.M2) were cleared even if "don't clear outputs" was selected
• Profi-S-I/O master did not work with more than 10 slaves (but "SIO FAIL 000" is indicated in the history)
• Profi-S-I/O master did not work on PCD1.M2 and PCD3.Mxx60 if the master station address was higher than 22
• The modem signal DCD on port 1 of a PCD3.Mxx60 was not read correctly

Firmware 1.16.45 (July 2011)

Main corrections

• After the program has been restored on the Smart Ethenet RIO Manager the data exchange to the RIO was no longer working (only concerns PCD2.M5 and PCD3.Mxxx0) , see FAQ 101640

Firmware 1.16.42 (July 2011)

New features

• Support of Smart Ethernet RIO PCD3.T665 | PCD3.T666
• Media mapping data (for Ethernet RIO and local Media mapping) is cleared at the same time as the I/O reset is done (including Power-on)

Main corrections

• When using a slow connection for an FTP transfer of big files the transfer could fail due to a timeout in the send process
• Change the backup file name to: "progname_yymmddhhmm.sbak" (before the year was in the middle, making sorting more difficult)
• PCD as Modbus RTU server (and a Siemens RTU is master) can stop answering requests after hours of operation
• PCD as Modbus IP client could go in halt due to a Bus Error if an invalid Modbus frame has been received (with only the Modbus IP header but no data)

Firmware 1.16.27

New features

• Program backup to file system including media content, see FAQ 101622
• Extension memory backup size to flash has now a fixed size (256 kByte) without re-ducing the available memory for the user program, see FAQ 101623
• The maximal length of an SMTP user name and password is extended to 128 characters, see FAQ 101590

Main corrections

• If the file system of a blue memory card was filled to the last byte, it was possible that the file system was no longer available after a reboot, see COM11031 / FAQ 101559
• If the SMTP servers stopps working while an Email is transmitted, the SMTP client could block, see FAQ 101610
• The HMI Editor option "Support all media types" was not supported on the PCD1.M2120, see FAQ 101549
• CSF InitDBItems could overwrite the subsequent DBs
• USB connection failed sometimes after a firmware download
• Answer to FTP command CWD returned the code 250 instead of 200
• Download in Run of changed Steps or Transitions could lead to “INVALID OPCODE”
• The IL instruction WTIME wrote an impossible time when called with an invalid value

Hardware compatibility of firmware 1.16.27

The firmware 1.16.27 requires a PCD equipped with 4 MB onboard flash (like the firmware 1.14.23). Therefore the minimal hardware versions for installing the 1.16.27 and later are:

For PCD3 systems older than listed the firmware 1.10.61 is the last firmware which can be installed on these systems. This firmware is and remains available on the support site in parallel to the 1.16.27.

Remarks 

• When updating from 1.10.xx or 1.14.xx
  Please note that the user program, user program backup as well as the communication settings are lost during the firmware update from 1.10.xx or 1.14.xx to 1.16.xx 
• BACnet applications
  The BACnet firmware compatible to firmware 1.16.42/45 is version 1.16.41. Please use the “Latest BACnet Firmware Package” (version 2) from the support site for PCD1.M2, PCD2.M5 and PCD3 systems in BACnet applications as usual (link below).

In the Device Configurator there is a parameter "Extension memory backup size". Using this parameter the size of the memory for backing-up DBs in runtime (in IL) was configured for firmware versions before 1.16.27.

Starting with firmware 1.16.27, this size is always 256 kByte (and the available size for the user program is not changed by this configuration).

Introduction
In the Device Configurator there is a parameter "Extension memory backup size":

Using this parameter the size of the memory for backing-up DBs in runtime (in IL with the instruction SYSWR K 3xxx) was configured for firmware versions before 1.16.27.

Usage before firmware 1.16.27
With firmware older than 1.16.27, configuring an "Extension Memory Backup Size" reduced the size of available program memory by the double amount of configured backup size.

Usage with firmware 1.16.27
Starting with firmware 1.16.27 the available "Extension Memory Backup Size" size is always 256 kByte, independent of the used system or the configured parameter in the Device Configurar. The available size for the user program is not changed by this configuration. Therefore the configuration can be set to "None" and the memory is still available.

Explanation
The explanation is that now the backup partition is no longer a "linear" partition but a file system.

With firmware 1.16.27 it is possible to write the user program backup to the file system. This new backup does also include the media (register, flags, timer, counter) as well as the configuration of IP protocol configuration such as the FTP and HTTP server settings.

Introduction
Since the first release of a PCD3 or PCD2.M5 it was possible to store the user program to flash by a "Copy user program to flash". The first version of this backup mechanism was copying the user program together with the hardware configuration (S-Bus address, IP address, memory allociation) to a "hidden" flash section (on-board or present on e.g. a PCD7.R500). This backup does not include e.g. the FTP server configuration, the DHCP configuration etc. The content of the registers, flags and counters were not included in the "linear" backup.

In order to improve the backup functionality a new backup strategy has been implemented in firmware 1.16.27 and more recent firmware releases. With this firmware the backup is written to a file and contains also the media contents and the configuration of the IP enhancements and FTP/HTTP server:

Content	"old" linear backup	linear backup to     hidden onboard flash  FW before 1.16.xx	FS backup to hidden   onboard flash  FW 1.16.27	new file system backup (to flash memory card or INTFLASH)
User program and  memory allocation
RAM and ROM DBs  (at the time of the   backup)
S-Bus settings  (Serial, IP address,  Modem, password)			*)
Content of media  (R/T/F)  e.g. first-time-inits
IP protocol settings   (DHCP, FTP, HTTP  etc.)			*)
Smart RIO files  (PCD3.T66x  programs)			*)

*) The configuration of the IP extensions as well as the program files are stored on the onboard flash and thus are remanent; this is why they are not included to the onboard backup file.

Location of the backup on the file system
The backup file is always written to folder "PCD_BACKUP" in the root of a flash module (e.g. "M2_FLASH:/PCD_BACKUP")
The name of the backup file starts with the device name from the PG5 project (first 8 characters), followed by the current date and has the extension "*.SBAK":

The file system backup to the onboard flash is done to a hidden file system.

How to create a backup to the file system?
PG5 2.0 SP2 provides an improved dialog for the definition of the destination device of the backup. With PG5 2.0.150 or PG5 1.4, the backup can be done as usual as soon as the folder "PCD_BACKUP" has been created manually on a flash module.
In case several flash modules are present on the PCD, the first device in the following order (from left to right on a PCD3.M5) will be used for the backup and restore:

• M1_FLASH:/PCD_BACKUP
• M2_FLASH:/PCD_BACKUP
• SL0FLASH:/PCD_BACKUP
• SL1FLASH:/PCD_BACKUP
• SL2FLASH:/PCD_BACKUP
• SL3FLASH:/PCD_BACKUP
• INTFLASH:/PCD_BACKUP (PCD3 Compact or WAC)

 Additional remarks

• Every time a new backup is created, the existing backup in this folder will be deleted by the PCD
• The backup on the file system has priority over an existing "old" image backup on the device.
• If there are several backup files in the same folder "PCD_BACKUP", there is no rule which the PCD will take!
  --> don't copy several backup files to the same folder
• It is possible copying the backup files from one PCD file system to another e.g. using FTP access
• PG5 2.0 SP2 will be able to generate backup files directly
• The "old" linear backups (restore as well as the creation) are still supported also with firmware which support the new file system backup mechanism
• The IP extensions (DHCP, PPP, DNS, FTP- and Web Server configuration) are not included to backup to the onboard flash
• Because the new FS backup is written to a file system, the memory cards containiing the "backup partition" (PCD3/7.R500, PCD3/7.R551 and PCD3/7.R651) modules are no longer necessary; the backups can be written to any flash card with a file system.
  

Firmware dependency for the "file system backup"

Systems not listed in this table do not support the user program backup to a file system.

In some special cases it can happen that suddenly it's no longer possible to transmit SMS messages from a PCD3 WAC (PCD3.M2230A4T5 or PCD3.M2330A4T5).

This problem only occurs on PCD3 WAC with GSM modem and with HW version smaller than B and was fixed with the HW version B (and higher).

Solution
To solve the problem there exist two possibilities:

• Use the hardware reset of the GMS modem after each sending of SMS or if the transmission of an
  SMS message fails.
  The flag for resetting the modem is mapped to the IO.DigitalOutput7 of the device configurator of PG5 2.0 (see below).
• Use a PCD3 WAC with HW version B or higher.
  

Remarks

• To ensure a high availability of the PCD3 WAC on the GSM/GPRS network, it is strongly recommend to reset the GSM modem regularly (e.g. once at day as done also from other GSM/GPRS modem supplier).
• The reset of the GSM modem could be performed by setting the Flag which is mapped to the IO.DigitalOutput7 of the device configurator of PG5 2.0.
  To use this reset function at least the I/O board FW 1.00.11 is required (all PCD3 WAC deliverd after July 2010 do have this or a more recent I/O board firmware).
  In case you have a pilot version (e.g. hardware version A), please ask your local sales representative for the I/O board FW 1.00.11 or later.
• Make sure that the modem is not used by the programmed application if the reset of the GSM modem is performed.

In some PCD3 WAC projects where the PPP- and GPRS-diagnostic FBoxes of the Wide Area Automation library (WAA library) are used the following problem was observed:

After program download and setting the PCD to run, the FBoxes are active without any error but the output values of the FBox "GPRS diagnose" is 0 even if the modem is initialized.

Symptom
In some projects where the PPP- and GPRS-diagnostic FBoxes of the Wide Area Automation library (WAA library) are used the following problem was observed:
After program download and setting the PCD to run, the FBoxes are active without any error but the output values of the FBox "GPRS diagnose" is 0 even if the modem is initialized:


Reason
The reason for this situation is that the FBox from the library version 2.6.150 has expected a "Clean All Elements" in order to correctly initialize.

Solution
Please update your WAA FBox library to version 2.6.151 or later and re-build / download your project. This FBox library version can be found on the support site.
In case it is not possible updating the FBox library, please execute a "Clean All Elements" before running the PCD (e.g. with the Online Debugger).

Remark
This FBox library version will be part of patch 2 for PG5 2.0.150.

Please read this FAQ in case you are updating the firmware from a PCD to 1.10.xx or 1.14.xx to 1.16.xx/1.20.xx(e.g. from 1.10.51 to 1.20.xx).

Before updating the firmware from your PCD from a version 1.10.xx or 1.14.xx to 1.16.xx/1.20.xx, please read the following points

• When updating the firmware of the PCD from a version 1.10.xx or 1.14.xx to 1.16.xx/1.20.xx the content of the memory is lost (user program inclusive backup, hardware configuration, register, flags etc.).
  The reason for this loss of memory is that the memory structure has been changed in order to allow more flags.
• In order to avoid the loss of any data, please "upload all" before updating the firmware (for that you can "download all" after updating the firmware.
  - Note that you'll need the USB port after the update (as your S-Bus address might be gone).
• Alternatively, you can also copy the user program to flash and upload the content of the media before the update (e.g. with the "Quick Data Transfer).
  In this case the program and the hardware configuration will be restored from flash after updating the firmware (for going online and downloading the media content after the FW update).
• PCD3 systems with hardware older than "D" (and PCD3.M3020 and PCD3.M3120 with hardware older than E48) can not be updated to firmware version 1.14.xx or later because these platforms are not equipped with enough memory to hold the firmware 1.14.xx. In case a FW 1.14.xx or more recent is loaded to one of these systems, the PCD will remain in the boot loader state after the download of the FW (in this state, a 1.10.xx can be loaded again).
• All PCD2.M5 systems can be equipped with a firmware 1.14. and more recent.
  

In case I/O addresses higher than 1024 are accessed with a PCD running firmware 1.14.23, the PCD will not go in run an loose its USB communication.

Symptom
In case the user program accesses I/Os with addresses over 1024 on a PCD running firmware 1.14.23, the USB communication is lost just after download of the program (the PCD will remain in Halt state in this case)

Reason
The firmware does not correctly react to the access of the I/Os over 1024 (wich do not exist) and therefore gets a bus error on address 100D9FF2H.

Solution
Please avoid the access to I/Os with address 1024 (which makes no sense, these I/O do not exist).
Starting with firmware version 1.14.30, the PCD will no longer go in halt but just ignore these accesses.

If you open the standard status page on a PCD there are some additional parameters shown which aren't obvious.

You can display the status page of a PCD with the URL
(address of PCD)/status.htm



Please find the necessary informations in the following text.

Speed:
Time assigned to the Web Server task in milliseconds.
Range: 1..15
Default: 5
Requirements: PCD3Mxxxx, PCD2M5xxx, Firmware > 1.10.00

Priority:
Priority of the TCP Web communiction driver in the Web Server.
Range: 1..12 (1 means highest, 12 lowest priority)
Default: 10 (standard port) and 5 (command port)
Requirements: PCD3Mxxxx, PCD2M5xxx, Firmware > 1.10.00

With firmware version 1.14.23 of the PCD3.Mxxx0 and the PCD2.M5xx0 the amount of available flags has been increased from 8191 to 14335.

Extension of amount of available flags on a PCD
With firmware version 1.14.23 the amount of available flags has been increased from 8191 to 14335. In order to use these flags, the firmware needs to be updated to version 1.14.19 or higher and PG5 2.0.150 (SP1 for PG5 2.0) is to be used.
In the "Build Options" from PG5 2.0 SP1 the range of dynamically used flags can be increased to 14335:


Supported hardware
The following hardware systems support the flag extension:

• PCD1.M2xx0
• PCD2.M5xx0
• PCD3 (see remark below)
• PCD3 Power CPUs (PCD3.Mxx60)

Remarks

• Please note that while the instruction list command set of the PCD fully supports the new range of 14335 flags, it is not possible to use them in "interpreted texts" (where "$Rnnnn" will be replaced by the value of the register with address "nnnn") because the syntaxt for the interpreted texs only supports 4 digits.
  This can lead to problems in case the dynamically addressed flags are used for the "HDLog to File" FBoxes for binary values. If this is the case it is recommended to configure the media allocation for dynamically addressed flags to a maximum of 9999.
• PCD3 systems with hardware older than "D" (and PCD3.M3020 and PCD3.M3120 with hardware older than E48) can not be updated to firmware version 1.14.xx because these platforms are not equipped with enough memory to hold the firmware 1.14.xx.
• When updating the firmware of the PCD from a version 1.10.xx to 1.14.xx the content of the memory is lost (user program, hardware configuration, register, flags etc.). Please "upload all" before updating the firmware (for that you can "download all" after updating the firmware. Note that you'll need the USB port after the update (as your S-Bus address might be gone). The reason for this loss of memory is that the memory structure has been changed in order to allow more flags.

The resources (registers, flags, timers, counters etc) and possibly the user program and the text strings/DBs on a PCD3.M3xx0 are stored in RAM. To ensure that they are not lost and that the hardware clock (where present) continues to run when there is a power failure, the PCD3s are equipped with a buffer capacitor (SuperCap).

Unfortunately the time has not been specified correctly in the manual 26/789 until version 11 of the manual. The duration is 4 hours and not 8 hours (after the SuperCap has been charged while 10 minutes).

A "Bus Error" (which is indicated in the history of the PCD) indicates that the firmware was not able to execute an internal command (reading from the memory bus).

Symptom
In case of a "Bus Error" the firmware of the PCD2.M5xx0 or the PCD3 has experienced a serious problem because an internal command could not be executed correctly. In this situation the PCD is automatically restarting the CPU for security reasons. After the automatically executed restart the PCD will

• go in "Halt" if no Software Watchdog is programmed in the user program
• go in "Run" in case a Software Watchtog is programmed in the user program

Reason
The reason for a Bus error is usually a combination of a situation which is not correctly treated by the firmware. A "Bus Error" is not related to e.g. S-Bus (or a serial communication) but to the internal memory bus.

Solution
In case the reason for the Bus Error is one of the following, please update your firmware to version 1.14.23 (or 1.10.61) for a PCD2.M5xx0 or a PCD3:

• The System Function (CSF) S.IPD.ReceiveData/S.IPD.SendData has been called with the remoteIP as undefined Text
• An FB parameter has been provided as operand for the instruction SYSCMP
• A "SASI OFF" has been executed on the serial port which has been used for an online connection
• A Modbus "Init Server TCP" has been executed but the PCD does not have an IP Address configured
• An attempt for reading data from a closed connection has been executed in Open Data Mode
• If I/O with address over 1024 (which do not exist) are accessed (with FW 1.14.23), see FAQ 101518
• If the Modbus TCP "Idle disconect time" is set to 0 with firmware versions older than 1.10.61 (or with a version 1.14.xx)

In case you have observed a Bus Error but the reason can not be found in the list above, please create a "diagnostic file" (from the "Online Configurator" menu "Tools") and provide this information to your local support team.

The System Function (SF library) "DB Access Library" allows e.g. copying texts into text or searching an expression within a text. These features have not been present in the first firmware version, and not all featurs are available on all PCD systems. Therefore please refer to this FAQ for the firmware dependency information.

What are the functions of the "DB Access Library"?
The System Function (SF library) "DB Access Library" allows e.g. copying texts into text or searching an expression within a text. The library consists of two parts, where the second part (including e.g. the SearchText function which allows sarching an expressino within a text) is only supported by Saia PCD® COSinus Systems (PCD2.M5, PCD3).
A detailed description of the functions can be found in the context menu of the "Function selector" from the IL Editor from PG5 2.0:


Firmware dependencies
The first part of the new "DB Access Library" consists of the following functions and is supported by the following PCD systems (systems not listed in the table do not support these features):

Functions

• CopyTextBytes
• CopyBytes
• CopyDBBytesToR
• CopyRToDBBytes
• GetDBItem
• InitDBBytes
• InitDBItems

Functions
The following functions are only supported on Saia PCD® COSinus Systems but not on systems like the PCD2.M150, M170 etc.

• SearchText
• ReadANumberFromText
• CopyNBytesFromTextToText
• CopyAValueFromRKToText
• CopyBytes

Remark
The function "CopyTextBytes" (copy one text into another, and thereby replacing $D, $H, $Rnnnn with date, time, register contents etc.) has already been supported by firmware versions before the ones listed in the first table; for more information please refer to FAQ 100886.

The PCD3 Compact (PCD3.M2xxx) is available in the Network configurator from PG5 2.0 but not in the one from PG5 1.4 300.

Problem
It is generally possible to programm and configure a PCD3.M2xxx compact with PG5 1.4 as long as the PCD3 Compact is not used as Profi-S-I/O Master because the PCD3.M2 is not available as Profi-S-I/O master in PG5 1.4 300.

Solution
This problem can be avoided by programming the PCD3 Compact with PG5 2.0; in the Network Configurator from PG5 2.0 the PCD3.M2xxx is available.

It is possible to use the interrupt inputs (Int0 = i 8100; Int1 = i 8101) of a PCD2.M5xxx or PCD3.Mxxxx as normal input without using the corresponding interrupt XOB.

Symptom
When using I8100 or I8101 in Fupla they are high ("1") even no tension is applied on them; the visualized states of these inputs in a fupla page don't correspond to the real state on the contact Int0 and Int1.

Reason
The reason for this situation is that Fupla does not correctly show the states.

Solutions

• Work-around
  In Fupla page you can add an "Binary Move" Fbox and use the output of this one as state of input 8100 (8101) as shown below  
  
• In PG5 2.0 this problem is corrected in PG5 2.0 SP1 (PG5 2.0.150)
• For PG5 1.4 no correction is foreseen; the work-around explained above can be used in order to visualize the states of the I/O.
  
  

Instead of the maximal value it is just possible to set the minimal value twice.

Problem
In the Device configurator for PG5 1.4 it is not possible to configure the minimal and maximal value for the PCD3 compact (only in case the Device Configurator is used in German language):
§ix101048§
Only the minimal value is availabe, but twice.

Reason
This is a bug in the Device configurator (concerns only the German language version of the Device Configurator).

Solution
Please install patch 11 (or later) for PG5 1.4.300 in order to solve this problem. This patch is availabe on the support site in the PG5 1.4.300 section.

In case a PG5 project has been created in PG 5 1.4.300 without patch 7 or later installed (or in a beta version of PG5 2.0, a $ version) the PCD3 compact was in pilot phase. At this time it wasn't possible adding an extension module (PCD3.Cxxx). In case this project is imported into PG5 2.0.110 the device configurator doesn't show the possibility to add an extension.

Solution
In order to have the possibility for adding an extension to a PCD3 compact please use PG5 2.0.110 or PG5 1.4.301.4 (patch 7 or later).
In the device configurator change of PCD type and then change it back to the original version (e.g. from PCD3.M2030V6 to PCD3.M2130V6 and then back). By doing so, the "+" appears for adding an extension module (e.g. a PCD3.C110Z09 or a PCD3.C200Z09):

The PCD goes into HALT when temporary data size has NOT been defined and an entry "TempData ILLEGAL" gets added to the PCD history.

This error occurs when no temporary data size has been defined.

Description:
Each COB (each task) which calls blocks that use temporary data should contain a "DEFTMP M x" instruction to define the amount of temporary data memory to be assigned to the task, where 'x' is in K bytes. S-Asm normally generates this instruction automatically if it knows that the COB uses temporary data, but because the COB is coded in Fupla and not in IL, and the temp data is accessed from a $COBSEG block, the instruction is not generated, so you must add it manually.

Solution:
The solution is to add the line "DEFTMP M ..." to the $COBSEG directive in the IL file (example):

$COBSEG
       CFB    TestFB
            R 0
            R 1
          DEFTMP M 2
$ENDCOBSEG

With the function codes SYSRD K 3000 or K 3100 it is possible to read the flash status (to check whether the flash is ready for backing up extension memory to flash).

Not all return values are mentioned in the manual versions until version 9.

Read Flash Status

Reads the Flash status and stores it in the ACCU and a Register with a SYSRD

Result

• If the ACCU is set Low and the return value in the register is 0 --> OK
• If the return value in the register is not 0 --> please refer to the list of status bits below for the reason why the flash can not be used.
• If the ACCU is set High  --> if the Flash is busy and SYSWR was not executed.

The Error Flag is set if there is an error. See status bits for details. The destination register contains the status bits (description below)

Status bits

To keep some important values in case of a program restore it is possible to store DBs to the onboard flash using the instructions SYSWR K 310x. When using an additionally memory card (R551, R600), these DBs on the onboard flash are lost.

Problem
On a PCD3.Mxxx0 or PCD2.M5xx0 it is possible to make a user program backup to flash. In case of a program lost, the program is restored. Often it is necessary to restore some values as well. In this case one can copy DBs to the onboard flash using the syswr 3100 (explanation in the manual 26/789). These DBs can be restored as well in case of a program lost. This works well, as long as no additional memory card is in use. As soon as a PCD3/7.R551 or a PCD3.R600/PCD2.R600 is in use, the program backup is stored to the flash card. The DBs on the onboard flash are therefore overwritten during the program restore.

Reason
The reason for this behaviour is, that when executing a program restore, the program is copied from the flashcard to the PCD RAM and to the onboard flash as well. Because of a wrong behaviour of the firmware, the DBs stored on the onboard flash are erased during this procedure.

Solution
The firmware 1.10.51 or higher corrects this problem.

On our Profibus DP Master modules and CPUs there are two LEDs available:

RUN = Yellow

ERROR = Red

Modules and CPUs
The LEDs RUN=Yellow and ERROR= Red are present on the following modules:
PCD7.F750
PCD7.F7500
PCD3.M654x: On this CPU the LEDs are below the cover. Otherwise you can see them if you open the blue cover that covers the battery-module, M1-, M2-Slot and the RUN Stop/switch. Through the little gap where the cover is cliped in, the LEDs are visible:



Status of the LEDs:
ERROR LED:
The ERROR LED is switched on for approximately 1 sec during startup. If the module is working correctly the error LED is switched of afterwards. In case the error LED is switched on or blinking the Profibus DP module has a serious problem that is most probably related to the hardware itself.

RUN LED:
The RUN LED is normally blinking after startup. If it is blinking fast (~10Hz), the Profibus communication is not running correctly. In case the Profibus communication works well, the RUN LED is blinking slowly (~1Hz). If the communication is not working properly, more information is available in the history of the PCD. Check the history of the PCD for Profibus DP FAIL errors (see list below for the meaning of these messages). If there is no entry in the history regarding the DP functionality, you can check the diagnostic flags and diagnostic registers. More information about the Profibus diagnostic is available in the manual Profibus DP 26/765. The manual is at the moment not up to date. Only the PCD7.F750 is mentioned. Otherwise most of the information in this manual like diagnostic information is valid for the PCD3.M654x and PCD7.F7500 as well. We are working on a new version.

PROF DP FAIL xxx (or PROF S-I/O fail if Profi-S-I/O is used)
ERR# Description
0 Key word MODE: not found
0 Wrong mode specified
0 Key word CONF: not found
0 DBX key word not specified
0 DBX number error
0 DBX number to large
0 DBX does not exist
0 Key word DIAG: not found
0 Flag or output key word not specified in DIAG
0 Error in address of diag flag or output
0 Range error diag flag or output
0 Register key word not specified in DIAG
0 Range error diag register
1 PROFIBUS-DP HW card not present
2 Error in instruction
3 DBX structure error
4 DBX type not for DP master (no PROFIBUS DBX)
5 FW-DBX version not compatible
6 No IN RING message after timeout on initialization
7 Semaphore error for data exchange (info to PCD support)
8 DBX error: data transfer function not implemented
9 Incompatible PCD7.F750 and PCD hardware

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.
  

The I/O address 255 is used for the hardware watchdog. Due to this fact this address can not be used as "common" input or output as written in the chapter "Hardware watchdog" from the PCD3 manual.

What for is the output 255 used?
This output has two functions. It is present as "normal" I/O address on the I/O bus and can also be accessed there. But additionally, the same address is also representing the hardware watchdog relay (onboard on the PCD3 CPU).

Which restrictions do result in this situation? 

• On the SLOT_15 (with base address 240) you mustn't plug "analog modules" (PCD3.Wxxx) and also mustn't plug any H-modules (PCD3.Hxxx).
• You can't use base address 255 as Input or Output, because it is use for activate the internal relay. This relay is accesible on the "terminal block for supply, watchdog, interrupt inputs".

Additional information

• When you plug an 16 OUTPUT module (e.g PCD3.A460) and you use the output 255 (and you do not use the Hardware Watchog FBox) the output works as usual (however, as it is recommended using the hardware watchog, it is not recommended using the output as "normal" output)
• When you plug an 16 INPUT module (e.g PCD3.E160) you won't be able to read the state of this input (the PCD will always read "0" even if the physical input 255 is high).

Yes, it is possible to connect one or two encoders with A, B and index signal directly to the onboard inputs of a PCD3.M2x30V6.

How to configure an encoder for a PCD3 Compact?
The configuration is done with the device configurator of PG5 2.0.

The first encoder has to be connected to the inputs 0,1,2 of the PCD.
The second encoder has to be connected to the inputs 3,4,5 of the PCD

More informations can be found on the manual of the PCD3.M2x30V6

Attached you find a PG5 2.0 backup with this configuration!

Remark
PCD3.M2x30V6 needs at least FW version 1.10.16.

Yes, this is possible with firmware version 1.10.15 and later.

With firmware version 1.10.15 and later, it is possible reading the CTS signal from port 3 in case RS422 is used on this port. The CTS signal can be read by executing the SICL instruction (it is also possible if the port is assigned and if the port is not assigned).
Additionally, it is possible writing the RTS and the COM signal using the SOCL instruction (again, only if RS422 is used).

Remark
Please note that the CTS does not exist on RS485 and therefore it can not be read, either.

 

*) HW dependant (only on PCD3.M5340)

It is possible to configure the onboard inputs and outputs of the PCD3.M2xxx with the "device configurator". A download of this configuration is not stored.

Problem
It is possible to configure the onboard inputs and outputs of the PCD3.M2xxx with the "Device Configurator". When downloading the hardware configuration with the "download configuration" button of the "Device Configurator" this configuration is not loaded to the CPU.

Solution
This configuration will only be loaded to the CPU when using the program download button of the PG5 Project manager.
On the other hand it is possible to read the configuration of the PCD3.M2xxx with the "upload configuration" button of the "Device Configurator".

There have been some restrictions concerning the usage of the S-Bus parity mode as master (SM1) on the PCD3.M and PCD2.M5 CPU. Since firmware version 1.10.51 these restrictions are eliminated.

The port 0 and 3 didn't support parity mode as Master between FW version 010 and 1.10.51 (while at this time all other ports supported the S-Bus Parity mode as master).
Since firmware version 1.10.51 it is possible to use the port 0 and 3 as Master in parity mode (all ports support parity mode as master and slave).

When i use for example a PCD3 Compact with 1MB Flash File-System (INTFLASH), the FTP-Client stops downloading data after max. 900kB.

There are more or less 100kB of the File-System memory reserved by the PCD system (64kB are reserved for the File-Compression feature and also some more reserved blocks). The same rule applies to the other PCD file system sizes / devices.

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.

On the first PCD3 hardware series (up to HW version D) the port 2 (RS 485) was the most frequent cause for repair. The reason was that no active protection (supressor diodes) could be present due to the relatively higher frequency (115KB). Some too big potentiel differencies on the port could damaged it!

Improvement
A HW modification was introduced in February 2008: a new IC driver containing supressor diodes is now assembled on all the PCD3 since HW D Modification 3. This modification increases the robustness of this port (note that the specifications given in the manual were already fulfilled with previous hardware version and has been furher improved by this modification).
All PCD3 which are send for repair are updated to this HW version (D mod. 3). Of course the next HW version (E, etc..)  are already equipped with this modification!

The experience shows that despite of this improvement a defective RS485 onboard port 2 is frequently the cause for repairs of the PCD3 systems. In order to avoid a damaged port 2 (on an installation where the common ground potential and an undisturbed signal can not be guaranteed) it is strongly recommended to apply a galvanical separation externally.

In PG5 1.4.300 the new DP Master CPU without ethernet is not available, just the PCD3.M6540 can be selected

Problem
The PCD3.M6440 is not available in the Hardware Settings of PG5 1.4.300. It is not possible to choose another CPU for the configuration

Solution
Install the Patch 5 or higher for PG5 1.4.300. This Patch is available on the support site. The next PG5 version will contain the PCD3.M6440.

In some cases it may be necessary resetting a PCD3 (e.g. because a password has ben set but forgotten).

A PCD3 system with recent firmware can be reset by pressing the Run/Halt button during power up of the PCD and then holding the button down for another 30 seconds. The LEDs will start blinking in another pattern when the memory will be reset.

• Power off the PCD3
• Push the "Run/Halt" button and keep it pushed
• Power on the PCD3 (still pushing the button)
• Keep the button pushed for around 20 to 30 seconds
• After the blinking pattern has changed, release the button. the PCD is now reset with default configuration and without program. 

Remarks

• Please note that in some cases, the backed-up program from the onboard flash is restored right after resetting the PCD.
  In this case, the PCD3 can be reset by using a PCD7.R5xx or a PCD3.R5xx which contains a userprogram (backed-up from another PCD3 system, but with correct memory allocation).
• The "clear memory" button from the PG5 menu "Online" does not work for SBC-NT systems (PCD3, PCD2.M480, PCD2.M5xx0).

Because of a wrong formatting of the MAC addresses printed on the stickers delivered together with PCD3 systems (with Ethernet option), leading zeros have sometimes been omitted.

Symptom
The MAC address shown on the small sticker which is delivered together with a PCD3 with Ethernet option is missing a "0" (see picture below).

The MAC address of this PCD3 is correct, the formatting does only concern the small sticker delivered together with the PCD3. The correct MAC address of this sticker is:
00:50:C2:8D:04:8E

Reason
The missing zero has not been printed due to a formatting error.

Remark
Saia-Burgess Controls AG has recognized this problem in May 2008 and since then the sticker do no longer miss preceding zeros in the MAC addresses.

When using firmware version 1.08.23 the Profi S-Bus address can only be set one time on the PCD3.M6540 port 2.

Symptom
A Profi S-Bus address is configured on port 2 of the PCD3.M6540 (with firmware 1.08.23). This address should be changed but this fails.

Reason
Due to a firmware problem the Profi S-Bus address cannot be changed if it is once set. Only the PCD3.M6540 Port 2 is concerned by this problem.
Firmware version 1.10.16 corrects this problem; with this version the Profi-S-Bus address can be changed as usual.

Solution
In case it is not possible updating the firmware the following workaround can be used:
Press the little Run/Halt button during startup and keep it pressed for around 30 seconds. After about 20 to 30 seconds, the LEDs "Run" and "Halt" will blink. Now you can release the button. If you go online with the Online Debugger "Media Corruption" will be displayed. The CPU program and hardware settings are cleaned. It is now possible to configure a new Profi S-Bus address.

To use the internal flash memory with file system on a PCD3 Compact (e.g. M2130V6), at least firmware version 1.08.12 is necessary!

Since the PCD3.M2xxx is still in pilot phase, the firmware is not publically available. Please contact your local SBC support if you need the firmware version mentioned above!

No. This cable is not designed for connecting a PCD2.Cxxx extension housing.

Connecting a PCD2.Cxxx can damage the involved hardware.

In firmware 03B and 03C an S-Bus broadcast telegram will block the communication interface until the next reboot of the PCD.

Symptom
When using firmware version 03B or 03C on either a PCD2.M480 or a PCD3.Mxxx0, the communication stops working after a sent broadcast. This only applies if the concerned PCD is acting as master on the S-Bus network.
This phenomenon occurs on S-Bus (Serial-S-Bus, Ether-S-Bus or Profi-S-Bus).

Reason
In firmware 03B and 03C an S-Bus broadcast telegram will block the communication interface until the next reboot of the PCD.

Solution
In order to resolve this problem, please update the firmware of your concerned PCD.

The article (order) number is: 4 405 4995 0

The first versions of the PCD3.M5340 controller have been delivered with a firmware that does not support the usage of the RS485 port on port 3.

Problem
The communication RS 485 on port 3 of the PCD3.M5340 is not working correctly. 

Reason
Due to a problem in the firmware, the port is not correctly initialized to RS 485.

Solution
Upgrade the PCD3 firmware to version 1.08.23 or higher.

Remark
There is no problem for the usage of the port 3 as RS422 port.

While the serial PGU port of systems before the PCD3 did always work as PGU port when connecting a PCD8.K111, the serial PGU port of the PCD3 can be configured for using a modem. If this is done, it is no longer possible attaching a PCD8.K111 and establishing a PGU connection.

Symptom
It is not possible going online with the PGU communication mode using a PCD8.K111 programming cable plugged in on the D-SUB labeled "Com/PGU" of a PCD3.M5xx0.

Reason
The port "Com/PGU" of the PCD3.M5xx0 can be used as either PGU port for programming the PCD or for connecting an external modem to the PCD3. In case a modem is connected, the full handshake must be enabled and by doing so the detection mechanism for a PGU connection established with a PCD8.K111 is disabled.
A second reason could be that the firmware 039 is installed on the PCD3. In this case a firmware problem avoids a successful serial PGU connection.

Solution
Connect to the PCD using a USB cable (which always works as programming connection) and upload the current hardware settings of your PCD3.
§ix100519§
After having uploaded the current configuration of the PCD3, check that the checkbox "Full RS232-handshaking on Port 0" is not checked. If it is checked, uncheck it and download the modified hardware configuration in order beeing able going online with a "serial PGU" connection.

If it is still not possible going online with the PCD3, please check the firmware version of the PCD3. Note that the version 039 has a known problem that avoids going online over the Serial PGU connection. In case you are concerned by this problem, please contact your local sales office and request a firmware that fixes this problem (e.g. 03A).

There's a small and nice freeware tool called "Port Query" for checking the IP ports of a system connected to an Ethernet network.

The tool "Port Query"
The "Port Query" tool scans the addressed system (addressed by IP-address) for the indicated ports.
You can choose between UDP and TCP or can scan both types. There are predefined sets of ports to be scanned.

This tool's especially designed for troubleshooting, for example in Open Data Mode, BacNet, FTP communication,
and testing if used ports are open and ready to be used. You can also check with this tool if a router or a firewall
blocks the specified port.

In the example below is shown a scan of the FTP connection, port 21 in TCP, on a PCD3.  

How to get it?
This tool can be obtained from the Microsoft Corporation for free. In order to get it, browse to the microsoft download page (link below) and sear for "PortQry Command Line Port Scanner".

Due to a firmware problem the clock of a PCD3.Mxxxx equipped with a firmware x3x older than version 037 can be corrupted in run time.

Symptom
The clock value of a PCD3.Mxxxx equipped with a firmware x3x older than version 037 can run "accelerated" while the PCD is in run. After a power off / on of the PCD, the clock will be set correctly again.

Reason
This behaviour is caused by a problem in the firmware and is related to the "Soft RTC" which has been introduced in version 030.

Solution
This problem is corrected in firmware version 037. Please refer to the support site where you can find the latest version of the PCD3 firmware in the section "Product information --> PCD3 --> Mxxx0"

Before you can use the SYSWR K 3100 and K 3101 calls, the onboard Flash first has to be partitioned.

To enable the possibility of saving/restoring Text/DB's into/from the PCD3 onboard Flash memory with the SYSWR K 3100 and K 3101 calls,  the onboard Flash first has to be partitioned. This partitioning is realized when you backup the user program to Flash.

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.

No, it is not possible. The Profi S-I/O is a SBC-specific solution. It is similair to Profibus DP but foreing Profibus devices will not work.

Profibus DP Master on PCD3
The new PCD3.M65xx will have a Profibus DP Master port instead of the Profi S-I/O port. On this PCD3 it will be possible to connect non-SBC DP-Slaves.

After the SMS has been sent the error LED is switched on immediately.

Problem
After each transmission of an SMS message the Error LED is switched on on the PCD3. Despide of this the SMS is send correctly.

Reason
The reason is a problem in the firmware. The SMS will be sent properly but the Error LED is always on after the first SMS has been send

Solution
This problem is corrected in firmware 030 and later.

How to update a loaded userprogram with a new userprogram on PCD7.R500

• PCD3 switch power off
• remove the old program flash
• insert the new program flash
• switch the PCD3 on
• press the Run/Halt push button for 3 seconds (the leds are flashing during the update)
• restart PCD3 with the Run/Halt switch 

When choosing the dynamic registers above 8191 on a PCD2.M5xx0, a PCD2.M480 or a PCD3, this error message can appear in case FBoxes are used which apply "indirect instructions".

Symptom
A build in PG5 1.4 failes with error 335:
Error 335: Komm.obj (432): JPI: __stc_C0001_00_01_02: Invalid register number
A build in PG5 2.0 failes with error 2035:
Error 2035: Komm.obj (432): TFRI: PCD.HDA.MacWrk.Reg: Invalid register number, max is 8191 for register indirect instructions

Reason
The problem is that 'register indirect' instructions (SASII, TFRI, STXMI, SRXMI etc.) do not allow register addresses above 8191. As these instructions are used by many FBoxes (Modem-Driver, HDLog or the HMI Editor), the last address of the "Dynamic Space" for registers must not be higher than 8191.

Solution

• In case plenty of registers are available:
  When using indirect instructions with dynamic addresses, the dynamic address range must not exceed the address 8191. This configuration is made in the "Sofware Settings" (PG5 1.4) or "Build Options" (PG5 2.0) of the according CPU/Device:
  PG5 1.4:
  
  PG5 2.0:
  
• In case no more registers are available, try the following procedure
  - Execute a "Clean files" of the CPU/Device
  - Rebuild the project
• In case a simple "Clean files" does not help,
  - Execute a "Clean Files"
  - Check which library causes the problem
  - Modify the "Link order" in order to link the program which contains the TFRI as first program
  - Open the Fupla and export and then delete pages/blocks which do not cause the problem
  - Rebuild the project
  - In case the build is successful: Add the previously removed blocks
  - In case the build still fails: continue to execute the "Clean files" and remove more Fupla blocks/pages

It’s possible to backup the application program and the hardware settings on the flash memory of the PCD.
Each PCD does have an onboard flash and it possible to plug an additional flash memory.  
This allows for example to store the application on a pluggable flash memory and to send then the memory to the end-user which then can restore the program from the pluggable memory.
In every case a backup to flash copies the "User Program" and the "Hardware configuration" to the onboard flash.

If no flash card plugged:
The user program and the hardware configuration is stored to the onboard flash. 

If a flash card for "User Program Backup" is plugged:
The user program is stored to the first flash card detected (in the sequence "M1 Slot", "M2 Slot", "I/O Slot 0..3") on a PCD.
In addition, the Backup is also written to the onboard flash. An existing backup on the onboard flash will be overwritten.

How to restore manually a Backup on the PCD:
Push the reset button (near of the USB connector) for 3s or go in the Online Configurator of PG5 on the menu point ‘Online, Flash Memory, Restore from Flash’

Difference between PCP2.M5xxx0, PCD3.Mxxx0 and PCD1.M0/2xx0, PCD3.Mxx60:
PCP2.M5xxx0, PCD3.Mxxx0:
You have to set the option in the Download window to download a backup in the onboard Flash.
You have also the possibility to download the Backup on a memory card.

Remark: If you store a backup on the onboard Flash and also on a memory card for example M1.
The backup from M1 will be restored and the backup on the onboard Flash will be overwritten with the program stored on the M1 memory card.

PCD1.M0/2xx0, PCD3.Mxx60:
On every program download there is directly a backup to the OnBoard Flash. 
You have the possibility to download also the backup in memory cards for example M1. 
You can also do a backup in the Internal Flash.

Flash Backup/Restore Priority
By default the PCD will choose which backup will be created or restored by searching for backups in the following order:
1. Slot M1, if fitted with Flash card
2. Slot M2, if fitted with Flash card
3. Slot 0, if fitted with a module containing a Flash or SD card
4. Slot 1, if fitted with a module containing a Flash or SD card
5. Slot 2, if fitted with a module containing a Flash or SD card
6. Slot 3, if fitted with a module containing a Flash or SD card
7. Internal Flash
8. Onboard Flash

Remarks

• Flash cards for "User Program Backup" are: PCD7.R500, PCD3.R500, PCD7.R550M04, PCD7.R551M04, PCD3.R551, PCD7.R561, PCD3.R561, PCD3.R600 
• If a "Restore User Program from Flash" is executed (e.g. because the user program has been lost due to a discharged SuperCap), the PCD will read the backup from the flash card (if available) and copy the content to the SRAM as well as to the onboard flash.
• A restore from a flash card will fail if the memory can not be allocated on the PCD (if e.g. a backup from a PCD3.M5 with hardware version D (--> 1 MByte memory) is plugged on a PCD3.M5 with hardware version 512 kByte memory available)).
• Since the firmware 1.16.27 it is possible to write the user program backup to the file system. This new backup does also include the media (register, flags, timer, counter) as well as the configuration of IP protocol configuration such as the FTP and HTTP server settings. See also the FAQ 101622
  

The PCD3.M3xxx, PCD3.M5xxx and PCD3.M6xxx do feature different possibilities for using the port 10 (D-Sub connector) and port 2 (terminal block).

The above mentioned port can be used for Profibus DP, Profi-S-IO or Profi-S-Bus communication. Please refer to the following table for possible usages:

The PCD2.M480 and the PCD3.Mxxx do not support the baudrates 100, 300 and 600 Baud.

When an element is configured as Integer with the format ##### (without dot) the value of the register is wrongly displayed on the terminal. This is a FW bug in the actual version of the PCD3.M_ and PCD2.M480.

This problem occurs with all FW version up to:

PCD3.M_         #13         (that means also 010, #11, #12)

PCD2.M480     #23         (that means also 020, #21, #22)

Solution
Please update the firmware of your PCD to the versions listed below (or later):

• PCD3.Mxxx0  FW 1.08.23
• PCD2.M480:  FW 1.08.19

Old Modbus FBox libraries from the company Engiby did not support register addresses above 8191.

Solution
With the Engiby Modbus FBox library version 2.5.010 (from June 2006) it is possible addressing registers until 16383. 

There have been some limitations according the IP norm that allowed only certain combinations of IP adresses and subnet masks (only classful networks with subnetting were allowed). However, these limitations are (or will be) removed in recent firmware versions according the Classless Internet Domain Routing (CIDR).

Introduction
The IP stack of our PCD controllers (PCD3 and PCD7.F655) was only supporting "classful networks with subnetting" according to the official IP standards. As result only IP address/subnet masks that conformed to the "classul networks with subnetting" were allowed in certain firmware versions of the PCD3 and the PCD7.F655. If the address/subnetmask was not conform to the rules (because e.g. supernetting was applied), the communication didn't work.
We are now introducing the "Classless Internet Domain Routing" CIDR to our stack which provides increased flexibility when dividing ranges of IP addresses into separate networks.

Classful networks
In classful networks (without subnetting) it is possible deriving the subnet mask based on the IP address accoring to the table below.

Further on, subnetting can be introduced by extending the "network portion" by using a part of the "host portion" (the right side of the subnet mask, in the classful network filled with "0"). Subnetting works with all PCD firmwares but supernetting does not (see example below).
The PCD3 firmwares older than the one mentioned in the table below does not allow class A or B subnet masks if the IP adresses are not in the defined range (because this would be supernetting).

Classless networks
For the "Classless Internet Domain Routing" CIDR the network classes mentioned above aren't relevant for the subnet mask any more. Therefore it is possible to define any subnet mask (subnetting and supernetting is allowed). Of course the network will only work properly if all the devices are configured correctly.
When in doubt about the required subnet mask for your PCD, please contact your network adminstrator.

Example
§ix100487§

Firmware versions introducing CIDR

The PCD2.M480, PCD2.M5xxx and PCD3.M5xxx can be used as an MPI server (Profi-S-Net port). As the mentioned PCD's only reply to MPI requests, this functionality can be used to connect for instance an intelligent terminal that supports MPI (an OP for instance), but other MPI functions like global data exchange or event driven communication are not supported.

To use the MPI function you need to do the following:

• early PCD2.M480 firmware versions (010 for instance) do not support the Profi-S-Net features, so the download of a new firmware version may be required
• in PG5: make a Profi-S-Bus configuration in the hardware settings and download the hardware settings. This enables the FTP based communication services on the Profi-S-Net port, defines the Profibus address ( = MPI address at the same time) and the port settings

• With Step7 it is possible to access the PCD media with:

  - SFC 67 X_Get

  - SFC 68 X_PUT
• on MPI, S7 ressources are used, so you need a table that tells you how PCD Classic ressources are mapped to S7 ressources:

*) see remarks below:

• if using the PCD8.D81W or VTWIN software, use the Siemens S7 driver for the PCD stations (with until version 4.75 the xx7 driver does not support the DB's mentioned in the above list). The addesses for flags and I/O are not introduced in the byte oriented format mentioned in the table, but in a bit-oriented format. This means that only multiples of 8 can be used as address. Example: to read the inputs 32 to 39, 32 has to be used as address.
• for PCD7.D7xx terminals: the correct wiring for the MPI cable is shown in the hardware manual, use termination resistances at the ends of the bus

Use caution when downloading FW to a PCD3.Mxxxx controller because it is possible downloading a wrong FW (e.g. the one for the PCD2.M480).

Once the wrong FW is downloaded follow this procedure for downloading the correct FW:

Once a FW which is written for the PCD2.M480 is downloaded into a PCD3, there is only one way to get the PCD running again:

1. PLC power on
2. Switch the RUN/STOP switch two times up and down while RUN LED is blinking. Then download the FW via PGU cable (PCD8.K111) in PGU mode.

Yes it’s possible to connect a PCD directly to the internet, but you have to protect your PCD against unauthorised access or cyber-attacks.

To protect the PCD against unauthorised access or cyber-attacks, it’s imperatively needed to take some protective measures.

Information about protective measures can be found on the support hp

If you need a PCD with cyber security levels SL3+ and based on ANSI ISA 62443 then checkout our PCD3.M6893 (QronoX PCD), this PCD was developed for cybersecure applications.

Information's can be found here.

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

Symptoms
Programmable PCD devices that act as S-BUS master on RS485 with PCD Firmware >= 1.28.20 and <= 1.28.33 get no answer from Slave devices on some of the S-Bus master requests, although S-BUS address, baud rate, polarity and line termination are ok.

Possible effects of the issue

Until now we have found that E-Line RIO communication seems to be more concerned of this problem than e.g. RS485 S-Bus data communication between CPU's.

In some of the cases the effect was, that it was not possible to write to the outputs of the E-Line RIO's or the change of values on the E-Line RIO Inputs was not transfered to the S-Bus master.

With the concerned Firmware it might be very difficult or impossible to download the user program over a gateway connection.

PCD Firmware 1.28.x for all programmable PCD types are concerned.

Reason

The reason of the issue is a error in the Firmware of the S-Bus master.
The problem on the Firmware is, that telegrams which contain DLE characters (B5 or C5) as last character of the telegram (CRC) where malformed because the last character is missing.

Since the CRC is calculated during runtime this malformed S-Bus request occurs depending of the content of the S-Bus request.

The (malformed) CRC is transfered with the S-Bus request from the master to the slave.

If now the slave receives the S-Bus request and the received CRC does not fit with the calculated CRC, then the S-Bus slave reject the S-Bus telegram.

Solution

In case you use the concerned Firmware on an installation with RS485 S-Bus Data communication, update the S-Bus master PCD to the newest available Firmware >= 1.28.34.

This Firmware do fix the issue CVE-2017-9628 related to Ethernet frame padding information leakage.
To avoid any problems in relation to this leakage we do recommend strongly to update to the latest Firmware
1.28.16 / 1.24.69 or newer as mentioned on the security upgrade section on this web-page.

Impact of the CVE-2017-9628
IEEE 802 specifies that packets have a minimum size of 56 bytes.
The Ethernet driver is expected to fill the data field with octets of zero for padding when packets are less than 56 bytes.
Resident memory and other data are used for padding in some implementations that could cause information leakage.
This attack is passive; the attacker can only see data that the affected devices sent out as part of a packet.

Vulnerability overview of the CVE-2017-9628
The previous implementation of firmware allowed other data from a known area of memory to be used in this field and could exfiltrate or leak data.

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.16 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.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

With Firmware >= 1.26.00, after Power off / on of the PCD, the LON bindings are lost.

Symptoms

The LON communication don’t works anymore after power off/on. In the commissioning tool, e.g. NL220  the Lon node is getting “red” after the function Network –>Test

Reason

In the FW 1.26.xx there is a problem with the file update on the Flash cards, the bindings are only updates in the memory but the operation to save them to the filesystem fails. Therefore the binding information is lost after power off / on.

Solution

The correction is done with >= 1.26.24. The firmware of the PCD and the LonIP FW have to be updated.

In the commissioning tool e.g. NL220 a Network -> Repair function has to be executed on the node.

Only the FW >= 1.26.00 are concerned. (e.g. FW 1.24.xx is not concerned of this problem)

In June 2017:
the COSinus FW 1.26.31 was released as maintenance version for the systems:

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

the BACnet and LonIP FW 1.26.31 was released as maintenance version, which do support the BACnet Revision 9.
To support the BACnet Revision 14 it's necessary to use the PCD and the BACnet FW 1.28.xx.

In March 2017:
the COSinus FW 1.26.28 was introduced into production for the systems:

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

the BACnet and LonIP FW 1.26.28 was introduced into production

In June 2016:
the COSinus FW 1.26.15 was introduced into production for the systems:

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

The COSinus FW 1.26.16 was introduced into production for the systems: PCD3.T665/T666/T668.

The BACnet and LonIP FW 1.26.15 was introduced into production

Attention:
The firmware 1.26.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 or 1.26.xx to a not compatible PCD.

Firmware 1.26.31 (June 2017)

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.

Firmware 1.26.28 (March 2017)

Improvements

• Text Ram can now be cleared (all chars are set to blank space) with the cgi interface by writing a zero length string.
• Ping request on ETH2 over rooter from different sub net.
• LonIP Mapper improvement
• Web Server RAM Disk increased
• Error Led not set on IR overflow

Main corrections

• All PCD's: MC0 communication with F2xx module and related communication flags are handled correctly in case of transmission
• All PCD's: Text Ram can now be cleared (all chars are set to blank space) with the cgi interface by writing a zero length string.
• All PCD's: Multiple AlarmLists with similar names will now be "initialized" correctly.
• All PCP's: TCP client keep alive is not working when anonymous port is used.
• All PCD's: Profi-SBus GWY does not wor, Profi-SBus Master/GWY stop working after cable is re plugged.
• All PCD's: PCD crash when use DIGI(R)/DIGO(R) with first parameter as FB parameter.
• All PCD's: Correction for modbus RTU communication over F2xx communication module
• 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.
• PCD1.M22x0: While changing the analog output value, the Watchdog is switching. Switching the Watchdog Relais over the corresponding flag has no influence.
• PCD2.M4x60: Sometimes the Profibus DP module is not initialized correctly on startup.
• PCD2.M5xx0: When Restore program because of a missing or dead battery configuration (SBus/IP,..) is not restored correctly.
• PCD2.M5xx0: 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 occuring at the moment of the timeout.
• PCD2.M5xx0: Sometimes config is lost after download project with self-download tool.
• PCD3.Mxxx0: Battery status shows FAIL also if battery module is missing.
• PCD3.Mxxx0: FTP server processing with long commands resolved.
• PCD3.Mxxx0: 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 occuring at the moment of the timeout.
• PCD3.Mxxx0: Sometimes config is lost after download project with self-download tool.
• PCD3.Mxx60: Profi-SBus/DP/SIO does not work on port 2 on PCD3.M3x60 & PCD3.M5360.
• PCD3.M6860: Ping request from over rooter from different sub net is not respond.
• PCD3.M6860/M880: Profibus/S-IO/Profi-SBus does not work stable.
• PCD3.M6860: Set PCD to HALT if there is no or incompatible media transfer between the two CPU's.
• PCD3.T66x: The RIO Status web page does not allow to clear the diagnostics.
• BACnet: The memory usage of the BACnet FW was increasing for every SubscrobeCOVProperty service, which has been received by the PCD.
• BACnet: A client configuration for Priority_Array properties in commadable objects (e.g. Analog-Value) does now allow reading (ReadProperty/COV) and writing (WriteProperty service to server) at the same time.
  
  

Firmware 1.26.15 (June 2016)

New features

• Support of PCD1.M2220-C15
• Support of PCD2.M4x60
• Support of PCD3.M3160/PCD3.M3360/PCD3.M5360
• Support of PCD3.M6880, PCD3.T668 Standby-CPU-System

Improvements

• PCD2.M4x6x, support Interrupt when reaching the configured ref Value
• PCD1.Mxxx0, PCD2.M4x60, PCD3.Mxx60 PCD7.D4xx: Increase None Volatile Register to 1000
• PCD3.T666/8: Increase the User Program Memory for to 256k
• PCD3.T66x: Support the ESIO manager use tag values for IP address
• PCD2/3.F2xx modules Baudrate: Support 300/600/1200 baud settings for in MC mode.
• S-Monitoring: In bar displays where the current time is visible, the average for the period is calculated not in a optimal way (time slice, ref time, is a bar). New it's displayed in seconds
  
  

Main corrections

• PCD3.M6860/M6880: When update FW on extension using the file system after update the extension FW can stay in an endless loop
• PCD3.M6880: crash wen Timmer/Counter is mapped in the Read Symbols
• PCD3.M6880: PCD can crash with MuKe Error when use the SBus GWY in parallel with modbus TCP
• PCD3.M6880: Standby CPU1 does not always HALT when CPU0 crash
• PCD3.M6880: CPU0 to 1 From Read data communication sometimes stop works
• PCD3.M6880: Add a Transmit Error diagnostic tag "DataTxErrors"
• PCD3.Mxxx0: Battery module on IO slot 3 does not show battery status in history
• PCD3.Mxxx0/PCD1.M2xx0: Some baudrates on onboard ports are not correct
• PCD2.M4x60: RTC read/write locks the PCD for about 30ms
• PCD2.M4x60: Modem does not work because of the not working DCD
• PCD3.T66x: Add ELine CSF library
• PCD3.T66x: Serial com does not work with SASI instruction
• PCD3.T66x: CSF Modbus Server Init gives an error when port 502 is used becasue this port is already open
• PCD7.D443WT5R: Assignation/Configuration of port 1 should return an error because port 1 is not supported
• PCD7.D443WT5R: Remove IO access from the system. PCD goes now in HALT with "INVALIDE OPCODE"
• PCD2.W220 with Pt1000: Significant deviation between singel channels
• BACnet: List Properties (like Date_List, Exception_Schedule, ...) could disappear after a PCD restart, if a WriteProperty request with an empty list value has been received for these properties before the restart. This behavior was only present for persistent properties
• BACnet: The Log_Buffer property of a Trend-Log object could not be read anymore using the ReadRange service, after a Event-Log or Trend-Log-Multiple has been read via ReadRange
• BACnet: Writing a single analog output channel is not working. The output is not changing. Writing output channels over the mapped functionality is working
• BACnet: PCD with BACNet loops with restart if program has "INVALIDE OPCODE"
• Restart Warm does not work
• SBus ELine has sometimes retries
• When create a Text/DB the backup fails until a restart is done
• PCD Crash with BUS ERROR on STXT instruction when text is empty
• Modem does not work correctly
• Modem does not work or PCD crash when modem is configure
• PCD can crash when error occurs in Modbus RTU
• The PCD crash if a BITI is executed with number as FB parameter
• PCD crash when use Profi-S-Bus Master
• Sometimes the program is lost when update FW from 1.24.xx to 1.26.xx
• MOVX/DIVX function where not working on Task or Temporary data when use indexed
• Add config tag value for GWY mode "data_no_secure" to deasble the secure data mode
• Not possible to upload a file through the Web server FTP interface (ftp.cgi or ftp.json) if that file starts with a white space character (either a space or a tab)
• CSF CopyDBBytesToR crash when destination is bigger than last Register
• Diagnostic Flags in S-Bus Master mode are not correct if there are collisions on the RS-485 network
• CSF Backup/Restore Media does give an error on restore when data change while backup/restore
• MOV instruction with type position as FB parameter gives error flag and fails
• Web-Alarm: Fix alarming color with "group color mode" and group bigger than 8

It’s possible that after a FW update of the PCD to the FW 1.20.xx, 1.22.xx or 1.24.xx there is a entry in the FW history ‘FWDnld UnknownFW’ after the history line ‘FWDnld 1.2x.xx PLC CLASSIC’ as shown on the image below.

The history message ‘FWDnld UnknownFW’ was caused by an error in the old FW of the PCD and does have no signification.

Just ignore this message and clear the history messages.

This error is in fact a kernel error produced when different systems of the PCD are called simultaneously and get pointed on a invalid address. As the result the PCD goes in halt unless the software watchdog has been programme!                 

According to our experience the error happens very very rarely and most probably won't happen again!

In case an FBox library (or an IL program) uses a functionality which is not implemented in the PCD firmware, the PCD will not go in run but display the error message "SF not loaded" (e.g. in the PCD history or in the Online Configurator).

Symptom
After the download of a program a SBC-NT based PCD (e.g. PCD3) does not go in run but remains in halt. When going online with the Online Configurator a message "SF not loaded" is displayed.


Reason
The user program uses a functionality which is not implemented in the firmware (and therefore the PCD can not run the user program).

Solution
The solution is either updating the firmware, or avoiding the CSF which leads to the problem.
In case it is not know which CSF is responsible for the "SF not loaded", the SF library can be found based on the program line indicated by the Online Configurator (the program line is indicated with "Halt at xxx" in the Status; in the screenshot above the CSF is on program line 4). By using the Online Debugger, this CSF can be displayed by typing "DP4C10"):

   Display Program 4 Count 10 (Enter)
  

In this case, the CSF calls the SF library 26 (which is not implemented in the Firmware 1.10.51 which is used above).

How to know the functionality based on the library number?
Below you can find a list of the most commonly used System Function libraries (and in which FBox libarary they are used):

• SF library 0: S.SF.IP (e.g. Open Data Mode)
  Used by several IP communication drivers such as EIB/Net and for reading or writing the IP address of the PCD.
• SF library 2: System library
  Used by FBoxes for reading the Serial number
• SF library 4: S-Net library
  E.g. Used by FBoxes for Profi-S-Bus and Ether-S-Bus
• SF library 6: S.SF.DBLib (e.g. CopyTextBytes), previously the "ApplicationLib" for CopyText
  E.g. used by the Modem FBox library, HDLog to File library.
• SF library 7: File System library
  E.g. used by the FBoxes for the File System or "HDLog to File"
• SF library 9: IP Services (EMail, PPP, DNS, SNMP etc.)
  E.g. used by the EMail library and the WAA (Wide Area Automation) FBox library
• SF library 10: S-Web Alarming library
  E.g. used by the S-Web Alarming FBoxes and the DDC Suite
• SF library 13: Modbus library
  E.g. used by Modbus and the P-Bus FBox library
• SF library 19: LON over IP library
  used by LON over IP functions
• SF library 22: SPI framing protocol for PCD2/3.F2xx(x)
  e.g. used by the M-Bus library 2.6.100 and later
• SF library 23: Energy Manager library
• SF library 25: LON FT library
• SF library 27: ELine library for ELine modules
  Since PCD firmware version 1.24.xx

The single function codes (second line of the CSF call, "0" in the screenshot above) of the relevant libraries can be found in the definition files in folder
   c:\Documents and Settings\All Users\Saia-Burgess\PG5_20\Libs\SF\*.lib
(e.g. SFModbusLib_en.lib for the functions of the Modbus library.

As the "original" Instruction List Set (with the mnemonics STH, OUT etc.) could not be extended by an unlimited amount of new instructions, the call of new features such as the Open Data Mode, Sending of EMails etc. is realised with so called SFs (which stands fro "System Function"). These SFs are called using CSF instructions (Call System Function).

What is a SF library?
A System Function library is a a set of functions which are implemented in the firmware and which can be called with the IL mnemonic CSF. Usually one SF library contains several functions which are related to each other. A CSF expects the SF library and the function from this library, together with a set of parameters (described in the online help of the SF library which can be found in the IL Editor SEdit from PG5 2.0).

How is a CSF used?
In the user program a SF function is called using the mnemonic CSF, followed by the library, the function and the parameters:
CSF     [cc]     Library
                    Function
                    Parameter 1
                    Parameter 2
                    ...


This can be done from inside an FBox, or directly from an IL program (as the engineering is faster using the FBoxes, the most CSFs are called from FBox libraries).
The "translation" between meaningful names (e.g. S.SF.DBLIB.CopyTextBytes) and the code which is used by the firmware is done by PG5. For a list of the most commonly used SF libraries, please refer to FAQ 101568.

In July 2010 the firmware 1.14.23 has been introduced into production for the PCD2.M5xx0 and the PCD3.Mxxx0. This FAQ lists the main differences between versions 1.10.51 and 1.14.23.

New features
please note that in order to take advantage of these new features PG5 2.0 SP1 (PG5 2.0.150) is required.

• Increased amount of available flags (14335 instead of 8191), see FAQ 101447
• S-Web and FTP Server as well as the IP Enhancements (DHCP, DNS, SNTP and PPP) can be configured in the Device Configurator, see FAQ 101464
• Webserver access levels can now be configured in the Device Configurator (was before in the WebBuilder settings), see FAQ 101613
• IEEE floating point values can be displayed on the S-Web server (display format is “e”), see FAQ 101188
• Number of COBs increased to 32, see FAQ 101467

Main corrections

• SYSWR for DB backup failed after a lot of backups, see FAQ 101466
• STXT with more than 512 bytes sent a wrong text, see FAQ 101468
• The IP address for the Open Data Mode System Function “ConnectTCP” could not be given as constant 

Hardware compatibility of firmware 1.14.23 with PCD3 systems
The firmware 1.14.23 requires a PCD equipped with 4 MB onboard flash. Therefore the minimal hardware versions for installing the 1.14.23 and later are:

For PCD3 systems older than listed the firmware 1.10.61 is the last firmware which can be installed on these systems. This firmware is and remains available on the support site in parallel to the 1.14.23.

Remarks 

• When updating from 1.10.xx
  Please note that the user program as well as the communication settings are lost during the firmware update from 1.10.xx to 1.14.xx (or 1.16.xx) 
• BACnet applications
  The BACnet firmware 1.14.26 is compatible to this new production firmware. Please download the latest BACnet firmware package for PCD firmware 1.14.xx from the support page (link below).

In case a text with more than 512 bytes is sent with a firmware older than 1.14.23 the according text has not been sent correctly.

Symptom
When sending a text with a length of more than 512 bytes on a PCD3 or a PCD2.M5 with a firmware older than 1.14.23 the text which is sent is not correct.
In case the text to be sent contains sub-texts which are introduced using interpreted text (e.g. the $Lnnnn) and the final length to be sent is more than 512 bytes, the same phenomenon can be observed.

Solution
Please update the firmware of your PCD to version 1.14.23 or later.

Up to firmware version 1.14.23 the maximal amount of COBs (Cyclic Organization Blocks) has been 16. In firmware 1.14.23 the amoung of COBs has been increased to 32. Thus on PCD2.M5 and PCD3 and newer systems up to 32 COBs can be used (COB to 31).

Remark
Please note that PG5 2.0 Service Pack 1 (PG5 2.0.150) is required in order to program the COBs 16 and higher.

In some cases, usually after a lot of backups which have been executed, the error bit 7 (flash task already started) or 8 (flash error) is set with firmware older than 1.14.23.

Symptom
A backup DB to flash (IL instruction "copy TEXT/DB to flash card", SYSWR 3000 or 3100) fails and the error bits 7 and/or 8 are set. This error remains, even after waiting several minutes without re-attempting a backup to flash.

Solution
This problem is corrected in firmware 1.14.23 or later. Please update your PCD firmware in order to solve this problem.

In May 2010 the firmware 1.10.51 has been introduced into production for the PCD2.M5xx0 and the PCD3.Mxxx0. This FAQ lists the main differences between these versions.

New features

• The Serial-S-Bus mode “Parity master” is now supported on all serial ports of the PCD, see FAQ 101103

Main corrections

• Increased stability for BACnet upload/merge (requires BACnet firmware version 1.10.50), see FAQ 101417
• Correction which avoids potential data loss on the SD cards when a card with more than 256 kBytes capacity is filled by 70%, see FAQ 101377
  In case an SD card is used on the PCD, the update of the firmware to the version 1.10.51 is strongly recommended!
• Avoided inter-character delay on port 2 and 3 (PCD2.M5) or 0 and 3 (PCD3) which could lead to communication problems, see FAQ 101382
• A Bus Error could occur in some specific cases, see FAQ 101418
• Reading Ni1000 sensors with a PCD2/3.W340 by the media mapping returned wrong values, see FAQ 101416
• Profi-S-I/O and Profibus DP Master did not work, see FAQ 101244

For writing data to files on the PCD file system and for sending SMS or EMails it is possible to enter the content of medias (registers, flags etc.) into the text to be written or sent. This is done by placing e.g. a $R0100 into the text to be sent. At the time of writing, the "$R0100" will be replaced by the content of the register 100.

While in the beginning only points could be used as seperators in interpreted texts, it is also possible using the comma as separator with recent firmware versions. In this case, instead of a point a comma is to be used:


Firmware dependencies
The comma separator can be used starting with the following firmware versions:

Under certain circumstances (if the file system is occupied by more than 70%) data losses on SD cards bigger than 256 MBytes have been observed.

Symptom
Under certain circumstances data losses on SD cards bigger than 256 MBytes have been observed. By analyzing these reports we have seen that in case more than 70% of the available memory on such a card is used it is possible that data is lost on the next power-up of the PCD or after the card has been re-inserted into the memory module holder (R600 / R6000) or opened by the SD Flash Explorer.
In case of many delete operations executed by the module the mentioned data loss can also occur if less than 70% of the available memory is used (due to the ware-out management of the SD card which varies the used memory areas).

Solution
An additional safety mechanism in the PCD firmware 1.10.51 as well as in the SD Flash Explorer in order to avoid future potential data loss on concerned cards has been implemented.
As soon as the system is rebooted (or the SD card is re-inserted into the R600 / R6000 mounted on a PCD with a new firmware versions) actions are taken in order to avoid the mentioned potential data loss.

The according firmware 1.10.51 (for PCD2.M5xx0 and for PCD3.Mxxx0 systems) with the new safety mechanism can be found on the support site www.sbc-support.ch.

In addition to the safety mechanism a new SD Flash Explorer version 2.0.215.0 features a “Backup” and a “Restore” feature which allows the creation of a backup of the file system.
This SD Flash Explorer can be downloaded from the support site from the section for the PCD7.R-SDxxx and will be distribued with the SP1 for PG5 2.0.

Remarks

• Even if the file system on a SD card is already filled up by more than 70%, it is still possible to download the data over FTP as long as the PCD is NOT switched off. This method is recommended before updating the firmware in order to guarantee that no data is lost.
• SD cards delivered by Saia-Burgess Controls AG after week7 of 2010 contain a mechanism that avoids the above mentioned data loss (as long as the card is not formatted with a firmware older than 1.10.51).
  

Since summer 2010 the PCD3 family (PCD3.M2xxx, PCD3.M3xxx, PCD3.M5xxx and PCD3.M6xxx) do support the "full-duplex mode" and Auto-MDIX on the Ethernet port.

The PCD systems PCD1.M2, PCD2.M5 and the PCD3.T665/665 as well as the MB Panels PCD7.D4xx do support the "full-duplex mode" and Auto-MDIX since the first hardware version.

PCD3
The easiest way to detect wheter a PCD3 features the full duplex mode as well as Auto-MDIX is checking whether the RJ45 plug is equipped with LEDs. If it is, the PCD supports the full duplex mode as well as the Auto-MDIX feature (auto-crossing the signals).
In detail the following hardware version or later are required in order to support full duplex and Auto-MDIX:

• The PCD3.M3xxx, PCD3.M5xxx and PCD3.M6xxx since hardware F.
• The PCD3.M2x30A4T1 and PCD3.M2x30A4T3 since hardware B.
• The PCD3.M2x30A4T5 since hardware C.

Before these hardware versions the PHY which was mounted on the PCD3.M3xxx, PCD3.M5xxx and PCD3.M6xxx CPUs was configured by hardware to work in half-duplex mode and not to support Auto-MDIX. As result, the half duplex mode was used even if the partner device was configured in auto negation mode and the port should be initialized in full duplex mode.
This was the case on all PCD3.M3xxx and PCD3.M5xxx up to hardware version E 4.

Remark

• With "half-duplex": The data throughput is not devided by two because of this configuration as the limiting factor is not the the full/half duplex mode of the ethernet interface but rather the time it takes for the PCD to treat the received telegrams. The data throughput of the whole network is not affected either, since the next switch/hub will have an own port configuration for every port used (so on one port half-duplex can be used, and on another port full duplex can be used at the same time).
• If the Auto-MDIX is supported it is not necessary to use a crossover cable for directly connecting e.g. a PC to a PCD, or a MB Panel to a PCD.

This FAQ contains an overview over the firmware versions currently used in production (which means that this firmware version is installed in our production facility).

Firmware versions used in production
The following firmware versions are currently used in production. For more information regarding the relevant firmware, please refer to the version information document of the according page.

PCD firmware versions

MB Panel firmware versions

RIO firmware versions

When working with PCD systems you will cross the expression "Saia PCD® COSinus" sooner or later. This FAQ explains what "Saia PCD® COSinus system" stands for.

The expression "Saia PCD® COSinus"
In general the expression "Saia PCD® COSinus" stands for PCD systems which are equipped with Freescale (previously Motorola) Coldfire CPU technology. The "non-Saia PCD® COSinus" systems from Saia-Burgess Controls AG are based on Freescale 68k CPU technology (e.g. PCS1, PCD2.M170 etc.).
The Coldfire CPU technology is a new and more performant CPU generation, new development is generally realized on Coldfire CPU (while the 68k CPUs still are available in parallel).
The first PCD system based on the Saia PCD® COSinus technology has been the PCD2.M48x. For this system the whole firmware has been re-written. The firmware of new systems is built up based on the firmware developed for the PCD2.M48x platform (having the same core modules). New firmware functionalities (e.g. Modbus which is implemented in the firmware) are basically designed for the Coldfire CPU technology and thus for Saia PCD® COSinus systems.

Saia PCD® COSinus based systems
The following list contains the main PCD systems which are based on Saia PCD® COSinus technology.

• PCD3.Mxxx
• PCD2.M48x
• PCD2.M5xxx
• PCD7.D4xx
• PCD1.M2xx (currently under development)

Does this mean that all Saia PCD® COSinus systems support the same firmware features?
No! Although the same base modules of the firmware are used, it is depending on the PCD system whether a specific feature is supported or not. For example the http protocol is supported by PCD3 and PCD2.M5xxx systems, but not on PCD2.M48x.

With an activated software watchdog the processor monitors itself and restarts the PCD in the event of a malfunction or a loop.

Description (extract from the hardware manual)
The hardware watchdog provides maximum security. However, for non-critical applications, a software watchdog may be suffcient, whereby the processor monitors itself and the CPU is restarted in the event of a malfunction or a loop.
The core of the software watchdog is the instruction SYSWR K 1000. When this is first issued, the software watchdog function is activated. This instruction must then be issued at least every 200 ms, or the watchdog will trigger and restart the controller.

Usage

• Placing a "Watchdog"-FBox in a FUPLA-file is the easiest solution:
  
• Instead of using the FBox it is possible calling the Software Watchdog in IL (using the instruction SYSWR K 1000)
  

If there is a SIO-Master and a DP-Master configured the SIO-Master does not go in the "Operate" state to make the data exchange.

Symptom
It can happen with the firmware version 1.10.16 that a PCD3 or a PCD2.M5 does not work as SIO-Master if they are also DP-Master.

Solution
This behavior is solved with the version 1.10.51 or newer (the first version which corrected this situation was 1.10.20). Please update the firmware of your PCD in order to solve this issue.

The WebServer2 is a re-implementation of the previous WebServer on Saia PCD® COSinus systems and of course compatibel to the previous version.

History
The first implementation of a Web Server on PCD systems has been realized around the year 2000. With growing experience additional features and higher performance have been requested. In order to fullfil this requirement, the WebServer has been re-implemented (with the result of the WebServer2).

What is new in the WebServer2?
In general the WebServer2 is functionally compatible to the previous implementation. In addition the following new features are supported:

• HTTP 1.1 support
• HTTP caching is supported. As result the in FAQ 100708 is no longer to be applied; It is recommended to enable the caching for the JVM (option "keep temprary files on PC") when working with the WebServer2.
  
  Remark: If the caching is not enabled, you will not profit from the supported caching; it will then work as it has before with the previous WebServer. 
• Better performance
• Parallel acces to files is properly supported (acces is no longer interrupted if another client loads the IMaster applet)
• Multiple Web clients can access the Web Server on the same physical interface with (Ether-S-Bus or Profi-S-Bus)
• Easier understandable error messages
• When texts are entered, the length of the text is specified (and no longer filled up with space characters)
• The WebServer2 does provide more information on the default page and has a nicer look. By viewing this page it is easy figuring out whether the WebServer2 is running on a PCD
  

  View of previous WebServer	View of WebServer2

Firmware (FW) supporting the WebServer2
The table below indicates the first firmware versions supporting the WebServer2. Systems not listed in this table do not feature the WebServer2.

^*) Please note that in the first pilot firmware not all features have been supported.

Remark
The only incompatibe difference between the previous WebServer and the WebServer2 concerns users that use the "HTML forms":

• The previous Web Server used:
  %%TAG%
• The WebServer2 expects (the "value" is no longer automatically added by the Web Server):
  value=%%TAG%

An example for the HTML forms on the WebServer2 can be found in the attached document.

Yes, a new set of instructions for calculation with IEEE floating point values (single and double) has been added to the firmware of PCD2.M480, PCD2.M5xx0 and PCD3.

Introduction
Motorola FFP (Fast Floating Point) has been used for floating point calculations since the beginning of PCD history. In order to simplify the interface against systems which do not support FFp but IEEE format for floating point values the instruction set of the PCD has been extended. All "twin" of all instructions available for the calculation with FFP values are now also available for IEEE calculations.

What are the instructions in detail?
Each of the existing instructions for FFP (the default) do also exist for IEEE Float and IEEE Double data. 

• For IEEE Float, precede the mnemonic with an 'E' character, for example EIFP, EFADD (instead of IFP or FADD) etc.
• For IEEE Double, precede the mnemonic with 'D', for example: DIFP, DFSUB.

Minimum Firmware (FW) requirement for this feature

PCD systems not listed in this table do not support this function.

Remarks

• These instructions can only be used with PG5 2.0.
• There is also a new instruction for the conversion from IEEE single to IEEE double (and vice versa):
  EFPD (single to double) and DFPE (double to single). These instructions are supported by firmware version 1.10.15 and later.
• The instructions for convertig a IEEE double value to an integer value and vice versa (DFPI and DIFP) are working correctly starting with firmware 1.14.23.
• IEEE single values can be displayed by the S-Web Server using the format "e" (e.g. 172.16.1.127/cgi-bin/readVal.exe,e) 

For "reading" a value from a PCD text (e.g. copying "1234" from a PCD text with content "The next number is: 1234" into a Register) a new System Function has been added for PCD3 and PCD2.M5xx0.

What does this System Function (SF) do?
The new function "S.SF.DBLIB.ReadANumberFromText" allows reading a number from a text and copy it into a register. Starting from a provided pointer, the next number will be searched and copied.

Where do I find the documentation for this function?
This function is documented in PG5 2.0. The easiest way to open the documentation is opening the SEdit, selecting the "SF DB Access Library" and hitting "F1":


Minimum Firmware (FW) requirement for this feature

PCD systems not listed in this table do not support this function.

Remark
This feature can only be used with PG5 2.0.

For parsing a PCD text for a specific expression (e.g. finding "world" in a PCD text with content "Hello world") a new System Function has been added for PCD3 and PCD2.M5xx0.

What does this System Function (SF) do?
The new function "S.SF.DbLib.SearchText" allows searching a text for a specific expression. If this expression is found, the SF returns the position of the expression within the text.

Where do I find the documentation for this function?
This function is documented in PG5 2.0. The easiest way to open the documentation is opening the SEdit, selecting the "SF DB Access Library" and hitting "F1":


Minimum Firmware (FW) requirement for this feature

PCD systems not listed in this table do not support this function.

Remark
This feature can only be used with PG5 2.0.

The XOB 8 who is called when the firmware detects an invalid instruction (Invalid OPC) in the user program is no longer called on the systems Saia PCD® COSinus (PCD3, PCD2.M5, PCD2.M480).

On the new systems, the control of the Invalid OPC is executed at the startup during the precompilation. So the XOB 8 will never be called.
This new mechanism is implemented to increase the speed and the flexibility of the systems Saia PCD® COSinus.

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).

In very special situations a PCD can get overloaded because of external influences in a way that a "KERNEL ERROR" or a "SWTO ERROR" (System Watchdog Timeout Error) is causing the PCD to restart automatically.

Symptom
In some very special circumstances (if a PCD is stressed by extreme external influences) the PCD3 automatically executes a reboot and then goes in HALT (if the software watchdog is programmed, the PCD automatically goes in RUN after the restart).
When going online and reading the PCD history, an entry "KERNEL ERROR" (on firmware versions 1.08.xx and earlier) or "SWTO ERROR" (on firmware versions 1.10.xx and later) can be found.

Reason
For saftey reasons the PCD executes a reboot in case the System Watchdog is no longer called within a specific time (this is the same behavior as the Software Watchdog, but directly on firmware level). In case of the Kernel Error a task-overload has been detected (FW indicating a Kernel Error (1.08.xx and earlier) do not feature the System Watchdog). 
Such a situation could e.g. be caused by an Ethernet telegram bombardement of several thousend telegrams per second or if a connected FDL network is disturbed heavily over a long time. In such a situation the PCD (with FW older than 1.10.xx) does only treat the interrupts generated by e.g. the IP telegrams and no longer executes the rest of its tasks (for security reasons, this state is interrupted by the automated reboot of the system).
 
Solution
A new Kernel together with other improvements which can avoid situations leading to SWTO Errors have been implemented in firmware version 1.10.xx (or in the special firmware with new kernel 1.08.19.12). Thanks to these improvements the PCD is even more robust against the mentioned influences which can cause a "SWTO Error" (or a "KERNEL ERROR").

Important

• Please note that in case a Software Watchdog is programmed, the PCD does automatically go in RUN after the restart executed by the System Watchdog (if no Software Watchdog is programmed, the PCD goes in HALT after the reboot caused by the System Watchdog)
• In general it is recommended using firmware version 1.10.16 or later rather than 1.08.19.12.

The PCD3 systems equipped with an Ethernet port and the PCD2.M5540 are able to send emails. But sending e-Mails is not only depending on the CPU itself.

The PCD3 systems equipped with an Ethernet port and the PCD2.M554x support SMTP (Simple Mail Transfer Protocol). Sending emails does not only depend on this feature but as well on the ISP (Internet Service Provider), the firewalls and router configurations between PCD and ISP.

The attached checklist with the criterias to verify with your provider and / or your IT support shall help to check whether sending E-Mail is possible.

This error message appears if the used firmware on the CPU does not support the "active and non ACK" filter for the S-Web alarming functionality (e.g. a PCD2.M150 with firmware 0D3).

Symptom
Instead of the alarm list of the S-Web alarming macro, the message "Failed to get data on alarm.exe" is displayed on the alarming page.

Reason
The reason is that the macro tries receiving the alarms filtered by the "active and not acknowledged" state of the alarms. This does only work if this feature is implemented in the according firmware.

Solution
Please update the firmware (FW) of your PCD system to the firmware supporting the according feature (see table below).

^*) On PCD3 and PCD2.M480 systems the "active and not acknowledged" filter has already been implemented in previous versions, but has been improved this indicated version.

Yes, this is possible by calling the system function (CSF) "IPGetLocalConfig".

Introduction
For having the possibility to read the current IP configuration from the user program, a specific System Function has been added to the firmware. This function does return the IP address, the subnet mask as well as the default gateway (each address in one register). The returned value contains the full IP address in one register (each byte or the register contains one octed of the IP address):

Example
This System Function is part of the IPD Library. In order to use these functions, the file "IPLib.inc" is to be included to the source file where the function is called. This can be done with the line:

$INCLUDE "IPLib.inc"

The IP configuration can then be read in th following way:

Returned IP address (hex):               0xAC100179h
IP address in "Dot-decimal notation": 172.16.1.121 (0xACh = 172, 0x10h = 16, 0x01h = 1, 0x79h = 121)

Firmware versions supporting the GetLocalIPConfig
Please refer to the table below for the first firmware versions that support the "IPGetLocalConfig" function.

Remark
The include file "IPLib.inc" from PG5 1.4.300 and earlyer versions needs to be updated in order to "know" this feature. Therefore please download the file "IPLib.inc" attached to this FAQ and replace the existing file from PG5 which is located in the "Libs/App" of PG5:

c:\Program Files\SAIA-Burgess\PG5 1_4\Libs\App\IPLib.inc

In firmware version 1.08.xx for systems running the Saia PCD® COSinus firmware, the system watchdog has been introduced. If a PCD reboots because of the system watchdog, the message "SWTO ERROR" is entered in the PCD history.

What for is a system watchog?
The system watchdog is a security measure which avoids a situation where the system (PCD) is blocked and does not properly execute the program any more. If the OS (Operating System) is "locked" in a loop and does no longer properly execute its tasks (among others, the user program), the PCD is automatically re-started. 

What does the system watchdog do?
The (internal) system watchog is configured directly on the CPU and will cause a re-boot if it is not triggered in a cyclic manner. Every reboot caused by the system watchdog is entered in the PCD history with the message SWTO ERROR (SWTO stands for System Watchdog TimeOut).
The behaviour after the automatic reboot caused by the system watchdog is depending on the software watchdog which can be programmed in the user program:

• If the software watchdog in the user program is enabled, the PCD will automatically go in RUN after a reboot caused by the system watchdog. 
• If no software watchdog is programmed in the user program, the PCD will go to "Halt" after it has rebooted because of the system watchdog.

Does the system watchdog conflict with other watchdogs?
No, the system watchdog does not conflict with e.g. the software watchdog programmed in the user program or with a hardware watchdog.  
 
When has the system watchdog been implemented?
The system watchdog has been implemented in firmware version 1.08.xx. The first production versions for the relevant systems can be found in the table below:

Remark
Note that the system watchog does not detect a bogus user program (e.g. an infinite loop) and therefore the usage of the software watchdog in the user program is still recommended.

The information provided in the history or the "Diagnostic file" of the PCD does not always give enough information for the firmware developpers to find the reason for e.g. a crash of a PCD. If more information is required in order to trace back a crash, a dump of the whole memory (SRAM, DRAM and FLASH) of a PCD can be done. This FAQ does apply to PCD1.M2, PCD2.M480, PCD2.M5xxx, PCD2.M45x0, PCD3 (including PCD3.Mxx60) and PCD7.D4xxxT5F (Programable MB-panels).

Working principle
For dumping the memory of one of the following systems a dedicated small executable SaiaDump.exe is available as standalone tool.

• PCD1.M2
• PCD2.M480
• PCD2.M5
• PCD2.M45x0
• PCD3
• PCD3.Mxx60 (fast CPU)
• PCD7.D4xxxT5F (programmable MB-panels)

Usage of the stand alone tool SaiaDump.exe:
This tool is called by a batch file which will call an executable (SaiaDump.exe) with hardware specific parameters. The executable will establish an USB connection to the PCD and will read out the memory content. This content will be stored in 4 files and all these files will automatically be stored in a *.zip archive.

General remark:
In order to obtain all necessary information it is important that the dump is made while the CPU's memory still contains the last information.
Since this information is lost (overwritten) when the PCD re-boots, it must be achieved that the PCD does not reboot in case of a crash (e.g. Bus Error or Kernel Error).
Therefore a specific SYSWR has been implemented.
This command is to be executed on the PCD e.g. in XOB 16 before a crash occurs (on every boot, because it is reset on each power off).

Software installation of SaiaDump.exe tool

• Download the archive "SaiaDump_V1_3_006_Rev211101.zip" from this FAQ
• Unpack the *.zip archive on your PC or Laptop
• In the extracted folder "SaiaDump" you'll find several batch files (e.g. RUN_DUMP.bat or RUN_DUMP_PCD1M2xx0.bat).
  By double-clicking on the file RUN_DUMP.bat, a dump is started (make sure that PCD is connected with a USB cable and no PG5 is running)
  
  After a successful dump a new *.zip archive with the name "PCDDump_date" will be stored in the same directory.
  Please send this archive (it should contain four files with the extension *.blk or *.bin and a log file) to the support. 

Preparing the PCD
In order to cause the PCD not to reboot in case of a crash, add the following lines to the code of your CPU (and remove the watchdogs, if present).
Alternatively, you can also add and link the file "DontRestartAfterCrash.src" which is contained in the folder "PCD_Preparation" off the "SaiaDump_exe.zip" to the concerned CPU in your PG5 project.

$INIT                   ; Add the following lines to the XOB 16
SYSWR K 9999     ; Instruction to cause the PCD not to
K 1                       ; reboot after a crash
$ENDINIT

This instruction has been implemented first in PCD3 firmware version 03A.
Therefore please also make sure that FW version 03A or higher is installed on the system.
The SBC Dump tool can only dump the memory of a PCD that has boot loader version 035 (created in April 2006) or higher installed.
In case your PCD has a too old boot loader or if you are in doubt of the boot loader version of your PCD, please refer to FAQ 100680 in order to learn more about how to find out the boot loader version and how to update the boot loader version. 

Dumping the PCD memory
After the next crash, the PCD will not re-boot anymore and will blink with all tree LEDs simultaneously instead. Please note that the SYSWR K 9999 (see above) must have been introduced before the crash and the LEDs must blink in this state! In this (and only in this) situation it is possible dumping the memory of the PCD:

Use of the stand alone tool SaiaDump.exe:
Launch the SaiaDump.exe for retrieving valuable debug information (it is also possible dumping the PCD if the PCD is in boot loader state or run for test purposes, but no valuable debug information can be retrieved from these files).
For launching the SBC Dump is should be enough to double-click the file RUN_DUMP.bat.

Additional information for PCD3.Mxxx7
The same tool can also be used for dumping the memory of a PCD3.Mxxx7. But note that the usage of the SYSWR listed above is not to be used.

FAQ updates

• December 2021(Version 1_3_006_Rev211101)
  - Support also the PCD2.M45x0
• March 2013 (version 1.3.006)
  - Support also the PCD7.D4xxxT5F (programmable MB-panels)
• July 2011 (version 1.3.005)
  - created batch files for easy launch or the SBC Dump executable 
  - added log file creation during dump process
• November 2010 (version 1.2)
  - supports new hardware: PCD1.M2 and PCD3.Mxx60 (fast CPU)
  - supports the new USB driver (for 64Bit OS) 
  - removed the firmware files from the package in order to make it smaller
• June 2010 (version 1.1)
  - increased SRAM memory Dump (2 MByte) for recent PCD systems (PCD3, PCD2.M5).
  - update of firmware delivered in the package to 1.10.51. 
• Mai 2009
  Version 1.0 of the SBC Dump: This version does also dump the internal SRAM of the PCD.

In firmware 03B and 03C an S-Bus broadcast telegram will block the communication interface until the next reboot of the PCD.

Symptom
When using firmware version 03B or 03C on either a PCD2.M480 or a PCD3.Mxxx0, the communication stops working after a sent broadcast. This only applies if the concerned PCD is acting as master on the S-Bus network.
This phenomenon occurs on S-Bus (Serial-S-Bus, Ether-S-Bus or Profi-S-Bus).

Reason
In firmware 03B and 03C an S-Bus broadcast telegram will block the communication interface until the next reboot of the PCD.

Solution
In order to resolve this problem, please update the firmware of your concerned PCD.

The first versions of the PCD3.M5340 controller have been delivered with a firmware that does not support the usage of the RS485 port on port 3.

Problem
The communication RS 485 on port 3 of the PCD3.M5340 is not working correctly. 

Reason
Due to a problem in the firmware, the port is not correctly initialized to RS 485.

Solution
Upgrade the PCD3 firmware to version 1.08.23 or higher.

Remark
There is no problem for the usage of the port 3 as RS422 port.

If a wrong or invalid firmware is downloaded to a PCD3, the firmware download progress bar reaches 100%. After the download finished, an error message appears indicating a failure caused by a NAK response.

Symptom
After the download of a firmware file the following error message from the Firmware Downloader (FWDnld) appears. The message is "Download failed on END command. Error: NAK response."
§ix100527§

Reason
The reason for this message is a "NAK" (Not Acknowledged) response from the PCD. Before the PCD loads a new firmware, it is verified by the PCD. If this verification fails (because of e.g. a wrong checksum of the firmware of because the firmware is not intended for this CPU type), a NAK response is sent by the PCD to the Firmware Downloader.

Solution

• Make sure the firmware you download is created for the CPU type you have attached (a firmware for e.g. the PCD2.M480 will not run on a PCD3.Mxxx0 system)

• Make sure the file you have downloaded is not corrupted (e.g. while the download from the internet or similar). In case of doubt, re-download it.

In order to simplify the interpretation of firmware versions and to avoid confusion regarding implemented features and bug fixes in different firmware versions, a new firmware version format for Saia PCD® COSinus based systems will be introduced.

Arguments for the new format
The new firmware version naming allows a clear and easy comparison between the different versions and their implemented features (PCD type specific) and bug fixes.
Questions like "Why is the Alarming functionality of the PCD3 Web Server implemented in firmware version $31 but not in version 031? - They both do have the same number..." should be past (however, if you're interested in the answer, please refer to FAQ100176)

Format description
The new firmware version name does consist of a major version, a branch version and a minor version separated by a dot (.).
Note that the prefix characters “0”, “$” or “#” are no longer used in this notation.

Concerned systems
The new firmware version format is applied to the systems based on Saia PCD® COSinus firmware (Classic and xx7). These are

• PCD1.M2xxx
• PCD2.M48x
• PCD2.M5xxx
• PCD3.Mxxxx
• PCD7.D4xx (MB Panels)

While the firmware names for the MB Panels and PCD1.M2xxx do have this format from beginning, it was introduced on the PCD3 and PCD2.M480 systems with the firmware version after 03B.

Version flow example
Below an example for a version flow. If e.g. a bug is corrected in the version 1.06.01, also version 1.07.02 and all following 1.06.xx versions do/will have this correction implemented.


Version types

• Released beta- or maintenance versions (equivalent to the current “Bxx” or “#xx” versions).
• Released Production versions (equivalent to the current “0xx” versions): These versions are introduced in the production.
• New function versions (equivalent to the current “$xx” versions).

Compatibility with PG5
The new firmware names are fully supported by PG5 V 1.4.200:

Previous versions of PG5 will only show the first three digits of the firmware version (e.g. “106” instead of “1.06.08”). The full firmware version can always be read by displaying byte F0F0 in the “Online Debugger” (type DYF0F0 ):

While the serial PGU port of systems before the PCD3 did always work as PGU port when connecting a PCD8.K111, the serial PGU port of the PCD3 can be configured for using a modem. If this is done, it is no longer possible attaching a PCD8.K111 and establishing a PGU connection.

Symptom
It is not possible going online with the PGU communication mode using a PCD8.K111 programming cable plugged in on the D-SUB labeled "Com/PGU" of a PCD3.M5xx0.

Reason
The port "Com/PGU" of the PCD3.M5xx0 can be used as either PGU port for programming the PCD or for connecting an external modem to the PCD3. In case a modem is connected, the full handshake must be enabled and by doing so the detection mechanism for a PGU connection established with a PCD8.K111 is disabled.
A second reason could be that the firmware 039 is installed on the PCD3. In this case a firmware problem avoids a successful serial PGU connection.

Solution
Connect to the PCD using a USB cable (which always works as programming connection) and upload the current hardware settings of your PCD3.
§ix100519§
After having uploaded the current configuration of the PCD3, check that the checkbox "Full RS232-handshaking on Port 0" is not checked. If it is checked, uncheck it and download the modified hardware configuration in order beeing able going online with a "serial PGU" connection.

If it is still not possible going online with the PCD3, please check the firmware version of the PCD3. Note that the version 039 has a known problem that avoids going online over the Serial PGU connection. In case you are concerned by this problem, please contact your local sales office and request a firmware that fixes this problem (e.g. 03A).

Due to a firmware problem the clock of a PCD3.Mxxxx equipped with a firmware x3x older than version 037 can be corrupted in run time.

Symptom
The clock value of a PCD3.Mxxxx equipped with a firmware x3x older than version 037 can run "accelerated" while the PCD is in run. After a power off / on of the PCD, the clock will be set correctly again.

Reason
This behaviour is caused by a problem in the firmware and is related to the "Soft RTC" which has been introduced in version 030.

Solution
This problem is corrected in firmware version 037. Please refer to the support site where you can find the latest version of the PCD3 firmware in the section "Product information --> PCD3 --> Mxxx0"

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).

When downloading a recent PCD3 firmware (e.g. 031) over e.g. USB it can occur that the error message "Download failed on END command" is shown at the end of the download. The LEDs of the PCD remain blinking in the "Firmware download" sequence.

Symptom
At the end of the firmware download (in S-Bus USB mode) of e.g. version $33 the "PCD Firmware Downloader" an error message window pops up saying "Download failed on END command, Error: No response."
After a reboot the PCD boots properly and has loaded the new firmware version.
§ix100473§

Reason
The PCD does answer the "END command" telegram too slowly. This is because the PCD first needs to calculate the CRC of the firmware wich takes a bit longer than 250 ms (which is the default timeout on S-Bus PGU).

Solution
In order to avoid this error message please increase the timeout of the "S-Bus USB" to e.g. 500 ms:

• Go offline with your PCD3

• In the "Online Settings" of the relevant CPU click the button "Setup" behind the channel selection "S-Bus USB"

• Change the default value of 250 ms to 500 ms

• Accept with "Ok" and close the "Online Settings"

Note
The same symptom can also appear when using other communication channels, e.g. Ethernet. In case the same message apperas also on Ethernet, please also update the accoring settings.

In case a PCD3 has installed a firmware version older than version 020 the download of a recent firmware version (e.g. 031) fails. The error message of the "PCD Firmware Downloader" in this case is "NAK response".

Symptom
It is not possible downloading a firmware newer than $25 (e.g. 031) to a PCD3 having installed a firmware version older than 020 (e.g. 018). The progress bar of the "PCD Firmware Downloader" nearly reaches 100% but then a message pops up saying "Download Failure, Error: NAK response".

Reason
The firmware download fails because the installed firmware (e.g. 018) first stores the downloaded firmware file to the onboard RAM (before copying the new firmware to the flash). The space required on this RAM is not sufficient for firmware versions newer than version $25.

Solution
The new firmware can only be loaded if the PCD is first switched to the "Loader State". In this state not the firmware itself but the boot loader handles the downloaded firmware file (and the boot loader does not copy the firmware to the RAM first).

Procedure for switching the PCD3 into "Loader State"

• Switch the power of the PCD on.
• On a PCD3.M5xx0
  Switch the RUN/STOP switch up and down as soon as the green RUN LED starts flashing.
  On a PCD3.M3xx0
  Press the RUN/STOP push button and release it as soon as the green RUN LED starts flashing.
• Verify that the PCD is switched to the “Loader State”:
  In case the PCD was successfully switched to the “Loader State” the “Run/Halt” LED will blink in an infinite sequence (dark-red-green-red) which is the indication of the “Loader State”.
  On the PCD3.M5xxx additionally the LED’s on the battery module will blink in the sequence “Run-Halt-Error-Halt-Run”.

Note
This procedure is only required for updating the firmware to a recent version. Once the firmware is updated this procedure is not required any more.

Remark
In case the booter version installed on the PCD is older than or equal to 024 it is only possible downloading the firmware in PGU mode using a PGU cable (PCD8.K111).

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
  

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.

the minimum firmware version for PCD3.M5540 hardware version D is V023

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:

This is related to a firmware problem in the PCD3 FW 018. Update to the next official version.

A firmware bug in version 018 does disable the power supply for the PCD8.K120 (Profi-S-Link cable) after a firmware download. A reboot of the controller is needed in order to get the adapter running again.

Symptom
After a firmware download to the PCD3.Mxxx0 the Profi-S-Link adapter doesn't work. No online connection over this cable is possible any more until the PCD3 is rebooted.

Reason
This is a bug of the firmware version 018 for the PCD3.

Solution
Upgrade the firmware to the next version (downloadable from the support site www.sbc-support.com). In case you cannot find the firmware there, contact support@saia-pcd.com.

Configuration:
PCD3
PCD3.F121 Port 1
or on Port 0 (just with FW $26)

Problem
When using a Sasi Slave F-Box for the configuration of channel 1 and choosing RS Type RS 232, it will generate an error and the communication will never work. Otherwise the same configuration works on a PCD2.

Reason
There is a difference in the Firmware of the PCD3 which doesn't allow this configuration

Solution
Choose RS Type Default in the Sasi Slave F-Box and it will work.

If you use the instructionlist command "TEST 10" for controlling the real time clock in the PCD3, the

systemcycletime will get down to approximitally 2 or 3 cycle. The bug will be fixed in the next FW_Version

check before Firmware download over a network TCP/IP or Modem:

before you update the PCD- firmware, check that your hardwaresettings and user program is stored in to the flash memory 

There are firmware depending differences in the handling of the Serial-S-Bus communication diagnosic flags TDIA and RDIA. Those flags are refreshed continuously by older FW versions but not by the Saia PCD® COSinus Classic PCD firmware (used for PCD2.M480 and PCD3 controllers).

Symptom
The diagnosic flags do indicate whether there has been a communication error. The flags are directly depending on the diagnostic register RDIA. If the RDIA holds any value not equal to 0, the according diagnostic flag is set.
The state of the diagnostic flags is refreshed every ms by conventional FW versions (used for PCD1, PCD2.M1x0, PCD4, PCD6).
The Saia PCD® COSinus Classic PCD firmware (used for PCD2.M480 and PCD3) does not any more refresh the diagnostic flags cyclically. On this FW, the diagnostic flags are only refreshed on a communication event (such as e.g. a SRXM instruction).

Reason
Basically the diagnositc flags are refreshed by the communication routine of the FW. Conventional FW is polling the communication routine cyclically (every ms).
The Saia PCD® COSinus Classic PCD dosn't call the communication routine cyclically but only on interrupt (e.g. the communication instruction SRXM does generate such an interrupt). This means that the diagnostic flags are only refreshed on a communication event.
The advantage of this method is a minimized CPU load due to the communication task.

Conclusion
This change of the behaviour of the diagnostic flags isn't conflicting with any description or manual. However, there could be some program code that bases on the automatic refres of those flags. In this case the code has to be adapted when intended to use on a PCD running Saia PCD® COSinus Classic PCD FW.
The adaption could be realized in the way that on reset of the RDIA (which has to be done anyways) also the diagnostic flags are reset.

There is an Error Led on nearly every PCD system that can indicate a problem on the system. Read this FAQ to learn more about the different reasons for a lit Error LED and how to find the problem causing the lit error LED.

What causes the Error LED to get lit?
There are different reasons for a lit error LED. The most common reasons are listed below:

• A problem while assigning a communication port (e.g. missing communication module or wrong parameters)
• A problem while sending an S-Bus telegram (e.g. missing port assignation or invalid data array or media)
• Invalid mathematical operation (e.g. division by zero or value overflow after a multiplication)
• Index register overflow

How to find the problem in the code/configuration?
One fast way to find the problem is reading the history entries of the PCD. This may be done by using either the Online Configurator or the Online Debugger (type "Display History"). In the History some of the problems are listed explicitely (e.g. IPM not present) for further information regarding the History entries, please refer to the PG5 Help. The chapter "Messages" contains "Halt and History messages".
If only an "Error Flag" is mentioned the next task is to find the program part where the Error status-flag is set. This is to be done by using the Online Debugger:

• Go online with your Fupla- or IL program.
• Open the Online Debugger and type "Restart Cold All CPUs".
• Still in the Online Debugger, type "Run Until Status-flag Error". As soon the Staus-flag "Error" is set, the PCD will be stopped. Therefore the Fupla Editor will jump to the page which actually is processed (only this page is part of the current Fupla file! If the Error isn't caused by this Fupla file, it will jump to any other page which doesn't cause the problem. Have a look at this page and the FBox with the "stop"-box on it and decide whether the problem could have been caused by this FBox!
  If there isn't any FBox that could cause any problems mentioned above, repeat the procedure while beeing online with the next Fupla file of the CPU).
• If you can't find the problem directly in a Fupla file, switch to the Online Debugger again. After having stopped, a line similar to the line written below will be shown:
  *001234  STH       I/O       48                                  A1   Z0     N0     P1    E1     IX      COB2
  This first number of this line indicates on which line of the code the problem happened: the last instruction BEFORE the line shown caused the problem (the error LED is lit after the problem).
• Type "Display Program <line indicated -10> Count 15". Now you can see the instruction that caused the problem: Refer to the IL instruction Set (Online Help of IL Editor SEDIT) in order to figure out what this instruction exactly does.

If a SASI instruction causes the problem, check out the following possible reasons:

• The port is already assigned (have a look at the HW configuration and search for further SASI instructions by typing "Locate Instruction SASI" in the Online Debugger!).
  Hint: Also have an eye on the SASI FBoxes you used as well as on the HMI Settings tab.
• The port doesn't exist
• The SASI text isn't valid
• S-Bus support isn't enabled in the Hardware Settings but an S-Bus assignation was executed. This won't work because in this case the PCD doesn't have an S-Bus address (which is required for S-Bus communication).

If it seems as a mathematical operation caused the error, use the online debugger to run shortly before the problem-causing part of the code by typing "Run Until Instruction-Pointer Equals <instruction line shortly before problem-line>" (note that the instruction line must contain an instruction!). Once reached this line, type "sTep". In the Step-mode, you will see the contents of the PCD medias [brackets].

Remark:
The Error LED is lit in case the Status Flag E (Error status flag is set high) and no XOB 13 is programmed. In case the XOB 13 is programmed, the Error Led won't get lit but this XOB is processed immediately.

Use caution when downloading FW to a PCD3.Mxxxx controller because it is possible downloading a wrong FW (e.g. the one for the PCD2.M480).

Once the wrong FW is downloaded follow this procedure for downloading the correct FW:

Once a FW which is written for the PCD2.M480 is downloaded into a PCD3, there is only one way to get the PCD running again:

1. PLC power on
2. Switch the RUN/STOP switch two times up and down while RUN LED is blinking. Then download the FW via PGU cable (PCD8.K111) in PGU mode.

We have made good experiences with the GALEP 4, for PCD1 FW together with the adaptor 210841. The local dealer for Switzerland is www.redacom.ch.

Order numbers for empty firmware chips:

PCD1.M1x0: 1x ASN 4 502 7178 (OTP27C4002), one time programmable
PCD1.M137: 1x ASN 4 502 7178 (OTP27C4002), one time programmable
PCD2.M110/M120: 2x ASN 4 502 7126 0 (27C1001-10, EPROM)
PCD2.M127: can be downloaded, refer to the product page on www.sbc-support.ch
PCD2.M150: 2x ASN 4 502 7341 0 (49F040 ,Flash-EPROM)
PCD2.M157: can be downloaded, refer to the product page on www.sbc-support.ch 
PCD2.M170: chip soldered on the main board, the FW can be downloaded with PG5 *
PCD2.M177: can be downloaded, refer to the product page on www.sbc-support.ch
PCD2.M480: chip soldered on the main board, the FW can be downloaded with PG5 *
PCD2.M487: can be downloaded, refer to the product page on www.sbc-support.ch
PCD3.Mxxxx: chip soldered on the main board, the FW can be downloaded with PG5 *

* Procedure to downlaod a firmware:
1) get the appropriate file from product page on the supportsite www.sbc-support.ch
2) open PG5 and go to the online-configurator; go offline
3) open the menu tools, download firmware
4) browse for the firmware file and start the download
5) load the HW configuration and the user program

Or "What is the difference between 0-, $- and #-firmware versions?". PCD firmware for non-Saia PCD® COSinus Systems (PCD1, PCD2.M1x0, PCD4, PCD6 and PCS) are named with 3 letters (e.g. 010, B0W or #31). This FAQ explains the meaning of these version and how to figure out which one is more recent.

The firmware version naming of non-Saia PCD® COSinus systems
In general the 3 letters (abc) are used for the following indications:

• a
  Definition of the kind version this firmware is. The possible versions are the following
  - 0xx versions are "official production versions" (010 is the first official production version)
  - Bxx versions are Beta versions which contain new features compared to the previous production version
  - #xx versions are "customer bug fix versions" of an official production FW version.
  - $xx versions (Pilot version) include new functionalities which are not yet fully tested. Therefore a $-version should only be used in field if the developement gives their ok!
• b
  The second letter defines the main production version (starting with 01x wich stands for first official production version, followed by 02x (where the 02x has important new features compared to the 01x version
• c
  The last letter is incremented for each build of the firmware (best observed for the bug-fix versions; #21 is based on the 020 firmware and contains corrections for the 020 firmware version) 

To figure out which version the base version of a bug fix- or pilot version is, have a look at the second character of the corresponding version (e.g. the "1" of the 013). This character indicates the official production version on which the bug fix or pilot version is based on.

Examples
010    is the official production version
018    is the production bug fix version of 010; no new functions
#19    is a customer bug fix version based on 018 (and therefore also on 010); no new functions
$19    is a pilot version based on 010 with new functions. The bug fixes done for e.g. 019 probably aren't implemented in this version! (the new features will be added to the production firmware versions in 020 or later.

Remark
Early versions of the Saia PCD® COSinus systems (PCD2.M480, PCD3, PCD2.M5) up to 039 were named with this system as well. In order to reduce confusion concerning features of a firmware the new firmware naming a.bb.cc has been applied (see FAQ 100741).

Some history entries introduced in new firmware versions can't be found in the Online Debugger Help nor in the online help of the Online Configurator.

Below you can find recently introduced History entries that can't be found in the Help files of PG5 versions older than PG5 1.3:

Error Messages concerning PCD1.M2, PCD2.M480, PCD2.M5xx0 and PCD3.Mxxx0 systems (SBC-NT)

The IL instruction DSP (display value on PCD7.F530 display) is not supported on Saia PCD® COSinus systems. When downloading it to a Saia PCD® COSinus system, the PCD will not go in RUN and give an error message such as "Invalid instruction" (e.g. a PCD2.M480), "Precompiler error" or "Invalid OPCODE" (on a PCD3.M5xx0 with firmware 1.10.16).

Why is the DSP instruction not supported on Saia PCD® COSinus systems?
Since it isn't allowed or even possibe to mount a PCD7.F530 card on a Saia PCD® COSinus system (e.g. a PCD2.M480, a PCD2.M5xx0, a PCD3 or a PCD1.M2xx0) the instruction for accessing the display of the PCD7.F530 is not supported by the CPU.

Remarks

• The PCD7.F530 can't be mouned on a PCD2.M170 or on a PCD2.M480 because it could cause a short circuit on the internal bus connector placed right under the slot B1.
• If a user program containing a DSP instruction is downloaded the PCD2.M480 won't run the program and the error message "Halt reason: invalid instruction" will be entered in the CPU's History.