It can occur that the value measured from the PCD2.W3x5 / PCD3.W3x5 modules 'freeze' during a time of about 1 to 2 minutes.

Afterwards, the modules function again and the measured analog input value is updated again in the application program. 

Affected modules:

PCD3.W3x5 cards manufactured between 1801 and 1916. (FW 1.04.00 or FW 1.04.02)
The manufacturing date is marked on the white sticker on the right side of the module.

Symptoms:

The measured value of the PCD2.W3x5 / PCD3.W3x5 cards can freeze freezes for 1 or 2 minutes. The measured value stays on the same value, there is no change. This will occur on average 1-3 times during 3 hours. This is due to a malfunction of the firmware of the module.

Afterwards, the modules function again and the measured analog input value is updated again in the application program.

Solution:

There is no isse for 'standard' HEVAC applications where no fast reaction time (< 2 minutes) is required.

For critical applications where this malfunction is not acceptable, we recommend the exchange of the affected PCD2.W3x5 / PCD3.W3x5 modules with new modules (manufacturing date 1916 or newer)
 

To replace the affected modules:

Order new PCD2.W3x5 / PCD3.W3x5 modules from SBC and send the affected modules back to SBC via RMA.

In the RMA form, note 'Advance exchange' with the remark '8D-SBC-19-001' in the comment.

The affected PCD2.W3x5 / PCD3.W3x5 modules will then be credited to you.

Depending of the hardware version of the W6x5 module and the I/O slot where the W6x5 module is plugged in, it’s possible that the analog output signal supplied from the W6x5 is not stable and is oscillating.

Symptom
The outputs of the PCD2/3.W6x5 do not deliver stable signals when placed on I/O slot 15 if hardware version B of the W6x5 is used.
If FBoxes are used for writing to the outputs, the FBox indicates temporarily an error.

Reason
The W6x5 modules with hardware version B are not correctly handling the Watchdog output (O 255).
Note that this is only the case if the module is placed on I/O slot 15 (base address 240). On all other slots the modules work correctly.

Solution
This problem is solved with hardware version A or C and newer of the PCD2.W6x5 or PCD3.W6x5 respectively.

When configuring a W525 module using the Device Configurator or the Profi-S-I/O (or Profibus DP) Network Configurator, the PCD2/3.W525 does need two registers for the analogue outputs and 8 registers for the analogue inputs.

The significations of the registers are the following:

Output registers: 

Description of the output registers:

Value CH0..1 (Register n, n+1)
This registers (Bit 0 to 15) does contain the analogue output value of the corresponding analogue output. It's a 12 Bit value.

Input registers:

Description of the input registers:

Value CH0..CH3 (Register n...n+3)
This registers (Bit 0 to 15) does contain the analogue input value of the corresponding analogue input. It's a 14 Bit value.

Load_Current / Load_Voltage (Register n+4)
On this register (Bit 0 to 15) the actual current or voltage value is displayed.

• current in [μA] (0..20'000)
• voltage in [mV] (0..10'000) 

Status Module (Register n+5)
This register (Bit 0 to 15) does contain the actual status of the module

Table module status:

Status Input (Register n+6)
This register (Bit 0 to 15) does contains the status of the input channels CH0..CH3.
The status of each input channel is displayed on 4 bits.

Table input status:

Status Output (Register n+7)
This register (Bit 0 to 15) does contain the status of the two output channels CH0 and CH1.
The status of each output channel is displayed on 6 bits.

Table output status:

PCD2.M5xx0 and the PCD3.Mxxx0 systems equipped with firmware 1.10.16 did not correctly calculate the temperature values of NI1000 temperature sensors measured with PCD2/3.W340 input modules.

Symptom
The temperature read by the media mapping for Ni1000 sensors which are connected to a PCD2.W340 or a PCD3.W340 installed on a PCD3 or a PCD2.M5 is not correct with firmware version 1.10.16.

Reason
The firmware did not correctly convert the measured signals to the according temperature.

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

A hardware conflict on a PCD2.M5xxx between a PCD2.W3x0 plugged to I/O slot 3 and the modules PCD2.F2xx0 and PCD2.R6000 leads to the fact that the communication- and memory modules do not work in this constellation. If the PCD2.W3x0 is removed from the I/O slot 3 the installation is working correctly.

Symptom
In case a PCD2.W3x0 analogue input module is plugged in the I/O slot 3 (base address 48) the communication modules PCD2.F2xx0 and the memory modules PCD2.R6000 do not work.
The LEDs on a communication module PCD2.F2100, a PCD2.F2210 or a PCD2.F2810 are lit 50% red and 50% green (blinking). The file system of the PCD2.R6000 (SLxFLASH:/) are not visible over e.g. FTP. Only PCD2.M5xxx with hardware version older than C345 are concerned.

Reason
The reason for this behavior is a conflict between the PCD2.W3x0 (PCD2.W300, PCD2.W310, PCD2.W340, PCD2.W350, PCD2.W360) and the PCD2.F2xx0 or R6000. This conflict exists only if the PCD2.W3x0 is plugged on the I/O slot 3 (base address 48).

Solution

• This conflict is no longer present with hardware version C345 of the PCD2.M5xxx (the according filter of the I/O bus has been adapted in order not to lead to this conflict).  
• In case it is not possible to replace the system immediately (or send it to the repair service for having this modification done), the problem can be solved by not using a PCD2.W30x in the I/O slot 3. If the communication module or the memory module is plugged into I/O slot 3 the installation will work correctly.

When the weighing modules first have been introduced it was possible to order a weighing module that was already calibrated for a specific weighing cell. This module was a PCD2.W721 (or PCD3.W721).

After gathering some experiences it turned out that such a calibration of a module is only asked very seldom. Beside of this fact it showed that better calibration results can be achieved when directly calibrating the module in the target system.

Due to these facts it has been decided to remove the PCD2/3.W721 from the price list. It is no longer possible ordering this module (instead, use a PCD2/3.W720).

The outputs of a PCD2.W525 or a PCD3.W525 need to be configured correctly. If this is the case, it is possible that a problem in the FBox leads to the fact that the outputs are not written correctly.

Symptom
The output signal of a W525 module is always 0. At the same time, the inputs of the FBox do work correctly.

Reason
This phenomenon can be caused by either

• an incorrect configuration in the FBox
• the module has no power supply connected. In this case the LED on the module is blinking
• a current output is configured and there is no load on the output
• by a problem in the FBox (this probelm is observed very rarely)

Solution
If the problem is not caused by an incorrect configuration of the FBox or by missing power supply of the module, please download and install the latest version of the FBoxes (V 2.6.100) from the support site.
After the installation of this library, please execute a build and download the project.

Remark
PG5 2.0.110 does contain the correct library.

In 2009 the combined analogue input and output modules PCD2.W5x0 and PCD3.W5x0 will be discontinued. This FAQ suggests possible replacement modules depending on the measured/given signals and the required resolution.

Replacement modules for PCD2/3.W5x0
The table below contains possible replacement modules for the discontinued PCD2.W1xx modules (all PCD2.W1xx had 4 input channels and 12 bit resolution).

Please note

• The W5x0 modules can not be replaced by other analogue input/output modules without adapting the user program of the according PCD! The FBoxes (or the IL code) for reading the analogue inputs need to be replaced with the FBox/IL code for the replacement module!
• There is no replacement for the ±20 mA input of the PCD2.W510 due to a very low demand. In case such a signal is to be measured we recommend applying an external converter of this input signal. 

Repair service for PCD2/3.W5x0
PCD2/3.W5x0 modules will be repaired by Saia Burgess Controls until end of 2014.

We strongly recommend using the FBoxes for analogue modules! In case this is not possible, please refer to the example project "Reading analogue input signals in Instruction List" on the "Getting Started" section of the support site.

In 2007 the analogue input modules PCD2.W1xx have been discontinued. This FAQ suggests possible replacement modules depending on the measured signals and the required resolution.

Replacement modules for PCD2.W1xx
The table below contains possible replacement modules for the discontinued PCD2.W1xx modules (all PCD2.W1xx had 4 input channels and 12 bit resolution).

Please note
The W1xx modules can not be replaced by other analogue input modules without adapting the user program of the according PCD! The FBoxes (or the IL code) for reading the analogue inputs need to be replaced with the FBox/IL code for the replacement module!

Repair service for PCD2.W1xx
PCD2.W1xx modules will be repaired by Saia-Burgess Controls AG until 31.12.2012.

PCD2.W745 and PCD3.W745 are by far the best choice, other modules (e.g. PCD2/3.W350 or PCD2/3.W220Z18) are only to be used when accuracy does not matter.

Introduction
The resistance of Pt 100 and Ni 100 elements is low compared to the resistance of the line connecting the sensor element to the PCD. When using 2 wire mode (e.g. with PCDx.W350) the resistance of the lines add to the resistance of the element, which means that the measured temperatures are always too high. Worse than that the line resistance has as well a temperature coefficient and there is no way to compensate for that in 2 wire mode.

Best choice of module
The answer to this issue is the 4 wire mode as supported by the PCDx.W745. A pair of lines is used to supply the element, another pair of lines to measure the voltage drop over the element. Thanks to this the resistance of the line and its temperature coefficient do no longer matter. Another advantage of the PCDx.W745 is the 16 bit resolution, which is advantageous for temperature measurements.

Remarks
The effect described in the first paragraph is as well present with Pt1000 / Ni1000 elements, but 10 times weaker. For many applications it is therefore adequate to use 2 wire mode, compensate the offset with a subtraction and forget about the temperature effect of the line when using Pt1000 / Ni1000. If you have a choice avoid elements with low resistance like Pt 100 / Ni 100 / Balco 500.

Depending on the resistive temperature detector type and the analogue input module, various combinations are possible which are not all listed in the FBox or the manuals.

In general an analogue input module designed for measuring the resistance of an NI1000 or PT1000 sensor can also measure the resistance of e.g. an NI1000 Landis & Staefa (L&S) or an NTC10 sensors (and many more). However, the FBox does not necessarily feature the option for configuring the relevant sensor type. In this case, the digital value of the input module can be read in the mode "1:1" and based on this value, the temperature can be calculated (or more precisely: interpolated) by using the FBox "Conversion 20 point" from the FBox Family "HVC General".
The according values which are to be filled in the "Conversion 20 point" FBox can be obtained from Saia-Burgess Controls AG.

Which combinations are possible?
In general it is important that the resistance range for which the analogue input module is designed for does fit the resistance range of the sensor for the temperature range to be measured. It is even possible to apply e.g. a parallel resistance in order to shift the resistance measured to a range which can be measured by the analogue input module. Below you can find some often used combinations of analogue input modules and special tempearture sensors:

• NTC10k sensor with PCD2/3.W340 together
• NTC10kPre sensor with PCD2.W220Z02 or PCD3.W220Z03
• NTC20k Honeywell with PCD2.W220Z02 or PCD3.W220Z03 
• Ni1000 L&S with large temperature range on PCD2/3.W220 or PCD2/3.W340
• Ni1000 Tk 5000 with PCD2/3.W360
• Ni200 DIN 43760 with PCD2/3.W350
• Potentiometer 1kOhm on PCD2/3.W220
• Potentiometer 2kOhm on PCD2/3.W340
• Staefa T1 with PCD2/3.W220
• QAC 31 with PCD2/3.W220
• KTY10-6 on PCD2/3.W220 or PCD2/3.W340 (temperature range -45..50°C)

Where from do I get the values for the conversion?
Please send a mail which contains the specific type of your sensor (if possible, provide the resistance table of the sensor) and the definition of the temperature range you need to measure to support@saia-pcd.com.

Most sensors with current output work with a range of 4..20 mA. Nevertheless it is possible measuring the range 0..20 mA with the analogue input modules for PCD systems.

Why do the SBC input modules have a range of 0..20 mA?
One advantage of measuring the whole range of 0..20 mA is that this way also a cable break (or a defective sensor) can be detected. If a value between 0..4 mA is measured, the conclusion is that either the cable is broken or the sensor is not working correctly.
Another advantage is that one module type can be used for both ranges (0..20 mA and 4..20 mA).

Does the specified resolution apply for the 0..20 mA or for the 4..20 mA?
The specified resolution does always apply for the full range of 0..20 mA. The same resoultion is used if the input module is used for measuring 4..20 mA.

Example
If a 12 bit input card is used, we'll have a resolution of 4095 DV (Digital Value) over the whole range 0..20 mA. One DV corresponds to 4.88 µA.
In case a range of 4..20 mA is measured the resolution will remain the same (4.88µA per DV) and the measured range of 16 mA will be divided by 3276 DV.
Of course it is still possible detecting a sensor/cable fault because the whole range 0..20 mA is measured by the module.

Due to a problem in PG5 (Fupla and Watchwindow) the values read by certain analogue modules can occasionally be corrupted while beeing online with the PCD.

Symptom
While beeing online with the PCD, input values of analogue input modules jump to wrong values. The problem occurs occasionally and the value shown while the error case is not predictable (but it often is always the same value). The problem occurs when beeing online with Fupla and/or the PG5 Watch Window.
When beeing online with Fupla only, the problem can disappear when viewing another Fupla page.
All analogue modules with the exception of intelligent analogue modules (W745, W720, W3x5, W525 and W6x5) can be concerned by this problem.

Reason
The reason for this problem is a problem in the "Synchronous Data View" of Fupla and the WatchWindow. When using the "Synchronous Data View" and viewing a digital input or output, PG5 automatically does read the following 31 I/Os, too. In case the addresses of an analogue module are read by this automatism, a value corruption can be the result.
Affected PG5 1.4 versions (older versions than PG5 1.4 aren't affected because the "Synchroneous Mode" was not implemented):

• PG5 1.4.100
• PG5 1.4.110
• PG5 1.4.130
• PG5 1.4.200 

PG5 1.4.120 does contain a correction that avoids this problem.

Solution
This problem can be fixed by installing PG5 SP 1.4.300. The latest version of the PG5 can be found on the support site (www.sbc-support.ch) in the section "Product information" --> "Software" --> "PG5"

The analogue input modules PCD2.W745 and PCD3.W745 do have a terminal 16 (GND) which is not documented in version 1 of the manual 27/796.

Reason for the terminal 16 (GND)
As the W745 is galvanically separated (the separation is from all terminals against the PCD I/O bus and not between the terminals) there is no defined ground level of the terminals. This leads to floating levels on the terminal side. In order to eliminate this floating level the terminal 16 is present for a connection against the common sensor ground.

When do I have to connect terminal 16 to GND?

• The terminal 16 should be connected to ground if no sensor does have an internal connection to the ground level. This is the case for common TC sensor or Pt/Ni sensors. In this case, connect the terminal 16 to ground.

• The terminal 16 should not be connected to ground if one or more sensors do have an own connection to ground (which is not recommended).

Note
The galvanic separation of the module is applied between the I/O bus of the PCD and the terminals of the W745. The terminals themselves are not separated galvanically agains each other (the GND of the inputs is connected on the module). The separation is designed for a voltage of 500 VDC.

In case a thermocouple sensor is connected with the wrong polarity, the FBox (or the FB) will indicate this with the error "underrange" or "underflow".

Note
The problem most likely occurs in higher temperature ranges as the voltage measured at room temperature is nearly =0. Therefore it is possible that the problem doesn't occur at room temperature (also the temperature measured is not accurate in this case, no error message is indicated).

This FAQ applies to the PCD2.W745 as well as for the PCD3.W745.

From a series produced in 2005 (Date Code "05xx" and FW-Version "020"),  a small percentage of modules of the mentioned types show the following problem:

• Input modules: the output values of the FBox freeze, the LED and diagnose output of the FBox indicate “no response”
• Output modules: the output values of the module freeze, the LED and diagnose output of the FBox indicate “no response”

If the problem does not appear within the first five minutes, it does not appear at all. If you have affected units, please return them for repair via your local SBC representative.

In contrast to the conventional analogue modules (e.g. the W600), the DAC (Digital to Analogue Convertor) of the PCD2/3.W6x5 is not accessed directly over the internal I/O bus of the PCD. The command is first interpreted by the module's micro controller and then cyclically passed to the DAC.

Reason for the new function principle
The employment of a µC on the module can decreases the load of the PCD's main CPU because the conversion and linearization of the output value is done directly on the I/O module (before writing it to the DAC). Because of the fact that the modules are equipped by a µC, they are called "intelligent analogue modules".

Handling by the user program
The command sequence for an analogue output value is too long for writing directly onto the internal I/O bus. Therefore specific FBoxes were created (also handling the module initialisation, value range checking and the interpretation of possible error flags from the module). The execution time of the FBox on a PCD2.M170 varies from 0.8 ms to 3.8 ms (depending on the stretch factor). The output value will be overtaken by the module's µC at the very ending of the execution of the code on the PCD.

Cycle time on the module
The µC of the modules PCD2/3.W605, PCD2/3.W615 and PCD2/3.W625 executes the following tasks cyclically:

• Comparison whether new values were sent by the PCD

• Calculation of the digital values to be sent to the DAC out of the value in user units

• Writing the digital values to the DAC

The µC cycle time of the W6x5 modules is firmware depending. While it is around 4 ms with FW version 020, it is around 2 ms with FW version 021 and above. (The module's firmware version is printed on a sticker on the module, holding 3 digits)
Since the cycle time of the PCD main CPU and the µC of the W6x5 are asynchronous, it may take up to twice the cycle time from the time the value was sent to the module until it written to the DAC. Also consider the output filter that delays the real output signal by some more µs.
The communication between the internal PCD I/O bus and the µC of the module influences the cycle time only slightly.

The screenshot below visualizes the execution time of the FBox part of one Channel (upper graph) and the output signal of the W6x5 (lower graph, 2...3.7 ms after executed command on the PCD). This graphs were recorded with a PCD2.M170 and a PCD2.W625 FW 021.
§ix100243§

Note regarding the TI
In the TI (up to version 5), a sampling rate of 2 ms is declared. This is not correct for modules equipped with FW version 020.
In the german version of the TI, a vaque translation of the sampling rate (translated to "Gesamtwandlungszeit") can cause missinterpretation.

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

‘Power PCD’s’ are:

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

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

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

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

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

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

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

Due of an issue on the production, some of the PCD2.C1000 and PCD2.C2000 produced between the week 20 and week 36 of the year 2021 where not equipped with a red jumper on the board of the PCD2.C1000/PCD2.C2000.

What is the effect if the if the red jumper is not plugged on the board?

If this red jumper is not put on the board of the PCD2.C1000/C2000, then the internal power supply is not feeding the I/O modules and it’s not possible to use the inputs/outputs of the plugged I/O cards correctly.

How to know if the red jumper is not plugged?

Visually, it’s possible to see if the jumper is plugged on the board when looking at the board from the lower side

If the PCD2.C1000/C2000 is connected to 24VDC:

The red error LED on the module is switched on.

LED’s if jumper is not plugged:

LED’s if jumper is plugged:

Which PCD2.C1000/C2000 are concerned from the issue?

PCD2.C1000/C2000 with production date between calendar week 20 and 36 of the year 2021 and which are marked with “Made in Romania” on the white label on the back of the PCD2.C1000 and PCD2.C2000

The fabrication date is also marked on the white label with for example 2133 or as 3321 (week 33 of year 21)

What to do if PCD2.C1000/C2000 are not equipped with the red jumper?

Contact your local SBC support and ask them to get the red jumpers.

They will send you then red jumpers.

To plug the red jumpers to the board, it’s necessary to remove the transparent cover of the PCD2.C1000/C2000 by unscrewing the 2 screws (Torx 10) and afterwards to plug the red jumper on the connector of the board.

Depending of the hardware version of the W6x5 module and the I/O slot where the W6x5 module is plugged in, it’s possible that the analog output signal supplied from the W6x5 is not stable and is oscillating.

Symptom
The outputs of the PCD2/3.W6x5 do not deliver stable signals when placed on I/O slot 15 if hardware version B of the W6x5 is used.
If FBoxes are used for writing to the outputs, the FBox indicates temporarily an error.

Reason
The W6x5 modules with hardware version B are not correctly handling the Watchdog output (O 255).
Note that this is only the case if the module is placed on I/O slot 15 (base address 240). On all other slots the modules work correctly.

Solution
This problem is solved with hardware version A or C and newer of the PCD2.W6x5 or PCD3.W6x5 respectively.

With some specific sensor and configuration, the inputs of a module PCD2/3.W525 could perturbate an other input of the same module

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

-        Galvanic separation of inputs/outputs.

-        Differential inputs/outputs.

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

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

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

Therefore is a special configuration of the jumper possible.

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

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

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

Attention:
The firmware 1.24.xx can be used only on PCD’s with 8 MB onboard firmware memory.
The table below does show the hardware dependencies in relation with the COSinus firmware versions

Do use at least the PG5 firmware downloader version 2.1.311 or newer (included in PG5 patch 2.1.311 or newer) to prevent the loading of the FW 1.24.xx to a not compatible PCD.

Firmware 1.24.69 (June 2017)

Improvements

• All PCD's: SBUS parity mode, correction when NAK character is received as first byte of response.
• All PCD's: When download new Ethernet-RIO Program with the option ‘Delete all backups’ it can happen that the RIO is not commissioning and don't goes anymore in ‘data exchange mode’ until the PCD reboots.
• All PCD's: When RIO name is not in upper case the RIO file is not updated until a restart is executed.
• All PCD's: When RIO file is downloaded with download changed RIO file then RIO file is not sent to RIO until a restart is executed.
• All PCD's: Ethernet Frame Padding Information Leakage fixed (CVE-2017-9628)
• PCD2.M5xx0 PCD3.Mxxx0: Self-download tool, sometimes config is lost after download of the project.

Firmware 1.24.67 (March 2017)

Improvements

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

Maintenance firmware 1.24.30 (Mai 2015)

Main corrections

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

Firmware 1.24.25 (February 2015)

Improvements

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

Main corrections

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

Firmware 1.24.09 (September 2014)
New features

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

Main corrections

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

Firmware 1.24.05 (August 2014)
New features

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

Improvements

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

Main corrections

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

The system catalog mentionned 6 digital inputs (24 Volt, 4 x interrupts) and 2 digital outputs (2 x PWM, 24V 100 mA). But in reality only 4 digital inputs (not 6) are available at the moment and 2 digital outputs as mentionned in HW manual!

Extract of HW manual:

With the PCD7.R610 memory it is necessary to use a new firmware version 1.23.32 or newer.

The firmware 1.23.32 does require a recent hardware version of the PCD with extended memory size.

Attention:

If the FW 1.23.32 is loaded to a not compliant hardware version then the firmware download is interrupted at about 86% with a NAK response message.

In this case it's only possible to re-load the FW 1.22.xx to the PCD.

Since PG5 2.1.311 the firmware downloader does verify the hardware version of the connected PCD and prevent the loading of a FW 1.23.xx to a not compatible PCD.

Basicaly all NT CPU can be updated with the new FW version from a given HW version!
Reason:
This new Firmware 1.23.32 needs a harware with an extented memory; 8 MB Flash.
All new CPUs as PCD1.M2xxx and PCD3+ (PCD3.Mxx6x) does have this extented memory and it's possible to use the FW 1.23.32 without any restriciton on this PCD's

But for the other PCD's it's necessary to use at least the hardware version as described on the table below. 

Table with the hardware dependencies in relation with the COSinus firmware versions.


Table showing the date when the first PCD with 8 MB onboard firmware memory where produced:

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

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

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

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

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

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

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

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

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

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

port 0 of the PCD2.M5440

and

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

The error is fixed since the FW 1.20.31.

Also the FW 1.16.69 doesn’t have this error.

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

The concerned PCD’s are:

• PCD2.M5440 (port 0 / RS232)

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

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

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

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

Communication over RS485 works fine.

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

Firmware 1.22.61 (February 2017)

New features

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

Main corrections

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

Firmware 1.22.48 (March 2015)

Main corrections

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

Firmware 1.22.46 (October 2014)

New features

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

Main corrections

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

Firmware 1.22.28 (January 2014)

New features

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

Main corrections

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

Firmware 1.20.25 (March 2013)

Main new Features / Extensions

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

Improvements

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

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

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

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

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

Solution:

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

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

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

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

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

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

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

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

In case the "PCD input reference" is used in the BACnet configuration and a persistent value is written in runtime over BACnet (with BACnet firmware 1.16.41), the PCD might no longer be able to read the configuration on next power up. As result the PCD remains in HALT and writes e.g. "BNt FAIL AI00006" into the history.

Symptom
In case the "PCD input reference" is used in the BACnet configuration and a persisten value is written in runtime over BACnet (with BACnet firmware 1.16.41), the PCD might no longer be able to read the configuration on next power up. As result the PCD remains in HALT and writes e.g. "BNt FAIL AI00006" into the history.

Reason
When writing a persistent value to BACnet and if the "PCD input reference" is used, the configuration stored in the flash memory is destroyed with firmware version previous to 1.16.59 (e.g. 1.16.41).

Solution
In case you use the "PCD input reference" and in case your BACnet configuration contains over 100 inputs (e.g. 60AI and 50 BI) please update the BACnet and PCD firmware to BACnet FW 1.16.59 and PCD FW 1.16.57 or later. This firmware can be downloaded from the support site.

Remark
Please note that the PCD only writes the error message into the history, but PG5 shows a message saying "Everyting is OK".

In case user program is restored from flash with a PCD3 or PCD2.M5540 with firmware 1.16.xx it is possible (depending on the device configuration) that the restored user program is not complete.

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


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

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

In some cases it is possible that a PCD7.F7500 is not correctly detected on a PCD2.M5540 with hardware version 'C' without modification '6'.

Symptom
The Profibus Master module PCD7.F7500 does not work while commissioning. During start-up of the PCD the Error LED is lit and in the history the message "PROF DP FAIL 000" is added (see screenshot from a diagnostic file below):

Reason
In some specific cases the PCD2.M5540 does not detect the PCD7.F7500. As result, the module can not be configured and the Error LED of the PCD is lit.
The PCD2.M5540 hardware version C with modification 3,5,6 contains a modification of the CPLD which assures that the module PCD7.F7500 it detected correctly.

Solution
Please use the PCD7.F7500 module with a PCD2.M5540 with the hardware version/modification "C 3,5,6"or newer.

In case you are concerned by this case and your PCD has an older version (e.g. version/modifications "C 3,4,5"), you need to replace the PCD2.M5540 with a newer one.

Remarks

• If the PCD2.M5540 is running with a PCD7.F7500 there is no need updating the hardware, even if the modification above is not applied (because the problem does only occur on some combinations of CPU and F-module
• Since May 2011 the PCD2.M5540 delivered by Saia-Burgess Controls AG have the modification 6 or later applied.

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

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

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

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

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

Additional information

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

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

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

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

Firmware 1.16.69 (July 2012)

New features

• Support of PCD7.R582 module

Main corrections

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

Firmware 1.16.52 (November 2011)

New features

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

Main corrections

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

Firmware 1.16.45 (July 2011)

Main corrections

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

Firmware 1.16.42 (July 2011)

New features

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

Main corrections

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

Firmware 1.16.27

New features

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

Main corrections

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

Hardware compatibility of firmware 1.16.27

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

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

Remarks 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 Additional remarks

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

Firmware dependency for the "file system backup"

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

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

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

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

• In order to avoid the loss of any data, please "upload all" before updating the firmware (for that you can "download all" after updating the firmware.
  
• Note that you'll need the USB port after the update (as your S-Bus address might be gone).
  Alternatively, you can also copy the user program to flash and upload the content of the media before the update (e.g. with the "Quick Data Transfer).
  
• In this case the program and the hardware configuration will be restored from flash after updating the firmware (for going online and downloading the media content after the FW update).

Additional remarks for PCD3 hardware bought some time ago
PCD3 systems with hardware older than "D" (and PCD3.M3020 and PCD3.M3120 with hardware older than E48) can not be updated to firmware version 1.14.xx and newer because these platforms are not equipped with enough memory to hold the firmware 1.14.xx (or 1.16.xx).
In case a FW 1.14.xx or more recent is loaded to one of these systems, the PCD will remain in the boot loader state after the download of the FW (in this state, a 1.10.xx can be loaded again).

All PCD1.M2 and PCD2.M5 systems can be equipped with a firmware 1.16. and more recent.

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

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

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

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

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

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

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

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

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



Please find the necessary informations in the following text.

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

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

Even the firmware filename suggests hardware rev. 'D' is needed this firmware is suitable for revisions 'A' and later.

With PG5 2.0 the current production firmwares gets also installed on the computer. They are located in the directory
"c:\Program Files\SAIA-Burgess\PG5_20\FW\Classic\" or similar.



The filename for the PCD2.M5_ contains a wrong minimum hardware revision description and is named "PCD2M5xx0_1.14.23(HW min D).blk" by mistake.
So in contrast to the filename the firmware 1.14.23 is applicaple to PCD2.M5xx0 with hardware revision 'A' and later.
The filename will be corrected with the next service pack for PG5 2.0.

The constellation of the CPU of the PCD2.M5540 and the on-board switch which is leads to the situation that (very few) telegrams may be lost. This fact can lead to the situation that the Error LED of e.g. a SASI IP Master FBox (or any communication FBox) turns red after a certain time of running communication.

Symptom
The "SASI IP Master" FBox (or every other IP-communication related FBox such as a Modbus/IP FBox) turns red after several minutes of running communication. The send and receive FBoxes do not indicate an error (as it is most likely not seen; it is only red during one retry, thus around 250ms).
In fact the phenomenon of lost telegrams (around one out of 6000) is not only present when using Ether-S-Bus or Modbus TCP/UDP but affects all IP communciation of the PCD2.M554x. It can easily be observed when using e.g. Ether-S-Bus or Modbus (because of the red LED in case of a retry), but also other telegrams such as http telegrams can be lost (but in this case the TCP level will automatically re-send the lost telegram).

Reason
This phenomenon is caused by a bug of the used Freescale processor in relation to the IP switch which is used on the PCD2.M5.

Solution
Unfortunately there is no solution available for this phenomenon.
Please note that the impact of this situation is not serious as all the communication protocols will automatically generate a retry which will be answered correctly. The only "damage" is a red LED and a single delay of the response time in case of a lost telegram.

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

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


Supported hardware
The following hardware systems support the flag extension:

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

Remarks

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

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

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

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

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

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

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

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

In case a PCD2.R6000 (with a hardware version / modification before B1) is plugged on a PCD2.M5 which is extended with a PCD2.C2000 the file system on the SD card is not accessible.

Symptom
The file system of a PCD2.R6000 is not accessible or visible if the R6000 is mounted on a PCD2.M5 which is extended with a PCD2.C2000 extension module. When connecting with an FTP client, the SLxFLASH is not visible at all.

Reason
Due to a hardware restriction of the PCD2.R6000 the module does not initialize correctly if a PCD2.C2000 is plugged.

Solution
This restriction is eliminated with hardware version B and hardware modification 1 (-->"B1"). This version is delivered since week 18 of 2010.
In case you are concerned by this restriction, please send your PCD2.R6000 to the repair service of SBC (with the remark "KR-PC-10-013"). This hardware update will be executed free of charge.

Remark
Please note that the same behaviour (R6000 does not work / is not detected; its LED "Diag" remains red) in case an analogue I/O module is plugged on the slot with I/O address 240. In this case, please remove the analogue I/O module from the slot with base address 240 (on this slot no analogue I/O module can be used as it would interact with the hardware watchdog of the PCD).

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 summer 2010 the PCD3 family (PCD3.M2xxx, PCD3.M3xxx, PCD3.M5xxx and PCD3.M6xxx) do support the "full-duplex mode" and Auto-MDIX on the Ethernet port.

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

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

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

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

Remark

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

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

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

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

Solutions

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

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

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

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

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

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

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

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

Read Flash Status

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

Result

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

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

Status bits

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

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

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

Solution
The firmware 1.10.51 or higher corrects this problem.

Yes, Modbus is supported by the firmware of recent Saia PCD® systems (on all ports, including the ones on F2xx modules since beginning of 2011) or by a dedicated FBox driver.

General
There are two possibilities to use Modbus on SBC CPUs (Classic versions).

• The new FBox library for Modbus "Modbus SBC Version" which takes advantage of the Modbus implementation directly in the Saia PCD® COSinus firmware.
  Available for PCD1.M2, PCD3 and PCD2.M5 with firmware version 1.10.16 or more recent (for using on F2xx modules, in minimum FW 1.14.23 is required).
• The Modbus FBox Library from our partner ENGIBY which is available since several years (www.engiby.ch) and supported also by PCD systems previous to the PCD3, PCD2.M5xxx and PCD1.M2xxx families (e.g. PCD2.M1x0, PCD2.M480 or PCD1.M1xx).

Remarks

• In order to use the firmware implementation of Modbus on PCD2.F2xxx or PCD3.F2xx modules, the following prerequisites need to be fullfilled:
  - minimal PCD firmware: 1.14.25 (1.14.23 does support the F2xx modules, but
    communication errors can occur)
  - minimal hardware version of the F2xx(x) module: version D (delivered since beginning 2011) 
• The FBoxes for "Modbus SBC Version" are available for download from the support site since July 2009.
  In PG5 2.0.110 and later the "Modbus SBC Version" is installed by default. Please note that a licence is required for this library.
  

A hardware conflict on a PCD2.M5xxx between a PCD2.W3x0 plugged to I/O slot 3 and the modules PCD2.F2xx0 and PCD2.R6000 leads to the fact that the communication- and memory modules do not work in this constellation. If the PCD2.W3x0 is removed from the I/O slot 3 the installation is working correctly.

Symptom
In case a PCD2.W3x0 analogue input module is plugged in the I/O slot 3 (base address 48) the communication modules PCD2.F2xx0 and the memory modules PCD2.R6000 do not work.
The LEDs on a communication module PCD2.F2100, a PCD2.F2210 or a PCD2.F2810 are lit 50% red and 50% green (blinking). The file system of the PCD2.R6000 (SLxFLASH:/) are not visible over e.g. FTP. Only PCD2.M5xxx with hardware version older than C345 are concerned.

Reason
The reason for this behavior is a conflict between the PCD2.W3x0 (PCD2.W300, PCD2.W310, PCD2.W340, PCD2.W350, PCD2.W360) and the PCD2.F2xx0 or R6000. This conflict exists only if the PCD2.W3x0 is plugged on the I/O slot 3 (base address 48).

Solution

• This conflict is no longer present with hardware version C345 of the PCD2.M5xxx (the according filter of the I/O bus has been adapted in order not to lead to this conflict).  
• In case it is not possible to replace the system immediately (or send it to the repair service for having this modification done), the problem can be solved by not using a PCD2.W30x in the I/O slot 3. If the communication module or the memory module is plugged into I/O slot 3 the installation will work correctly.

The new TCP/IP settings are valid and activated as soon as the changing of the number is finished by pressing in the center of the joystick of the eDisplay.

A restart or a power off/on of the PCD is not required to activate the new TCP/IP settings.

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

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

No, the PCD2.M5 CPU supports only one TCP/IP address. The two Ethernet connectors ETH1 and ETH2 do act as a switch.

If you need to have two different TCP/IP addresses then you have to use a PCD2.M480 with two PCD7.F655 modules.

For more information please refer to the FAQ 100785

The onboard outputs "Out0" and "Out1" of the PCD2.M5xxx are not working on hardware version "B" and "C".

Symptom
The onboard outputs "Out0" and "Out1" do not work on a PCD2.M5xxx with hardware version "B" or "C".

Reason
The reason for this malfunction is that the functionality is not supported by the version of the CPLD (Complex Programmable Logic Device) programmed on hardware version "B" and "C".

Solution
The functionality is given from hardware version "C 1". This update can only be done from Saia-Burgess Controls AG, so the PCD is to be sent to the repair service for the update.

Remark
In week 21 of 2008 the version "C 1" has been introduced into production.

After a succesful download the PCD3 or the PCD2.M5xx0 doesn't go in run. It stays in HALT in XOB 16.

Symptom
The download option "RUN Program after succesful download" is activated. With a specific project, the CPU doesn't go in RUN. It can be started manually without problems. The installed PCD3 firmware is 1.08.23 (1.08.19 for PCD2.M5xx0 or 1.08.21 for PCD2.M480).

Reason
Due to a firmware problem, the CPU goes not in RUN if the project has a specific (big) size. The PCD3 and PCD2.M5xxx and PCD2.M480 CPU's with firmware version <=1.08.23 are concerned.

Solution
Please update the firmware of your

• PCD2.M480 to 1.08.53 or later
• PCD2.M5xx0 to 1.10.16 or later
• PCD3.Mxxx0 to 1.10.16 or later

The firmeware can be downloaded from the support site (the first firmware with the correction is 1.08.31).

On the master PCD the I/O mapping to Register 4096 until Register 16'383 for RIO-networks (Profibus DP or Profi-S-I/O) doesen't work on PCD3 and PCD2.M480 and PCD2.M5xx0 systems with firmware version 1.08.23.

Symptom
When using addresses between 4096 to 16383 on the maser PCD for reading/writing medias of Profibus-DP / Profi-S-I/O slaves, no values can be read from these slaves. The relevant registers are not updated by the Profibus or S-I/O task in this case.
This problem does only occur with firmware versions 1.08.xx until version 1.08.31; it is therefore even possible that a project correctly runs until the firmware of the Profi-S-I/O or Profibus DP master PCD has been updated. 

Reason
The reason for this behavior is an incorrect mapping on the Profibus-DP / Profi-S-I/O master done by the firmware of the CPU. This behaviour has been introduced in version 1.08.xx (pilot versions already in 1.07.xx) and is solved in version 1.08.34 and later.

Solution
Please update the firmware of your

• PCD3 to 1.10.16 or later
• PCD2.M5 to 1.10.16 or later
• PCD2.M480 to 1.08.53 or later

If this is not possible for some reason, only use adresses R 0 - R 4095 to map the modules. 

Due of the housing of the connector of the PCD2.K1.. extension cable a minimum distance of 6 cm is required between the PCD2.M… CPUs and PCD2.C1.. extension rack, if the extension rack PCD2.C1.. is placed on the right side of the PCD2.M… CPU.

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

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

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

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

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

Software installation of SaiaDump.exe tool

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

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

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

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

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

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

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

FAQ updates

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

Due to a hardware problem on the first pilot versions of the PCD2.M5540 the RTS and CTS are crossed.

Problem
The pilot versions and hardware version A of the PCD2.M5540 has the RTS and CTS sign crossed on terminal X3 and X4.

Reason
This happend due to a layout failure on the board on the PCD2.M5540 (Hardwareversion A and older)

Solution
Connect the RTS and CTS invers to the documentation if you have a concerned hardware.

Depending of the PCD type and the used port it's possible to use the XON/XOFF protocol.

Symptom
A SASI (Assign Serial Interface) in mode MC2 (Character mode with Xon/Xoff protocol) fails. The error flag is set after the SASI instruction.

Reason
The XON/XOFF protocol is not supported on this PCD or port.

List of supported ports
PCD3.M5xxx: the mode MC2 is supported on port 0 (Com/PGU) and also on the PCD3M5340 in RS422 on port 3 (S-Net/MPI).
PCD2.M5xxx: the mode MC2 is supported on port 2.
PCD1.M2xxx: the mode MC2 is not supported.


Remark
Please note that on the PCD2/3.F2xx modules, the XON/XOFF mode is not yet supported (which is not correctly documented in the manual 26/789).

When mounting a PCD7.F120 into a PCD3.F121 / PCD3.F2xx or when using a PCD7.F120 on a PCD2.M5, the communication doesn't work. The reason therefore is an incompatibility between the PCD7.F120 and PCD3.Fxxx (or PCD2.M5) modules and the old .

Symptom
After having mounted a PCD7.F120 into a PCD3.Fxxx or on a PCD2.M5, the communication doesn't work. No communication is possible using the relevant port.

Reason
The PCD7.F120 does require a power supply which is not present on the PCD3.Fxxx modules or on the sockets from PCD2.M5xxx / PCD2.M48x CPUs. This power supply is not present because the new communication module PCD7.F121 (which supports baud rates up to 115 kBit/s) doesn't require a power supply any more.

Solution
In case you are concerned by this problem just replace the PCD7.F120 by a PCD7.F121.

Remark
All modules PCD3.Fxxx ordered as RS232 module are delivered together with a PCD7.F121 (In fact, the PCD7.F120 has been replaced by the PCD7.F121). The only situation where a problem can occur is in case an (old) PCD7.F120 from an existing PCD system is mounted into a PCD3 or a PCD2.M5 / PCD2.M480.

In some cases it is the same hardware, but due to the fact that the system contains a system ID written in EEPROM we can not guarantee that a xx7 PCD works properly with Classic firmware and invers.

Therefore it is not possible to download a Classic firmware to Classic PCDs and xx7 Firmware to xx7 PCDs.

General
A PCD CPU is bought as xx7 system or as Classic system. As described above, the possibility of a conversion is not guaranteed or offered by Saia-Burgess Controls AG.
There is no service "Convert from xx7 to Classic" or similar available at the repair service.

Additional details

• PCD2.M1xx, PCD1.M1xx
  The xx7 hardware is not identical to the classic PCD hardware, as result it can not be converted by a firmware change.
• PCD2.M5, PCD2.M480 and PCD3
  While it could be possible to run a Classic PCD as xx7 PCD (depending on the hardware type etc.), it is e.g. not possible to load a Classic PCD if it was bought as xx7 system (because in this case PG5 will not accept downloading the hardware configuration as the system ID is not correct).

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

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

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

Solution

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

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

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

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

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

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

  - SFC 67 X_Get

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

*) see remarks below:

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

The "PCD driver" of the PCD7.D7xx terminals is not supported by all PCD systems.

Symptom
When the communication driver "PCD driver" is used in a PCD8.D81w project, the communication works on the PGU Port (port 0) of a PCD2.M110 (or a PCD2.M120) but not on the following systems: PCS1, PCD2.M150/M170/M480/M5xx0 or on a PCD3.

Reason
The PGU mode of recent PCD systems is no longer based on the P800 communication protocol (which uses the obsolete communication protocol "Mode D"). The recent PCD2 and the PCD3 use S-Bus on Port 0, and the PCD driver on the terminal uses P800 protocol. Because the PCD7.D7xx terminals use the P800 protocol if the "PCD driver" is selected, the communication does not work on systems developed after the PCD2.M110/M120.

Solution
So there are 2 solutions possible:

• Use the S-Bus driver on the terminal (recommended): In this case the project has to be adapted accordingly and an S-Bus connection cable is to be used (according to our Workshop Documents).
• Only for PCD2.M150 and PCD2.M170: Modify your communication cable (Pin 6 should not be used, Pin 6 of PGU port =0). In the PCD program you need to add a "SASI Slave Mode D" with the parameters: RS 232, 9600, Parity, 7-E-1.
  This solution can only be applied on PCD2.M150 and M170 systems, but not on other systems (because the Mode D is no longer supported).
  See attached document for wiring information in this case.

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.

The PCD8.K120 Profi-S-Link adapter needs to be powered with 24VDC.
The 24VDC for the PCD8.K120 is available on the PIN # 7 of the 9-pol D-Sub connector of the PCD2.M480 /PCD3.M where you connect the PCD8.K120 adapter.
To switch on the 24VDC on the Pin # 7 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 download the Hardware settings to the PCD.

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

‘Power PCD’s’ are:

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

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

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

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

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

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

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

Depending of the hardware version of the W6x5 module and the I/O slot where the W6x5 module is plugged in, it’s possible that the analog output signal supplied from the W6x5 is not stable and is oscillating.

Symptom
The outputs of the PCD2/3.W6x5 do not deliver stable signals when placed on I/O slot 15 if hardware version B of the W6x5 is used.
If FBoxes are used for writing to the outputs, the FBox indicates temporarily an error.

Reason
The W6x5 modules with hardware version B are not correctly handling the Watchdog output (O 255).
Note that this is only the case if the module is placed on I/O slot 15 (base address 240). On all other slots the modules work correctly.

Solution
This problem is solved with hardware version A or C and newer of the PCD2.W6x5 or PCD3.W6x5 respectively.

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

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

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

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

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

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

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

The production of PCD2.M120 systems has been discontinued by the end of 2009. As possible replacement a PCD2.M150 or a PCD2.M5xx0 can be used.

The PCD2.M120 can be repaired until the end of 2014 (five years after the phase-out).

Communication on port 3 (PCD2.F520) during startup can lead to a DUART HW ERROR on the PCD2.M150

Problem
If there is a communicatin running on port 3 during startup (e.g. an OPC server which is polling data from the PCD), it can happen that the PCD goes in HALT with a DUART HW ERROR on startup.

Reason
Due to a firmware problem, the communication on port 3 can cause problems during the startup procedure.

Solution
The problem was corrected in FW 0F1 or later for the PCD2.M150. If you are concerned contact your support for the bugfix firmware. Note that the problem only occurs on startup.

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.

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

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

Read Flash Status

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

Result

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

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

Status bits

Yes, Modbus is supported by the firmware of recent Saia PCD® systems (on all ports, including the ones on F2xx modules since beginning of 2011) or by a dedicated FBox driver.

General
There are two possibilities to use Modbus on SBC CPUs (Classic versions).

• The new FBox library for Modbus "Modbus SBC Version" which takes advantage of the Modbus implementation directly in the Saia PCD® COSinus firmware.
  Available for PCD1.M2, PCD3 and PCD2.M5 with firmware version 1.10.16 or more recent (for using on F2xx modules, in minimum FW 1.14.23 is required).
• The Modbus FBox Library from our partner ENGIBY which is available since several years (www.engiby.ch) and supported also by PCD systems previous to the PCD3, PCD2.M5xxx and PCD1.M2xxx families (e.g. PCD2.M1x0, PCD2.M480 or PCD1.M1xx).

Remarks

• In order to use the firmware implementation of Modbus on PCD2.F2xxx or PCD3.F2xx modules, the following prerequisites need to be fullfilled:
  - minimal PCD firmware: 1.14.25 (1.14.23 does support the F2xx modules, but
    communication errors can occur)
  - minimal hardware version of the F2xx(x) module: version D (delivered since beginning 2011) 
• The FBoxes for "Modbus SBC Version" are available for download from the support site since July 2009.
  In PG5 2.0.110 and later the "Modbus SBC Version" is installed by default. Please note that a licence is required for this library.
  

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

Due of the housing of the connector of the PCD2.K1.. extension cable a minimum distance of 6 cm is required between the PCD2.M… CPUs and PCD2.C1.. extension rack, if the extension rack PCD2.C1.. is placed on the right side of the PCD2.M… CPU.

Yes, the PCD2.M480 is able to handle two TCP/IP (PCD7.F655) modules.

If there is the need to have two independent TCP/IP modules on one PCD, then you have to use the PCD2.M480 CPU. On the PCD2.M480 it is possible to install two PCD7.F655, one on the emplacement B1 and one on the emplacement B2.

The PCD2.M480 does support the routing mechanism of TCP/IP request between the two cards only for the direction:
TCP/IP card on emplacement B1 to TCP/IP card on emplacement B2.

From firmware version 0D0 it is possible to download the firmware to the PCD2.M150. It is not any more necessary to write the firmware chips (Flash) on an EPROM burner.

Introduction
For an easyer firmware upgrade procedure the booter and firmware of the PCD2.M150 has been improved in a way that it is possible to download the firmware directyl with the PG5 firmware downloader. The minimal firmware version for enabling this firmware download is 0D0 (the accoring *.hex files do contain the appropriate booter version 010 or higher).

Of course it is still possible to write the firmware flash on a EPROM burner as it is to be done for older versions.
In case your PCD is equipped with a firmware older than 0D0 (e.g. 0C4) you have to burn a new firmware chip (manufacturer either AMIC or SST) with a firmware 0D0 or newer. You can find these files as usual on the support site in the product folder of the PCD2.M150.

Official introduction in production
The first official firmware supporting the download of a new firmware is 0D3. This firmware has been officialized and introduced into production in week 30 of 2006. The booter version installed with this firmware is 012.

Firmware download procedure
As soon as you have installed the firmware 0D0 or higher, you can simply downlod a new firmware with the following procedure (given the installed chip supports the download of the firmware, see FAQ 100606).

• Open PG5
• From the menu "Tools" select the "Online Configurator"
• In the Online Configurator click the button "Go offline" (for downloading the firmware PG5 must be offline)
• From the Online Configurator menu "Tools" select "Download Firmware"
• In the Firmware Download Utility click the button "Add" and browse to the new firmware for the PCD2.M150 (the file must have the extension *.blk). Make sure only this file is visible in the window. If there are other files, remove them with the button "Del".
  
• Click "Start" for starting the download

The file to be downloaded is a *.blk file which can be downloaded from the support site as well.

Flash chips supporting the download of the firmware
There are several flash chips holding the frimware on the PCD2.M150. Unfortunately the first introduced chip does not support the download of the firmware. Below a list of the used flash chips:

• AMIC A29040 (A29040B-70F)
  This chip supports the download of the firmware. The download of the booter is supported from booter version 013 (to be installed together with firmware 0E3 hex files). 
• SST 39SF040
  This chip supports the download of the firmware as well as the download of the booter^*).
• ATMEL AT49F040
  This chip doesn't support the download of the firmware. For updating the firmware, the new firmware version has to be burned to the chip using an EPROM burner.

^*) For updating the booter out of booter version 010, 011 and 012 the PCD must be set in the bootloader mode first.

In some cases it is the same hardware, but due to the fact that the system contains a system ID written in EEPROM we can not guarantee that a xx7 PCD works properly with Classic firmware and invers.

Therefore it is not possible to download a Classic firmware to Classic PCDs and xx7 Firmware to xx7 PCDs.

General
A PCD CPU is bought as xx7 system or as Classic system. As described above, the possibility of a conversion is not guaranteed or offered by Saia-Burgess Controls AG.
There is no service "Convert from xx7 to Classic" or similar available at the repair service.

Additional details

• PCD2.M1xx, PCD1.M1xx
  The xx7 hardware is not identical to the classic PCD hardware, as result it can not be converted by a firmware change.
• PCD2.M5, PCD2.M480 and PCD3
  While it could be possible to run a Classic PCD as xx7 PCD (depending on the hardware type etc.), it is e.g. not possible to load a Classic PCD if it was bought as xx7 system (because in this case PG5 will not accept downloading the hardware configuration as the system ID is not correct).

No, the GSD-Files are different. They have a different identification. The PCD2.M170 needs the GSD-File PCD2_Slave (SAIAcd20.gsd), otherwise the PCD4.M170 needs the PCD4.M170_Slave (SAIAcd40.gsd)

• 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

If you try to connect to the the WEB Server of a PCD2.M170, PCD2.M150 (pilot FW) or a PCS1 and no WEB Server project has been downloaded, the following error is displayed: "Error 4 -Invalid page indentifier in the PCD answer".

On the "older" system it is necessary to download a Web Server project (even if it is empty) into the PCD in order to be able to access to the default SBC WEB Pages!

On the Saia PCD® COSinus systems (PCD3, PCD2.M5 and PCD2.M480) this problem doesn't occur!

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

Communication via TCP/IP was not possible with F650 FW Version 010 and PCD2.M150 FW Version 0C0.

Solution: FW Version 0C2 or later is necessary for the M150

If once the Software Watchdog is configured on a PCD2.M150, the system can't be started any more until the FW will be changed to either an older version (not recommended) or to the latest version 0E3 (recommended)!

This problem is due to a too long starting sequence of the FW which will cause the Software Watchdog to restart the system right after its initial start. This causes the PCD not booting up at all any more.
In the concerned state, all LEDs (RUN, HALT and ERROR) are lit; the restart will be proceeded before the actual boot sequence indicated by the running LED's of the PCD starts.

To solve this problem the FW chips have to be replaced. These chips either can be ordered at your SBC representative or the actually used chips can be rewritten using a EPROM burner such as GALEP IV.
Since the FW of a PCD2.M150 is written in Flash EPROMs, it can be ereased and reloaded with the hex files of the FW version 0E3 available on the Support Site www.sbc-support.ch or at your SBC representative.

it's very important to use the firmware $0H or higher on the PCD7.F650 in combination with a PCD2.M480.

The "PCD driver" of the PCD7.D7xx terminals is not supported by all PCD systems.

Symptom
When the communication driver "PCD driver" is used in a PCD8.D81w project, the communication works on the PGU Port (port 0) of a PCD2.M110 (or a PCD2.M120) but not on the following systems: PCS1, PCD2.M150/M170/M480/M5xx0 or on a PCD3.

Reason
The PGU mode of recent PCD systems is no longer based on the P800 communication protocol (which uses the obsolete communication protocol "Mode D"). The recent PCD2 and the PCD3 use S-Bus on Port 0, and the PCD driver on the terminal uses P800 protocol. Because the PCD7.D7xx terminals use the P800 protocol if the "PCD driver" is selected, the communication does not work on systems developed after the PCD2.M110/M120.

Solution
So there are 2 solutions possible:

• Use the S-Bus driver on the terminal (recommended): In this case the project has to be adapted accordingly and an S-Bus connection cable is to be used (according to our Workshop Documents).
• Only for PCD2.M150 and PCD2.M170: Modify your communication cable (Pin 6 should not be used, Pin 6 of PGU port =0). In the PCD program you need to add a "SASI Slave Mode D" with the parameters: RS 232, 9600, Parity, 7-E-1.
  This solution can only be applied on PCD2.M150 and M170 systems, but not on other systems (because the Mode D is no longer supported).
  See attached document for wiring information in this case.

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

In case there is a PCD3.Cxxx that contains the slot having the base address 240, the watchdog programmed by using the IL instruction "COM" won't work properly.

This is because the PCD3.Cxxx with base adress 192 does buffer the state of the output 255 (also if there is no real I/O) and the PCD's CPU is reading this buffered state instead of the state of the Watchdog.
Therefore the "COM" instruction (that sets the output acording to its state) always will set the output to the same state. The result of the watchdog not beeing toggled is that the watchdog relais is falling off.

One of the following solutions could be used as workaround for PCD2.M1x0:

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

‘Power PCD’s’ are:

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

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

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

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

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

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

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

Depending of the hardware version of the W6x5 module and the I/O slot where the W6x5 module is plugged in, it’s possible that the analog output signal supplied from the W6x5 is not stable and is oscillating.

Symptom
The outputs of the PCD2/3.W6x5 do not deliver stable signals when placed on I/O slot 15 if hardware version B of the W6x5 is used.
If FBoxes are used for writing to the outputs, the FBox indicates temporarily an error.

Reason
The W6x5 modules with hardware version B are not correctly handling the Watchdog output (O 255).
Note that this is only the case if the module is placed on I/O slot 15 (base address 240). On all other slots the modules work correctly.

Solution
This problem is solved with hardware version A or C and newer of the PCD2.W6x5 or PCD3.W6x5 respectively.

On the CPU PCD2.M480 can be plugged two PCD7.F655 Ethernet cards. This feature allows you to program either Ethernet redundancy by creating an reduced "IP Firewall" or to realise an Ether-S-Bus to Ether-S-Bus gateway.

If you configure your two PCD7.F655 cards with two different IP addresses on two different IP networks, you can create IP redundancy and act as an IP Firewall and block therefore all the IP traffic between the two specific IP networks.

If you configure your two PCD7.F655 cards with two different IP addresses on two different IP networks, you can also create an "Ether-S-Bus Router" with forwarding Ether-S-Bus telegrams from one IP network to the other one.
The only thing you have to bother is, that it's only possible to create an "Ether-S-Bus to Ether-S-Bus gateway" from "Channel 9" towards "Channel 8". The opposite direction doesn't work. This feature works well for Ether-S-Bus communication and is limited to communicate with PCD stations situated on the same IP Subnet as the IP Gateway is programmed.

With firmware 1.08.21 of the PCD2.M480 the gateway could get blocked in some specific cases.

Symptom
The S-Bus gateway of a PCD2.M480 blocks after several hours to even months of correct functionality.

Reason
In case the timeout which is configured on the S-Bus master which accesses the slave port of the PCD2.M480 (e.g. the PC running PG5) is configured to a time which is very near of the timeout which is configured on the master gateway port on the PCD, it was possible with the firmware 1.08.21 that the gateway buffers could get blocked. This could lead to the situation that the gateway functionality got blocked.
In case the timeouts are correctly configured (which means that the timeout on the PC is several times higher than the one configured on the gateway master port) this problem could not be observed.

Solution
In order to avoid a blocked gateway port, please update the firmware to version 1.08.53 or later.
Additionally it is strongly recommended to correctly configure the timeouts (on the gateway master port and of course also on the master accessing the gateway slave port(s)).

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.

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

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

Read Flash Status

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

Result

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

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

Status bits

Yes, Modbus is supported by the firmware of recent Saia PCD® systems (on all ports, including the ones on F2xx modules since beginning of 2011) or by a dedicated FBox driver.

General
There are two possibilities to use Modbus on SBC CPUs (Classic versions).

• The new FBox library for Modbus "Modbus SBC Version" which takes advantage of the Modbus implementation directly in the Saia PCD® COSinus firmware.
  Available for PCD1.M2, PCD3 and PCD2.M5 with firmware version 1.10.16 or more recent (for using on F2xx modules, in minimum FW 1.14.23 is required).
• The Modbus FBox Library from our partner ENGIBY which is available since several years (www.engiby.ch) and supported also by PCD systems previous to the PCD3, PCD2.M5xxx and PCD1.M2xxx families (e.g. PCD2.M1x0, PCD2.M480 or PCD1.M1xx).

Remarks

• In order to use the firmware implementation of Modbus on PCD2.F2xxx or PCD3.F2xx modules, the following prerequisites need to be fullfilled:
  - minimal PCD firmware: 1.14.25 (1.14.23 does support the F2xx modules, but
    communication errors can occur)
  - minimal hardware version of the F2xx(x) module: version D (delivered since beginning 2011) 
• The FBoxes for "Modbus SBC Version" are available for download from the support site since July 2009.
  In PG5 2.0.110 and later the "Modbus SBC Version" is installed by default. Please note that a licence is required for this library.
  

After a succesful download the PCD3 or the PCD2.M5xx0 doesn't go in run. It stays in HALT in XOB 16.

Symptom
The download option "RUN Program after succesful download" is activated. With a specific project, the CPU doesn't go in RUN. It can be started manually without problems. The installed PCD3 firmware is 1.08.23 (1.08.19 for PCD2.M5xx0 or 1.08.21 for PCD2.M480).

Reason
Due to a firmware problem, the CPU goes not in RUN if the project has a specific (big) size. The PCD3 and PCD2.M5xxx and PCD2.M480 CPU's with firmware version <=1.08.23 are concerned.

Solution
Please update the firmware of your

• PCD2.M480 to 1.08.53 or later
• PCD2.M5xx0 to 1.10.16 or later
• PCD3.Mxxx0 to 1.10.16 or later

The firmeware can be downloaded from the support site (the first firmware with the correction is 1.08.31).

On the master PCD the I/O mapping to Register 4096 until Register 16'383 for RIO-networks (Profibus DP or Profi-S-I/O) doesen't work on PCD3 and PCD2.M480 and PCD2.M5xx0 systems with firmware version 1.08.23.

Symptom
When using addresses between 4096 to 16383 on the maser PCD for reading/writing medias of Profibus-DP / Profi-S-I/O slaves, no values can be read from these slaves. The relevant registers are not updated by the Profibus or S-I/O task in this case.
This problem does only occur with firmware versions 1.08.xx until version 1.08.31; it is therefore even possible that a project correctly runs until the firmware of the Profi-S-I/O or Profibus DP master PCD has been updated. 

Reason
The reason for this behavior is an incorrect mapping on the Profibus-DP / Profi-S-I/O master done by the firmware of the CPU. This behaviour has been introduced in version 1.08.xx (pilot versions already in 1.07.xx) and is solved in version 1.08.34 and later.

Solution
Please update the firmware of your

• PCD3 to 1.10.16 or later
• PCD2.M5 to 1.10.16 or later
• PCD2.M480 to 1.08.53 or later

If this is not possible for some reason, only use adresses R 0 - R 4095 to map the modules. 

Due of the housing of the connector of the PCD2.K1.. extension cable a minimum distance of 6 cm is required between the PCD2.M… CPUs and PCD2.C1.. extension rack, if the extension rack PCD2.C1.. is placed on the right side of the PCD2.M… CPU.

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

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

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

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

Yes, the PCD2.M480 is able to handle two TCP/IP (PCD7.F655) modules.

If there is the need to have two independent TCP/IP modules on one PCD, then you have to use the PCD2.M480 CPU. On the PCD2.M480 it is possible to install two PCD7.F655, one on the emplacement B1 and one on the emplacement B2.

The PCD2.M480 does support the routing mechanism of TCP/IP request between the two cards only for the direction:
TCP/IP card on emplacement B1 to TCP/IP card on emplacement B2.

On PCD2.M480 it might happen that when a Online connection went offline and OnLine again that it doesn't work again: a message "No response" appears! In order to be able to connect again, it is necessary to plugg out and in again the programming cable PCD8.K111.

This phenomenon is related to the way the DSR signal is managed on the serial port of your PC/Laptop! We have noticed this problem on some Dell Desktops.

Solution
Please use PG5 1.4.300 in order to avoid this problem (at least version 1.4.200.1 is required).

If a project Web Editor contains trends or alarms, it might not be possible to visualised the Web page and be online with PG5 simultaneously. In order to go online with the PCD a powerup is necessary!

The advanced functions aren't supported by this firmware version, this causes the disfunctionning!

Update the PCD with a nwer FW version at least B2B.  You can get the last firmware version from the support site.

When mounting a PCD7.F120 into a PCD3.F121 / PCD3.F2xx or when using a PCD7.F120 on a PCD2.M5, the communication doesn't work. The reason therefore is an incompatibility between the PCD7.F120 and PCD3.Fxxx (or PCD2.M5) modules and the old .

Symptom
After having mounted a PCD7.F120 into a PCD3.Fxxx or on a PCD2.M5, the communication doesn't work. No communication is possible using the relevant port.

Reason
The PCD7.F120 does require a power supply which is not present on the PCD3.Fxxx modules or on the sockets from PCD2.M5xxx / PCD2.M48x CPUs. This power supply is not present because the new communication module PCD7.F121 (which supports baud rates up to 115 kBit/s) doesn't require a power supply any more.

Solution
In case you are concerned by this problem just replace the PCD7.F120 by a PCD7.F121.

Remark
All modules PCD3.Fxxx ordered as RS232 module are delivered together with a PCD7.F121 (In fact, the PCD7.F120 has been replaced by the PCD7.F121). The only situation where a problem can occur is in case an (old) PCD7.F120 from an existing PCD system is mounted into a PCD3 or a PCD2.M5 / PCD2.M480.

In some cases it is the same hardware, but due to the fact that the system contains a system ID written in EEPROM we can not guarantee that a xx7 PCD works properly with Classic firmware and invers.

Therefore it is not possible to download a Classic firmware to Classic PCDs and xx7 Firmware to xx7 PCDs.

General
A PCD CPU is bought as xx7 system or as Classic system. As described above, the possibility of a conversion is not guaranteed or offered by Saia-Burgess Controls AG.
There is no service "Convert from xx7 to Classic" or similar available at the repair service.

Additional details

• PCD2.M1xx, PCD1.M1xx
  The xx7 hardware is not identical to the classic PCD hardware, as result it can not be converted by a firmware change.
• PCD2.M5, PCD2.M480 and PCD3
  While it could be possible to run a Classic PCD as xx7 PCD (depending on the hardware type etc.), it is e.g. not possible to load a Classic PCD if it was bought as xx7 system (because in this case PG5 will not accept downloading the hardware configuration as the system ID is not correct).

No, this function is only available on the PCD3.M5xxx.

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

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

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

Solution

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

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

If the Port 3 is initialized in mode S-Bus slave it won't work anymore with FW 020. The bug is corrected in FW Versions > 020 (#21) and did not appear in versions < 020.

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

This problem occurs with all FW version up to:

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

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

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

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

The serial ports of the PCD2.M480 does allow to communicate up to 115 kB/s.

The PCD2.M480 does support the following baudrates:

• For the ports 2,3  and 4,5 following combination of baud rates are not allowed on the same  PCD2.F5xx:
  19,2 kBaud and 38,4 kBaud
• On the port 1 it’s not possible to use the S-Bus party Master mode.
• Mode D is not supported.

The minimum firmware version for these features is 020. If you have been using $-versions as a pilot customer, please update to version 020 or later.

If a firmware version older or equal 018 is used, the MPI shell starts even if no configuration is made. With all newer firmwares the MPI communication only starts if a configuration is made.

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

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

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

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

  - SFC 67 X_Get

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

*) see remarks below:

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

Communication via TCP/IP was not possible with F650 FW Version 010 and PCD2.M150 FW Version 0C0.

Solution: FW Version 0C2 or later is necessary for the M150

For exemple if the port 6 is GMP, the Gateway function is working but the communication doesn't work on that port. It means that the send and received Fbox are red!

For gateway funktionality minimum M480 FW $1D is nessesary.

In the FW Version $1C the modem funktiuonality is not given. This is correctet in $1D to.

it's very important to use the firmware $0H or higher on the PCD7.F650 in combination with a PCD2.M480.

The "PCD driver" of the PCD7.D7xx terminals is not supported by all PCD systems.

Symptom
When the communication driver "PCD driver" is used in a PCD8.D81w project, the communication works on the PGU Port (port 0) of a PCD2.M110 (or a PCD2.M120) but not on the following systems: PCS1, PCD2.M150/M170/M480/M5xx0 or on a PCD3.

Reason
The PGU mode of recent PCD systems is no longer based on the P800 communication protocol (which uses the obsolete communication protocol "Mode D"). The recent PCD2 and the PCD3 use S-Bus on Port 0, and the PCD driver on the terminal uses P800 protocol. Because the PCD7.D7xx terminals use the P800 protocol if the "PCD driver" is selected, the communication does not work on systems developed after the PCD2.M110/M120.

Solution
So there are 2 solutions possible:

• Use the S-Bus driver on the terminal (recommended): In this case the project has to be adapted accordingly and an S-Bus connection cable is to be used (according to our Workshop Documents).
• Only for PCD2.M150 and PCD2.M170: Modify your communication cable (Pin 6 should not be used, Pin 6 of PGU port =0). In the PCD program you need to add a "SASI Slave Mode D" with the parameters: RS 232, 9600, Parity, 7-E-1.
  This solution can only be applied on PCD2.M150 and M170 systems, but not on other systems (because the Mode D is no longer supported).
  See attached document for wiring information in this case.

There are some restriction on the PCD2.M480, the port 1 as Master Port doesn't support parity mode.

Note: The "Break mode" is not supported on the PCD2.M480!

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.

The PCD8.K120 Profi-S-Link adapter needs to be powered with 24VDC.
The 24VDC for the PCD8.K120 is available on the PIN # 7 of the 9-pol D-Sub connector of the PCD2.M480 /PCD3.M where you connect the PCD8.K120 adapter.
To switch on the 24VDC on the Pin # 7 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 download the Hardware settings to the PCD.

In case there is a PCD3.Cxxx that contains the slot having the base address 240, the watchdog programmed by using the IL instruction "COM" won't work properly.

This is because the PCD3.Cxxx with base adress 192 does buffer the state of the output 255 (also if there is no real I/O) and the PCD's CPU is reading this buffered state instead of the state of the Watchdog.
Therefore the "COM" instruction (that sets the output acording to its state) always will set the output to the same state. The result of the watchdog not beeing toggled is that the watchdog relais is falling off.

One of the following solutions could be used as workaround for PCD2.M1x0: