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.

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

Due to an error on the E-Line S-Bus communication library < 1.2.110, the S-Bus communication stops after a certain time, if the communication mode ‘on Event’ or ‘on Sampling time n’ has been selected on the S-Bus communication FBoxes

Problem description:
If on the S-Bus FBox ‘SEND’ or ‘RCV’ the communication mode ‘on Event’ or ‘on Sampling time n’ was selected then after the update of the PG5 E-Line S-Bus communication library < 1.2.110, the S-Bus communication of the ‘SEND’ or ‘RCV’ FBox stops after a certain time and no S-Bus data’s are exchanged to the S-Bus slaves.
This problem occurs on all possible communication channels like RS485 or Ethernet.

The communication works well, if on the above mentioned FBoxes the communication mode was set to ‘On each cycle’ or ‘on data change’.

Detail information about the behavior:
Communication stops after a certain time:
The communication stops after 24 days after a power on of the PCD because the PCD internal millisecond systemcounter which is used for the event transmission has reached his maximum value and will be reseted to the value 0. Due of an error on the FBox library, this situation leads then to the communication failure.

Solution:
Either configure the communication mode in the ‘old’ FBox to ‘On each cycle’ or ‘on data change’ or use the E-Line S-Bus communication library 1.2.110 or newer.
The error is fixed in the FBox library 1.2.110, means the ‘event’ or ‘on sampling time’ communication runs well.

Due to an error on the communication library 2.7.370, the S-Bus communication stops after a certain time or after the download of the program, if the communication mode ‘on Event’ or ‘on Sampling time n’ has been selected on the S-Bus communication FBoxes

Problem description:
If on the S-Bus FBox ‘SASI S-Bus Master’, ‘SASI S-Bus extended’, ‘SEND’ or ‘RCV’ the communication mode ‘on Event’ or ‘on Sampling time n’ was selected then after the update of the PG5 communication library to the version 2.7.370, the S-Bus communication of the ‘SEND’ or ‘RCV’ FBox stops after a certain time or after the download of the new compiled program and no S-Bus data’s are exchanged anymore to the S-Bus slaves.
This problem occurs on all possible communication channels like RS485 or Ethernet.
The communication works well, if on the above mentioned FBoxes the communication mode was set to ‘On each cycle’ or ‘on data change’.

Detail information about the behavior:
Communication stops after a certain time:
The communication stops after 24 days after a power on of the PCD because the PCD internal millisecond systemcounter which is used for the event transmission has reached his maximum value and will be reseted to the value 0. Due of an error on the FBox library, this situation leads then to the communication failure.

Communication stops after the download of the new compiled program:
The library 2.7.370 internally uses a register which was not used before.
Depending of the value stored in the past in this register it’s possible that the S-Bus communication runs well or stops after the download of the program.

Solution:
Either configure the communication mode in the ‘old’ FBox to ‘On each cycle’ or ‘on data change’ or use the S-Bus communication FBox library 2.7.380 or newer.
The error is fixed in the FBox library 2.7.380, means the ‘event’ or ‘on sampling time’ communication runs well.

Fbox Update of the E-Line Library causes Problem with I/O refresh in Fupla

Symptoms

PG5 2.2.140 with E-Line Fbox Library V2.1.100.
After the automatical Fbox Update in the Fupla Editor, the Projekt will be Rebuilded and downloaded into the PCD without Errors.
Checking the Funktions Online, there is no Refresh for the States of Inputs and Funktion for the Outputs visible.
An Kommunikation Error is not indicated.

Reason

An Error in the PG5 2.2.140 does not perform a clean update

Solution

Is described in FAQ 101994

In PG5 2.2.220 the Error is fixed

Following modules have status visible directly on the device and in the symbol.

This Faq does explain the meaning of each status. This is valid for the following modules. (L-Series)

1.1 General status

1.1.1 LED signalization

2.1 Analog inputs

2.1.1 LED signalization

*) To avoid error indication (blinking LED) unused inputs should be configured in voltage range (default).

2.1.2     Status register

The analog input status registers are updated cyclically when the firmware read the inputs.
Each register contain 4 analog input states, one byte by channel.

Below for example the AnalogueInputStatus0_3:

The state register has 2 bits for information about overflow & underflow and the 6 others are reserved

The status is cleared when the input has again a correct value.

2.2  Analog outputs

2.2.1    LED signalization

2.3 Digital input

2.3.1    LED signalization

2.4 Relay output

2.4.1    LED signalization

In Mai 2017 the firmware 1.08.06 was introduced into production for the systems:
PCD1 E-Line RIO's L-Series

In March 2017 the firmware 1.04.25 was introduced into production for the systems:
PCD1.B1010-A20

In October 2016 the firmware 1.04.24 was introduced into production for the systems:
PCD1.G1100-C15, PCD1.G360x-C15, PCD1.F2611-C15, PCD1.W5300-C15

Firmware 1.08.06 (Mai 2017)

Main corrections

• For the E-Line RIO's, L-Series, support the S-Bus and Modbus communication on the RS485

Firmware 1.04.25 (March 2017)

Main corrections

• For the PCD1.B1010-A20, correction of the randomly change of the S-Bus address used in the device due of EMV possible interferences on the digital inputs DI12 to DI23

Firmware 1.04.24 (October 2016)

Main corrections

• A download of application programs with a program size > 60 kByte could put the pro-grammable IO-modules in a reset mode
• Program download to the programmable IO-modules over RS485 and a gateway station was not possible
• On the PCD1.G360x-C15 the initialisation of the triac outputs is done to late after a power on of the PCD1.