The requested software / document is no longer marketed by Saia-Burgess Controls AG and without technical support. It is an older software version which can be operated only on certain now no longer commercially available products.
-
PCD4
-
Series (obsolete)
Documentation
Good to know
The PCD4 family has been discontinued and is no longer available. Please refer to FAQ 101098 for more information until when PCD4 modules are repaired.
PCD4.M240 (obsolete): Both CPUs have got the same firmware as a PCD4.M1x0, the latest version 005 can be found on the PCD4.M1x0 pages.
PCD4.M340 (obsolete): CPU0 has got the same firmware as a PCD4.M1x0, the latest version 005 can be found on the PCD4.M1x0 pages. CPU1 with LAN2 has the same firmware as a PCD6.T1xx, last version 005, only available on request.

PCD4 / _Firmware
-
Why do I sporadically get communication errors when connecting a PCD/PCS in "Secure S-Bus Data Mode"? (FAQ #101180)
In case a "non Saia PCD® COSinus" PCD or PCS1 system is connected with "Secure S-Bus Data mode" (e.g. over a serial cable or over modem) from time to time a telegram is not answered correctly.
Symptom
A PCD or a PCS connected with another system (e.g. PC or another PCD system) using the "Secure S-Bus Data mode" does not answer a telegram from time to time. This can e.g. be seen by a red LED on transmit or receive FBoxes (or in case a PC is used, by interpreting the tracewin files).
This phenomenon can be observed on PCD1.M1x5, PCD2.M150, PCD2/4.M170 and PCS1 systems (with firmware which are supporting the "Secure S-Bus Data mode"). Saia PCD® COSinus based systems (PCD2.M480, PCD2.M5xx0 and PCD3) are not concerned.
Reason
The reason for this behavior is that the PCD/PCS does not correcly answer telegrams where the sequence number in the secure S-Bus Data Mode header is 0xC5h. This is the case in every 255th telegram.
(The character "C5" should be replaced by "C5 01" but this is not done).
Solution
Please refer to the table below for firmware version which do correctly handle the "C5" and therefore the symptom described above is avoided.System Firmware PCD1.M1x5 0F0PCD2.M150 0F0PCD2.M170 0F0PCS1 0F0 -
Why do I get a "68k add Error" when writing a text on the S-Web Server? (FAQ #101049)
When trying to write a text (with address higher than 4000) using the S-Web Server, the PCD system stopps working and in the PCD history a "68k add Error" is indicated.
Symptom
When trying to write a text (with address higher than 4000) using the S-Web Server, the PCD system stopps working and in the PCD history a "68k add Error" is indicated.
The following PCD systems are concerned:- PCD1.M1x5 with firmware version higher than 0B0
- PCD2.M150 with firmware version higher than 0E0
- PCD2/4.M170 with firmware version higher than 030
- PCS1.Cxx0 with firmware version higher than 0C0
Reason
This behaviour is not intended. Due to a problem in the firmware the write access fails.
Solution
This problem is solved in firmware version 0E6 (the version indication 0E6 is the same for all systems) which can be downloaded from the support site (www.sbc-support.ch). -
Why is the message: "Failed to get data on alarm.exe" displayed on the alarming page? (FAQ #100963)
This error message appears if the used firmware on the CPU does not support the "active and non ACK" filter for the S-Web alarming functionality (e.g. a PCD2.M150 with firmware 0D3).
Symptom
Instead of the alarm list of the S-Web alarming macro, the message "Failed to get data on alarm.exe" is displayed on the alarming page.
Reason
The reason is that the macro tries receiving the alarms filtered by the "active and not acknowledged" state of the alarms. This does only work if this feature is implemented in the according firmware.
Solution
Please update the firmware (FW) of your PCD system to the firmware supporting the according feature (see table below).System minimal FW PCS1.Cxxx 0E3PCD1.M1x5 0E3PCD2.M150 0E3PCD2/4.M170 0E3PCD2.M480 1.08.21*)PCD2.M5xx0 1.08.19PCD3.Mxxx0 1.08.23*)
*) On PCD3 and PCD2.M480 systems the "active and not acknowledged" filter has already been implemented in previous versions, but has been improved this indicated version. -
Error LED of PCD is lit! How to find the problem? (FAQ #100269)
There is an Error Led on nearly every PCD system that can indicate a problem on the system. Read this FAQ to learn more about the different reasons for a lit Error LED and how to find the problem causing the lit error LED.
What causes the Error LED to get lit?
There are different reasons for a lit error LED. The most common reasons are listed below:- A problem while assigning a communication port (e.g. missing communication module or wrong parameters)
- A problem while sending an S-Bus telegram (e.g. missing port assignation or invalid data array or media)
- Invalid mathematical operation (e.g. division by zero or value overflow after a multiplication)
- Index register overflow
How to find the problem in the code/configuration?
One fast way to find the problem is reading the history entries of the PCD. This may be done by using either the Online Configurator or the Online Debugger (type "Display History"). In the History some of the problems are listed explicitely (e.g. IPM not present) for further information regarding the History entries, please refer to the PG5 Help. The chapter "Messages" contains "Halt and History messages".
If only an "Error Flag" is mentioned the next task is to find the program part where the Error status-flag is set. This is to be done by using the Online Debugger:- Go online with your Fupla- or IL program.
- Open the Online Debugger and type "Restart Cold All CPUs".
- Still in the Online Debugger, type "Run Until Status-flag Error". As soon the Staus-flag "Error" is set, the PCD will be stopped. Therefore the Fupla Editor will jump to the page which actually is processed (only this page is part of the current Fupla file! If the Error isn't caused by this Fupla file, it will jump to any other page which doesn't cause the problem. Have a look at this page and the FBox with the "stop"-box on it and decide whether the problem could have been caused by this FBox!
If there isn't any FBox that could cause any problems mentioned above, repeat the procedure while beeing online with the next Fupla file of the CPU). - If you can't find the problem directly in a Fupla file, switch to the Online Debugger again. After having stopped, a line similar to the line written below will be shown:
*001234 STH I/O 48 A1 Z0 N0 P1 E1 IX COB2
This first number of this line indicates on which line of the code the problem happened: the last instruction BEFORE the line shown caused the problem (the error LED is lit after the problem). - Type "Display Program <line indicated -10> Count 15". Now you can see the instruction that caused the problem: Refer to the IL instruction Set (Online Help of IL Editor SEDIT) in order to figure out what this instruction exactly does.
If a SASI instruction causes the problem, check out the following possible reasons:
- The port is already assigned (have a look at the HW configuration and search for further SASI instructions by typing "Locate Instruction SASI" in the Online Debugger!).
Hint: Also have an eye on the SASI FBoxes you used as well as on the HMI Settings tab. - The port doesn't exist
- The SASI text isn't valid
- S-Bus support isn't enabled in the Hardware Settings but an S-Bus assignation was executed. This won't work because in this case the PCD doesn't have an S-Bus address (which is required for S-Bus communication).
If it seems as a mathematical operation caused the error, use the online debugger to run shortly before the problem-causing part of the code by typing "Run Until Instruction-Pointer Equals <instruction line shortly before problem-line>" (note that the instruction line must contain an instruction!). Once reached this line, type "sTep". In the Step-mode, you will see the contents of the PCD medias [brackets].
Remark:
The Error LED is lit in case the Status Flag E (Error status flag is set high) and no XOB 13 is programmed. In case the XOB 13 is programmed, the Error Led won't get lit but this XOB is processed immediately. -
What EPROM burner is recommended to create firmware chips for PCD's? (FAQ #100256)
We have made good experiences with the GALEP 4, for PCD1 FW together with the adaptor 210841. The local dealer for Switzerland is www.redacom.ch.
Order numbers for empty firmware chips:
PCD1.M1x0: 1x ASN 4 502 7178 (OTP27C4002), one time programmable
PCD1.M137: 1x ASN 4 502 7178 (OTP27C4002), one time programmable
PCD2.M110/M120: 2x ASN 4 502 7126 0 (27C1001-10, EPROM)
PCD2.M127: can be downloaded, refer to the product page on www.sbc-support.ch
PCD2.M150: 2x ASN 4 502 7341 0 (49F040 ,Flash-EPROM)
PCD2.M157: can be downloaded, refer to the product page on www.sbc-support.ch
PCD2.M170: chip soldered on the main board, the FW can be downloaded with PG5 *
PCD2.M177: can be downloaded, refer to the product page on www.sbc-support.ch
PCD2.M480: chip soldered on the main board, the FW can be downloaded with PG5 *
PCD2.M487: can be downloaded, refer to the product page on www.sbc-support.ch
PCD3.Mxxxx: chip soldered on the main board, the FW can be downloaded with PG5 ** Procedure to downlaod a firmware:
1) get the appropriate file from product page on the supportsite www.sbc-support.ch
2) open PG5 and go to the online-configurator; go offline
3) open the menu tools, download firmware
4) browse for the firmware file and start the download
5) load the HW configuration and the user program -
Baudrate limitation on serial ports (FAQ #100252)
Basically on PCD systems introduced before 2003 there are some restrictions to be considered about the maximum baud rate of serial communications.
Depending on firmware and hardware not all serial ports can be used at their theoretical maximum baud rate at the same time.
Systems introduced before 2003:
- All PCD1, PCD2 (except PCD2.M480), PCD4 and PCD6 as well as PCS1 classic contollers do have a baud rate limitation of 38.4 kB/s on each serial port.
For older firmware (FW) versions there is a further restriction since there is one UART responsible for two serial ports and this UART cannot handle baud rates of 38.4 kB/s on both ports at the same time. The port allocation of the UARTs is the following: first UART: port 0 and 1; second UART: port 2 and 3 etc.
This means that it isn't possible to set the concerned ports to
- 38.4 kB/s each
- one to 38.4 kB/s and one to 19.2 kB/s
- but it is possible to set one port to 38.4 kB/s and one port to 9600 B/s. - Due to more efficent port handling recent FW versions do have the following restriction (independent of production date of HW):
Amount of ports available divided by 2 equal amount of ports that can communicate at 38.4 kB/s. All the residuary ports do have a maximal baud rate of 19.2 kB/s.
In addition an UART of an PCD7.F5xx isn't able to handle 19.2 kB/s on one and 38.4 kB/s on the other port. But it is possible to assign both ports to 38.4 kB/s.
Systems introduced since 2003 (PCD2.M480 and PCD3.xxxx):
Due to faster hardware there are much higher baud rates possible on the serial ports (up to 115 kB/s)!
There is only one restriction regarding UART sharing left:
On a PCD7.F5xx it is not possible to communicate on one port at 19.2 kB/s and one the second port at 34.8 kB/s at the same time (but two times 38.4 kB/s is possible!).
This means that all ports may communicate at the maximum baud rate (which is specified in the technical information (TI) or in the manual) at the same time.FW versions that support the new port handling mentioned above:
For the following and newer FW version the following rule is valid:
Amount of ports available divided by 2 equal amount of ports that can communicate at 38.4 kB/s.
All the residuary ports do have a maximal baud rate of 19.2 kB/s.PCD system required FW version PCD1.M1x0 V081 PCD2.M110/M120 V090 PCD2.M150 V0C0 PCD2/4.M170 V010 PCD4.Mxx5 not supported PCD6.M1xx/M2xx not supported PCD6.M3x0 V040 PCS1.C8xx V090 - All PCD1, PCD2 (except PCD2.M480), PCD4 and PCD6 as well as PCS1 classic contollers do have a baud rate limitation of 38.4 kB/s on each serial port.
-
Communication interface isn't reset on SW watchdog restart with option XOB0 enabled (FAQ #100243)
Communication interfaces containing a co-processor aren't restarted after a restart caused by the software watchdog with the option "Execute XOB0". In fact only a restart cold will be executed but without resetting the communication modules.
This behaviour is a bug and will be corrected in the next FW version for the corresponding CPU. As soon as the new FW is built it will be available on the support homepage.
In the meantime it is recommended not to use the option "Execute XOB0" for the software watchdog. In this case the communication modules will be reset normally on software watchdog execution.
-
Firmware version naming of non-Saia PCD® COSinus systems (FAQ #100176)
Or "What is the difference between 0-, $- and #-firmware versions?". PCD firmware for non-Saia PCD® COSinus Systems (PCD1, PCD2.M1x0, PCD4, PCD6 and PCS) are named with 3 letters (e.g. 010, B0W or #31). This FAQ explains the meaning of these version and how to figure out which one is more recent.
The firmware version naming of non-Saia PCD® COSinus systems
In general the 3 letters (abc) are used for the following indications:- a
Definition of the kind version this firmware is. The possible versions are the following
- 0xx versions are "official production versions" (010 is the first official production version)
- Bxx versions are Beta versions which contain new features compared to the previous production version
- #xx versions are "customer bug fix versions" of an official production FW version.
- $xx versions (Pilot version) include new functionalities which are not yet fully tested. Therefore a $-version should only be used in field if the developement gives their ok! - b
The second letter defines the main production version (starting with 01x wich stands for first official production version, followed by 02x (where the 02x has important new features compared to the 01x version - c
The last letter is incremented for each build of the firmware (best observed for the bug-fix versions; #21 is based on the 020 firmware and contains corrections for the 020 firmware version)
To figure out which version the base version of a bug fix- or pilot version is, have a look at the second character of the corresponding version (e.g. the "1" of the 013). This character indicates the official production version on which the bug fix or pilot version is based on.
Examples
010 is the official production version
018 is the production bug fix version of 010; no new functions
#19 is a customer bug fix version based on 018 (and therefore also on 010); no new functions
$19 is a pilot version based on 010 with new functions. The bug fixes done for e.g. 019 probably aren't implemented in this version! (the new features will be added to the production firmware versions in 020 or later.
Remark
Early versions of the Saia PCD® COSinus systems (PCD2.M480, PCD3, PCD2.M5) up to 039 were named with this system as well. In order to reduce confusion concerning features of a firmware the new firmware naming a.bb.cc has been applied (see FAQ 100741). - a
-
Not all History entries can be found in the Online Help of PG5 (FAQ #100173)
Some history entries introduced in new firmware versions can't be found in the Online Debugger Help nor in the online help of the Online Configurator.
Below you can find recently introduced History entries that can't be found in the Help files of PG5 versions older than PG5 1.3:
History Entry Meaning Remark MEM-EXT. ERROR Extension memory corrupted Replaces "BAD TXT/DB TABLE" CONFIG TOO LONG HW setting to long to be put in EEPROM Replaces "BAD MODEM STRING" WATCHDOG FAIL Restart due to SW Watchdog was executed IPM NOT PRESENT There is an IP configuration but no IP module IPM DONT RESTART PCD has restarted but the IP module does not respond IPM HAS OLD FW The IP module FW is not compatible with the PCD FW IP FAIL SASITEXT There is an error in the SASI text IP FAIL SASI DBX There is an error in the node list configuration DBX IP FAIL NO IPM An IP function has been carried out, but the PCD has no IP configuration IP FAIL TOUT Incorrect timeout value in Ether-S-Bus master SASI text IP FAIL PORT Nbr Incorrect port number in Ether-S-Bus master SASI text Included text >3 Text nesting depth overflow SBUS PGU Error The SBUS PGU Port defined in the HW Settings isn't physically present
Error Messages concerning PCD1.M2, PCD2.M480, PCD2.M5xx0 and PCD3.Mxxx0 systems (SBC-NT)History Entry Meaning . Media corruption This message indicates that the onboard RAM has been corrupted (becaused of a discharged superCap, bad Battery or similar).
If this message is shown, all medias (R, C, F) are reset to 0, the clock is reset and the program is restored from the onboard flash (if possible).
This entry has been replaced in firmware version 1.10.04 by "Memory Lost nn"Memory Lost nn Replacement message for "Media Corruption", but with more detailed informaton why the user program was restored and the media reset (since FW version 1.10.04):
01: Bad or missing battery
02: Supercap voltage too low
03: Corrupted memory pattern/signature
04: RAM memory cleared by user (push button)
05: RAM and flash memory cleared by push button
06: Corrupted program headerNot RUN on xx7HW The HW is a xx/ type; the FW doesn't run the program on this HW SYS. TYPE ERROR The HW system type isn't correct Reg>4095 not sup The FW doesn't support more than 4095 registers SF NOT LOADED System function (CSF) isn't present CSF INV PAR NBR Invalide CSF parameter number DOUBLE TIME BASE Timebase defined more than once XOB Nbr to big XOB (Exception Organisation Block) number is too big COB Nbr to big COB (Cyclic Organisation Block) number is too big FB Nbr to big FB (Function Block) number is too big PB Nbr to big PB (Program Block) number is too big IST Nbr to big IST (Initial STep) number is too big ST Nbr to big ST (STep) number is too big TR Nbr to big TR (TRansition) number too big SB Nbr to big SB (Sequential Block) number too big FABINFO CRC FAIL Invalid CRC in the fabrication information. Please contact SBC SYSWDOG START Restart due to SW Watchdog executed NO COB No COB loaded EXTHDR EEPR FAIL Error in the EEPROM extended header IP SB GWY FAIL TCP/IP SBus gateway can't be initialised IP Ch xxx no mem No memory to open the channel on the TCP/IP Open data mode MODEM: UART fail UART doesn't accept the configuration MODEM: Reset fail Error on the modem reset command MODEM: No modem No modem or defective modem equipped on the port MODEM: Init fail Error on modem initialisation MODEM: ERROR??? Unknown modem error DIFF CFG Ch x Different configuration on Profi-S-Net port x. Verify the configuration of the port PS FAIL SASI DBX Error in the node list configuration DBX PS FAIL TOUT Incorrect timeout value in Profi-S-Bus master SASI text PS FAIL SAP Incorrect SAP number in Profi-S-Bus master SASI text PS FAIL SASITEXT Error in SASI text PSM NOT PRESENT Profi-S-Net (Profibus) configuration but no Profi-S-Net (Profibus) existent PSBus GWY FAIL Profi-S-Bus GWY can't be initialized PSBus PGU FAIL Profi-S-Bus PGU port can't be initialized
SWTO ERROR System Watchdog Timeout Error, see FAQ 100908 and 101069 BUS ERROR Internal memory access failed. Please contact your local support team, see FAQ 101069 TCPS ERROR TCPIP-Stack crash. Please contact your local support team
KRNL ERROR Internal task overload. Please contact your local support team, see 101069 BACnet incompatible FW The BACnet firmware found on the PCDx.R56x module is not compatible with the PCD firmware. Please update the BACnet firmware (see FAQ: 101010)
This message is only given with firmware version 1.10.16 and later.Bnt FAIL TL00001 An error occurred in relation to the BACnet configuration. Please refer to FAQ 101436. MANUAL HALT Indication that the PCD has been halted by pushing the Run/Halt button (implemented in firmware 1.14.23 and later) EXT DEVICE FAIL This message can be generated by PCD systems with FW 1.10.xx; The message is wrong and should be "31 CALL LEVELS".
It indicates a too big nesting level of FB/PBs (if XOB 10 is programmed, it is called in this case)RESISTERS FAIL The termination resistors of port 3 of a PCD3.M5340 can not be activated due to a firmware restriction, see FAQ 101722. INVALID PERI DBXHardware configuration contains errors (e.g. peripheral addresses, modules not supported by the firmware)