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

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.

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 some specific sensor and configuration, the inputs of a module PCD2/3.W525 could perturbate an other input of the same module

Module PCD2/3.W525 are not designed as other analog input modules (as PCD2/3.W340 or W200 for example). Particularities of the module W525 are the following:

-        Galvanic separation of inputs/outputs.

-        Differential inputs/outputs.

For most of sensors, which are used in differential mode, no problem could be detected from other inputs.

With the use of non-differential sensor, when all (-) parts would be connected together, perturbation might be visible on another channel. As the W525 module has galvanic isolation and due to the design of the module, unwanted return current could appear and disturb other inputs.

If you experience such situation, there is a possibility to connect the (-) of your sensor to the gnd of the module. By doing it this, galvanic isolation of the whole module will not be valid anymore.

Therefore is a special configuration of the jumper possible.

No, the PCD7.F110, PCD7.F120, PCD7.F150 and PCD7.F180 can’t be used on PCD1.M2 and PCD2.M4x60 devices.

Only the PCD7.F1xxS modules are supported on the PCD1.M2 and PCD2.M4x60 CPU’s.

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

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

After Power on the PCD goes to HALT with the message:

IO HW Lock Fail

Symptom:

If you go online with the online configurator, you get the following message:



Reason:

The module PCD2.W525 was removed.


Solution:

The module PCD2.W525 has to be plugged into Slot1.

The following explanation is from the manual 27-619_EN:

Slot 1 is only for operation with a PCD2.W525 module. This module is factory installed and included with delivery.
If this module is removed, the PCD1.Room cannot switch into RUN mode.

The PCD1.Room is able to handle up to 10 S-Bus and 10 Modbus slaves.

With the PCD FW < 1.22.25 the slave addresses had to be in the address range from 0-9.
It was not possible to communicate with slaves where the address was > 9.

Since the FW >= 1.22.25 it's possible to use the whole address range between 0 and 253 for addressing the slaves and to use up to 10 different addresses in this range.
If you use more than 10 addresses then these addresses are unaccounted and it's not possible to read/write to this slaves.
If you want to give new addresses or change addresses to the salves a download of the application program and therefore a reset of the PCD 1.Room is necessary.

With TCP/IP connections (Ether-S-BUS and Modbus TCP/UDP) there are no limitation if the PCD acts as slave.
If the PCD is master the slave addresses for Modbus and S-BUS are also limited to 10. Concerning the number of IP-Nodes / IP addresses there are the usual limits (more information can be found in the manuals for Modbus 26/866 and Ethernet 26-776).

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

Due of an error of PG5 2.0 and PG5 2.1 it’s not possible to configure on the device configurator correctly the Profi-S-Bus of the PCD1.M2xx0.

The device configurator uses the port 2 for Profi-S-Bus, instead to use the port 0.

The error is fixed on PG5 2.1 version PG5 $2.1.047

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.

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

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.
  
  
  
  

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 the PCD1.M2120 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" file on the flash file system or to a file in the folder PCD_BACKUP on a INTFLASH or the M1 flash card. 
This backup does not include the content of the registers, flags and counters.

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:

Content	backup to     hidden onboard flash,  FW before 1.16.xx	FS backup to hidden   onboard flash  FW 1.16.27	file system backup (to M1 card or INTFLASH)
User program and  memory allocation
RAM and ROM DBs  (at the time of the backup)
S-Bus settings (address,  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)	n/a	*)

*) 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. "INTFLASH:/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":


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, the backup can be done as usual as soon as the folder "PCD_BACKUP" has been created manually on the M1 flash module or the INTFLASH.
The following order will be used for the backup and restore:

• M1_FLASH:/PCD_BACKUP
• INTFLASH:/PCD_BACKUP

 Additional remarks

• Every time a new backup is created, the existing backup in this folder will be deleted by the PCD
• 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 IP extensions (DHCP, PPP, DNS, FTP- and Web Server configuration) are included to backup (onboard and flash card/INTFLASH)
• Because the new FS backup is written to a file system, the memory cards containiing the "backup partition" (PCD7.R500, PCD7.R551 and PCD7.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 with media content"

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.

On a PCD1.M2 if you define 2 PCD2.W525 with the media mapping activated there will be an error after the download of the program and the PCD1.M2 will stay in halt.

With PG5 2.0.150 this is not possible to program 2 PCD2.W525 with the media mapping activated on a PCD1.M2. Even if you are using the Patch 4 it will not work.

After the download of the program you will get the following error:


This problem is solved with PG5 $2.0.182 or more recent.
We suggest to use PG5 2.0 Service Pack 2.

Please read this FAQ in case you are updating the PCD firmware from a version previous to 1.16.xx to 1.16.xx (e.g. from 1.14.23 to 1.16.16).

When updating the firmware of the PCD from a version to 1.14.xx (or previous) to version 1.16.xx the content of the memory is lost (user program, hardware configuration, register, flags etc. and the user program backup on the onboard flash).

Reason
The reason for this data loss is that the onboard flash (where the user program backup is stored) is reformatted in order to support the new backup mechanism which also does backup the confiugration of the IP Enhancements (DHCP, DNS, PPP, FTP- and Web server).
Reformatting the flash takes up to one minute right after the download of the new firmware.

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

Additional remarks for PCD3 hardware bought some time ago
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 and newer because these platforms are not equipped with enough memory to hold the firmware 1.14.xx (or 1.16.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 PCD1.M2 and PCD2.M5 systems can be equipped with a firmware 1.16. and more recent.

The price list 2011 does not contain the article number of the screw terminal blocks from a PCD1.M2xxx. This is why the numbers are listed here.

X0: 4 405 5089 0 (11-pole, labeling 0-10)
X1: 4 405 5087 0 (9-pole, labeling 11-19)
X2: 4 405 5088 0 (10-pole, labeling 20-29)
X3: 4 405 4919 0 (10-pole, labeling 30-39)

§ix101284§

In case the file system on e.g. a "blue memory module" such as the PCD7.R550, R551 or R561 is filled up to the last byte, it may happen that the memory module can no longer be accessed.

Symptom
After a file system has been filled up completely the files on this module are no longer accessible after the next reboot of the PCD. 

• In case of an FTP access to the PCD, the file system on this memory module (e.g. M1_FLASH:/) is no longer visible.
• In case a "Memory Management" FBox is placed in the Fupla program, the error -71 (FS_FILE_SYSTEM_CHECK_ERROR) is indicated.  

Reason
The reason for this situation is most likely that the whole memory has been used, and there is no more space left for executing a "compression" of the content of the module (see FAQ 101558 for more information regarding the amount of memory available on the file system).
In this case the firmware detects (at start-up of the PCD), that it is no longer possible to correctly manage the flash (e.g. executing a compression) and therefore avoids accessing the memory module with error -71: "Mounted with Errors".

Solution

• If the error happened:
  In case no relevant data is stored on the module it can be made accessible by a format of the module (which can be executed by the "Memory Management" FBox from the library "File System").
  For formatting the card please set up the parameter "Block size: 1024bytes" in the "Memory Management" FBox. (When you set it to "default" the FBox tries to read the block size from the memory card and of course it fails.) 
• In case important data is stored on the module, please contact your local sales office.
• In order to avoid this error:
  - Do not fill-up the flash memory module to the last byte (but as described in the manual to 80%
    if static data is stored, and to 50% if data is regularly written to the flash module.
  - Update the firmware to firmware 1.16.27 and later (or 1.10.61 for older systems); these versions avoid
    the situation that the flash is filled up to the last byte (which can lead to the error -71).  

Remarks

• This phenomenon can occur on the following systems or modules:
  - PCD3.R550, PCD3.R551, PCD3.R561
  - PCD7.R550, PCD7.R551, PCD7.R561
  - INTFLASH of a PCD3 Compact or a PCD1.M2
  

When using a memory module with a file system the available memory for the files is smaller than the specified size of the module. This FAQ explains what for the "not usable" memory is used.

Symptom
When storing files on a file system from a memory module or to a file system on the PCD itself (e.g. the INTFLASH from a PCD3 Compact) the total size of all files which can be stored is smaller than the specified size of the memory.
If e.g. a memory is defined with 1 MByte, it is possible that I can only store 866 kByte to the file system on this memory module.

Reason
The reasons for this phenomenon are the following:

• Memory management
  Some of the memory is used for the management of the file system itself (for that the firmware "knows" where to find the files which are stored).
  Example: On a "blue" memory module such as the PCD7.R550, R551 or R561, the size for this internal ornanization data is 64 kByte.
• Memory reserved for compress task
  Aditionally there is one sector of the memory reserved for the compressing task. During this task, the PCD needs to copy data from the sectors to be compressed to this reserved memory.
  Example: On a "blue memory module" such as the PCD7.R550, R551 or R561, the size of this sector used for compressing the flash is 64 kByte
• Every file needs at least one "block" of memory
  The files located in the memory are stored in blocks, and a block can only contain data from one file. This means that as soon as a file is generated (even if the size is just 8 bytes), the whole block can not be re-used for another file.
  Example: This leads to the fact that e.g. 10 files with one character in it (which would be 10 bytes in total) will use 10 blocks (which is around 10 kByte on the INTFLASH of a PCD1.M2xxx or a "blue flash module").
  The amount of "unusable" memory is depending on the number of files and the block size of the file system. In maximum the "unusable" memory is the number of files multiplied with the block size.   

This rules apply to all file systems on memory modules and on the INTFLASH (if available). These are:

• PCD1.M2xxx (INTFLASH)
• PCD2.R6000
• PCD3.R550, PCD3.R551, PCD3.R561
• PCD3.R600
• PCD7.R550, PCD7.R551, PCD7.R561
• INTFLASH of a PCD3 Compact or a PCD1.M2
  

In case the option "All elements" is activated in the HMI Editor the PG5 project does not work on a PCD1.M2120. After the download of the project, the PCD1 will not go in RUN but remain in Halt with the message "SF NOT LOADED".

Symptom
In case the option "All elements" is activated in the HMI Editor the PG5 project does not work on a PCD1.M2120. After the download of the project, the PCD1 will not go in RUN but remain in Halt with the message "SF NOT LOADED":


Reason
The HMI Editor uses a System Function which is not available in firmware for the PCD1.M2 up to version 1.14.xx. The required System Function is supported in firmware 1.16.27 and later.

Solution
Please update the PCD firmware to version 1.16.27 or later.
In case you do not have the possibility to update the firmware, it is possible to to disable this option "Support all media types" (and to map the media to flags) in the HMI Editor. If doing so, don't forget to adapt the according parameter in the Heavac Init FBox as well.

Remark

Please note that flags with addresses over 8191 are not supported by the HMI Editor.

When using the PCD1.M2xx0 the option "Automatic Reset" of the Heavac FBox library is not working.

RAM DBs/Texts once defined are not changed when downloading the program with PG5.

Symptom
The FBoxes from the Heavac library (as well as the ones from the DDC Suite) are not reset after a download of the program to the PCD. This is not even the case if the option "Automatic Reset" is enabled.
A possible consequence may be that the times configured in a clock FBox are never set correctly (unless you execute a manual reset of the Heavac Init FBox).

Also it is possible that baud rates don't change after downloading a program (with a new baud rate) because the SASI texts are not updated after download with PG5. The same error can also cause that a changed recipient in an email FBox is not updated and the FBox shows asterisks as output.

Reason
The reason for this phenomenon is that PG5 2.0.150 with patch 1 applied does not initialize the RAM DBs (on which the functionality of the "Automatic Reset" is based).
The problem appears also when having PG5 2.0.150 with Patch 3 installed, that texts once defined do not change.

Solution
In order to solve this issue please install the patch 4 for PG5 2.0.150 by executing the following steps:

• Install PG5 2.0.150
• Install patch 4 for PG5 2.0.150
• Re-download your project; from now on the "Automatic Reset" from the Heavac library (which is also applied to the DDC Suite FBoxes) is working correctly.

Remark
Plase note that this FAQ has been updated; At the time the FAQ has been released patch 2 was mentioned, but in fact patch 4 is required.

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.

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.

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

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