Because the energy meters have a slower S-Bus interface the "SASI S-Bus Master" FBox gets red when communicating with energy meters. This red LED can be ignored (or the FBox SEnergyInit can be used; this FBox does not get red on every retry but only if the Energy Meter does not answer at all).
In the english version of the FBox library for the Energy meters ALE3 with Serial-S-Bus interface the symbol names have been mixed up so that the same value appears as "T1part" and as "T2 part" (partial counter of tariff 1 and 2 are identical, equal to the one from Part2).
If a S-Bus communication is used between the PCD3 or PCD2.M5xx0 and the MB VGA panel (PCD7.D457Vxxx and PCD7.D410Vxxx) then it may not be possible to write to the PCD variables (depending of the firmware installed on the MB VGA panel).
We have received the information that on an application it was not possible to access with PG5 version 2.1.420 over serial line (RS232) in PGU or S-Bus mode to the PCD and the message: Error 99: Can’t open port comx was shown in the debugger. The reason why it was not possible to access the PCD was the fact, that the com port was used from another application at the same time. The application which have used the same serial port was the software SoMachine from Schneider Electric. Solution: To be able to go online in this situation, it’s necessary to stop the software SoMachine from
To power on the PCD8.K120 Profi-S-Link adapter you have to enable the Profi-S-Bus of the corresponding port on the "Profi-S-Bus" folder of the PG5 Hardware settings and you have to downolad the Hardware settings to the PCD.
It’s possible that the some of the S-Bus telegrams transferred from the PCD S-Bus master to the S-Bus slaves over RS485 are malformed, and the S-Bus slave does reject the request from the master. This could lead to the situation that for example the PCD S-Bus master don’t receive actual values from E-Line RIO’s or that the program download of a PCD program from the PC to a Slave PCD which is located behind a gateway PCD, fails. The firmware update of the PCD who act as S-Bus master with a firmware 1.28.34 or newer solves the issue.
If the S-Bus communication over TCP/IP between PCD’s does not work, then do check on the TCP/IP settings table of the PG5 project manager that the field “use” is checked for each line (device) which have to communicate over S-Bus TCP/IP. It’s possible that after an import of a PG5 1.4 project in to PG5 2.0 the field “use” on the TCP/IP settings table is unchecked and therefore the communication over S-Bus TCP/IP doesn’t work.
Due of an error on PG5 2.1.420, a download of the application program to the PCS1 does delete the S-Bus configuration which was loaded previously with the PG5 device configurator The error is fixed in PG5 2.1.430.
-Line PCD1 / _Firmware Classic Why the RS-485 S-Bus [...] possible that the some of the S-Bus telegrams transferred from the PCD S-Bus master to the S-Bus slaves over RS485 are malformed, and the S-Bus slave does reject the request from the master. This could lead to the situation that for example the PCD S-Bus master don’t receive actual values from E-Line RIO’s or that the program download of a PCD program from the PC to a Slave PCD which is located behind