Newer PCD types and newer PCD7.D4xx devices have micro-SD memory card (uSD) on the PCB (printed circuit boards)

The following data’s are stored on the this uSD card on the PCD’s PCB:

• Firmware for the PCD
• Device configurator settings (PG5)
• Application program done with PG5
• Webeditor 8 project (PG5)
• DATA (e.g HDLog) created by the application program in runtime
• Setup, Calibration (PCD7.D443, PCD7.D450, PCD.D470)
• Program Backup on internal Flash

In some cases, it is necessary to replace the micro-SD memory card (uSD) of the PCD.

This FAQ describes how to replace the micro-SD memory card (uSD) which is mounted on the PCD controller's PCB (printed circuit boards)  

The attached .pdf describes how to replace the micro-SD memory card (uSD) used on the PCB of the PCD

No

Saia-Burgess Controls devices and software are not affected from Domain Name System (DNS) vulnerabilities published with the report name NAME:WRECK

-

No, Saia-Burgess Controls devices and software are not affected from AMNESIA:33 or from SUNBURST

• AMNESIA:33: Describes Security vulnerabilities in TCP/IP stacks
• SUNBURST: Is a trojan

No, SBC devices are not affected from the Ripple20 zero-day vulnerabilities since none of our products uses the TCP/IP software library developed by Treck, Inc.

The device configurator gives an error when a card with 16 digital inputs or outputs is configured on base address 240 because the address 255 is reserved for the hardware watchdog!

Can I use the I/O card on this slot?
Whether the media mapping is configured or not, it is possible to put a 16 I/O card on address 240. The only condition is that the last I/O of the card (address 255) isn't used! The message "On the defined module, the last input/output with address 255 cannot be used." can be ignored for digital I/O modules (but not for analogue I/O modules)

Remark
It is planned to change the error message of the device configurator.

Firmware versions before the version 1.10.51 were not supporting retries during the "Upload/Merge" process of the BACnet configurator. In case a telegram got lost during upload of the BACnet configuration (from the PCD to the PC) the transfer was been aborted.

Symptom
During an Upload (for the function "Upload/Merge" of the BACnet configurator) all of the sudden the transfer of the configuration stops. This phenomenon is observed when a telegram is lost. This telegram loss is random, dependent on the network load.

Reason
Firmware versions before the version 1.10.51 were expecting a communication without telegram losses. In case a telegram was lost (due to network problems) the transfer was interrupted by the PCD firmware. Because of the interruption the BACnet firmware was not notified, but it remained in a state of waiting for the completion of the upload process.

Solution
The firmware version 1.10.51 (for the PCD3 or the PCD2.M5) together with the BACnet firmware 1.10.50 are more robust and can cope with telegram losses during the upload of the BACnet configuration. Please update the firmware of your PCD and the one on your PCD7.R56x to the mentioned (or later) firmware versions.

Remark
Please note that the firmware version of both, he PCD and the BACnet module must be updated.

Some Ethernet devices do generate gratuitous ARP telegrams every time they are connected to an Ethernet network. This telegram informs the router that there is a new IP address on the network and causes it to update its internal MAC addresses table in case the according IP was already mapped to a MAC address.

Background
If a device is replaced on a network and the new device does have the same IP address, it won't be reachable until the router (or other devices that communicate with the replaced system) refreshes the MAC address table.
The gratuitous ARP telegrams are one way to inform a router about a modification of the MAC address bound to an IP address.

Does a PCD generate gratuitous ARP telegrams?
No, a PCD (e.g. a PCD3, a PCD2.M5xxx or a PCD equipped with a PCD7.F655) does not generate gratuitous ARP telegrams when being connected to an Ethernet network (when it gets a "Link"). This feature is not implemented in the stack, and there are no plans for implementing this feature into the stack of the F655 because:

• there is a relatively easy to realize workaround available
• and the gratuitous ARP telegram is only required in case PCD is being replaced (which is not very often)

How to cause the router to update its MAC address?
Instead of relying on a gratuitous ARP telegram, a simple telegram can be sent to the router device every time the link is being detected (indicated by a rising edge of the "Diagnostic Flag+6", or as in the attached code example just regularly every 60 seconds). The telegram to be sent can be done by using the Open Data mode of the PCD.
Attached you can find a small code example which could be used on a PCD3 or a PCD2.M5xx0 (given no other ODM code is implemented on the system). This code can be added to a CPU in PG5 1.4.300 project using the "Add files..." (from the context menu of the "Program Files" folder of the CPU). Additionally, plase update the symbol "RemoteIP" within this file to a fitting IP address on you network and read the header of the file for more information how to work with this code. 

Due to a problem of the firmware version 039 the serial PGU connection on the PGU port does not work.

Symptom
It is not possible connecting the PCD2.M480 (with firmware version 039 installed) with serial PGU mode using a PGU cable PCD8.K111.

Reason
A problem of the firmware version 039 causes the serial PGU connection not to work.

Solution
If possible use the (faster) USB port of the PCD for connecting the PCD. In case this is not possible for you, please contact your local sales office and request a firmware that fixes the problem (e.g. 03B). 

XOBs 20 and 25 are called when interrupt input INB1 or INB2 of the PCD1/2 has detected a rising edge.

Problem
Obviously XOB 20/25 are called and they are not programmed. The PCD has detected a rising edge on INB1/INB2.

Reason
If the interrupt inputs are used XOB20/25 has to be programmed otherwise this will generate an error. If the interrupt inputs are not used and there is a history entry anyway it can be that the PCD detects a rising edge do to disturbances.

Solution
If the interrupt inputs are used, programm the XOB 20 /25.
If the interrupt inputs are not used, connect the INB1 and INB2 to the GND to avoid disturbances

The PCD CPUs can be protected with a password. Once the CPU is password protected it is not possible reading its hardware or user program any more.

How can I protect my PCD with a password?
The protection is done by configuring a password in the hardware settins and downloading this configuration (make sure you have enabled the "Password" in the download window).

How can I remove the password?
There are two possibilities to remove the password from the PCD:

• You can re-download the hardware configuration (with the password protection in the Hardware Settings unchecked). Again, make sure you have enabled the "Password" in the download window. You will be prompted for the password when downloading the new configuration.
• You can clear the whole memory of the PCD or the PCS. Doing so will not only remove the password but will erase the whole configuration and user program of the PCD! The "Clear Memory..." function can be found in the menu "Online" of the PG5 "Online Configurator".

Restrictions

• The procedure "Clear Memory..." does not yet work for all CPU types (e.g. the PCD3 memory can not be cleared with this function). (An alternative way could be removing the battery and removing the power supply in case the user program is stored in RAM).
• The minimal PG5 version featuring the "Clear Memory..." function is PG5 1.4.120.

On the PCD1, and PCD2.M110/120/150 it is possible to put a memory chip as extension memory. The table below contains a list of the supported extension memory chips for classic PCD's.

No the XOB 5 is only supported by the PCD4 and PCD6

Reason
The reason is, that the "IO Bus Quit fail" is a hardware interrupt created by the PCD4 and PCD6 I/O modules. On the PCD3 and also PCD2 I/O modules it is not supported and therfore not available.

Yes, it is implemented in the PCD3 with FW Version $12 or later. On the PCD2.M5xx0 it is supported with every firmware

The S-Net MPI-Port has to be configured as Port 3 instead of Port 10. It can be used as free standard RS 485-Port for S-Bus, to add a Bus-Terminal etc.

The wiring is:

D-Sub S-Net MPI                           S-Bus / Terminal ...
Pin
    3 RxD/TxD-P  --------------------- /TX /RX
    5 GND           --------------------- GND         
    8 RxD/TxD-N  --------------------- TX RX

After an Ethernet module has been replaced (and the IP address remained the same), it is often not possible connecting to the according PCD. The reason is that the PC "remembers" the old MAC address (which is different on every Ethernet module) and tries to connect to the old MAC address.

Symptom
After exchanging a PCD7.F65x or a PCD with Ethernet port, the communication between PC and PCD doesn't work any more. The same phenomenon can also be observed if the PCD is connected via a router (which also has a table where all IP addresses are listed together with its MAC address).

Reason
IP stations do address each other over its MAC address and not over its IP address. The first time a telegram is sent to a IP address, an ARP (address resolution protocol) telegram is sent which queries the MAC address for the relevant IP address. The destination station will then respond with its own MAC address (which will be stored by the originator of the telegram). After the MAC address has been received once, it will be stored on the originator for future use.
If the MAC address of a device changes, but the IP address remains the same, the originator of the communication (or a router or a switch in-between) needs to refresh its MAC table!  

Solution
To make the PC aware of the new MAC address, the PC needs to delete the MAC entry of the according IP address (for that it qureies it again for the next telegram). This is done automatically by the PC but takes some time.
To force a refresh of the MAC entry of an IP addres, the MAC adress of the concerned IP address in the local PC cache has to be deleted by using the arp command in the Windows Command Prompt. This can be done with the command "arp -d Entry_To_Delete":

The command prompt (screenshot above) can be launched from the Windws Start menu; Select "Execute" and type "cmd".

Short discription of  useful  ARP commands

• arp -a   display the  contents of the local cache
• arp -d   claer all contents of the correspond  IP- Adress
• ARP /?  display all possible parameter of ARP-Command
  

Remark
In case there are routers and switches in-between the PC and the PCD, also their cache needs to be deleted. This can be done by restarting the device.

No. Changing modules under tension can result in damage to the modules and CPU.

Remark
Please note that not only the PCD Power supply but also the tension on the I/Os themself (and the power supply of the I/O modules) must be removed before the modules can be removed without risk.

Yes it’s possible to connect a PCD directly to the internet, but you have to protect your PCD against unauthorised access or cyber-attacks.

To protect the PCD against unauthorised access or cyber-attacks, it’s imperatively needed to take some protective measures.

Information about protective measures can be found on the support hp

If you need a PCD with cyber security levels SL3+ and based on ANSI ISA 62443 then checkout our PCD3.M6893 (QronoX PCD), this PCD was developed for cybersecure applications.

Information's can be found here.

In January 2024:
the COSinus BACnet FW 1.28.59 was put on the support homepage.  

In April 2022:
the COSinus FW 1.28.51 was introduced into production for the systems:

- PCD1.M0xx0/M2xx0, PCD2.M4x60, PCD3.Mxx60 and PCD3.M6880.

In February 2019:
the COSinus FW 1.28.37 was released as maintenance version for the systems:

- PCD1.M0xx0/M2xx0, PCD2.M4x60, PCD3.Mxx60, PCD3.M6880 and PCD3.T665/T666/T668.

In June 2017:
the COSinus FW 1.28.16 was introduced into production for the systems:

- PCD1.M0xx0/M2xx0, PCD2.M4x60, PCD3.Mxx60, PCD3.M6880 and PCD3.T665/T666/T668.

the BACnet and LonIP FW 1.28.51/1.28.59 was put into production, which do support the BACnet Revision 14.
To support the BACnet Revision 9 it's necessary to use the PCD and the BACnet FW 1.26.xx.

Attention:
The firmware 1.28.xx or later can be used only on the following PCD's with 8 MB onboard firmware memory:
PCD1.M0xx0/M2xx0, PCD2.M4x60, PCD3.Mxx60, PCD3.M6880 and PCD3.T665/T666/T668

The table below does show the hardware dependencies in relation with the COSinus firmware versions

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

Firmware 1.28.59 (only BACnet firmware) (January 2024)

Main corrections

• BACnet: MI/MO/MV objects, invalid values for Alarm_Values and Fault_Values are rejected
• BACnet: BI/BV/BO objects, present value of can only be 0 or 1
• BACnet: COMMAND object, present value writing returns an error if bigger that the number of actions
• BACnet: Trendlog objects, property value check is done according to specifications
• BACnet: Limit COV subscription to 3000 and send PDU-Error if length of response is too big
• BACnet: Disable I-Have response when state is disable / disable-init
• BACnet: Calendar Object Date List, don’t allow wild card in this property entries
• BACnet: writing invalid array to Array properties returns correct Error code
• BACnet: Pulse Converter Object, send out-of-range PDU-Error if count processing is < 0
• BACnet: Controller goes to HALT with SWTO error
• BACnet: MS/TP Controller goes to HALT with SWTO error
• BACnet: Schedule accepts Sundays in Week and Day
• BACnet: GetEnrollmentSummary: correct reply if list is empty

Firmware 1.28.51 (April 2022)

Main corrections

• All PCD’s: Saia PCD Modbus diag does not work if diag flag > 9999
• All PCD’s: SNTP and hardware RTC is diverging from more than 2 seconds, then History message ‘RTC Fail error’ is generated
• All PCD’s: SNTP Time synchronization does not work with DHCP
• All PCD’s: E-Mails send from PCD could contain unwanted characters like 0 or others
• All PCD’s: S-Monitoring values for S-Monitoring bar graphs are sometime wrong
• All PCD’s: S-Monitoring Year graph scaling displayed wrongly
• All PCD’s: TCP, open data mode protocol, communication is blocked after rejection of 32 connections
• All PCD’s: LonIP CSF is locked when an error occurs
• PCD2.M45x0: SRXM does not support FB parameters as operand 3 and 4 for source and destination
• PCD1.M2220-C15: Watchdog LED does not follow Relay when PCD goes in STOP or HALT
• PCD3.M6880: Data exchange between CPU 0 and CPU 1 does not work reliable if STL instruction is used
• BACnet: Calendar state not updating after add/remove list element service
• BACnet: Exception schedule writing to certain array index fails
• BACnet: Schedule crashes with SWTO error
• BACnet: MS/TP client properties are not written if many values change simultaneously
• BACnet: Problem reliability & out of service, reliability is not written when oos is high
• BACnet: Web CGI commands to read BACnet platform tags like ..AddFW,Version,BACnet don’t work
• BACnet: Web scheduler/calendar templates do not work
• BACnet: PCD3.M6860 no BACnet communication on ETH2 if router is used
• BACnet: Rev 4 not working with Name based Client
• BACnet: Rev14 does not allow high limit value below 5 on analogue input

Firmware 1.28.37 (February 2019)

New features

• All PCD’s: FW extension to close all open FTP connections
• BACnet: Calendar objects have been extended with a synchronization mode. Each server calendar object can be configured as Slave or Master calendar
• BACnet: New mappings for alarming counters have been added to Notification-Class objects.
• BACnet: The PCD will now accept AcknowledgeAlarm service requests, which use complete wildcards as timestamps.

Main corrections

• All PCD’s: On S-Bus data mode, if S-Bus CRC contains a S-Bus DLE as last character then S-Bus telegram is incorrect and not accepted from S-Bus recipient. (Since FW 1.28.20)
• All PCD’s: Not all bytes are transmitted when working with MC4 or MC5 mode on F2xxx module
• All PCD’s: RS485 driver keep holding bus after a while
• All PCD’s: Http request ‘is modified’ is not handled correctly on the PCD Web-Server which lead to the effect that web project is not loaded correctly on the browser
• All PCD’s: PCD can crash when breakpoint is updated during conditional RUN
• All PCD’s: PCD can crash on download in run since FW 1.28.27.
• All PCD’s: PCD can crash on download in run when Graftec is used
• All PCD’s: PCD crashes when using browser to access the default page of PCD with "Display Root Content Enabled = YES"
• All PCD’s: RCOB does not start COB when it was stopped before with SCOB
• All PCD’s: Profibus communcation using onboard FDL port. The FCS test for SD2 telegram was not implemented correctly.
• All PCD’s: When S-Bus IP Nodelist is used it’s possible that the communication using nodes does no more work after execute a download in run
• All PCD’s: XOB parameter as Registers does not work if 16bit addressing was used
• All PCD’s: LonFT10: SNVT_obj_status and SNVT_obj_request can be used in user profiles
• PCD3.Mxx60, PCD3.T6xx, PCD1.M2xx0, PCD2.M4x60: usage of I/O media mapping slows done the cycle time 2 times in comparison to FW 1.26.xx
• PCD2.M4x60: Download LonIP config not possible
• PCD2.M4x60: RTC gets sometime corrupted data when PCD7.F7500 is used on PCD2.M4x60
• PCD2.M4x60: RTC Time is wrong after several days of run
• PCD7.D443WTxR: uBrowser use alphapad.teq even if screen is rotated by 90°
• PCD7.D443WT5R: History entry Memory ‘Lost -1’ written in the History
• BACnet; Event Enrolment does not work correctly with external reference devices.
• BACnet; When using BACNet Webvisu the memory used increase each time the scheduler is edited.
• BACnet; PCD crash when BACnet Webvisu edit scheduler.
• BACnet; BACnet WebVisu does not display correct value for the WeeklySchedule value.
• BACnet; ACK Required bit in notification message is not set according to the related NV ack_required bits
• BACnet: The PCDAlarmStatus mapping property does not work correctly.
• BACnet: Mappings, which changed to the value 0 directly after a program download, are not updated correctly on the BACnet property.
• BACnet: The Priority-Array mapping does not work correctly after startup.
• BACnet: Initialization of Puls converter count with input reference gives error
• BACnet: Fix issue with weekly scheduler.
• BACnet: Fix issue with WeekNDay entries
• BACnet: The Restore functionality over BACnet does not work, when the PCD has been reset over factory reset.
• BACnet: The Action property in the command object does not handle NULL datatype and priority entries correctly, if they are used in the ActionCommand. Additionally, the Action property can now be read via index.
• BACnet: Priority_Array entry 16 will be overwritten on startup with the last Present_Value mapping
• BACnet: Out of Service -> Value for PV overridden after reboot by Input ref
• BACnet: The Log_Buffer to csv conversion for trend-log objects does not skip time change entries
• BACnet: Unmapped Priority-Array property array entries are not stored persistent
• BACnet: BACnet configuration on the PCD is not deleted when "unlinked" from PG5
• BACnet: Change Client Time_Of_Restart mapping to Unix time
• BACnet: Client mapping - Threshold is not implemented correctly
• BACnet: Mapped Reliability properties within analogue objects does interfere with the objects functionality. When the Reliability is mapped, the mapping has not full control over the property value.
• BACnet: The program download fails, when the BACnet config contained notification-class objects with event-counter mappings
• BACnet: BACnet Trend-Log(-Multiple) data can’t be retrieved as csv data
• BACnet: The SubscribeCOVProperty service can’t be executed on complete Priority_Arrays

Firmware 1.28.16 (June 2017)

New features

• All PCD's: When push button is pressed while power on then do not update FW from FS in order to execute a delete all.
• PCD1.M0xx0/M2xx0, PCD2.M4x60, PCD3.Mxx60, PCD3.M6880 and PCD3.T665/T666/T668:
  Enhancement for HTTP server to transparently support sending compressed files.

Main corrections

• All PCD's SBUS parity mode, correction when NAK character is received as first byte of response.
• All PCD's: When download new Ethernet-RIO Program with the option ‘Delete all backups’ it can happen that the RIO is not commission and no goes no more in ‘data exchange mode’ until the PCD reboots.
• All PCD's: When RIO name is not in upper case the RIO file is not updated until a restart is executed.
• All PCD's: When RIO file is downloaded with download changed RIO file then RIO file is not sent to RIO until a restart is executed.
• All PCD's: Ethernet Frame Padding Information Leakage fixed (CVE-2017-9628)
• All PCD's: The Modbus CSF CloseSRPort does not free the port then a open/SASI call give an error and the port does not work.
• PCD1.M2xx0 PCD1.M22x0 PCD2.M4x60: PCD can crash while power down when XOB 0 is programmed.
• PCD1.M2xx0 PCD1.M22x0 PCD2.M4x60: MC0 mode with start/stop flag working again.
• PCD7.D443WT5R: Alarming does not work since 1.28.00 FW.
• PCD7.D443WT5R: When watchdog timeout occurs PCD7.D443WT5R does't reboot and stays locked.

Firmware 1.28.11 (Arpil 2017)

New features

• All PCD's: Support of BACnet Revision 14

Main corrections

• All PCD's: Various Open Data Mode fixes: Read Timeout enhancement, Client Connection timeout and Client Keep alive with anonymous port issue fixed
• All PCD's: Modbus RTU on all ports but specially on the F2xx module has been corrected to handle the response timeout processing in the case that the response is just occurring at the moment of the timeout.
• All PCD's: Battery status shows FAIL also if battery module is missing.
  All PCD's: Various minor issues fixed
• PCD1.M2xx0 & PCD3+: 38400/115200 baud settings adjustment
• PCD2.M4x60: PCD7.F7500 initialization

Due to a production error it's possible that PCD2.M5540 which have been produced in 2020 may contain a wrong production date with year 2000 and calendar week 0.

This wrong production date leads to an error message being entered in the PCD history:
'FABINFO CRC FAIL'

and in the PG5 Online configurator hardware info and in the diagnostic file the warning:
'Fab. Date (year/week): 2000/00; BAD PROD INFO CHECKSUM'
is displayed.

Error description:

This wrong production date leads to an error message being entered in the PCD history and also in the hardware info of the PG5 Online configurator the warning is displayed.

However, the PCD2.M5540 works perfectly.

I.e. the functionality of the PCD2.M5540 and the user program which is processed on the PCD2.M5540 are in no way affected by this warning.

Information shown in PG5 online configurator, Hardware Info...

Information shown on PCD's history

Solution:

To fix the issue, load the attached program on the affected PCD2.M5540 and set PCD2.M5540 in Run mode.

The program will set the manufacturing date to the year 2020, calendar week 60 and store the information retentively in the uEprom of the PCD2.M5540.

Calendar week 60 was used to recognize that the fabrication date was modified using this PG5 program.

After switching an off and on of the 24VDC the warning
'Fab. Date (year/week): 2000/00; BAD PROD INFO CHECKSUM'
is no longer displayed and the fabrication date year 2020, calendar week 60 is displayed.

The program only needs to be run 1 time on the PCD2.M5540.

It is not necessary to integrate the program into your application program.

Then load your application program into the PCD.

Symptoms
Programmable PCD devices that act as S-BUS master on RS485 with PCD Firmware >= 1.28.20 and <= 1.28.33 get no answer from Slave devices on some of the S-Bus master requests, although S-BUS address, baud rate, polarity and line termination are ok.

Possible effects of the issue

Until now we have found that E-Line RIO communication seems to be more concerned of this problem than e.g. RS485 S-Bus data communication between CPU's.

In some of the cases the effect was, that it was not possible to write to the outputs of the E-Line RIO's or the change of values on the E-Line RIO Inputs was not transfered to the S-Bus master.

With the concerned Firmware it might be very difficult or impossible to download the user program over a gateway connection.

PCD Firmware 1.28.x for all programmable PCD types are concerned.

Reason

The reason of the issue is a error in the Firmware of the S-Bus master.
The problem on the Firmware is, that telegrams which contain DLE characters (B5 or C5) as last character of the telegram (CRC) where malformed because the last character is missing.

Since the CRC is calculated during runtime this malformed S-Bus request occurs depending of the content of the S-Bus request.

The (malformed) CRC is transfered with the S-Bus request from the master to the slave.

If now the slave receives the S-Bus request and the received CRC does not fit with the calculated CRC, then the S-Bus slave reject the S-Bus telegram.

Solution

In case you use the concerned Firmware on an installation with RS485 S-Bus Data communication, update the S-Bus master PCD to the newest available Firmware >= 1.28.34.

This Firmware do fix the issue CVE-2017-9628 related to Ethernet frame padding information leakage.
To avoid any problems in relation to this leakage we do recommend strongly to update to the latest Firmware
1.28.16 / 1.24.69 or newer as mentioned on the security upgrade section on this web-page.

Impact of the CVE-2017-9628
IEEE 802 specifies that packets have a minimum size of 56 bytes.
The Ethernet driver is expected to fill the data field with octets of zero for padding when packets are less than 56 bytes.
Resident memory and other data are used for padding in some implementations that could cause information leakage.
This attack is passive; the attacker can only see data that the affected devices sent out as part of a packet.

Vulnerability overview of the CVE-2017-9628
The previous implementation of firmware allowed other data from a known area of memory to be used in this field and could exfiltrate or leak data.

In April 2022:
the COSinus FW 1.28.51 was introduced into production for the systems:

- PCD1.M0xx0/M2xx0, PCD2.M4x60, PCD3.Mxx60 and PCD3.M6880.

In February 2019:
the COSinus FW 1.28.37 was released as maintenance version for the systems:

- PCD1.M0xx0/M2xx0, PCD2.M4x60, PCD3.Mxx60, PCD3.M6880 and PCD3.T665/T666/T668.

In June 2017:
the COSinus FW 1.28.16 was introduced into production for the systems:

- PCD1.M0xx0/M2xx0, PCD2.M4x60, PCD3.Mxx60, PCD3.M6880 and PCD3.T665/T666/T668.

the BACnet and LonIP FW 1.28.16 was put into production, which do support the BACnet Revision 14.
To support the BACnet Revision 9 it's necessary to use the PCD and the BACnet FW 1.26.xx.

Attention:
The firmware 1.28.xx or later can be used only on the following PCD's with 8 MB onboard firmware memory:
PCD1.M0xx0/M2xx0, PCD2.M4x60, PCD3.Mxx60, PCD3.M6880 and PCD3.T665/T666/T668

The table below does show the hardware dependencies in relation with the COSinus firmware versions

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

Firmware 1.28.51 (April 2022)

Main corrections

• All PCD’s: Saia PCD Modbus diag does not work if diag flag > 9999
• All PCD’s: SNTP and hardware RTC is diverging from more than 2 seconds, then History message ‘RTC Fail error’ is generated
• All PCD’s: SNTP Time synchronization does not work with DHCP
• All PCD’s: E-Mails send from PCD could contain unwanted characters like 0 or others
• All PCD’s: S-Monitoring values for S-Monitoring bar graphs are sometime wrong
• All PCD’s: S-Monitoring Year graph scaling displayed wrongly
• All PCD’s: TCP, open data mode protocol, communication is blocked after rejection of 32 connections
• All PCD’s: LonIP CSF is locked when an error occurs
• PCD2.M45x0: SRXM does not support FB parameters as operand 3 and 4 for source and destination
• PCD1.M2220-C15: Watchdog LED does not follow Relay when PCD goes in STOP or HALT
• PCD3.M6880: Data exchange between CPU 0 and CPU 1 does not work reliable if STL instruction is used
• BACnet: Calendar state not updating after add/remove list element service
• BACnet: Exception schedule writing to certain array index fails
• BACnet: Schedule crashes with SWTO error
• BACnet: MS/TP client properties are not written if many values change simultaneously
• BACnet: Problem reliability & out of service, reliability is not written when oos is high
• BACnet: Web CGI commands to read BACnet platform tags like ..AddFW,Version,BACnet don’t work
• BACnet: Web scheduler/calendar templates do not work
• BACnet: PCD3.M6860 no BACnet communication on ETH2 if router is used
• BACnet: Rev 4 not working with Name based Client
• BACnet: Rev14 does not allow high limit value below 5 on analogue input

Firmware 1.28.37 (February 2019)

New features

• All PCD’s: FW extension to close all open FTP connections
• BACnet: Calendar objects have been extended with a synchronization mode. Each server calendar object can be configured as Slave or Master calendar
• BACnet: New mappings for alarming counters have been added to Notification-Class objects.
• BACnet: The PCD will now accept AcknowledgeAlarm service requests, which use complete wildcards as timestamps.

Main corrections

• All PCD’s: On S-Bus data mode, if S-Bus CRC contains a S-Bus DLE as last character then S-Bus telegram is incorrect and not accepted from S-Bus recipient. (Since FW 1.28.20)
• All PCD’s: Not all bytes are transmitted when working with MC4 or MC5 mode on F2xxx module
• All PCD’s: RS485 driver keep holding bus after a while
• All PCD’s: Http request ‘is modified’ is not handled correctly on the PCD Web-Server which lead to the effect that web project is not loaded correctly on the browser
• All PCD’s: PCD can crash when breakpoint is updated during conditional RUN
• All PCD’s: PCD can crash on download in run since FW 1.28.27.
• All PCD’s: PCD can crash on download in run when Graftec is used
• All PCD’s: PCD crashes when using browser to access the default page of PCD with "Display Root Content Enabled = YES"
• All PCD’s: RCOB does not start COB when it was stopped before with SCOB
• All PCD’s: Profibus communcation using onboard FDL port. The FCS test for SD2 telegram was not implemented correctly.
• All PCD’s: When S-Bus IP Nodelist is used it’s possible that the communication using nodes does no more work after execute a download in run
• All PCD’s: XOB parameter as Registers does not work if 16bit addressing was used
• All PCD’s: LonFT10: SNVT_obj_status and SNVT_obj_request can be used in user profiles
• PCD3.Mxx60, PCD3.T6xx, PCD1.M2xx0, PCD2.M4x60: usage of I/O media mapping slows done the cycle time 2 times in comparison to FW 1.26.xx
• PCD2.M4x60: Download LonIP config not possible
• PCD2.M4x60: RTC gets sometime corrupted data when PCD7.F7500 is used on PCD2.M4x60
• PCD2.M4x60: RTC Time is wrong after several days of run
• PCD7.D443WTxR: uBrowser use alphapad.teq even if screen is rotated by 90°
• PCD7.D443WT5R: History entry Memory ‘Lost -1’ written in the History
• BACnet; Event Enrolment does not work correctly with external reference devices.
• BACnet; When using BACNet Webvisu the memory used increase each time the scheduler is edited.
• BACnet; PCD crash when BACnet Webvisu edit scheduler.
• BACnet; BACnet WebVisu does not display correct value for the WeeklySchedule value.
• BACnet; ACK Required bit in notification message is not set according to the related NV ack_required bits
• BACnet: The PCDAlarmStatus mapping property does not work correctly.
• BACnet: Mappings, which changed to the value 0 directly after a program download, are not updated correctly on the BACnet property.
• BACnet: The Priority-Array mapping does not work correctly after startup.
• BACnet: Initialization of Puls converter count with input reference gives error
• BACnet: Fix issue with weekly scheduler.
• BACnet: Fix issue with WeekNDay entries
• BACnet: The Restore functionality over BACnet does not work, when the PCD has been reset over factory reset.
• BACnet: The Action property in the command object does not handle NULL datatype and priority entries correctly, if they are used in the ActionCommand. Additionally, the Action property can now be read via index.
• BACnet: Priority_Array entry 16 will be overwritten on startup with the last Present_Value mapping
• BACnet: Out of Service -> Value for PV overridden after reboot by Input ref
• BACnet: The Log_Buffer to csv conversion for trend-log objects does not skip time change entries
• BACnet: Unmapped Priority-Array property array entries are not stored persistent
• BACnet: BACnet configuration on the PCD is not deleted when "unlinked" from PG5
• BACnet: Change Client Time_Of_Restart mapping to Unix time
• BACnet: Client mapping - Threshold is not implemented correctly
• BACnet: Mapped Reliability properties within analogue objects does interfere with the objects functionality. When the Reliability is mapped, the mapping has not full control over the property value.
• BACnet: The program download fails, when the BACnet config contained notification-class objects with event-counter mappings
• BACnet: BACnet Trend-Log(-Multiple) data can’t be retrieved as csv data
• BACnet: The SubscribeCOVProperty service can’t be executed on complete Priority_Arrays

Firmware 1.28.16 (June 2017)

New features

• All PCD's: When push button is pressed while power on then do not update FW from FS in order to execute a delete all.
• PCD1.M0xx0/M2xx0, PCD2.M4x60, PCD3.Mxx60, PCD3.M6880 and PCD3.T665/T666/T668:
  Enhancement for HTTP server to transparently support sending compressed files.

Main corrections

• All PCD's SBUS parity mode, correction when NAK character is received as first byte of response.
• All PCD's: When download new Ethernet-RIO Program with the option ‘Delete all backups’ it can happen that the RIO is not commission and no goes no more in ‘data exchange mode’ until the PCD reboots.
• All PCD's: When RIO name is not in upper case the RIO file is not updated until a restart is executed.
• All PCD's: When RIO file is downloaded with download changed RIO file then RIO file is not sent to RIO until a restart is executed.
• All PCD's: Ethernet Frame Padding Information Leakage fixed (CVE-2017-9628)
• All PCD's: The Modbus CSF CloseSRPort does not free the port then a open/SASI call give an error and the port does not work.
• PCD1.M2xx0 PCD1.M22x0 PCD2.M4x60: PCD can crash while power down when XOB 0 is programmed.
• PCD1.M2xx0 PCD1.M22x0 PCD2.M4x60: MC0 mode with start/stop flag working again.
• PCD7.D443WT5R: Alarming does not work since 1.28.00 FW.
• PCD7.D443WT5R: When watchdog timeout occurs PCD7.D443WT5R does't reboot and stays locked.

Firmware 1.28.11 (Arpil 2017)

New features

• All PCD's: Support of BACnet Revision 14

Main corrections

• All PCD's: Various Open Data Mode fixes: Read Timeout enhancement, Client Connection timeout and Client Keep alive with anonymous port issue fixed
• All PCD's: Modbus RTU on all ports but specially on the F2xx module has been corrected to handle the response timeout processing in the case that the response is just occurring at the moment of the timeout.
• All PCD's: Battery status shows FAIL also if battery module is missing.
  All PCD's: Various minor issues fixed
• PCD1.M2xx0 & PCD3+: 38400/115200 baud settings adjustment
• PCD2.M4x60: PCD7.F7500 initialization

With Firmware >= 1.26.00, after Power off / on of the PCD, the LON bindings are lost.

Symptoms

The LON communication don’t works anymore after power off/on. In the commissioning tool, e.g. NL220  the Lon node is getting “red” after the function Network –>Test

Reason

In the FW 1.26.xx there is a problem with the file update on the Flash cards, the bindings are only updates in the memory but the operation to save them to the filesystem fails. Therefore the binding information is lost after power off / on.

Solution

The correction is done with >= 1.26.24. The firmware of the PCD and the LonIP FW have to be updated.

In the commissioning tool e.g. NL220 a Network -> Repair function has to be executed on the node.

Only the FW >= 1.26.00 are concerned. (e.g. FW 1.24.xx is not concerned of this problem)

In June 2017:
the COSinus FW 1.26.31 was released as maintenance version for the systems:

- PCD1.M0xx0/M2xx0, PCD2.M4x60, PCD3.Mxx60, PCD3.M6880 and PCD3.T665/T666/T668.

the BACnet and LonIP FW 1.26.31 was released as maintenance version, which do support the BACnet Revision 9.
To support the BACnet Revision 14 it's necessary to use the PCD and the BACnet FW 1.28.xx.

In March 2017:
the COSinus FW 1.26.28 was introduced into production for the systems:

- PCD1.M2220, PCD1.Mxx60, PCD2.M4x60, PCD3.Mxx60, PCD3.M6880 and PCD3.T665/T666/T668.

the BACnet and LonIP FW 1.26.28 was introduced into production

In June 2016:
the COSinus FW 1.26.15 was introduced into production for the systems:

- PCD1.M0xx0, PCD1.M2xx0, PCD2.M4x60, PCD3.Mxx60 and PCD3.M6880.

The COSinus FW 1.26.16 was introduced into production for the systems: PCD3.T665/T666/T668.

The BACnet and LonIP FW 1.26.15 was introduced into production

Attention:
The firmware 1.26.xx or later can be used only on the following PCD's with 8 MB onboard firmware memory:
PCD1.M0xx0/M2xx0, PCD2.M4x60, PCD3.Mxx60, PCD3.M6880 and PCD3.T665/T666/T668

The table below does show the hardware dependencies in relation with the COSinus firmware versions

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

Firmware 1.26.31 (June 2017)

Main corrections

• All PCD's SBUS parity mode, correction when NAK character is received as first byte of response.
• All PCD's: When download new Ethernet-RIO Program with the option ‘Delete all backups’ it can happen that the RIO is not commission and no goes no more in ‘data exchange mode’ until the PCD reboots.
• All PCD's: When RIO name is not in upper case the RIO file is not updated until a restart is executed.
• All PCD's: When RIO file is downloaded with download changed RIO file then RIO file is not sent to RIO until a restart is executed.
• All PCD's: Ethernet Frame Padding Information Leakage fixed (CVE-2017-9628)
• All PCD's: The Modbus CSF CloseSRPort does not free the port then a open/SASI call give an error and the port does not work.
• PCD1.M2xx0 PCD1.M22x0 PCD2.M4x60: PCD can crash while power down when XOB 0 is programmed.
• PCD1.M2xx0 PCD1.M22x0 PCD2.M4x60: MC0 mode with start/stop flag working again.

Firmware 1.26.28 (March 2017)

Improvements

• Text Ram can now be cleared (all chars are set to blank space) with the cgi interface by writing a zero length string.
• Ping request on ETH2 over rooter from different sub net.
• LonIP Mapper improvement
• Web Server RAM Disk increased
• Error Led not set on IR overflow

Main corrections

• All PCD's: MC0 communication with F2xx module and related communication flags are handled correctly in case of transmission
• All PCD's: Text Ram can now be cleared (all chars are set to blank space) with the cgi interface by writing a zero length string.
• All PCD's: Multiple AlarmLists with similar names will now be "initialized" correctly.
• All PCP's: TCP client keep alive is not working when anonymous port is used.
• All PCD's: Profi-SBus GWY does not wor, Profi-SBus Master/GWY stop working after cable is re plugged.
• All PCD's: PCD crash when use DIGI(R)/DIGO(R) with first parameter as FB parameter.
• All PCD's: Correction for modbus RTU communication over F2xx communication module
• All PCD's: When RIO file is downloaded with download changed RIO file then RIO file is not sent to RIO until a restart is executed.
• PCD1.M22x0: While changing the analog output value, the Watchdog is switching. Switching the Watchdog Relais over the corresponding flag has no influence.
• PCD2.M4x60: Sometimes the Profibus DP module is not initialized correctly on startup.
• PCD2.M5xx0: When Restore program because of a missing or dead battery configuration (SBus/IP,..) is not restored correctly.
• PCD2.M5xx0: Modbus RTU on all ports but specially on the F2xx module has been corrected to handle the response timeout processing in the case that the response is just occuring at the moment of the timeout.
• PCD2.M5xx0: Sometimes config is lost after download project with self-download tool.
• PCD3.Mxxx0: Battery status shows FAIL also if battery module is missing.
• PCD3.Mxxx0: FTP server processing with long commands resolved.
• PCD3.Mxxx0: Modbus RTU on all ports but specially on the F2xx module has been corrected to handle the response timeout processing in the case that the response is just occuring at the moment of the timeout.
• PCD3.Mxxx0: Sometimes config is lost after download project with self-download tool.
• PCD3.Mxx60: Profi-SBus/DP/SIO does not work on port 2 on PCD3.M3x60 & PCD3.M5360.
• PCD3.M6860: Ping request from over rooter from different sub net is not respond.
• PCD3.M6860/M880: Profibus/S-IO/Profi-SBus does not work stable.
• PCD3.M6860: Set PCD to HALT if there is no or incompatible media transfer between the two CPU's.
• PCD3.T66x: The RIO Status web page does not allow to clear the diagnostics.
• BACnet: The memory usage of the BACnet FW was increasing for every SubscrobeCOVProperty service, which has been received by the PCD.
• BACnet: A client configuration for Priority_Array properties in commadable objects (e.g. Analog-Value) does now allow reading (ReadProperty/COV) and writing (WriteProperty service to server) at the same time.
  
  

Firmware 1.26.15 (June 2016)

New features

• Support of PCD1.M2220-C15
• Support of PCD2.M4x60
• Support of PCD3.M3160/PCD3.M3360/PCD3.M5360
• Support of PCD3.M6880, PCD3.T668 Standby-CPU-System

Improvements

• PCD2.M4x6x, support Interrupt when reaching the configured ref Value
• PCD1.Mxxx0, PCD2.M4x60, PCD3.Mxx60 PCD7.D4xx: Increase None Volatile Register to 1000
• PCD3.T666/8: Increase the User Program Memory for to 256k
• PCD3.T66x: Support the ESIO manager use tag values for IP address
• PCD2/3.F2xx modules Baudrate: Support 300/600/1200 baud settings for in MC mode.
• S-Monitoring: In bar displays where the current time is visible, the average for the period is calculated not in a optimal way (time slice, ref time, is a bar). New it's displayed in seconds
  
  

Main corrections

• PCD3.M6860/M6880: When update FW on extension using the file system after update the extension FW can stay in an endless loop
• PCD3.M6880: crash wen Timmer/Counter is mapped in the Read Symbols
• PCD3.M6880: PCD can crash with MuKe Error when use the SBus GWY in parallel with modbus TCP
• PCD3.M6880: Standby CPU1 does not always HALT when CPU0 crash
• PCD3.M6880: CPU0 to 1 From Read data communication sometimes stop works
• PCD3.M6880: Add a Transmit Error diagnostic tag "DataTxErrors"
• PCD3.Mxxx0: Battery module on IO slot 3 does not show battery status in history
• PCD3.Mxxx0/PCD1.M2xx0: Some baudrates on onboard ports are not correct
• PCD2.M4x60: RTC read/write locks the PCD for about 30ms
• PCD2.M4x60: Modem does not work because of the not working DCD
• PCD3.T66x: Add ELine CSF library
• PCD3.T66x: Serial com does not work with SASI instruction
• PCD3.T66x: CSF Modbus Server Init gives an error when port 502 is used becasue this port is already open
• PCD7.D443WT5R: Assignation/Configuration of port 1 should return an error because port 1 is not supported
• PCD7.D443WT5R: Remove IO access from the system. PCD goes now in HALT with "INVALIDE OPCODE"
• PCD2.W220 with Pt1000: Significant deviation between singel channels
• BACnet: List Properties (like Date_List, Exception_Schedule, ...) could disappear after a PCD restart, if a WriteProperty request with an empty list value has been received for these properties before the restart. This behavior was only present for persistent properties
• BACnet: The Log_Buffer property of a Trend-Log object could not be read anymore using the ReadRange service, after a Event-Log or Trend-Log-Multiple has been read via ReadRange
• BACnet: Writing a single analog output channel is not working. The output is not changing. Writing output channels over the mapped functionality is working
• BACnet: PCD with BACNet loops with restart if program has "INVALIDE OPCODE"
• Restart Warm does not work
• SBus ELine has sometimes retries
• When create a Text/DB the backup fails until a restart is done
• PCD Crash with BUS ERROR on STXT instruction when text is empty
• Modem does not work correctly
• Modem does not work or PCD crash when modem is configure
• PCD can crash when error occurs in Modbus RTU
• The PCD crash if a BITI is executed with number as FB parameter
• PCD crash when use Profi-S-Bus Master
• Sometimes the program is lost when update FW from 1.24.xx to 1.26.xx
• MOVX/DIVX function where not working on Task or Temporary data when use indexed
• Add config tag value for GWY mode "data_no_secure" to deasble the secure data mode
• Not possible to upload a file through the Web server FTP interface (ftp.cgi or ftp.json) if that file starts with a white space character (either a space or a tab)
• CSF CopyDBBytesToR crash when destination is bigger than last Register
• Diagnostic Flags in S-Bus Master mode are not correct if there are collisions on the RS-485 network
• CSF Backup/Restore Media does give an error on restore when data change while backup/restore
• MOV instruction with type position as FB parameter gives error flag and fails
• Web-Alarm: Fix alarming color with "group color mode" and group bigger than 8

It’s possible that after a FW update of the PCD to the FW 1.20.xx, 1.22.xx or 1.24.xx there is a entry in the FW history ‘FWDnld UnknownFW’ after the history line ‘FWDnld 1.2x.xx PLC CLASSIC’ as shown on the image below.

The history message ‘FWDnld UnknownFW’ was caused by an error in the old FW of the PCD and does have no signification.

Just ignore this message and clear the history messages.

In case an FBox library (or an IL program) uses a functionality which is not implemented in the PCD firmware, the PCD will not go in run but display the error message "SF not loaded" (e.g. in the PCD history or in the Online Configurator).

Symptom
After the download of a program a SBC-NT based PCD (e.g. PCD3) does not go in run but remains in halt. When going online with the Online Configurator a message "SF not loaded" is displayed.


Reason
The user program uses a functionality which is not implemented in the firmware (and therefore the PCD can not run the user program).

Solution
The solution is either updating the firmware, or avoiding the CSF which leads to the problem.
In case it is not know which CSF is responsible for the "SF not loaded", the SF library can be found based on the program line indicated by the Online Configurator (the program line is indicated with "Halt at xxx" in the Status; in the screenshot above the CSF is on program line 4). By using the Online Debugger, this CSF can be displayed by typing "DP4C10"):

   Display Program 4 Count 10 (Enter)
  

In this case, the CSF calls the SF library 26 (which is not implemented in the Firmware 1.10.51 which is used above).

How to know the functionality based on the library number?
Below you can find a list of the most commonly used System Function libraries (and in which FBox libarary they are used):

• SF library 0: S.SF.IP (e.g. Open Data Mode)
  Used by several IP communication drivers such as EIB/Net and for reading or writing the IP address of the PCD.
• SF library 2: System library
  Used by FBoxes for reading the Serial number
• SF library 4: S-Net library
  E.g. Used by FBoxes for Profi-S-Bus and Ether-S-Bus
• SF library 6: S.SF.DBLib (e.g. CopyTextBytes), previously the "ApplicationLib" for CopyText
  E.g. used by the Modem FBox library, HDLog to File library.
• SF library 7: File System library
  E.g. used by the FBoxes for the File System or "HDLog to File"
• SF library 9: IP Services (EMail, PPP, DNS, SNMP etc.)
  E.g. used by the EMail library and the WAA (Wide Area Automation) FBox library
• SF library 10: S-Web Alarming library
  E.g. used by the S-Web Alarming FBoxes and the DDC Suite
• SF library 13: Modbus library
  E.g. used by Modbus and the P-Bus FBox library
• SF library 19: LON over IP library
  used by LON over IP functions
• SF library 22: SPI framing protocol for PCD2/3.F2xx(x)
  e.g. used by the M-Bus library 2.6.100 and later
• SF library 23: Energy Manager library
• SF library 25: LON FT library
• SF library 27: ELine library for ELine modules
  Since PCD firmware version 1.24.xx

The single function codes (second line of the CSF call, "0" in the screenshot above) of the relevant libraries can be found in the definition files in folder
   c:\Documents and Settings\All Users\Saia-Burgess\PG5_20\Libs\SF\*.lib
(e.g. SFModbusLib_en.lib for the functions of the Modbus library.

As the "original" Instruction List Set (with the mnemonics STH, OUT etc.) could not be extended by an unlimited amount of new instructions, the call of new features such as the Open Data Mode, Sending of EMails etc. is realised with so called SFs (which stands fro "System Function"). These SFs are called using CSF instructions (Call System Function).

What is a SF library?
A System Function library is a a set of functions which are implemented in the firmware and which can be called with the IL mnemonic CSF. Usually one SF library contains several functions which are related to each other. A CSF expects the SF library and the function from this library, together with a set of parameters (described in the online help of the SF library which can be found in the IL Editor SEdit from PG5 2.0).

How is a CSF used?
In the user program a SF function is called using the mnemonic CSF, followed by the library, the function and the parameters:
CSF     [cc]     Library
                    Function
                    Parameter 1
                    Parameter 2
                    ...


This can be done from inside an FBox, or directly from an IL program (as the engineering is faster using the FBoxes, the most CSFs are called from FBox libraries).
The "translation" between meaningful names (e.g. S.SF.DBLIB.CopyTextBytes) and the code which is used by the firmware is done by PG5. For a list of the most commonly used SF libraries, please refer to FAQ 101568.

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.

In July 2010 the firmware 1.14.23 has been introduced into production for the PCD2.M5xx0 and the PCD3.Mxxx0. This FAQ lists the main differences between versions 1.10.51 and 1.14.23.

New features
please note that in order to take advantage of these new features PG5 2.0 SP1 (PG5 2.0.150) is required.

• Increased amount of available flags (14335 instead of 8191), see FAQ 101447
• S-Web and FTP Server as well as the IP Enhancements (DHCP, DNS, SNTP and PPP) can be configured in the Device Configurator, see FAQ 101464
• Webserver access levels can now be configured in the Device Configurator (was before in the WebBuilder settings), see FAQ 101613
• IEEE floating point values can be displayed on the S-Web server (display format is “e”), see FAQ 101188
• Number of COBs increased to 32, see FAQ 101467

Main corrections

• SYSWR for DB backup failed after a lot of backups, see FAQ 101466
• STXT with more than 512 bytes sent a wrong text, see FAQ 101468
• The IP address for the Open Data Mode System Function “ConnectTCP” could not be given as constant 

Hardware compatibility of firmware 1.14.23 with PCD3 systems
The firmware 1.14.23 requires a PCD equipped with 4 MB onboard flash. Therefore the minimal hardware versions for installing the 1.14.23 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.14.23.

Remarks 

• When updating from 1.10.xx
  Please note that the user program as well as the communication settings are lost during the firmware update from 1.10.xx to 1.14.xx (or 1.16.xx) 
• BACnet applications
  The BACnet firmware 1.14.26 is compatible to this new production firmware. Please download the latest BACnet firmware package for PCD firmware 1.14.xx from the support page (link below).

In case a text with more than 512 bytes is sent with a firmware older than 1.14.23 the according text has not been sent correctly.

Symptom
When sending a text with a length of more than 512 bytes on a PCD3 or a PCD2.M5 with a firmware older than 1.14.23 the text which is sent is not correct.
In case the text to be sent contains sub-texts which are introduced using interpreted text (e.g. the $Lnnnn) and the final length to be sent is more than 512 bytes, the same phenomenon can be observed.

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

Up to firmware version 1.14.23 the maximal amount of COBs (Cyclic Organization Blocks) has been 16. In firmware 1.14.23 the amoung of COBs has been increased to 32. Thus on PCD2.M5 and PCD3 and newer systems up to 32 COBs can be used (COB to 31).

Remark
Please note that PG5 2.0 Service Pack 1 (PG5 2.0.150) is required in order to program the COBs 16 and higher.

In some cases, usually after a lot of backups which have been executed, the error bit 7 (flash task already started) or 8 (flash error) is set with firmware older than 1.14.23.

Symptom
A backup DB to flash (IL instruction "copy TEXT/DB to flash card", SYSWR 3000 or 3100) fails and the error bits 7 and/or 8 are set. This error remains, even after waiting several minutes without re-attempting a backup to flash.

Solution
This problem is corrected in firmware 1.14.23 or later. Please update your PCD firmware in order to solve this problem.

In May 2010 the firmware 1.10.51 has been introduced into production for the PCD2.M5xx0 and the PCD3.Mxxx0. This FAQ lists the main differences between these versions.

New features

• The Serial-S-Bus mode “Parity master” is now supported on all serial ports of the PCD, see FAQ 101103

Main corrections

• Increased stability for BACnet upload/merge (requires BACnet firmware version 1.10.50), see FAQ 101417
• Correction which avoids potential data loss on the SD cards when a card with more than 256 kBytes capacity is filled by 70%, see FAQ 101377
  In case an SD card is used on the PCD, the update of the firmware to the version 1.10.51 is strongly recommended!
• Avoided inter-character delay on port 2 and 3 (PCD2.M5) or 0 and 3 (PCD3) which could lead to communication problems, see FAQ 101382
• A Bus Error could occur in some specific cases, see FAQ 101418
• Reading Ni1000 sensors with a PCD2/3.W340 by the media mapping returned wrong values, see FAQ 101416
• Profi-S-I/O and Profibus DP Master did not work, see FAQ 101244

For writing data to files on the PCD file system and for sending SMS or EMails it is possible to enter the content of medias (registers, flags etc.) into the text to be written or sent. This is done by placing e.g. a $R0100 into the text to be sent. At the time of writing, the "$R0100" will be replaced by the content of the register 100.

While in the beginning only points could be used as seperators in interpreted texts, it is also possible using the comma as separator with recent firmware versions. In this case, instead of a point a comma is to be used:


Firmware dependencies
The comma separator can be used starting with the following firmware versions:

Under certain circumstances (if the file system is occupied by more than 70%) data losses on SD cards bigger than 256 MBytes have been observed.

Symptom
Under certain circumstances data losses on SD cards bigger than 256 MBytes have been observed. By analyzing these reports we have seen that in case more than 70% of the available memory on such a card is used it is possible that data is lost on the next power-up of the PCD or after the card has been re-inserted into the memory module holder (R600 / R6000) or opened by the SD Flash Explorer.
In case of many delete operations executed by the module the mentioned data loss can also occur if less than 70% of the available memory is used (due to the ware-out management of the SD card which varies the used memory areas).

Solution
An additional safety mechanism in the PCD firmware 1.10.51 as well as in the SD Flash Explorer in order to avoid future potential data loss on concerned cards has been implemented.
As soon as the system is rebooted (or the SD card is re-inserted into the R600 / R6000 mounted on a PCD with a new firmware versions) actions are taken in order to avoid the mentioned potential data loss.

The according firmware 1.10.51 (for PCD2.M5xx0 and for PCD3.Mxxx0 systems) with the new safety mechanism can be found on the support site www.sbc-support.ch.

In addition to the safety mechanism a new SD Flash Explorer version 2.0.215.0 features a “Backup” and a “Restore” feature which allows the creation of a backup of the file system.
This SD Flash Explorer can be downloaded from the support site from the section for the PCD7.R-SDxxx and will be distribued with the SP1 for PG5 2.0.

Remarks

• Even if the file system on a SD card is already filled up by more than 70%, it is still possible to download the data over FTP as long as the PCD is NOT switched off. This method is recommended before updating the firmware in order to guarantee that no data is lost.
• SD cards delivered by Saia-Burgess Controls AG after week7 of 2010 contain a mechanism that avoids the above mentioned data loss (as long as the card is not formatted with a firmware older than 1.10.51).
  

This FAQ contains an overview over the firmware versions currently used in production (which means that this firmware version is installed in our production facility).

Firmware versions used in production
The following firmware versions are currently used in production. For more information regarding the relevant firmware, please refer to the version information document of the according page.

PCD firmware versions

MB Panel firmware versions

RIO firmware versions

When working with PCD systems you will cross the expression "Saia PCD® COSinus" sooner or later. This FAQ explains what "Saia PCD® COSinus system" stands for.

The expression "Saia PCD® COSinus"
In general the expression "Saia PCD® COSinus" stands for PCD systems which are equipped with Freescale (previously Motorola) Coldfire CPU technology. The "non-Saia PCD® COSinus" systems from Saia-Burgess Controls AG are based on Freescale 68k CPU technology (e.g. PCS1, PCD2.M170 etc.).
The Coldfire CPU technology is a new and more performant CPU generation, new development is generally realized on Coldfire CPU (while the 68k CPUs still are available in parallel).
The first PCD system based on the Saia PCD® COSinus technology has been the PCD2.M48x. For this system the whole firmware has been re-written. The firmware of new systems is built up based on the firmware developed for the PCD2.M48x platform (having the same core modules). New firmware functionalities (e.g. Modbus which is implemented in the firmware) are basically designed for the Coldfire CPU technology and thus for Saia PCD® COSinus systems.

Saia PCD® COSinus based systems
The following list contains the main PCD systems which are based on Saia PCD® COSinus technology.

• PCD3.Mxxx
• PCD2.M48x
• PCD2.M5xxx
• PCD7.D4xx
• PCD1.M2xx (currently under development)

Does this mean that all Saia PCD® COSinus systems support the same firmware features?
No! Although the same base modules of the firmware are used, it is depending on the PCD system whether a specific feature is supported or not. For example the http protocol is supported by PCD3 and PCD2.M5xxx systems, but not on PCD2.M48x.

With an activated software watchdog the processor monitors itself and restarts the PCD in the event of a malfunction or a loop.

Description (extract from the hardware manual)
The hardware watchdog provides maximum security. However, for non-critical applications, a software watchdog may be suffcient, whereby the processor monitors itself and the CPU is restarted in the event of a malfunction or a loop.
The core of the software watchdog is the instruction SYSWR K 1000. When this is first issued, the software watchdog function is activated. This instruction must then be issued at least every 200 ms, or the watchdog will trigger and restart the controller.

Usage

• Placing a "Watchdog"-FBox in a FUPLA-file is the easiest solution:
  
• Instead of using the FBox it is possible calling the Software Watchdog in IL (using the instruction SYSWR K 1000)
  

If there is a SIO-Master and a DP-Master configured the SIO-Master does not go in the "Operate" state to make the data exchange.

Symptom
It can happen with the firmware version 1.10.16 that a PCD3 or a PCD2.M5 does not work as SIO-Master if they are also DP-Master.

Solution
This behavior is solved with the version 1.10.51 or newer (the first version which corrected this situation was 1.10.20). Please update the firmware of your PCD in order to solve this issue.

The WebServer2 is a re-implementation of the previous WebServer on Saia PCD® COSinus systems and of course compatibel to the previous version.

History
The first implementation of a Web Server on PCD systems has been realized around the year 2000. With growing experience additional features and higher performance have been requested. In order to fullfil this requirement, the WebServer has been re-implemented (with the result of the WebServer2).

What is new in the WebServer2?
In general the WebServer2 is functionally compatible to the previous implementation. In addition the following new features are supported:

• HTTP 1.1 support
• HTTP caching is supported. As result the in FAQ 100708 is no longer to be applied; It is recommended to enable the caching for the JVM (option "keep temprary files on PC") when working with the WebServer2.
  
  Remark: If the caching is not enabled, you will not profit from the supported caching; it will then work as it has before with the previous WebServer. 
• Better performance
• Parallel acces to files is properly supported (acces is no longer interrupted if another client loads the IMaster applet)
• Multiple Web clients can access the Web Server on the same physical interface with (Ether-S-Bus or Profi-S-Bus)
• Easier understandable error messages
• When texts are entered, the length of the text is specified (and no longer filled up with space characters)
• The WebServer2 does provide more information on the default page and has a nicer look. By viewing this page it is easy figuring out whether the WebServer2 is running on a PCD
  

  View of previous WebServer	View of WebServer2

Firmware (FW) supporting the WebServer2
The table below indicates the first firmware versions supporting the WebServer2. Systems not listed in this table do not feature the WebServer2.

^*) Please note that in the first pilot firmware not all features have been supported.

Remark
The only incompatibe difference between the previous WebServer and the WebServer2 concerns users that use the "HTML forms":

• The previous Web Server used:
  %%TAG%
• The WebServer2 expects (the "value" is no longer automatically added by the Web Server):
  value=%%TAG%

An example for the HTML forms on the WebServer2 can be found in the attached document.

Yes, a new set of instructions for calculation with IEEE floating point values (single and double) has been added to the firmware of PCD2.M480, PCD2.M5xx0 and PCD3.

Introduction
Motorola FFP (Fast Floating Point) has been used for floating point calculations since the beginning of PCD history. In order to simplify the interface against systems which do not support FFp but IEEE format for floating point values the instruction set of the PCD has been extended. All "twin" of all instructions available for the calculation with FFP values are now also available for IEEE calculations.

What are the instructions in detail?
Each of the existing instructions for FFP (the default) do also exist for IEEE Float and IEEE Double data. 

• For IEEE Float, precede the mnemonic with an 'E' character, for example EIFP, EFADD (instead of IFP or FADD) etc.
• For IEEE Double, precede the mnemonic with 'D', for example: DIFP, DFSUB.

Minimum Firmware (FW) requirement for this feature

PCD systems not listed in this table do not support this function.

Remarks

• These instructions can only be used with PG5 2.0.
• There is also a new instruction for the conversion from IEEE single to IEEE double (and vice versa):
  EFPD (single to double) and DFPE (double to single). These instructions are supported by firmware version 1.10.15 and later.
• The instructions for convertig a IEEE double value to an integer value and vice versa (DFPI and DIFP) are working correctly starting with firmware 1.14.23.
• IEEE single values can be displayed by the S-Web Server using the format "e" (e.g. 172.16.1.127/cgi-bin/readVal.exe,e) 

For "reading" a value from a PCD text (e.g. copying "1234" from a PCD text with content "The next number is: 1234" into a Register) a new System Function has been added for PCD3 and PCD2.M5xx0.

What does this System Function (SF) do?
The new function "S.SF.DBLIB.ReadANumberFromText" allows reading a number from a text and copy it into a register. Starting from a provided pointer, the next number will be searched and copied.

Where do I find the documentation for this function?
This function is documented in PG5 2.0. The easiest way to open the documentation is opening the SEdit, selecting the "SF DB Access Library" and hitting "F1":


Minimum Firmware (FW) requirement for this feature

PCD systems not listed in this table do not support this function.

Remark
This feature can only be used with PG5 2.0.

For parsing a PCD text for a specific expression (e.g. finding "world" in a PCD text with content "Hello world") a new System Function has been added for PCD3 and PCD2.M5xx0.

What does this System Function (SF) do?
The new function "S.SF.DbLib.SearchText" allows searching a text for a specific expression. If this expression is found, the SF returns the position of the expression within the text.

Where do I find the documentation for this function?
This function is documented in PG5 2.0. The easiest way to open the documentation is opening the SEdit, selecting the "SF DB Access Library" and hitting "F1":


Minimum Firmware (FW) requirement for this feature

PCD systems not listed in this table do not support this function.

Remark
This feature can only be used with PG5 2.0.

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.

The XOB 8 who is called when the firmware detects an invalid instruction (Invalid OPC) in the user program is no longer called on the systems Saia PCD® COSinus (PCD3, PCD2.M5, PCD2.M480).

On the new systems, the control of the Invalid OPC is executed at the startup during the precompilation. So the XOB 8 will never be called.
This new mechanism is implemented to increase the speed and the flexibility of the systems Saia PCD® COSinus.

The PCD3 systems equipped with an Ethernet port and the PCD2.M5540 are able to send emails. But sending e-Mails is not only depending on the CPU itself.

The PCD3 systems equipped with an Ethernet port and the PCD2.M554x support SMTP (Simple Mail Transfer Protocol). Sending emails does not only depend on this feature but as well on the ISP (Internet Service Provider), the firewalls and router configurations between PCD and ISP.

The attached checklist with the criterias to verify with your provider and / or your IT support shall help to check whether sending E-Mail is possible.

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

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

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

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

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

This error message appears if the used firmware on the CPU does not support the "active and non ACK" filter for the S-Web alarming functionality (e.g. a PCD2.M150 with firmware 0D3).

Symptom
Instead of the alarm list of the S-Web alarming macro, the message "Failed to get data on alarm.exe" is displayed on the alarming page.

Reason
The reason is that the macro tries receiving the alarms filtered by the "active and not acknowledged" state of the alarms. This does only work if this feature is implemented in the according firmware.

Solution
Please update the firmware (FW) of your PCD system to the firmware supporting the according feature (see table below).

^*) On PCD3 and PCD2.M480 systems the "active and not acknowledged" filter has already been implemented in previous versions, but has been improved this indicated version.

Yes, this is possible by calling the system function (CSF) "IPGetLocalConfig".

Introduction
For having the possibility to read the current IP configuration from the user program, a specific System Function has been added to the firmware. This function does return the IP address, the subnet mask as well as the default gateway (each address in one register). The returned value contains the full IP address in one register (each byte or the register contains one octed of the IP address):

Example
This System Function is part of the IPD Library. In order to use these functions, the file "IPLib.inc" is to be included to the source file where the function is called. This can be done with the line:

$INCLUDE "IPLib.inc"

The IP configuration can then be read in th following way:

Returned IP address (hex):               0xAC100179h
IP address in "Dot-decimal notation": 172.16.1.121 (0xACh = 172, 0x10h = 16, 0x01h = 1, 0x79h = 121)

Firmware versions supporting the GetLocalIPConfig
Please refer to the table below for the first firmware versions that support the "IPGetLocalConfig" function.

Remark
The include file "IPLib.inc" from PG5 1.4.300 and earlyer versions needs to be updated in order to "know" this feature. Therefore please download the file "IPLib.inc" attached to this FAQ and replace the existing file from PG5 which is located in the "Libs/App" of PG5:

c:\Program Files\SAIA-Burgess\PG5 1_4\Libs\App\IPLib.inc

In firmware version 1.08.xx for systems running the Saia PCD® COSinus firmware, the system watchdog has been introduced. If a PCD reboots because of the system watchdog, the message "SWTO ERROR" is entered in the PCD history.

What for is a system watchog?
The system watchdog is a security measure which avoids a situation where the system (PCD) is blocked and does not properly execute the program any more. If the OS (Operating System) is "locked" in a loop and does no longer properly execute its tasks (among others, the user program), the PCD is automatically re-started. 

What does the system watchdog do?
The (internal) system watchog is configured directly on the CPU and will cause a re-boot if it is not triggered in a cyclic manner. Every reboot caused by the system watchdog is entered in the PCD history with the message SWTO ERROR (SWTO stands for System Watchdog TimeOut).
The behaviour after the automatic reboot caused by the system watchdog is depending on the software watchdog which can be programmed in the user program:

• If the software watchdog in the user program is enabled, the PCD will automatically go in RUN after a reboot caused by the system watchdog. 
• If no software watchdog is programmed in the user program, the PCD will go to "Halt" after it has rebooted because of the system watchdog.

Does the system watchdog conflict with other watchdogs?
No, the system watchdog does not conflict with e.g. the software watchdog programmed in the user program or with a hardware watchdog.  
 
When has the system watchdog been implemented?
The system watchdog has been implemented in firmware version 1.08.xx. The first production versions for the relevant systems can be found in the table below:

Remark
Note that the system watchog does not detect a bogus user program (e.g. an infinite loop) and therefore the usage of the software watchdog in the user program is still recommended.

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.

In order to simplify the interpretation of firmware versions and to avoid confusion regarding implemented features and bug fixes in different firmware versions, a new firmware version format for Saia PCD® COSinus based systems will be introduced.

Arguments for the new format
The new firmware version naming allows a clear and easy comparison between the different versions and their implemented features (PCD type specific) and bug fixes.
Questions like "Why is the Alarming functionality of the PCD3 Web Server implemented in firmware version $31 but not in version 031? - They both do have the same number..." should be past (however, if you're interested in the answer, please refer to FAQ100176)

Format description
The new firmware version name does consist of a major version, a branch version and a minor version separated by a dot (.).
Note that the prefix characters “0”, “$” or “#” are no longer used in this notation.

Concerned systems
The new firmware version format is applied to the systems based on Saia PCD® COSinus firmware (Classic and xx7). These are

• PCD1.M2xxx
• PCD2.M48x
• PCD2.M5xxx
• PCD3.Mxxxx
• PCD7.D4xx (MB Panels)

While the firmware names for the MB Panels and PCD1.M2xxx do have this format from beginning, it was introduced on the PCD3 and PCD2.M480 systems with the firmware version after 03B.

Version flow example
Below an example for a version flow. If e.g. a bug is corrected in the version 1.06.01, also version 1.07.02 and all following 1.06.xx versions do/will have this correction implemented.


Version types

• Released beta- or maintenance versions (equivalent to the current “Bxx” or “#xx” versions).
• Released Production versions (equivalent to the current “0xx” versions): These versions are introduced in the production.
• New function versions (equivalent to the current “$xx” versions).

Compatibility with PG5
The new firmware names are fully supported by PG5 V 1.4.200:

Previous versions of PG5 will only show the first three digits of the firmware version (e.g. “106” instead of “1.06.08”). The full firmware version can always be read by displaying byte F0F0 in the “Online Debugger” (type DYF0F0 ):

The diagnostic flag TBSY of the "Character Mode" (used for sending characters over a serial line) is not handled the same way on a PCD3 compared to "older" systems like e.g. PCD2.M170.

Symptom
If the relevant port is assigned in MC mode, the diagnostic flag TBSY is indicating that the serial port is busy sending characters. This is the case on e.g. a PCD2.M170.
This behaviour is not the same on a PCD2.M5xxx or a PCD3.Mxxxx, especially not when using a PCD3.F121 or a F2xx(x) modules. On a PCD3/PCD2.M5 the TBSY flag is not any more high during the whole time the port is busy. Instead, it is only high a short time at the very beginning of the send task.

Reason
The reason for this difference is a new manner to access the UART of the port. On older systems the characters were directly written to the UART while on the PCD3 a buffer is placed in-between. Instead of indicating the "send-state" of the UART like on older systems, the TBSY represents the state of this buffer (the size can be found at the end of this FAQ) on the PCD3 or the PCD2.M5.

Solution
This difference shouldn't lead to problem is most cases. However, in some applications the state of the TBSY is used to control e.g. the RTS signal of the line (using the instruction SOCL). In this case the communication (working on a PCD2.M170) won't work any more on a PCD3 or a PCD2.M5.
In this situation one of the following workarounds could be applied:

• Instead of assigning the port in MC0 it could be assigned in MC4 (MC4 is usually described as "MC for RS485"). In this mode the UART is managing the RTS autonomously (and therefore there is no more need to set the RTS by the user program). Note that in this case the SOCL commands are to be removed from the program!
• The duration while the RTS is to be set could be calculated beforehand (based on the amount of characters to be sent) and loaded into a timer. While this timer is high, the RTS can be set using the SOCL command.
  Note that this solution is not really a "nice" one and can only work with very low baud rates.

Notes

• All firmware versions of the PCD3xxx and PCD2.M5xxx do treat the TBSY as described in this FAQ.
• The buffer size is depending on the port used:
  PCD3 port 1 and 2: 24 characters
  PCD3 port 0 and 3:  2 characters
  PCD2.M5 port 0 and 1: 24 characters
  PCD2.M5 port 2 and 3:  2 characters
  

This FAQ applies in case the booter of a PCD2.M150 needs to be updated.

How can a booter be upgraded?
There are mainly two ways how the booter of a PCD2.M150 can be upgraded:

• A new firmware chip is burned with an EEPROM burner. In this case a *.hex file is written onto the flash chip in a tool like e.g. GALEP. The *.hex file contains a booter as well as a firmware for the PCD2.M150 (e.g. the firmware 0D3 and the booter 012).
  
• The other method is that the booter is downloaded directly onto the PCD2.M150. In this case some conditions need to be fulfilled: The currently installed booter must support an update of the booter on the present flash chip.

Flash chips used and the support of downloading the booter

• SST 39SF040 firmware flash
  In case the firmware is stored on a flash chip from the manufacturer SST (not used in production any more) the minimal booter version for updating the booter is 010. See procedure below.
  
• AMIC A29040 firmware flash
  In case the firmware is stored on a flash chip from the manufacturer AMIC the minimal booter version for updating the booter is 013. If an older version of the booter is present, the new booter must be written by using an EPROM burner.
  
• ATMEL AT49F040 firmware flash
  The first versions of the PCD2.M150 were delivered with this chip. This chip does not support the update of the firmware or the update of the booter with PG5. A new firmware must be written by using an EPROM burner in every case.

How to find out the currently installed booter version?
The booter version present on your PCD2.M150 (firmware 0D0 or newer) can be read using the online debugger:
Type: D Y 800010                 (Display bYte 800010)
The booter version will be indicated at the end of the line shown.

What can I do if I have a chip listed above but there is a too old booter installed
In this case, please download the hex file version of the firmware used in production from the product section "Programmable Controller" --> "PCD2" --> "Mxxx CPUs" --> "PCD2.M150". These hex files can be written to your chips using a suitable EEPROM burner like Galep.
Once this firmware has been written to your chips, the firmware update can be done from the firmware download tool from PG5 (*.blk files are to be downloaded).

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.

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.

check before Firmware download over a network TCP/IP or Modem:

before you update the PCD- firmware, check that your hardwaresettings and user program is stored in to the flash memory 

There are firmware depending differences in the handling of the Serial-S-Bus communication diagnosic flags TDIA and RDIA. Those flags are refreshed continuously by older FW versions but not by the Saia PCD® COSinus Classic PCD firmware (used for PCD2.M480 and PCD3 controllers).

Symptom
The diagnosic flags do indicate whether there has been a communication error. The flags are directly depending on the diagnostic register RDIA. If the RDIA holds any value not equal to 0, the according diagnostic flag is set.
The state of the diagnostic flags is refreshed every ms by conventional FW versions (used for PCD1, PCD2.M1x0, PCD4, PCD6).
The Saia PCD® COSinus Classic PCD firmware (used for PCD2.M480 and PCD3) does not any more refresh the diagnostic flags cyclically. On this FW, the diagnostic flags are only refreshed on a communication event (such as e.g. a SRXM instruction).

Reason
Basically the diagnositc flags are refreshed by the communication routine of the FW. Conventional FW is polling the communication routine cyclically (every ms).
The Saia PCD® COSinus Classic PCD dosn't call the communication routine cyclically but only on interrupt (e.g. the communication instruction SRXM does generate such an interrupt). This means that the diagnostic flags are only refreshed on a communication event.
The advantage of this method is a minimized CPU load due to the communication task.

Conclusion
This change of the behaviour of the diagnostic flags isn't conflicting with any description or manual. However, there could be some program code that bases on the automatic refres of those flags. In this case the code has to be adapted when intended to use on a PCD running Saia PCD® COSinus Classic PCD FW.
The adaption could be realized in the way that on reset of the RDIA (which has to be done anyways) also the diagnostic flags are reset.

The Profibus DP configurator of PG5 1.3 (older than SP1.3.120) does create configuration files that don't run on a PCD2.M110/120 equipped with FW 080 and older.

Symptom
The Profibus DP Module can't be initialised. The error LED is lit instead and "PROFIBUS FAIL 000" is entered in the History of the PCD. Profibus DB Master and Slave configurations are concerned.

Reason
The reason for this problem is that the Profibus DP configurator (coming along with PG5 1.3.100 or SP1.3.110) will store the configurations in DBX 4. This address isn't available in FW versions up to 080 (since only 4 DBX are available, address 0 included).

Solution

• Either update to the latest official FW for the PCD2

• Or Update to PG5 SP1.3.120 (or higher)

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

There is an Error Led on nearly every PCD system that can indicate a problem on the system. Read this FAQ to learn more about the different reasons for a lit Error LED and how to find the problem causing the lit error LED.

What causes the Error LED to get lit?
There are different reasons for a lit error LED. The most common reasons are listed below:

• A problem while assigning a communication port (e.g. missing communication module or wrong parameters)
• A problem while sending an S-Bus telegram (e.g. missing port assignation or invalid data array or media)
• Invalid mathematical operation (e.g. division by zero or value overflow after a multiplication)
• Index register overflow

How to find the problem in the code/configuration?
One fast way to find the problem is reading the history entries of the PCD. This may be done by using either the Online Configurator or the Online Debugger (type "Display History"). In the History some of the problems are listed explicitely (e.g. IPM not present) for further information regarding the History entries, please refer to the PG5 Help. The chapter "Messages" contains "Halt and History messages".
If only an "Error Flag" is mentioned the next task is to find the program part where the Error status-flag is set. This is to be done by using the Online Debugger:

• Go online with your Fupla- or IL program.
• Open the Online Debugger and type "Restart Cold All CPUs".
• Still in the Online Debugger, type "Run Until Status-flag Error". As soon the Staus-flag "Error" is set, the PCD will be stopped. Therefore the Fupla Editor will jump to the page which actually is processed (only this page is part of the current Fupla file! If the Error isn't caused by this Fupla file, it will jump to any other page which doesn't cause the problem. Have a look at this page and the FBox with the "stop"-box on it and decide whether the problem could have been caused by this FBox!
  If there isn't any FBox that could cause any problems mentioned above, repeat the procedure while beeing online with the next Fupla file of the CPU).
• If you can't find the problem directly in a Fupla file, switch to the Online Debugger again. After having stopped, a line similar to the line written below will be shown:
  *001234  STH       I/O       48                                  A1   Z0     N0     P1    E1     IX      COB2
  This first number of this line indicates on which line of the code the problem happened: the last instruction BEFORE the line shown caused the problem (the error LED is lit after the problem).
• Type "Display Program <line indicated -10> Count 15". Now you can see the instruction that caused the problem: Refer to the IL instruction Set (Online Help of IL Editor SEDIT) in order to figure out what this instruction exactly does.

If a SASI instruction causes the problem, check out the following possible reasons:

• The port is already assigned (have a look at the HW configuration and search for further SASI instructions by typing "Locate Instruction SASI" in the Online Debugger!).
  Hint: Also have an eye on the SASI FBoxes you used as well as on the HMI Settings tab.
• The port doesn't exist
• The SASI text isn't valid
• S-Bus support isn't enabled in the Hardware Settings but an S-Bus assignation was executed. This won't work because in this case the PCD doesn't have an S-Bus address (which is required for S-Bus communication).

If it seems as a mathematical operation caused the error, use the online debugger to run shortly before the problem-causing part of the code by typing "Run Until Instruction-Pointer Equals <instruction line shortly before problem-line>" (note that the instruction line must contain an instruction!). Once reached this line, type "sTep". In the Step-mode, you will see the contents of the PCD medias [brackets].

Remark:
The Error LED is lit in case the Status Flag E (Error status flag is set high) and no XOB 13 is programmed. In case the XOB 13 is programmed, the Error Led won't get lit but this XOB is processed immediately.

We have made good experiences with the GALEP 4, for PCD1 FW together with the adaptor 210841. The local dealer for Switzerland is www.redacom.ch.

Order numbers for empty firmware chips:

PCD1.M1x0: 1x ASN 4 502 7178 (OTP27C4002), one time programmable
PCD1.M137: 1x ASN 4 502 7178 (OTP27C4002), one time programmable
PCD2.M110/M120: 2x ASN 4 502 7126 0 (27C1001-10, EPROM)
PCD2.M127: can be downloaded, refer to the product page on www.sbc-support.ch
PCD2.M150: 2x ASN 4 502 7341 0 (49F040 ,Flash-EPROM)
PCD2.M157: can be downloaded, refer to the product page on www.sbc-support.ch 
PCD2.M170: chip soldered on the main board, the FW can be downloaded with PG5 *
PCD2.M177: can be downloaded, refer to the product page on www.sbc-support.ch
PCD2.M480: chip soldered on the main board, the FW can be downloaded with PG5 *
PCD2.M487: can be downloaded, refer to the product page on www.sbc-support.ch
PCD3.Mxxxx: chip soldered on the main board, the FW can be downloaded with PG5 *

* Procedure to downlaod a firmware:
1) get the appropriate file from product page on the supportsite www.sbc-support.ch
2) open PG5 and go to the online-configurator; go offline
3) open the menu tools, download firmware
4) browse for the firmware file and start the download
5) load the HW configuration and the user program

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

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

Systems introduced before 2003:

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

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

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

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

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

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

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

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.

Or "What is the difference between 0-, $- and #-firmware versions?". PCD firmware for non-Saia PCD® COSinus Systems (PCD1, PCD2.M1x0, PCD4, PCD6 and PCS) are named with 3 letters (e.g. 010, B0W or #31). This FAQ explains the meaning of these version and how to figure out which one is more recent.

The firmware version naming of non-Saia PCD® COSinus systems
In general the 3 letters (abc) are used for the following indications:

• a
  Definition of the kind version this firmware is. The possible versions are the following
  - 0xx versions are "official production versions" (010 is the first official production version)
  - Bxx versions are Beta versions which contain new features compared to the previous production version
  - #xx versions are "customer bug fix versions" of an official production FW version.
  - $xx versions (Pilot version) include new functionalities which are not yet fully tested. Therefore a $-version should only be used in field if the developement gives their ok!
• b
  The second letter defines the main production version (starting with 01x wich stands for first official production version, followed by 02x (where the 02x has important new features compared to the 01x version
• c
  The last letter is incremented for each build of the firmware (best observed for the bug-fix versions; #21 is based on the 020 firmware and contains corrections for the 020 firmware version) 

To figure out which version the base version of a bug fix- or pilot version is, have a look at the second character of the corresponding version (e.g. the "1" of the 013). This character indicates the official production version on which the bug fix or pilot version is based on.

Examples
010    is the official production version
018    is the production bug fix version of 010; no new functions
#19    is a customer bug fix version based on 018 (and therefore also on 010); no new functions
$19    is a pilot version based on 010 with new functions. The bug fixes done for e.g. 019 probably aren't implemented in this version! (the new features will be added to the production firmware versions in 020 or later.

Remark
Early versions of the Saia PCD® COSinus systems (PCD2.M480, PCD3, PCD2.M5) up to 039 were named with this system as well. In order to reduce confusion concerning features of a firmware the new firmware naming a.bb.cc has been applied (see FAQ 100741).

Some history entries introduced in new firmware versions can't be found in the Online Debugger Help nor in the online help of the Online Configurator.

Below you can find recently introduced History entries that can't be found in the Help files of PG5 versions older than PG5 1.3:

Error Messages concerning PCD1.M2, PCD2.M480, PCD2.M5xx0 and PCD3.Mxxx0 systems (SBC-NT)

The IL instruction DSP (display value on PCD7.F530 display) is not supported on Saia PCD® COSinus systems. When downloading it to a Saia PCD® COSinus system, the PCD will not go in RUN and give an error message such as "Invalid instruction" (e.g. a PCD2.M480), "Precompiler error" or "Invalid OPCODE" (on a PCD3.M5xx0 with firmware 1.10.16).

Why is the DSP instruction not supported on Saia PCD® COSinus systems?
Since it isn't allowed or even possibe to mount a PCD7.F530 card on a Saia PCD® COSinus system (e.g. a PCD2.M480, a PCD2.M5xx0, a PCD3 or a PCD1.M2xx0) the instruction for accessing the display of the PCD7.F530 is not supported by the CPU.

Remarks

• The PCD7.F530 can't be mouned on a PCD2.M170 or on a PCD2.M480 because it could cause a short circuit on the internal bus connector placed right under the slot B1.
• If a user program containing a DSP instruction is downloaded the PCD2.M480 won't run the program and the error message "Halt reason: invalid instruction" will be entered in the CPU's History.

Yes it’s possible to connect a PCD directly to the internet, but you have to protect your PCD against unauthorised access or cyber-attacks.

To protect the PCD against unauthorised access or cyber-attacks, it’s imperatively needed to take some protective measures.

Information about protective measures can be found on the support hp

If you need a PCD with cyber security levels SL3+ and based on ANSI ISA 62443 then checkout our PCD3.M6893 (QronoX PCD), this PCD was developed for cybersecure applications.

Information's can be found here.

In April 2011 a new firmware for the PCD2.M487 has been introduced into production. This FAQ lists the main differences of this firmware compared to the previous firmware used in production (1.315)

New features

• Support of PCD7.R400 produced after April 2010
  (with older firmware it is only possible to read but not to written the R400 produced after April 2010, see FAQ 101391)
• Support of PCD2.W525 analogue input/output module

Main corrections

• In some cases inter-character delays on port 6 have been observed
• MPI OPRead telegrams were sometimes not correctly answered during power-up of the PCD
• PCD2.W610 output was not correctly calculated in case SIMATC Format has been configured
• On a PCD2.W745 only the first channel was read correctly
• Fetch/Write over ISO on TCP closed the connection after 10s

The Error LED of the PCD2.M127 does blink in case a PCD2.F7xx module is configured but the communication (Profibus or LON) is not working (e.g. because the module itself or a configured Profibus DP slave is not present).

Remark
The user documentation states that the Error LED can be programmed in the user program; this statement is wrong as the blinking error LED can only be stopped by either avoiding the failed communication or by removing the communication configuration from the project.

In february 2010 a new firmware version for the systems PCD2.M177 and PCD.Smart.M177 has been introduced into production. The reason for this introduction is that a new type of flash is used on the PCD7.R400 memory modules. This new flash memory is only supported by the new firmware 3.123 (and later versions).

When working with PCD systems you will cross the expression "Saia PCD® COSinus" sooner or later. This FAQ explains what "Saia PCD® COSinus system" stands for.

The expression "Saia PCD® COSinus"
In general the expression "Saia PCD® COSinus" stands for PCD systems which are equipped with Freescale (previously Motorola) Coldfire CPU technology. The "non-Saia PCD® COSinus" systems from Saia-Burgess Controls AG are based on Freescale 68k CPU technology (e.g. PCS1, PCD2.M170 etc.).
The Coldfire CPU technology is a new and more performant CPU generation, new development is generally realized on Coldfire CPU (while the 68k CPUs still are available in parallel).
The first PCD system based on the Saia PCD® COSinus technology has been the PCD2.M48x. For this system the whole firmware has been re-written. The firmware of new systems is built up based on the firmware developed for the PCD2.M48x platform (having the same core modules). New firmware functionalities (e.g. Modbus which is implemented in the firmware) are basically designed for the Coldfire CPU technology and thus for Saia PCD® COSinus systems.

Saia PCD® COSinus based systems
The following list contains the main PCD systems which are based on Saia PCD® COSinus technology.

• PCD3.Mxxx
• PCD2.M48x
• PCD2.M5xxx
• PCD7.D4xx
• PCD1.M2xx (currently under development)

Does this mean that all Saia PCD® COSinus systems support the same firmware features?
No! Although the same base modules of the firmware are used, it is depending on the PCD system whether a specific feature is supported or not. For example the http protocol is supported by PCD3 and PCD2.M5xxx systems, but not on PCD2.M48x.

The PCD3 systems equipped with an Ethernet port and the PCD2.M5540 are able to send emails. But sending e-Mails is not only depending on the CPU itself.

The PCD3 systems equipped with an Ethernet port and the PCD2.M554x support SMTP (Simple Mail Transfer Protocol). Sending emails does not only depend on this feature but as well on the ISP (Internet Service Provider), the firewalls and router configurations between PCD and ISP.

The attached checklist with the criterias to verify with your provider and / or your IT support shall help to check whether sending E-Mail is possible.

In order to simplify the interpretation of firmware versions and to avoid confusion regarding implemented features and bug fixes in different firmware versions, a new firmware version format for Saia PCD® COSinus based systems will be introduced.

Arguments for the new format
The new firmware version naming allows a clear and easy comparison between the different versions and their implemented features (PCD type specific) and bug fixes.
Questions like "Why is the Alarming functionality of the PCD3 Web Server implemented in firmware version $31 but not in version 031? - They both do have the same number..." should be past (however, if you're interested in the answer, please refer to FAQ100176)

Format description
The new firmware version name does consist of a major version, a branch version and a minor version separated by a dot (.).
Note that the prefix characters “0”, “$” or “#” are no longer used in this notation.

Concerned systems
The new firmware version format is applied to the systems based on Saia PCD® COSinus firmware (Classic and xx7). These are

• PCD1.M2xxx
• PCD2.M48x
• PCD2.M5xxx
• PCD3.Mxxxx
• PCD7.D4xx (MB Panels)

While the firmware names for the MB Panels and PCD1.M2xxx do have this format from beginning, it was introduced on the PCD3 and PCD2.M480 systems with the firmware version after 03B.

Version flow example
Below an example for a version flow. If e.g. a bug is corrected in the version 1.06.01, also version 1.07.02 and all following 1.06.xx versions do/will have this correction implemented.


Version types

• Released beta- or maintenance versions (equivalent to the current “Bxx” or “#xx” versions).
• Released Production versions (equivalent to the current “0xx” versions): These versions are introduced in the production.
• New function versions (equivalent to the current “$xx” versions).

Compatibility with PG5
The new firmware names are fully supported by PG5 V 1.4.200:

Previous versions of PG5 will only show the first three digits of the firmware version (e.g. “106” instead of “1.06.08”). The full firmware version can always be read by displaying byte F0F0 in the “Online Debugger” (type DYF0F0 ):

Due to a problem of the firmware version 039 the serial PGU connection on the PGU port does not work.

Symptom
It is not possible connecting the PCD2.M480 (with firmware version 039 installed) with serial PGU mode using a PGU cable PCD8.K111.

Reason
A problem of the firmware version 039 causes the serial PGU connection not to work.

Solution
If possible use the (faster) USB port of the PCD for connecting the PCD. In case this is not possible for you, please contact your local sales office and request a firmware that fixes the problem (e.g. 03B). 

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

Yes. With all xx7 series PCD2 controllers, the operating system can be updated via a serial port. PCD3 systems can be updated using the USB port.

PCD2.M1x7 require a PCD7.F120 interface module to do this. With the PCD2.M487, FW updates can take place directly across the PGU port. With the PCD1.M137, FW updates are only possible by changing the PROM. Further information about FW update procedures for whichever controller, and the cable required for connection to the PC's COM port, can be found under www.sbc-support.ch/overview/xx7family.htm  Just click here on the PCD required, then go to the "Firmware" heading and download instructions and the latest operating system.

The output stays low if it is not a valid value.

Problem
The output of a logic operation stays low, even if the condition is true
or
The output to a counter/timer stays 0 even if a value should be transmitted

Reason
If the output accesses a physical address p.ex. O 48, and there is no Digital Output card plugged in this slot, the output value in the program will always stay low.
If the output value for a Timer or Counter is negative p.ex. -1 which is an invalid value for a Timer or Counter the content of the timer or Counter will always stay 0

Solution
Plug a card or map the output to flag instead of a physical address
Write a valid value to the Timer/Counter

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

For connecting a PCD2.C2000 to a PCD2.M5xxx a PCD2.K106 version B or later is required. During the past year, the following modifications of the PCD2.K106 have been realized.

The following hardware versions of the cable PCD2.K106 do (will) exist: 

• Version C (will be delivered as soon as the stock of Version B is sold out)
  For compatibility with the PCD2.C2000 the length has been increased to 900 mm. Features a connector with a 90 degree angle.
• Version B
  Features a 90 degree angle and has a lenght of 700 mm.
• Version A (obsolete)
  Does not feature a 90 degree angle.

This FAQ will be updated as soon as the version B is no longer delivered.

Per example: Some input LED's are on even if the signal is low on the input.

Problem
After connecting some input wires the LED's are in a undefined status. Some or all LED's are on, even if the signal is low on the input.

Reason
In most cases problems like this are wiring problems. Per example L is not connected correctly.

Solution
The "L" has to be connected to the minus in source operation mode (positiv logic) and to the plus in sink operation mode (negativ logic).

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

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

As a replacement, we recommend the usage of BACnet.

Yes, it’s possible to connect up to 16 MP-Bus devices per MP-Bus line and the PCD supports the MP-Bus light protocol.

Belimo has enhanced the functionality of the MP-Bus in that way that, in some conditions, it’s possible to connect up to 16 devices on the same MP-Bus.

The devices which support this feature are named MPL/MPX or/and Belimo MP-Bus light.

SBC has adapted their Belimo PG5 FBox library to support up to 16 devices per MP-Bus line.

On Fupla, on the FBox selector window the FBox which supports the address range 1 to 16 are selectable from the category ‘MP-Bus’, ‘MPX Devices 1- 16’.

This means, that a PCD could handle up to 128 Belimo devices, if on all 8 possible MB-Bus lines of the PCD, only MPX devices would be connected.

MP and MPX Addressing
The 16-address feature was introduced since the library version 2.7.527

Remarks:
1.
The Duplex Driver Fbox for the PCD2.T500 module supports only the MP address range (1-8).
2.
The Single Driver Fbox supports the MP address range (1-8) as well as the MPX range (1-16) by respecting the following rules.

• You can use addresses up to 16 if you have only MPX devices on the MP-Bus.
• You can mix up old MP and new MPX devices as long as all devices are in the address range 1 to 8.
• You can use 2 buses, one for the old MP devices (1-8), One for new MPX devices (1-16)

Consequently:

• If more then 8 (up to 16) devices should be connected on a MP-Bus line, then only MPX devices can be used on this the MP-Bus line.
• You cannot mix up old MP devices with new MPX devices using addresses in range 9 to 16 on the same bus.
• In other words, as long as one old MP device is on the bus the address range is limited to 1-8.
  
  

Yes, it’s possible to connect up to 16 MP-Bus devices per MP-Bus line and the PCD supports the MP-Bus light protocol.

Belimo has enhanced the functionality of the MP-Bus in that way that, in some conditions, it’s possible to connect up to 16 devices on the same MP-Bus.

The devices which support this feature are named MPL/MPX or/and Belimo MP-Bus light.

SBC has adapted the Belimo PG5 FBox library to support up to 16 devices per MP-Bus line.

On Fupla, on the FBox selector window the FBox which supports the address range 1 to 16 are selectable from the category ‘MP-Bus’, ‘MPX Devices 1- 16’.

This means, that a PCD could handle up to 128 Belimo devices, if on all 8 possible MB-Bus lines of the PCD, only MPX devices would be connected.

MP and MPX Addressing
The 16-address feature was introduced since the library version 2.7.527

Remarks:
1.
The Duplex Driver Fbox for the PCD2.T500 module supports only the MP address range (1-8).
2.
The Single Driver Fbox supports the MP address range (1-8) as well as the MPX range (1-16) by respecting the following rules.

• You can use addresses up to 16 if you have only MPX devices on the MP-Bus.
• You can mix up old MP and new MPX devices as long as all devices are in the address range 1 to 8.
• You can use 2 buses, one for the old MP devices (1-8), One for new MPX devices (1-16)

Consequently:

• If more then 8 (up to 16) devices should be connected on a MP-Bus line, then only MPX devices can be used on this the MP-Bus line.
• You cannot mix up old MP devices with new MPX devices using addresses in range 9 to 16 on the same bus.
• In other words, as long as one old MP device is on the bus the address range is limited to 1-8.

Under certain conditions it’s possible that the configuration of the DALI devices with the F-Box ‘Dali Cfg Manger’ doesn’t work correctly.

Definition or changing of the DALI address of the DALI device, setting up the DALI parameters in the DALI device doesn’t work properly, then new values are not stored on the DALI device.

Description of the error:
Under certain conditions it’s possible that the configuration of the DALI devices with the F-Box ‘Dali Cfg Manger’ doesn’t work correctly.
Definition or changing of the DALI address of the DALI device, setting up the DALI parameters in the DALI device doesn’t work properly, then new values are not stored on the DALI device.

This behavior happens, if the transmission of the configuration telegrams from the PCD to the DALI devices takes to long time.
This situation could occur if the cycle time of the application program on the PCD is to long or if the PCD does use need some cycle time for other tasks (like BACnet communication)

To tests if the configuration is written correctly in to the DALI device, just read out the DALI parameters from the device after the writing of the parameters and compare this value with the previously written  value.

Solution:
We have fixed the problem in that way, that we do now handle the configuration telegrams directly in the PCD2.F2610 or PCD3.F261 DALI communication module.

The FW of the F2610/F261 module have to be at least the version 1.03.23.

The DALI configuration F-Box was also adapted to support the new firmware of the F2610/F261 module.
Use at least the ‘Dali-F26x’ Library version $2.7.358 or higher.

Technical reason:
The DALI specification does define for the configuration telegrams which have to be send to the DALI devices, that this configuration telegram have to be send two times to the DALI device.

The time delay between the first and the second configuration telegram has not to be longer then 100ms.

If the delay is > 100ms then the DALI devices does not accept the new configuration and does use the old parameters.

The RS-232 S-Bus communication may doesn't work at all with PCD2.F2xx0 or PCD3.F2xx modules when communicating over converters (like modem or optical converters) to other devices. On PCD2.F2xx0 and PCD3.F2xx with Firmware less or equal V020 the handling of the RTS signal is wrong.

Symptom
Due of a Firmware error on the PCD2.F2xx0 and PCD3.F2xx module (with Firmware of the PCD2.F2xx0/PCD3.F2xx module: less or equal V020) it may be, that the S-Bus communication over converters (like modem or optical converters) to other devices does not work.

The S-Bus communication works fine, if no converters are used in between.
Also other communications protocols then S-Bus like "Mode C, Modbus" works fine on the PCD2.F2xx0 and PCD3.F2xx module (with and without converters in between).

On the print screen below, the signal 1 is RTS and signal 2 is the dataflow.
With PCD3.F121, the RTS signal behaves correctly, with PCD2.F2xx0 or PCD3.F221 not.

Communication with PCD3.F121


Communication with PCD3.F221


Workaround to use the RS-232 S-Bus communication over converters:
For the PCD3:
Instead of using a PCD3.F221, use the PCD3.F121.

For PCD1.M2 or PCD2.M5:
Instead of using a PCD2.F2xx0, use the PCD7.F121S.

Solution
The Firmware version 1.xx.xx of the module PCD2.F2xx0 or PCD3.F2xx will solve this bug with the handling of the RTS signal. Please contact your local SBC Support center.

When reading values from some specific M-Bus devices with the M-Bus modules PCD2/3.F27xx, the M-Bus driver may show the error "Missing value" even though all values are correctly returned by the device.

Symptom
When using the M-Bus modules PCD2/3.F27xx (with the framing protocol), the M-Bus driver may display the error "Missing value" even though all values are correctly returned. The problem concerns only few devices; so far the following concerned devices are known:

• Janitza, electricity counter
• EMU Professional, electricity counter
• L&G Ultraheat 50, heating counter

Reason
This problem occurs because the PCD firmware (older than 1.16.66) looses some bytes if the reply telegrams is longer than 240 bytes (and the framing protocol is used).

Solution
This problem is corrected in the PCD firmware version 1.16.66 and later. This firmware is e.g. contained in the BACnet firmware package available on the Support Site (under "Communication Protocols" --> "BACnet")

The M-Bus communication between the "Hydrometer M-Bus Receiver 868" (alternatively called "MB-Receiver") and the PCD2.F2710 has been analyzed and it was found that the device does not conform to the M-Bus specification (SN EN 13757-2). Therefore it can not be used together with the PCD2/3.F27x(0).

During our analysis it was found that the power consumption variation of the "Hydrometer M-Bus Receiver 868" while receiving data is higher than specified in the M-Bus specification. This leads to the fact that the communication between the F271x and the "Hydrometer M-Bus Receiver 868" receiver is not working.
Note that the manufacturer is explicitly specifying that this device is only to be used with "his" M-Bus master, see screenshot below.

Detailed information
Analyzed Radio Receiver: Hydrometer M-Bus Receiver 868
The device takes the power from the M-Bus communication lines; current consumption is around 20mA (instead of max. 1.5mA). So far, this is no problem as long as the device is counted as ~13x load. But when sending data on the M-Bus lines, the current consumption of this slave changes by more than 10mA, and this change is seen as incoming data on the M-Bus master side.

The M-Bus standard SN EN 13757-2 specifies:
Voltage variation of 1..15V shall not change the bus current by more than Nx3uA/V. N must be specified, values in the range from 1 to 4 are allowed. Max. change with SBC M-Bus master: 12V*4*3uA/V = 144uA.

Conclusion
The "Hydrometer M-Bus Receiver 868" does not comply with M-Bus standard. (and its manufacturer specifies that this Receiver has to be used only with their master devices). Therefore it can be (by chance) that it works with third party master devices. With the F27x modules the functionality is not guaranteed (guaranteed functionality would require a hardware redesign of the F27x to support the special device).

Remark
In Germany the "Hydrometer M-Bus Receiver 868" is distributed by Hydrometer while in Switzerland it is distributed by Techem and in France the same device is distributed by the company Sappel under the name "IZAR".

In order to read data from "CALEC aquameter energy master" devices using the F27x modules (except PCD2.F2700 or PCD3.F270) the M-Bus FBox library 2.6.117 or later is required.

Symptom
When trying to read data from a "CALEC aquametro energy master" device using e.g. a PCD3.F271 and the M-Bus FBox library (older than version 2.6.117) from Engiby a timeout is the result. This is only the case with the aquametro device, other M-Bus devices can be read correctly.

Reason
The Engiby M-Bus FBox library (older than version 2.6.117) does not read correctly from the CALEC device if the framing protocol (used for the modules PCD2.F2710 or a PCD3.F271) is configured. On the other hand data are read correctly if the character mode is configured with an F270(0) (to be selected with "RS 485/F270" as Serial line type in the M-Bus driver FBox).

Solution

• Update your M-Bus library to version 2.6.117 or later (please request the library directly from Engiby)
• If it is not possible updating the FBox library it is also possible accessing the "CALEC aquametro" using a  PCD3.F270 (or a PCD2.F2700) and configure it to use the character mode (see screenshot below) in the FBox "MBus Driver":
  

There is a possibility to update the firmware of a PCD2.F2xxx or PCD3.F2xx, in this FAQ it is explained how to proceed.

In general the procedure is the same like you would update the firmware of a PCD3. Connect the computer via USB to the PLC and start the PG5 2.0 Firmware Downloader. Change the file for the download to the required .bin file and start the download in USB PGU mode.

Problem

When more than one PCD2.F2xxx or PCD3.F2xx is plugged in the PLC there can appear some error messages.

Solution

In this case you have to specify the Slot in which the Module is plugged which you want to download the firmware into. This is made in the Options of the Firmware Downloader “Select SPI Slot…”

When choosing in which Slot you want to download the firmware you can make sure that the right module is updated, if “No Options is selected it will try to download the firmware to the first PCD2.F2xxx or PCD3.F2xx which is found on the I/O Bus.


Remark
The minimal system requirements are:
PG5 2.0.200
PCD Firmware 1.16.48
 
Modules supporting a firmware update:
PCD2.F26xx
PCD2.F27xx
PCD3.F26x
PCD3.F27x

In the M-Bus library for the SBC Energy Meters (which can be installed for PG5 1.4, PG5 2.0 and PG5 2.1) the following modifications have been applied.

Modification in the SBC MBus library 2.7.006 (March 2013)

• Added support for PG5 2.1
• Removed the option "BACnet"
  

Modification in the SBC MBus library 2.6.113 (December 2011)

• Added outputs of the FBox: total active power and total reactive power is now provided

Modification in the SBC MBus library 2.6.104 (July 2011)

• A negative reactive power measured by SBC M-Bus Energy Meters was displayed incorrectly
• Support of the new modules PCD2/3.F271(0), F272(0) and F273(0)
  If you use such a module, please configure the "Serial line" in the driver FBox to "M-Bus/F27xx" and ensure you have the firmware 1.16.52 or later on the PCD.
  With older library version, you don’t have this option and you can only use the modules PCD2/3.F270(0) with the mode "RS485/F270".

• With the M-Bus library 2.6.013 the driver sent M-Bus resets repetitively
• With older versions than 2.6.014 the SBC M-Bus Energy Meters were not always correctly connected.

• There exist two libraries for M-Bus:
  - The "full version" from Engiby
    which supports all the M-Bus Energy meters from SBC, but also from other manufacturers
  - the "SBC version"
    which supports only the M-Bus Energy meters from SBC.
• The "SBC version" is available from the support site;
  for the "Engiby version" please contact Engiby in order to obtain the last version. www.engiby.ch 
• Please do install the "SBC version" or the "Engiby version" but not both in parallel; this could lead to inconsistent file combinations.

Some M-Bus devices (so far only observed on a MBus water counter from the company Allmess / Actris) are very sensitive against inter-character delays.

Symptom
Some M-Bus devices connected to a PCD2.F2xxx or a PCD3.F2xx (or on the ports listed below under "Remark") are not answering to all requests. The same device does work fine when the M-Bus gateway is connected to another port (e.g. on port 0 of the PCD2.M5). 

Reason
The reason for this phenomenon could be that the M-Bus device is very sensitive against inter-character delays in the telegrams.

Solution
In order to avoid the inter-character delays a new feature has been implemented in the firmware of the PCD (the freeze bit, see FAQ 100916). The M-Bus library 2.5.203 from Engiby does work with this mechanism and thus avoids the inter-character delays in the telegrams.

Remark
With firmware 1.10.16 it has been observed that such inter-character delays are present in telegrams sent on the ports listed below even when using the freeze-mode mentioned:

• PCD2.M5xxx: port 2 and port 3
• PCD3.Mxxxx: port 0 and port 3

In order to avoid these inter-character delays, please use firmware 1.10.51 for your PCD2.M5xx0 or PCD3. This firmware can be downloaded from the according product section on the support site www.sbc-support.ch.

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 more than 1 displays of the same type (PCD7.D23x and PCD7.D290) are connected to a RS 485 port (Bus terminal) of a PCDx.F2xx module, the communication doesn't work. Only one of the displays is available, the other one(s) is (are) not accessible!

The ports 100 to 131 available on the PCDx.F2xx modules have different timing properties and are therefore not appropriate for PCD7.D23x and PCD7.D290 in bus terminal topoloy!

Workaround:
Use another RS 485 port (onboard or with F1xx).

The diagnostic flag TBSY of the "Character Mode" (used for sending characters over a serial line) is not handled the same way on a PCD3 compared to "older" systems like e.g. PCD2.M170.

Symptom
If the relevant port is assigned in MC mode, the diagnostic flag TBSY is indicating that the serial port is busy sending characters. This is the case on e.g. a PCD2.M170.
This behaviour is not the same on a PCD2.M5xxx or a PCD3.Mxxxx, especially not when using a PCD3.F121 or a F2xx(x) modules. On a PCD3/PCD2.M5 the TBSY flag is not any more high during the whole time the port is busy. Instead, it is only high a short time at the very beginning of the send task.

Reason
The reason for this difference is a new manner to access the UART of the port. On older systems the characters were directly written to the UART while on the PCD3 a buffer is placed in-between. Instead of indicating the "send-state" of the UART like on older systems, the TBSY represents the state of this buffer (the size can be found at the end of this FAQ) on the PCD3 or the PCD2.M5.

Solution
This difference shouldn't lead to problem is most cases. However, in some applications the state of the TBSY is used to control e.g. the RTS signal of the line (using the instruction SOCL). In this case the communication (working on a PCD2.M170) won't work any more on a PCD3 or a PCD2.M5.
In this situation one of the following workarounds could be applied:

• Instead of assigning the port in MC0 it could be assigned in MC4 (MC4 is usually described as "MC for RS485"). In this mode the UART is managing the RTS autonomously (and therefore there is no more need to set the RTS by the user program). Note that in this case the SOCL commands are to be removed from the program!
• The duration while the RTS is to be set could be calculated beforehand (based on the amount of characters to be sent) and loaded into a timer. While this timer is high, the RTS can be set using the SOCL command.
  Note that this solution is not really a "nice" one and can only work with very low baud rates.

Notes

• All firmware versions of the PCD3xxx and PCD2.M5xxx do treat the TBSY as described in this FAQ.
• The buffer size is depending on the port used:
  PCD3 port 1 and 2: 24 characters
  PCD3 port 0 and 3:  2 characters
  PCD2.M5 port 0 and 1: 24 characters
  PCD2.M5 port 2 and 3:  2 characters
  

Due of an issue on the production it’s possible that PCD3.H112 modules with fabrication date between calendar week 45/2020 and calendar week 06/2021 doesn’t work at all.

Due of an issue on the production it’s possible that PCD3.H112 modules with fabrication date between calendar week 45/2020 and calendar week 06/2021 doesn’t work at all.

The fabrication date is printed on the sticker on the module and would be displayed as 2045 to 2106, marked in the red rectangle on the picture.

Affected modules:

• PCD3.H112 with fabrication date between 2045 and 2106 could be concerned from the issue
  
  
• PCD3.H112 module older than 2045 or newer then 2106 are not concerned
• PCD3.H114, PCD2.H112, PCD2.H114, PCDx.H112Z28 and PCDx.H114Z28 modules are not concerned from this issue

Symptom:

After powering on the PCD3.H112, the red CCO x LED is switched on.

On application level, no input signals from the input terminals Ax, Bx and Cx are recognized and therefore no counting is performed on the application program.

Solution:

The concerned PCD3.H112 modules needs to be replaced.

Please order new PCD3.H112 modules and send back the concerned PCD3.H112 to SBC with RMA as described on the following link: https://sbc-support.com/en/services/repair-service/

In the RMA form, note 'Advance exchange' with the remark 'CRABBMS-163' in the comment.

The affected PCD3.H112 modules will then be credited to you.

The call structure for the FB "Home" from the FB library for the PCD2.H32x modules has been modified between version B2.34 and version $2.36. As result, the programs that were written for (or with) the FB version B2.34 or older need to be adapted in order to run with the current FB version.

Symptom
A project containing a call of the FB "Home" for the PCD2.H32x module which was written for a FB version older than B2.34 can not be built with a recent version of the FB. The error messages on build could e.g. be:

Linking: _H320_B.obj + H320.obj
Lib files: D2H320_B.obl
To: H320_B.pcd Operand errors:
Error 320: H320.gbd: Line 223: Invalid FB parameter: CFB H320.Home: Param 2. See module D2H320_B.src: Line 3570

Error 320: H320.gbd: Line 223: Invalid FB parameter: CFB H320.Home: Param 2. See module D2H320_B.src: Line 4207
...

Reason
Some of the parameters to be passed to the FB Home have been modified. While binary parameters have been expected to be "C Constants" in FB version B2.34 (and earlier versions), the same parameters are expected to be "K constanst" starting with version $2.36 and later versions. The version $2.36 has been distibuted starting in April 2002. 

Solution
In order to be able to build the project, please add the media code "K" to the parameters 2, 3, 6 and 7 of the call for the FB "Home" (see example below). 

CFB  H230.Home     ; Homing H320 module
     K 1           ; Par. 1: Axis Number  (k1->k14)
     K 0           ; Par. 2: Reference search direction(K 0=down;K 1=up)
     K 1           ; Par. 3: Reference leave direction(K 0=down;K 1=up)
     HomeVelMin_1  ; Par. 4: Velocity minimum : 2000
     HomeVelMax_1  ; Par. 5: Velocity maximum : 5000
     K 10          ; Par. 6: Homing timeout : seconds
     K 1           ; Par. 7: Encoder index pulse.(K 0=No;K 1=Yes)

Remark
Please note that the current version of the manual does not describe the content of this FAQ. The online help of the FB (distibuted with PG5) is correct since PG5 1.4.101.

In case of high environment temperatures together with a configuration of very low frequencies, the PCD2.H210 or the PCD3.H210 could generate an incorrect amount of output pulses.

Symptom
If the module is exposed to high environment temperatures and a very low frequency range (9.5 – 2431 Hz) is configured, it may happen that the module does generate too few output pulses. In this situation 1 to 4 pulses per revolution can be "forgotten".

Reason
This phenomenon is caused by a timing problem of the FPGA programmation.

Solution
The FPGA version HD7 (introduced into production in February 2007) does correct this timing problem. In case you are concerned by this problem, please contact your local representative and ask for a new version of the FPGA (version HD7). This FPGA is mounted on the module (the version of the FPGA is indicated on a round sticker on the FPGA) and can be replaced easily.

There has been a bug in the FPGA versions older than HD6 that caused the FB Home not to work if a limit switch was active on power up of the PCD.

Symptom
The FB "Home" for the PCD2.H210 or for the PCD3.H210 does not work if the limit switches are enabled (in the FB "Init") and if a limit switch was active on power up of the PCD.

Reason
This behaviour is caused by a bug in the FPGA (Field-Programmable Gate Array) version HD5 and older. The FPGA version of your H210 is indicated on a small round sticker on the FPGA (a chip on a socket).

Solution
The problem is fixed in version HD6 and all later versions. If you are concerned by this problem, please contact your local SBC representative and request the actual FPGA version.  

The homing FB of the PCD2.H31x and PCD3.H31x are designed for interpreting limit switches of the axis. However, it is possible working around the limit switches for the homing.

How can the FB home be used without evaluating the limit switches?

In order not to evaluate the limit switches, the corresponding flags can be set high constantly. This is possible because the state of the input switches is passed to the FB as flags and not directly as inputs.

The code above is to be introduced before the call of the homing FB (instead of the mapping of the connected input switches to the flags fLSx_x shown in the example of the manual).

Note
The evaluation and actions to be taken in normal operation (not during the homing) are to be programmed by the user!

When using both axes of the PCD2.H325 or PCD2.H327 modules together with SSI encoders, it is absolutely necessary to use FB Version 2.42 or higher.

Symptom
If both axes of a PCD2.H325 or PCD2.327 are used together with SSI absolut value encoders, only the axis which was initialized as last will work. On the other axis, the SSI driver will not work until the next initialisation (wich causes the SSI driver of the other axis not to work any more).

Reason
The SSI driver of the module is multiplexed. In FB versions older that version $2.41, this multiplexing isn't implemented correctly.

Solution
Upgrade the FBs used in your project to V2.42. This version is installed automatically during the installation of PG5 SP1.3.120.

The PCD2.H322 and PCD2.H327 are slave modules. Nonetheless the second axis can be used as master.

In general there are two different types of the PCD2.H32x modules:

• The PCD2.H320 and PCD2.H325 are designed to control 2 axes (independently or one depending of the other)

• The PCD2.H322 and PCD2.H327 are designed as slave modules. They can be used depending of an external axis (connected to the first axis as synchronisation input) in electronical gearing mode.
  However, the second axis of a slave module can also be used independently.

The differences between a "normal" H32x module and a slave module mainly are the following:

• The axis 1 of a slave module is not equipped with an output and therefore can not be used to control a motor/driver system.

• The input impedance of the axis 1 is lower than the one of the second axis. This allows to connect several slave module to one master encoder.

There is no restriction for the use of the second axis. This axis is to be programmed exactly as an axis of a PCD2.H320. It therefore can be used in any profile mode.

The value returned on the command RdIndexRg (Read Index Register) of the FB Exec is depending on the major version of the FB's.

While old FB's versions returned the value divided by the machines mechanical factor, the recent FB versions don't apply this division any more.

Symptom
The value returned by the FB Exec called with the command code RdIndexRg (Read Index Register) is not the same as it was with the old FB verison.

Reason
In the new FB versions (from V10.01 on), the read value of the index register isn't divided by the mechanical factor. This was the case in the old FB version (V2.1). (Therefore the result was returned in user units in the old FB's)

Workaround if same behaviour is required
The attached example code can be used in order to convert the read value (Index impulses) into user units.

Note
Note that in this case this (multiplied) index register (not to be confused with the PCD's index register) cannot be used as error check as described in the manual.

A program that handles H-modules does most likely include FBs (that are provided together with the PG5 Contols Suite). If a project was created with an older version of the programming tool, also the FB's provided with the older programming software were used. This may cause problems because of incompatibilities of the FB calls.

To get around of this problem it is recommended to copy the used FBs directly into the CPU directory of the concerned project. This way the use of the correct FB version is guaranteed.

If in a file the directive "$INCLUDE filename.ext" is recognised, PG5 will first search in the CPU directory itself and if the specified file isn't present there, the default FB directory will be searched.
The default FB directory (PG5 wide) is defined in the "Directories" of the "Options..." in the PG5 Project Manager menu "Tools".
A further way of specifying the FB directory (CPU wide) is using the "Directories" tab of the CPU Settings (requires the checkbox "Use Override Libraries" to be checked). In this case, the PG5 wide directory specification doesn't take effect any more.

However, since the Override Libraries might have to be adjusted if the project is transfered to anoder PC (eg. a Laptop) or the whole FB's provided by a newer version of PG5 has to be downgraded if a project is imported to a newer PG5 version, the it is the easyest and most secure way if the FB's are always directly stored in the project itself.

In the FPGA version HC3 of the PCD2.H110 there is a small bug: The LEDs for the CCO (Counter Controlled Output) and TCO (Timer Controlled Output) aren't working. However, CCO and TCO are working correctly, only the LEDs are affected.

The bug is corrected in FPGA version HC4.

It isn't possilbe to proceed a second homing after the first attempt faild (e.g. due to a timeout) on the PCD2.H32x modules. What is the reason and how do I get the servo running again?

This behaviour of the PCD2.H32x FB library is implemented for security reasons. During the homing several FB internal flags are set/reset (e.g. a flag indicating that the limit swich 1 was found and therefore the moving direction was changed). On a timeout those flags aren't reset and therefore it was very dangerous to proceed with the homing without having initialized those flags again.

The FB Init will reset all those flags. Therfore it is sufficient to call the FB Init once again for the concerned axis in order to be able to home the relevant axis.

In the manual of the PCD2.H110 you can find an example of automatic period measurement where the XOB 20 is used for reading the measurement continuously. This example doesn't work on a PCD2.M480 due to it's input filter of the interrupt input INx that is connected to the TCO signal of the PCD2.H110.

Since the signal of the output of the PCD2.H110 in measuring mode "perjod-automatic" is only high for 1.6 µs it is very hard to detect it. As the interrupt input is optimized for recognising signals with 1 kHz (50/50 % duration of high/low states) the duration of 1.6 µs is too short to recognise this TCO signal.

As workaround it is suggested configuring the TCO output in mode "static-normal". As this isn't possible in automatic measuring mode, the measuring mode has to be changed to "period-manual".
To achieve a continious measurement you'll have to start a new measurement in the XOB20 (after reading the measured value).

There is no problem detecting the TCO output as long the module doesn't work in automatic measurement mode since in this cases the TCO is high for more than 1.6 µs.

It is absolutely necessary to enable the motor driver after the initialisation of an H3xx. Otherwise the motor will move unintendedly and uncontrolled.

The cause is that the D/A converter always will give out -10 Volts. As long as the module isn't properly initialised this signal will be given out.

The CPLD version < HQ4 of the PCD2.H31x (HW version ≥ B) is not compatible with the I/O bus of the PCD2.M170 and the PCD2.M480. The CPLD of the modules has to be updated in Murten in order to use the H31x module on a PCD2.M170 or a PCD2.M480.

To figure out what CPLD version is loaded on a PCD2.M31x module just have a look at the round sticker on the chip next to the blue I/O bus connector of the module.
In case the version is HQ1, HQ2 or HQ3 and the hardware version is B (-->print index D) or newer, you'll have to send the module to Murten for updating the H31x.

In case you don't want to use the module on a PCD mentioned above there is no need for a update of the CPLD.

After an emergency stop the power of the driver must be switched off! You also have to stop the motion from the axis module H31x. This FAQ entry points out two ways to do that.

After an emergency stop, the power of the driver must be switched off!
You also have to stop the motion from the axis module H31x.

First way:
set high the parameter 8 in the FB init in order to stop the motion in case of exceeding position tolerance.

Second way:
Connect the emergency stop to a digital input and execute the command "StopUrg".

The Flag "Ondest_x" indicates that the position of the integrator has been reached (theoretical position). It does not mean the actual position is reached.

Ondest_x --> Theoretical position - position error

The "real" position at the time the Ondest_x flag is set is actually the Theoretical position minus the Position error

- To reduce the position error, you have to adjust the PID parameters.
- You have the possibility to select a breakpoint for a selected position (same value as setpoint position). In that case you have to execute the command "LdBrkPtAbs" or "LdBrkPtRel". When the breakpoint is reached, the flag "fBrkPt_x" becomes high.

It could happen that the position of linear encoders with high resolutions aren't read properly by the PCD2.H311 with hardware version older than A2.

With HW version < A2 of the PCD2.H310 it could happen that the Index position isn't captured properly.

It is possible to set a reference position zero at any point with the following command:

This problem is fixed. Please download the latest version (2.02 or newer) from PCD-Support Website (www.sbc-support.ch).

This problem is fixed. Please download the latest version (2.02 or newer) from PCD-Support Website (www.sbc-support.ch).

When the PCD2 is switched off right after the function ‘Set Zero’ (FB

SetZero), the module PCD2.H150 reads bad value at the next power ON of

the PCD2. Why?

To prevent dublicate symbol names all symbol names related to H Module FB's are merged to a group. As a result this group name has to be added to every FB related symbol. This either can be done by adding the group name directly (<groupname>.<symbolname>) or by using the directive set $GROUP <groupname>/ $ENDGROUP.

Between the directive set $GROUP / $ENDGROUP in front of every symbol  is added. 

In a graftec structure (SB) these directives have to be set before the first and after the last symbol defined in the *.equ file of the corresponding FB.

When modifying the user program, the $ENDGROUP can be by accident moved and is not set in the last step or transition anymore. As a result, symbols used after the $ENDGROUP are no longer recognised and the user program doesn't work any more.

How to solve this problem:

Some of the parameters of the FB's for programming the H-Modules are defined as registers that have to be loaded before the call of the FB.

No. This cable is not designed for connecting a PCD2.Cxxx extension housing.

Connecting a PCD2.Cxxx can damage the involved hardware.

It is only possible to determine whether the PCD's circuit board is fitted with a Swissbit micro-SD memory card by visual inspection.

The attached document describes how to know whether the circuit board of the PCD is fitted with a Swissbit micro-SD memory card.

The attached document describes how to proceed if you want to copy csv-Files (e.g., from HDLog) and Webeditorproject files which are stored on the Intflash of a PCD.

This could be useful if you are replacing an internal micro-SD memory card which is used on the circuit board of the PCD and you want to re-use the files stored on the old micro-SD memory card.

Newer PCD types and newer PCD7.D4xx devices have micro-SD memory card (uSD) on the PCB (printed circuit boards)

The following data’s are stored on the this uSD card on the PCD’s PCB:

• Firmware for the PCD
• Device configurator settings (PG5)
• Application program done with PG5
• Webeditor 8 project (PG5)
• DATA (e.g HDLog) created by the application program in runtime
• Setup, Calibration (PCD7.D443, PCD7.D450, PCD.D470)
• Program Backup on internal Flash

Yes it’s possible to connect a PCD directly to the internet, but you have to protect your PCD against unauthorised access or cyber-attacks.

To protect the PCD against unauthorised access or cyber-attacks, it’s imperatively needed to take some protective measures.

Information about protective measures can be found on the support hp

If you need a PCD with cyber security levels SL3+ and based on ANSI ISA 62443 then checkout our PCD3.M6893 (QronoX PCD), this PCD was developed for cybersecure applications.

Information's can be found here.

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.

Due to a production error it's possible that PCD2.M5540 which have been produced in 2020 may contain a wrong production date with year 2000 and calendar week 0.

This wrong production date leads to an error message being entered in the PCD history:
'FABINFO CRC FAIL'

and in the PG5 Online configurator hardware info and in the diagnostic file the warning:
'Fab. Date (year/week): 2000/00; BAD PROD INFO CHECKSUM'
is displayed.

Error description:

This wrong production date leads to an error message being entered in the PCD history and also in the hardware info of the PG5 Online configurator the warning is displayed.

However, the PCD2.M5540 works perfectly.

I.e. the functionality of the PCD2.M5540 and the user program which is processed on the PCD2.M5540 are in no way affected by this warning.

Information shown in PG5 online configurator, Hardware Info...

Information shown on PCD's history

Solution:

To fix the issue, load the attached program on the affected PCD2.M5540 and set PCD2.M5540 in Run mode.

The program will set the manufacturing date to the year 2020, calendar week 60 and store the information retentively in the uEprom of the PCD2.M5540.

Calendar week 60 was used to recognize that the fabrication date was modified using this PG5 program.

After switching an off and on of the 24VDC the warning
'Fab. Date (year/week): 2000/00; BAD PROD INFO CHECKSUM'
is no longer displayed and the fabrication date year 2020, calendar week 60 is displayed.

The program only needs to be run 1 time on the PCD2.M5540.

It is not necessary to integrate the program into your application program.

Then load your application program into the PCD.

Yes, it’s possible to suppress alarm notifications on BACnet by controlling the communication.
This is an official BACnet mechanism and available with BACnet firmware from 1.24.41 (or newer) and since PG5 2.1.420.

To suppress the alarms it’s necessary to modify the BACnet communication mode of the device as described below.

In general, the communication of the BACnet device is controlled. There are 3 options:

• (0) Standard communication (default).
  All requests will be answered and device will also send COV, Alarm or Event-notifications if necessary
• (1) No communication.
  The device will not answer to any request and does not send any COV, Alarm or Event-notifications.
• (2) Reduced communication. The device will answer all requests, but does not send any COV, Alarm or Event-notifications.
  This mode is usually selected if device is under maintenance and alarm notifications should be suppressed.

To control the communication mode as described above, 1 additional register must be defined and set to the corresponding value. A 2^nd register can be used to get the current communication status.

In the example below, a “ComState” and “ComDisable”  register has been defined. The “ComDisable” has to be controlled by application, e,g. via a maintenance switch at the cabinet or a software switch.

The “ComStatus” will show the actual communication status and is a read only.

Finally those 2 register have to be mapped within BACnet Configurator into Device object, property “Communication Status” and “Communication Disable”:

Good to know: DDC Suite 2.7 has implemented this mechanism into BACnet Device FBox for easier use.

If this two new items are used with a BACnet FW < 1.24.41 then BACnet does not start

This FAQ explains under which circumstances, which texts are writeable/editable during runtime.

Non-Saia PCD® COSinus Systems (PCD1.M1xx, PCD2.M1xx)
 
With Flash or EPROM Memory plugged
-          Texts < 4000 are not writeable in runtime
-          Texts >= 4000 are writeable in runtime

 With RAM Memory plugged
-          Texts < 4000 are writeable in runtime but PG5 recognizes if one of these texts has changed*
-          Texts >= 4000 are writeable in runtime


Saia PCD® COSinus-Systems
 
PCD3.Mxxx0 and PCD2.M5xx0
-          Texts < 4000 are writeable in runtime but PG5 recognizes if one of these texts has changed*
-          Texts >= 4000 are writeable in runtime
 
PCD3.Mxx60 and PCD1.M2xx0
-          Texts are configurable in the Build Options, define First Writeable Text.




*If one of these texts have changed, PG5 will give a message when you want to go online with PG5 indicating that the 
 program is not the same. Also these texts will be overwritten when the program is downloaded again. 

It is correct that the indication of a low battery will appears earlier due to more accurate prediction on a new Saia PCD® COSinus system than before on a PCD2/1.M1xx.

There are two main reasons to explain this fact:
 
- The supervision function was improved
The new battery supervision function sets the battery under a very small load to predict the end of battery capacity. In term of battery capacity, this additional load is negligible, but allows the system to warn before the battery is really empty. That gives enough time to exchange the battery and preventing memory lost. This is not the case on the previous generation, where only the voltage was supervised.
 
- There is more memory to support
The recent systems have much larger memory; the resulting standby current to be supplied from the Battery increased short the time duration.
 
Summary of working principle with the Lithium Battery
System with passive battery supervision applied on the following PCD’s:
PCD1.M130, PCD1.M135, PCD2.M110, PCD2.M120 and PCD2.M150
The voltage of the battery is supervised.
SBC advise to change the battery all 1 - 3 years.

System with active battery supervision since 2001 applied on the following PCD’s:
PCD1.M2xxx, PCD2.M170, PCD2.M480, PCD2.M5xxx, and PCD3.Mxxxx 
If the 24VDC power is switched on, then the voltage of the battery is measured during short time all 12 seconds where the battery is submitted to a small discharge.
This allows to warn the application program before the capacity of the battery reach its end.
We estimate that in this case the battery has still two days of reserve capacity for the changing of the battery.
In most recent PCD's the battery change can be done from end-user keeping the 24VDC power supply of the PCD switched ON.
If during the battery change, the 24VDC power supply of the PCD remains switched ON then there is no lost of the SRAM content (means that the PCD medias does retain there values)

A lost of the SRAM content (PCD medias like registers, flags and the application program [application program only if there is no application program stored in the Flash memory] does occurs only if the 24VDC power supply is switch off during the battery change.

The specifications in the manual concerning the typical life time of a Renata battery is still correct (1-3 years).

Today, on April 2013 we are able to give more precise lifetime expectancy for the battery for PCD’s produced since July 2012:

However SBC advices to preventable change of the Lithium battery all 5 years

Note that these values are set conservatively; longer lifetime of the battery can be achieved in the practice.

For PCD’s produced before July 2012, above mentioned times could be shorted by 20% due to larger SRam standby current.

The value of standby current is verified on each device during the production.

Under some special circumstances it happend on very few installations that the analogue modem did not answer anymore to incoming calls.

Problem
An analogue modem PCD2.T814, PCS1.T814 or Q.M716-KS1 does not always answer to incoming calls.

Reason
Under special circumstances and in relation to a bad telephone line this could happen due to a problem in the firmware of the modem. Only very few applications where concerned by this problem.

Solution
A new firmware was introduced into production. There is no need for replacing successfully working modems. Modems equipped with the new firmware do have the following firmware and hardware version (available from stock since October 2008):

Problem:
In the Belimo MP-Bus TI 26/342 on page 10 the following sentence is still in the manual:

Caution! When using BELIMO VAV regulators, passive external sensors cannot be integrated!

This is not valid anymore. passive sensors can be integrated. If there is a new release of the manual this will be corrected.

It was not possible before the MP-Bus library 2.5.300 which was distributed with PG5 1.4.300.

Problem
Since the new PCD3.F2xx modules where developped it was possible to have up to 8 MP-Bus Masters in a project. With the old MP-Bus Belimo library it was not possible to have more than one master in a Fupla file.

Solution
With the new MP-Bus library >=2.5.300 it is now possible to have several MP-Bus Masters in one project. The master now have a name "Channel" and the differnet F-Boxes refer to this "Channel".

Restriction
If an old project is converted to the Belimo MP Bus Version 2.5.300 / 2.5.301 it could be, that compiling is not possible anymore due to a conflict. In this case install the version 2.5.302 or higher (FAQ 100 957).

There are error messages displayed for each old FBox that it should be replaced.

Problem
After installing the new version of the Belimo library which allows to have more than one MP-Bus Master in a Fupla file, it is not possible anymore to build the old projects.

Reason
The MP-Bus Belimo library 2.5.300 and 2.5.301 had an incompatibility with older MP-Bus Versions. The library 2.5.300 was distributed with PG5 1.4.300.

Solution
Please update your MP-Bus FBox library version to version 2.5.302 or higher. The latest version of the FBox library can be downloaded from the support site in the section "Product information" --> "Software" --> "PG5" --> "FBox libraries".

In the time between October 2007 and May 2008, Saia-Burgess Controls AG has delivered few modems of the type PCD2.T814 which aren't functional due to an incorrectly plugged cable.

Symptom
A internal modem (Type PCD2.T814) which has been delivered in the time period between October 2007 and May 2008 does not work at all.

Reason
Unfortunately few modems (3 cases known so far) have been delivered with an incorrectly plugged flat cable (see picture below). Due to this incorrectly mounted cable, the modem does not work at all (and the modem could also have been damaged; therefore it may be that the modem does not work even if the cable is plugged in again in the correct way).

Red indication: Incorrectly plugged cable
Green indication: Correctly plugged cable

Solution
In case you have received a modem where the cable is plugged incorrectly, please return this modem to your local Saia Burgess Sales Office with the remark "FB-CS-08-003".

There is a problem in the Belimo library distributed togehter with PG5 1.4.200.

Symptom
All MP-Bus F-Boxes are green but no values are beeing transmitted.

Reason
There is a problem in the Belimo library 2.5.140 which is installed together PG5 1.4.200

Solution
A correction for this problem has been implemented in the MP Bus library version 2.5.142. The easyest way for resolving the problem is updating to PG5 1.4.300 or higher (the latest PG5 version is available on the supportsite www.sbc-support.ch in the section "Product info" --> "Software" --> "PG5").

The choosen F-Box option for passive sensor PT 1000 doesn't work properly

Problem
The option for passive sensor PT1000 is not working correctly

Possible reasons
-No sensor is connected
-The sensor is wrong wired.
-Special reason: The F-Box version V 2.5.100 is in use. With this F-Box version the “passive sensor option” will not work! An update to version 2.5.121 or higher is necessary.

The same application was working properly with PCD2.T813 before.

Problem
When sending a pager message the "Modem Driver" F-Box turns red imediately. Or the Call Pager F-Box turns red and get's an error after sending the message

Reason
The modem PCD2.T814 and M716-KS1 with firmware <2.04 is not supporting Bit-Parity-Stop 7-E-1 which is needed on some pager servers.

Solution
Another Bit-Parity-Stop has to be used. Per example 8-N-1if this is as well supported on the pager server. Otherwise if 7-E-1 is needed the modem must have a firmware >=2.04.

Since November 05 all PCS1 with analog and ISDN modem are deliverd with T814 and T851 modem. The PCS1 needs to have modification 4 in order to use those new modems.

    In case of older PCS1 (< modif. 4) which need to be equipped now with a modem,
or which are already equipped with an older modem (T813 or T850) and need to be repaired,  
they must  be send to Murten for modification.

Only PCS1 modification 4 can receive new modem T814 / T851!

The first serie of PCD2.T814 modems with baseprint firmware < V1.09 have a problem when using the modem in the Hardware Settings for programming, for sending SMS and for DTMF at the same time.

Problem
After the modem has once tried to send an SMS it is no more possible to go online over the modem.

Reason
There was a bug in the firmware. The problem only appears when using all three functions in the same project.

Solution
New modems will have the corrected firmware V 1.09 or higher. If you have a modem the following workaround is recommended: All baudrates has to be 9600 baud. Please note, that you have to set the "Transmission Speed" in the "Call SMS" F-Box to 9600 Baud too. Default is 2400 Baud and will cause problems.

In the fourth quarter of 2005 a new modem type PCD2.T814 has been introduced. The difference between the PCD2.T813 and the PCD2.T814 is only hardware related. The functionalities and compatibilities remain the same.

Reason for the introduction of the PCD2.T814 and the PCD2.T851
The new type has been intoduced due to availability problems of the modem print mounted on the PCD2.T813.

Further information
In order to be able to manage a compatibility of the new modem print, a special "interpreter" has been introduced. This interpreter is placed between the modem and the interface to the PCD and "translates" strings that wouldn't be known to the modem (and vice-versa).

The modem library offers the possibility to use the modem for an online connection and alternatively for giving commands using DTMF. In this case the PCD has to decide whether the incoming call is a data call (for an online connection) or a voice call (for the DTMF driver). The switching between those call types may cause some problems, depending on the quality of the signal that is transmitted (sent) by the calling modem.

Symptom
If the modem default standby mode in the Modem 14 FBox is set to "DTMF+PGU", no online connection is possible any more. Instead, the PCD does activate the DTMF driver also when trying to go online with PG5.

Reason
In versions of the modem library delivered before PG5 1.3.120, the decision for the switching was made based on a carrier frequency transmitted by the modem.
This method seems to be depending on varoius influences such as the level of the carrier frequency of both of the involved modems, line quality etc.

Solution
Since the old method failed in some cases, a new option was introduced:
Instead of configuring the default modem mode for a voice call (and then listening for a data carrier frequency), the default mode can be switched to data mode (and after a timeout, the mode will be switched to voice for the dtmf driver).
This new mode is activated by entering an "Additional Build Option" in the Software settings of the CPU in the PG5 project:

The string to be entered is:
/D._MODEM._OPTION._DEFAULTDATA0

In this example the modem channel is Port 0 (DEFAULTDATA0). If an other channel is used the string has to be adapted. For Port 1 (DEFAULTDATA1)

Important: Since the PGU Mode is now forced, the modem will automaticaly make a PGU connection after 10sec. if the DTMF Mode is not forced. To force the DTMF mode enter *# while this 10sec. Otherwise no DTMF commandes are accepted.

It is necessary to load an MSN (multi subscriber number) to the ISDN modem, if differend devices are connected on the same line.

If you want that the PCD2.T813 ring 5 times before it answers the init string has to be modified in the hardware setting and in the Modmbase.dat also if the modem library is used.

In the HW setting modify the INIT string so:

AT&F1%C0&K0\\N0S25=100S0=5\r    (5 replace 2)

In the Modmbase.dat file (C:\Program Files\SAIA-Burgess\PG5 1_2\Libs\App\modmbase.dat) do the same modification for T813:

$elseif _MODMTYPE=201
;;[Test 1] T813 model 144
;;===========================================
TEXT _MODMREST  "ATZ<CR>"       ;;reset string
TEXT _MODMINIT  ""              ;;initialisation string
  "AT&F1%C0&K0S25=100S91=9<CR>" ;;
TEXT _MODMINIT1 ""  ;;Optional Init string 1
TEXT _MODMINIT2 ""  ;;Optional Init string 2
TEXT _MODMINIT3 ""  ;;Optional Init string 3
TEXT _MODMINIT4 ""  ;;Optional Init string 4
TEXT _MODMINIT5 ""  ;;Optional Init string 5
TEXT _MODMATCR "AT<CR>" ;;Dummy AT
TEXT _MODMPREF  "ATDT"          ;;dial prefix
TEXT _MODMSUFF  "<CR>"          ;;dial suffix
TEXT _MODMSUFS "<CR>"  ;;dial suffix for phone call
TEXT _MODMINIP ""  ;;Init for phone call
TEXT _MODMHGUP  "ATH<CR>"       ;;hang up commande
TEXT _MODMCMND  "+++"           ;;command string
TEXT _MODMAUTO  "ATS0=5<CR>"    ;;auto-answer mode (5 replace 2)
etc...

Of course the modem type modified in the modmbase.dat is to be selected in the modem driver FBox ( for this example the modem type "Test 1")

Note: It isn't possible to let the modem PCD2.T813 ring more than 5 times, 5 is the maximum value!
The reason for this restriction is the standard TBR21 valid for all european countries.

The AT command set of the PCD2.T813 features a way for getting information regarding the line quality. Also the transmission rate last used as well as the fastes used transmission rate will be shown.

The AT command for reading these information is:

AT&V1

The tricky part for reading these information is that this data isn't stored in FLASH. This means that after a power down/power up the data will be lost.

Procudure for reading the line quality information
As conclusion the user of a PCD2.T813 is urged to use a PCD7.F120 which then will be connected to the modem.
The lines between the terminals of the PCD7.F120 and the modem terminals should be connected with a D-SUB connecter that easily can be unplugged (in order to connect a PC with e.g. hyper terminal to the modem).
Once this installation is created, the modem can be run as usual and a modem connection can be established to it. After this connection is terminated, the connector between modem and PCD may be unplugged and the PC is to be connected to the modem (make sure the PCD isn't unplugged because this would lead to data loss).
E.g. the hyperterminal may be used in order to transmit the command mentioned above and the data will be sent to the hyper terminal.

There is a security function that causes a modem to be "blacklisted". This happens after twelve call attempts in a row weren't successful.

Once a modem is "blacklisted" no further calls may be initiated until the blacklist is reset by a power down/power up.

The blacklist function is a limitation of unanswered calls, and the message BLACKLISTED is sent by the modem after the thirteenth call without any success (none of these calls was answered). After this further calls to any number are suppressed as long as the blacklist is not cleared.

Since disabling the blacklist function isn't allowed by law (unless the modem is used a privat network), the blacklisting feature can not be disabled on the currently distributed modems (PCD2.T814, PCD2.T851, Q.M716-KS1, Q.T726-RS1 and Q.G736-AS2)

With analogue, ISDN and GSM modems and telephones quite a lot of combinations are possible, but what functions are supported? The following table gives you the necessary information:

1) some ISDN telephones have to be put in DTMF mode when the connection is established

2) only if the ISDN modem supports analogue protocols (rather rare)

3) theoretically possible, but not tested

There are two things to check:

• the PBX (Private Branch Exchange) can be configured in a way so it blocks modem connections on this extension, ask to check this configuration.

• the T850 can be configured to answer to a specific MSN (Multiple subscriber number) only. If a T850 is brand new it answers to all modem calls, but if the modem has been used in another application where an MSN has been defined, this can cause problems. PG5: the most elegant way to configure the MSN is using the relevant FBox of the Modem Library

There is a "power down reset" that can be activated in the Modem 14 Driver FBox. This hardware reset will the modem power down and up again.

For PCD2.T813, PCD2.T813Z42, PCD2.T850 and internal analogue and ISDN modems only (GSM Modems do not support the hardware reset):

In order to reset an internal modem the hardware reset output of the "Modem 14" FBox can be used.

In the adjust window for the parameter "Hardware reset option" choose "always". Additionally the Hardware Reset Output "HwR" of the FBox has to be connected to the corresponding output address written in the right side of the Fupla window (output address field).

The hardware reset output of PCD controllers is (base address of the PCD2.T8xx) +3, in the PCS1 the hardware reset is available on O 99.

Examples:

PCD2.M170 module base address = 16 hardware reset = O 19
PCD2.M120/150 module base address = 64 hardware reset = O 67
PCS1 hardware reset = O 99

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.

Since the FTP server of the PCD has been developped, SBC suggested to use the freeware FTP Client Filezilla to access the PLC Filesystem.

Lately and with newest FileZilla versions we received several reports that there are difficulties with the FTP Client FileZilla (e.g. that the IMasterSaia.jar was not completely downloaded).

Symptoms
There were problems while downloading several files in parallel to the PLC Filesystem. And sometimes it wasn't even possible to download the IMaster.jar file, because there was infinite repetition of downloading from side of the FTP Client Filezilla. After a restart of the PC, FileZilla worked again properly.

Reason
Unfortunatley these phenomenons were often not reproducible in Murten and appear to be random. Therefore it is very difficult to pinpoint the reason for the problems.

Conclusion
As these problems are only concerning few installations we do not intend to "forbid" the usage of the the FTP Client FileZilla together with the PCD FTP Server. However, in case you are faced with the above mentioned problems we suggest to use another the FTP Client. One client with which we made very good experiences during the past yars is the one coming with the shareware "Total Commander" (shareware). "Total Commander" also exists as portable version.

In some cases increasing the timeout in Filezilla to 60 seconds helps.

Update 03.07.2013
On FileZilla there is an option to limit the transfer speed.
Switching on this speed limitation does allow loading without problems files to the PCD.

To enable the speed limit, click on the tachometer symbol (on the bottom right corner of the FileZilla window)


On the next window do select the option "Enable speed limits" and do set the values to 100/20 KiB/s.

When using a memory module with a file system the available memory for the files is smaller than the specified size of the module. This FAQ explains what for the "not usable" memory is used.

Symptom
When storing files on a file system from a memory module or to a file system on the PCD itself (e.g. the INTFLASH from a PCD3 Compact) the total size of all files which can be stored is smaller than the specified size of the memory.
If e.g. a memory is defined with 1 MByte, it is possible that I can only store 866 kByte to the file system on this memory module.

Reason
The reasons for this phenomenon are the following:

• Memory management
  Some of the memory is used for the management of the file system itself (for that the firmware "knows" where to find the files which are stored).
  Example: On a "blue" memory module such as the PCD7.R550, R551 or R561, the size for this internal ornanization data is 64 kByte.
• Memory reserved for compress task
  Aditionally there is one sector of the memory reserved for the compressing task. During this task, the PCD needs to copy data from the sectors to be compressed to this reserved memory.
  Example: On a "blue memory module" such as the PCD7.R550, R551 or R561, the size of this sector used for compressing the flash is 64 kByte
• Every file needs at least one "block" of memory
  The files located in the memory are stored in blocks, and a block can only contain data from one file. This means that as soon as a file is generated (even if the size is just 8 bytes), the whole block can not be re-used for another file.
  Example: This leads to the fact that e.g. 10 files with one character in it (which would be 10 bytes in total) will use 10 blocks (which is around 10 kByte on the INTFLASH of a PCD1.M2xxx or a "blue flash module").
  The amount of "unusable" memory is depending on the number of files and the block size of the file system. In maximum the "unusable" memory is the number of files multiplied with the block size.   

This rules apply to all file systems on memory modules and on the INTFLASH (if available). These are:

• PCD1.M2xxx (INTFLASH)
• PCD2.R6000
• PCD3.R550, PCD3.R551, PCD3.R561
• PCD3.R600
• PCD7.R550, PCD7.R551, PCD7.R561
• INTFLASH of a PCD3 Compact or a PCD1.M2
  

In case a backup from/to the flash card (e.g. a PCD7.R500) can not be executed (due to the reasons listed below) this following message is displayed by PG5: "Failed to copy to/from Flash. Check Flash memory or card is fitted?"

Possible reason
It is most probably due to the fact that the flash memory doesn't contain a user programme or the contained configuration isn't compatible with the PCD.
For example the configuration might contain an IP Adress but the PCD doesn't have an Ethernet port!

Possible solution 

• use the flash memory on the suitable PCD
• or try to download a new user programme / configuration from the PCD
  -> flash card (Project Manager menu "Online" --> "Flash Memory" --> "Copy program to flash"
• or delete the content of the  Flash memory using the press Run/Halt button beside the USB connector. Therefore press longer than 1 minute (until the Red/Green LED is flashing at 2 hz) at power up as described in the manual 26/789 chap. 3.19.1

In the manual for the file system it is recommended to compress a flash file system after a file has been deleted. This FAQ explains the differences between SD flash systems such as the PCD3.R600 equipped with PCD7.R-SDxxx and the PCD7.R55x and PCD7.R561 modules.

Introduction
In the manual for the file system it is recommended to compress a flash file system after a file has been deleted. This is strongly recommended for the PCD7.R5xx modules, INTFLASH etc. because for these systems the compress is used in order to make "freed" memory available again.
The SD cards used in the PCD3.R600 or the PCD2.R6000 are equipped with an own controller which automatically makes "freed" memory available again. On the other hand, the free memory (where data has been deleted) will remain at its place. This leads to "holes" in the used memory structure which is not ideal (because of increased time used for the initialitation of the card on start up). The compress task will remove these "holes" in the memory.

Conclusion
A "compress" is not necessary for making memory space from deleted files available on SD cards. But the compress optimizes the memory usage and should be done from time to time.
As it is easyer to program the compress right after the deletion of a file, this is the easyer way to realize this recommendation. 

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

In case more than one PCD2.R6000 produced before August 2009 are installed on a PCD2.M5xxx, the PCD does not properly initialize the file systems during start up. As result the file systems can not be used (and are not visible on the FTP server of the PCD).

Symptom
The file systems of the PCD2.R6000 on slot #0 to slot #3 (SLxFLASH:/) on a PCD2.M5xxx are not be visible on a PCD2.M5xx0 with several PCD2.R6000 equipped. This phenomenon can be observed on systems equipped with SD flash cards PCD7.R-SD512 and PCD7.R-SD1024 which have a production date in the year 2009 (09xx) if the hardware version of the PCD2.R6000 is older than "B".
If only one PCD2.R6000 is equipped, no problem is to be expected. A single PCD2.R6000 can be inserted in any slot from slot #0 to slot #3.

Reason
In dependance of the hardware modification of the R6000 the PCD can not correctly initialize the file systems of the above mentioned cards at start-up if more than one R6000 is plugged. As result the file systems can not be used (and are not visible on the FTP server of the PCD).
There is no data loss in this situation.

Solution
With hardware version "B" of the PCD2.R6000 it is possible to mount several PCD2.R6000 modules on the PCD (without any restriction of the production date of the SC card).
Modules with this modification are available from stock since beginning of August 2009 (calendar week 32 of 2009).

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.

There are several possibilities to access the content of an SD card (used with a PCD3.R600 or a PCD2.R6000).

How can I access the content of a SD card?

• Over the Automation server of the PCD3 it is possible 
  - Web Server of the PCD(--> read only, and the file must be placed in the folder "WEBPAGES")
  - FTP Server of the PCD (read/write)
  - by sending the file by EMail (SMTP)
• With a card reader on a PC. For doing so the "SBC SD File System Explorer" is to be used.
  
  

Remarks
The content of a SD card is stored in the file SAIANTFS.FFS (which occupies 90% of the available disk space of the SD card). Please note that it is not allowed to "drag and drop" the file SAIANTFS.FFS on another SD card without using the "SBC SD File System Explorer"; if this is done there is no guarantee that the PCD is able to find the (copied) content of this SD card. 

The "SBC SD File System Explorer" is for free and can be donwloaded from the PCD3.R600 product section on the support site (www.sbc-support.ch).


Procedure to copy the content of an SD card to another SD card

• use the SBC SD File System Explorer
• extract the files from the first SD card
• add these files on the second SD card

One write access executed with the new version of the FBoxes can write up to 3072 characters (the FBox executes several write commands for 255 bytes each, which is the biggest junk of data which can be written to the file system with one internal command). This new FBox library is available for PG5 1.4 and for PG5 2.0 (2.0.210)

With the help of the FBox "Log to file" or "Log to file advanced" it's possible to store data to the filesystem of the PCD.
These FBoxes permit the user that information is written according to his needs (formatting) into the file.
Older FBoxes have the limitation that only 255 characters could be written at once in to the file.
With newer FBoxes we have increased the limit of the "Head" value and the "Val" value of the FBox "Log to File Advanced" from 255 characters to 3072 characters.

Version dependencies
Minimum requirement for the file system library to support the writing of 3072 characters:

• For PG5 1.4: $2.5.309
• For PG5 2.0: 2.6.200 (delivered with PG5 2.0.210) 

Remarks

• Minimal firmware version to use this new library is 1.10.16.
• The length of 3072 bytes concerns the effectively written data; in case template texts using e.g. $Rnnnn are used, the amount of written bytes count.
• When working with the System Funtions (CSF), the maximum amount is 255 characters.
   

Example
The text "Register 0 contains: $R0000" is written to a file:

• if register 0 has value 1234:           25 characters (bytes) are written
  (Written content: "Register 0 contains: 1234")
• if register 0 has value 1234567890: 31 characters are written.
  (Written content: "Register 0 contains: 1234567890")

If the file- or directory- names are not correct, this will lead to errors.

Directories
A directorie name needs always a slash in front of the name in the text definition:
"/Mydir"

Files
For file names the slash is not allowed:
"Myfile"

General
Note that the maximal length of filenames (including the extension etc.) is 23 characters.
"thisisthemaximum123.txt"

The maximal filename length on the filesystem is 64 characters.
M2_Flash:/Directory/File.txt

Be careful when implementing time and date to the filename with the syntax $D and $H. $D per example will use 9 characters. If the file has an extension as well, per example .csv, already 13 characters are used, means the filename itself cannot be longer than 10 characters.

Special characters like ä, ö, ü are not allowed on the filesystem.

Remark
Please note that "special characters" such as "ü", "¢", "ç" are not supported on the PCD file system. Additionally, the maximal file name lenght is 23 characters.

If a file- or directory- name is defined with a fixed length, it can lead to problems

Problem
The FBox indicates an error and the file or directory is not created on the filesystem

Reason
The file- or directory- name has to be defined with a default text size. If the text is defined as fixed and there are less characters than defined it is filled up with spaces. Since spaces are not allowed on the filesystem, this will lead to an error.

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