The PCD1.M120 and PCD1.M130 have been discontinued by the end of 2006 and the repair service has been stopped by the end of 2011 after the usual 5 years of guaranteed repair service.

The mechanically identical PCD1.M125 or PCD1.M135 could be used as replacement product. In some applications the usage of a PCD1.M2xx0 could also be considered.

The first generation of PCDs with integrated S-Web server did not support http-direct (e.g. the PCD1.M125, PCD1.M135, PCD2.M150, PCD2.M170, PCD2.M480) . Therefore the access of the S-Web Server must be realized using the free software "S-WebConnect" which is to be installed on a PC (accessing the PCD using e.g. Ether-S-Bus). Alternatively, an MB Panel can also access the S-Web Server (e.g. using Ether-S-Bus).

However, it is important to know that only one S-Bus client can access the S-Web Server over Ether-S-Bus at the same time!

Problem
By desing the S-Web Server of a PCD can only be accessed by one S-Bus connection per physical port (Serial-S-Bus, Profi-S-Bus, Ether-S-Bus). As result it is possible to access the S-Web Server over Serial-S-Bus and in parallel over Ether-S-Bus, but it is only possible to have one Ether-S-Bus Master which connects the S-Web Server.

That means it is not possible to access the S-Web Server of a PCD at the same time with the S-WebConnect (Ether-S-Bus) and the MB panel (Ether-S-Bus) because in this case the S-Web Server is accessed 2 times trough the same physical port (Ethernet Port).

Work around 
Here you can use the Web Connect as frontentd. The S-WebConnect will serialize the web requests and therefore avoid two parallel connections.

• The WebConnect creates only 1 connection to the Eternet Port of the PCD (Ether-S-Bus to a PCD1.M135 for example)
  --> there is no problem, because only one connection was created
• With the MB panel, instead to accessing the WebServer of the PCD directly (with the Ether-S-Bus protocol), the MP panel can be accessed indirectly via the S-WebConnect.

Example
For this example the following configuration is to be done in the MB panel configuration:

• HTTP direct
• Remost host IP of the PC (where the WebConnect is installed)
• as html file to open, you have to write: WebConnect_Connection_Profil/File_Name.html (htm)

For more information please refer to the manual for the "Web Server Classic" (26/790).

Due to an error in the firmware 0F0 the IP communication does not work on the following systems:

PCD1.M1x5, PCD2.M150, PCD2.M170

Symptom
The IP communication does not work (and the firmware 0F0 is installed on the PCD). When going online over Socket this leads to an 68k Address Error and the CPU goes in HALT.

Reason
There is an error in the firmware 0F0 which leads to this problem.

Solution
Please update to firmware version 0F1 which is available on the support site.
In case you do not have access to the internet, it is also possible downgrade to a firmware from before 0F0 (e.g. 0E6).

Remark
The firmware version 0F0 has been introduced to the production in February 2010 and has been available on the support site since March 2010 until April 2010 (release of the 0F1).

On PCD1.M1x0 or a PCD2.M110/120 with old firmware version the CPU won't go in run anymore after downloading the project with PG5 2.0.110.

Symptom
As soon as the program is downloaded with PG5 2.0.110 the PCD1 (or a PCD2.M110) does not go in run anymore. The error message is "Text segment error" or similar.

Reason
Old firmware versions do not support the DBX (e.g. the one containing the TCP/IP Settings table) created by PG5 2.0.110.

Solution
The solution is either to update the firmware to the actual version found on the support site or to modify the "*.saia5pj" file according to the following instruction: 

• Close PG5 2.0
• Open your project under c:\Documents and Settings\All Users\Saia-Burgess\PG5_20\Projects\
• Open the file "Projectname.saia5pj" with a text editor like e.g. TextPad
  You will see the following structure (or similar):
  
  [Project]
  FileRevision=2
  UserName=SBC TCS-Support Murten
  PG5Version=V2.0.110.10
  PatchVersion=5
  Name=Project17
  Description=
  DownloadAllOptions=0xFFFFFFFF
  NumberOfCpus=1
  LastActive=Device1
  
• Add the line: NoTcpipDbxFiles=1
  Afterwards it looks like:
  
  [Project]
  FileRevision=2
  UserName=SBC TCS-Support Murten
  PG5Version=V2.0.110.10
  PatchVersion=5
  Name=Project17
  Description=
  DownloadAllOptions=0xFFFFFFFF
  NumberOfCpus=1
  LastActive=Device1
  NoTcpipDbxFiles=1
  
  [LibraryFiles]
  NumberOfLibs=-1
  
  [CommonFiles]
  NumberOfFiles=0
  
  [CPU1]
  Path=Device1
  DownloadSeq=1

After this modification you can open PG5 2.0110, execute a "rebuild all" and download the project again. Now the CPU goes in run.

Remark
PG5 2.0 SP 1 will no longer generate the DBX in question. The SP1 will presumabely be released end of March 2010.

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.

Since January 2004 for PCD1.M110 and July 2004 for PCD1.M120/130 are the FW chips soldered on the PCD1.M1x0.

This is the modification 1 which was introduced on HW E but this modification can be done on older HW version too, so we may find for example HW: E1, D1, etc...

The FBox "send SMS" now supports the funktion "$-commands in text" (which is set default "Yes") which is not supported on PCD1.M1x0 and PCD2.M110/PCD2.M120.

Symptom
Only empty texts are sent in SMS messages if the option "$-commands in text" is set to "Yes" and a PCD1.M1x0 is used. While sending the SMS message, the error led of the PCD is lit.

Reason
The feature "$-commands in text" is not supported by the PCD1.M1x0 and the PCD2.M110/120.
Please refer to FAQ 100786 for detailed list of PCD systems and firmware versions supporting the "$-commands in text".

Solution
For PCD1.M1x0 set the "$-commands in text" funktion on "No".

Remark
PCD1.M1x5 do support "$-commands in text".

The memory capacity for the user program of some PCD1 or PCD2 types can be extended by plugging an additional RAM chip. This FAQ lists the chip types which have been tested for the use on a PCD1 or a PCD2.M110, PCD2.M120 or PCD2.M150.

Please refer to the table below for the chip types to be used as user program extensions:

The PCD1.M110, PCS1 and PCD3 are equipped with a supercap. This supercap needs a certain time until it is fully charged.

PCD1.M110/120
It takes about 30min. until the supercap is fully charged (5T). To keep the RAM content at least 2V are needed. The supercap contains 2V after about 5min. After this time the PCD1 will keep the data in RAM for a short time. The  buffer time (30 days for PCD1.M110 and 7 days for PCD1.M120) can only be guaranteed if the supercap is fully charged, that means after at least 30 minutes runtime.

PCS1
It takes about 45min. until the supercap is fully charged (5T). To keep the RAM content at least 2V are needed. The supercap contains 2V after about 6min. After this time the PCS1 will keep the data in RAM for a short time. The full buffer time (5..15 days) can only be guaranteed if the supercap is fully charged, that means after at least 45 minutes runtime.

PCD3
It takes about 6min. until the supercap is fully charged (5T). To keep the RAM content at least 2V are needed. The supercap contains 2V after about 1.5min. After this time the PCD3 will keep the data in RAM for a short time. The full buffer time can only be guaranteed if the supercap is fully charged, that means after at least 6 minutes runtime.

The booter versions up to version 0A2 can cause a register corruption after an power up of a PCD1.M1x5. The result of this problem can lead to wrong register contents after a short interruption of the power supply.

Symptom
If a booter version smaller 0A3 is used on the PCD1 it is possible that the register contents are corrupted after a short interruption of the power supply of the PCD1.M125 or PCD1.M135.
The booter version can be identfied by reading byte 800010 on the PCD1.M1x5. To do so, open the "Online Debugger" (PG5 Menu "Tools"-->"Online Debug") and type:
D Y 800010 <Enter> (for "Display memory Map")
After having done this, the booter version is indicated at the right side of the output line in the Online Debugger.

Reason
This problem is caused by a bug in the booter versions up to version 0A2

Solution
Update your booter to version 0A3 or newer. The easyest way to do so is using the Firmware- and Booter update tool that can be found in the PCD1.Mxxx section on the support page. This tool will establish a connection to the connected PCD in PGU mode and will download the new Booter and the Firmware.

It is a HALT-button.

• update to version 084 or later, as the firmware chips with the affected version are soldered to the mainboard, the units have to be returned to the factory for this operation

• update to version 097 or later by replacing the firmware chips, the firmware files are available on www.sbc-support.ch , an EPROM burner is required for this operation (for instance Galep 4)

• update to version 01A or later by downloading the new firmware using the online configurator, the .blk file is available on www.sbc-support.ch

Assistance by your local SBC Agent or Representative:

• your local partner will assist you with the realization of the recommended solutions

Some PCD types (Classic and xx7) have stored their firmware on 4 Mbit flash chips plugged on the main board. Further on the user memory/backup memory of many PCDs may be extended by mounting a flash chip. This FAQ contains a list of those memory chips in relation to the usage.

The possible applications for the 4 MBit flash chips

The possible applications for 1 MBit flash chips

If the download of the HW settings or the program has been aborted or interrupted, it is possible that the signature or the Flash EPROM got corrupted. This causes the PCD to interprete the user memory chip as RAM chip and therefore it isn't possilbe any more to write the Flash user memory.

Symptom
After an interrupted or aborted download of the hardware settings or the user program it isn't possible to download the hardware settings. The common error messages of PG5 are:

• "PCD memory write error" (after attempt to download correct HW settings or program)
• "The configured Code/Text Memory size is incorrect, it should be 448KB." (after attempt to download uploaded HW settings).

To figure out whether your mounted Flash has a wrong signature written in, either upload the HW settings or open the Online Debugger and type "DM[Enter]"(Display Memory Map).
In case it says that there is RAM mounted but you know that it is a Flash chip, this chip is concerned of the problem described here.

Reason
Once the signature in the header of the Flash user memory is corrupted it isn't possible any more to write this chip using the PCD. Since the PCD interpretes the mounted chip as RAM it also tries to write it like RAM (what will fail...).

Solution
The only way to reuse this user memory is to erase it using an EPROM burner like GalepIV or similar. Once the Flash is ereased and mounted again, the PCD will recognise an empty chip and test whether it is RAM or Flash memory. Once the Flash is recognised the chip will receive the correct Flash signature in it's header.

Note
Please note that also wrong jumper positions of the memory size or the memory type (RAM, Flash or EPROM) can cause the same symptom (because also in this case the PCD tries to write on the flash with the wrong procedure). In this case the problem can be solved by switching the jumpers to the right position (according to the memory mounted).

A lot of applications require a real time clock (RTC), for instance all user programs written in Fupla using the Heavac/HLK/CVC Library. Only buy the low cost version PCD1.M110 if you are sure you don't need an RTC, choose a PCD1.M120 or M130 in all other cases.

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.

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.

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

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)
  

In case a "non Saia PCD® COSinus" PCD or PCS1 system is connected with "Secure S-Bus Data mode" (e.g. over a serial cable or over modem) from time to time a telegram is not answered correctly.

Symptom
A PCD or a PCS connected with another system (e.g. PC or another PCD system) using the "Secure S-Bus Data mode" does not answer a telegram from time to time. This can e.g. be seen by a red LED on transmit or receive FBoxes (or in case a PC is used, by interpreting the tracewin files).
This phenomenon can be observed on PCD1.M1x5, PCD2.M150, PCD2/4.M170 and PCS1 systems (with firmware which are supporting the "Secure S-Bus Data mode"). Saia PCD® COSinus based systems (PCD2.M480, PCD2.M5xx0 and PCD3) are not concerned.

Reason
The reason for this behavior is that the PCD/PCS does not correcly answer telegrams where the sequence number in the secure S-Bus Data Mode header is 0xC5h. This is the case in every 255th telegram.
(The character "C5" should be replaced by "C5 01" but this is not done).

Solution
Please refer to the table below for firmware version which do correctly handle the "C5" and therefore the symptom described above is avoided.

When trying to write a text (with address higher than 4000) using the S-Web Server, the PCD system stopps working and in the PCD history a "68k add Error" is indicated.

Symptom
When trying to write a text (with address higher than 4000) using the S-Web Server, the PCD system stopps working and in the PCD history a "68k add Error" is indicated.
The following PCD systems are concerned:

• PCD1.M1x5 with firmware version higher than 0B0
• PCD2.M150 with firmware version higher than 0E0
• PCD2/4.M170 with firmware version higher than 030
• PCS1.Cxx0 with firmware version higher than 0C0 

Reason
This behaviour is not intended. Due to a problem in the firmware the write access fails.

Solution
This problem is solved in firmware version 0E6 (the version indication 0E6 is the same for all systems) which can be downloaded from the support site (www.sbc-support.ch).

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

The booter versions up to version 0A2 can cause a register corruption after an power up of a PCD1.M1x5. The result of this problem can lead to wrong register contents after a short interruption of the power supply.

Symptom
If a booter version smaller 0A3 is used on the PCD1 it is possible that the register contents are corrupted after a short interruption of the power supply of the PCD1.M125 or PCD1.M135.
The booter version can be identfied by reading byte 800010 on the PCD1.M1x5. To do so, open the "Online Debugger" (PG5 Menu "Tools"-->"Online Debug") and type:
D Y 800010 <Enter> (for "Display memory Map")
After having done this, the booter version is indicated at the right side of the output line in the Online Debugger.

Reason
This problem is caused by a bug in the booter versions up to version 0A2

Solution
Update your booter to version 0A3 or newer. The easyest way to do so is using the Firmware- and Booter update tool that can be found in the PCD1.Mxxx section on the support page. This tool will establish a connection to the connected PCD in PGU mode and will download the new Booter and the Firmware.

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.

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

Basically on PCD systems introduced before 2003 there are some restrictions to be considered about the maximum baud rate of serial communications.

Depending on firmware and hardware not all serial ports can be used at their theoretical maximum baud rate at the same time.

Systems introduced before 2003:

• All PCD1, PCD2 (except PCD2.M480), PCD4 and PCD6 as well as PCS1 classic contollers do have a baud rate limitation of 38.4 kB/s on each serial port.
  For older firmware (FW) versions there is a further restriction since there is one UART responsible for two serial ports and this UART cannot handle baud rates of 38.4 kB/s on both ports at the same time. The port allocation of the UARTs is the following: first UART: port 0 and 1; second UART: port 2 and 3 etc.
  This means that it isn't possible to set the concerned ports to
  - 38.4 kB/s each
  - one to 38.4 kB/s and one to 19.2 kB/s
  - but it is possible to set one port to 38.4 kB/s and one port to 9600 B/s.
  
• Due to more efficent port handling recent FW versions do have the following restriction (independent of production date of HW):
  Amount of ports available divided by 2 equal amount of ports that can communicate at 38.4 kB/s. All the residuary ports do have a maximal baud rate of 19.2 kB/s.
  In addition an UART of an PCD7.F5xx isn't able to handle 19.2 kB/s on one and 38.4 kB/s on the other port. But it is possible to assign both ports to 38.4 kB/s.

Systems introduced since 2003 (PCD2.M480 and PCD3.xxxx):

Due to faster hardware there are much higher baud rates possible on the serial ports (up to 115 kB/s)!
There is only one restriction regarding UART sharing left:
On a PCD7.F5xx it is not possible to communicate on one port at 19.2 kB/s and one the second port at 34.8 kB/s at the same time (but two times 38.4 kB/s is possible!).
This means that all ports may communicate at the maximum baud rate (which is specified in the technical information (TI) or in the manual) at the same time.

FW versions that support the new port handling mentioned above:
For the following and newer FW version the following rule is valid:
Amount of ports available divided by 2 equal amount of ports that can communicate at 38.4 kB/s.
All the residuary ports do have a maximal baud rate of 19.2 kB/s.

Communication interfaces containing a co-processor aren't restarted after a restart caused by the software watchdog with the option "Execute XOB0". In fact only a restart cold will be executed but without resetting the communication modules.

This behaviour is a bug and will be corrected in the next FW version for the corresponding CPU. As soon as the new FW is built it will be available on the support homepage.

In the meantime it is recommended not to use the option "Execute XOB0" for the software watchdog. In this case the communication modules will be reset normally on software watchdog execution.

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.

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

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

As a replacement, we recommend the usage of BACnet.

It is depending of the PCD/PCS used, the rest of the programme and of the memory available:

PCD2.M170/M150 until1000, advised 500 -700        
PCD1,PCS1 advised maximum 400-600         
When Extended Memory isn't used (not advised du to the speed) we can used normally 50 - 150 SNVT. 

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

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

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

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

If a PCS1 does use at the same time a serial communication with > 9’600 baud and the user wants to make a binding with the LonMaker then it’s possible that the binding will not succeed and on the LonMaker there is an error message:

“The device is application less or is not associated with a program record”

To solve the problem and to be able to make the binding either you have to switch off the serial communication or to use a baudrate <= 9'600 baud.

The reason of the problem is, that the PCS1 has not enough CPU power to perform simultaneously a Lon binding and a serial communication with > 9'600 baud.

The PCD must be equipped with a PCD7.F8xx module and RAM is to be mounted on the memory socket, with the "memory use" set to RAM (the binding does not work with a Flash).

The RAM Text and RAM DB have to be set to the following range:
- PCD1: 2000-2499, 2500-2599
- PCD2: 4000-4499, 4500-4999

If 1 Mbit RAM is used the user memory should soon be too small, it is recommended to use 4 Mbit RAM.
For a PCD1 we recommend to use maximal 400-600 SNVT.
For other PCD the theoretical limit is 4095 SNVT.


How to save the binding in a Flash?

Follow these steps:
¨      Bind the network using RAM on all PCD
¨      Execute an upload dBx and rebuild (all)
¨      Replace the RAM with flash on all PCD at wish
¨      Download the program again, this goes now in flash