Communication protocols supported by Saia PCD®

If the Control interval (ASS/ABI-CI) is set to 0 then the error flag will be set to high after the SASI instruction.

The Control interval (ASS/ABI-CI) is defined on the following menu of the PG5 Profibus-FMS configurator:

Edit Station, Channel List, Header

On Profibus Network it is important to use the right cable and connector as the communication speed goes up to 12 Mbautes!

Those cable and connectors are used in Profibus DP, FMS, Profis S-Bus, Profi S-IO and MPI!

The first document describes the configuration between UNIGYR PRU and PCD2

For mounting and installation instructions we refer to the SBC Manuals PCD2 26/737

The second document describe an PG5 Version 1.3 example for the communication between the PCD2 and UNIGYR PRU

   for more Help or application support you can connect:

   A&P Kieffer Omnitec Sàrl

   59, avenue Pasteur / BP 317

   L-2013 Luxembourg

   Tel.:  (+352) 474848-258

   Mail: martin.theis@kiffer-omnitec.lu

There are confusing screw terminal identifier terminologies around. Depending on the manufacturer the identifiers used are in conflict to the identifiers you can find in SBC manuals.

General
RS-485 is a Bus-system, therefore the signal wires shall not be crossed.

Sometimes "+Data" and "-Data" can be found on devices. Then "+Data" propably has to be connected to "/Rx-/Tx" (or /D) and "-Data" to "Rx-Tx" (or D).

Converters
Some products form other manufacturers (p.e. RS232 - RS485 converters) are often inversly indicated. Therefore it is sometimes necessary to cross the wires.

Profibus and Profi-S-I/O 

Example for the port 3 of the PCD3.M5540 as Serial-S-Bus
RS485 connection (Serial-S-Bus) between PCD3.M5540 port 3 (S-Net D-Sub used as RS485 Serial-S-Bus) and PCD2.M5540 port 2 (connector block X3):

When the 4 channels analog carte PCD2.W745 is used on a PCD3.T760 RIO module 6 registers are available on the master station. It is important to know that the 2 first registers contain the diagnostic bits of the 4 inputs channels!

How to interpret those 2 diagnostic registers (anal_16 and anal_17) ?
The first 2 bytes (low bytes) gives the diagnostic bit of 2 analog channels (1 byte per channel) as indicated in the following screenshot:


Signification of each bit (from right to left):

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

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

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

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

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

Remarks

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

The maximum of exchanged data over a Profibus DP interface (or Profi-S-I/O) interface is depending on the system (the amount is not the same for a PCD7.F750 or a PCD3).

PCD7.F750 placed on a PCD2.M1x0 (non SBC-NT)
The Profibus DP manual states that the maximal amount of exchanged data per PCD7.F750 is 2942 bytes.

PCD3, PCD2.M5 or PCD2.M480 and PCD1.M2 (SBC-NT)
The limitation mentioned above does not apply for SBC-NT systems where the maximal amount of exchanged data is 2048 bytes.

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:

On our Profibus DP Master modules and CPUs there are two LEDs available:

RUN = Yellow

ERROR = Red

Modules and CPUs
The LEDs RUN=Yellow and ERROR= Red are present on the following modules:
PCD7.F750
PCD7.F7500
PCD3.M654x: On this CPU the LEDs are below the cover. Otherwise you can see them if you open the blue cover that covers the battery-module, M1-, M2-Slot and the RUN Stop/switch. Through the little gap where the cover is cliped in, the LEDs are visible:



Status of the LEDs:
ERROR LED:
The ERROR LED is switched on for approximately 1 sec during startup. If the module is working correctly the error LED is switched of afterwards. In case the error LED is switched on or blinking the Profibus DP module has a serious problem that is most probably related to the hardware itself.

RUN LED:
The RUN LED is normally blinking after startup. If it is blinking fast (~10Hz), the Profibus communication is not running correctly. In case the Profibus communication works well, the RUN LED is blinking slowly (~1Hz). If the communication is not working properly, more information is available in the history of the PCD. Check the history of the PCD for Profibus DP FAIL errors (see list below for the meaning of these messages). If there is no entry in the history regarding the DP functionality, you can check the diagnostic flags and diagnostic registers. More information about the Profibus diagnostic is available in the manual Profibus DP 26/765. The manual is at the moment not up to date. Only the PCD7.F750 is mentioned. Otherwise most of the information in this manual like diagnostic information is valid for the PCD3.M654x and PCD7.F7500 as well. We are working on a new version.

PROF DP FAIL xxx (or PROF S-I/O fail if Profi-S-I/O is used)
ERR# Description
0 Key word MODE: not found
0 Wrong mode specified
0 Key word CONF: not found
0 DBX key word not specified
0 DBX number error
0 DBX number to large
0 DBX does not exist
0 Key word DIAG: not found
0 Flag or output key word not specified in DIAG
0 Error in address of diag flag or output
0 Range error diag flag or output
0 Register key word not specified in DIAG
0 Range error diag register
1 PROFIBUS-DP HW card not present
2 Error in instruction
3 DBX structure error
4 DBX type not for DP master (no PROFIBUS DBX)
5 FW-DBX version not compatible
6 No IN RING message after timeout on initialization
7 Semaphore error for data exchange (info to PCD support)
8 DBX error: data transfer function not implemented
9 Incompatible PCD7.F750 and PCD hardware

The Profibus DP-DP Coupler 6ES7 158-0AD00-0XA0 from Siemens is used to exchange data between two Profibus DP Master devices. The coupler itself acts as Profibus DP Slave and is to be connected to two different Profibus networks. It will copy the "input" of one side of the coupler to the "output" of the other side. This device is used by several customers and works with Profibus DP masters from SBC.

Important points when commissioning the 6ES7

• It is important that the modules on both sides of the DP/DP coupler do have an identical size
  When defining the modules, make sure that the size of the modules is identical on both "sides" (networks) of the coupler. Make sure that the "input" area of one side corresponds to the "output" area of the other side.
• The diagnostic bit in for the coupler has several possible meanings:
  - It can indicate "no communication"
  - or it can indicate a configuration mismatch (e.g. different size of the modules)
  - or it can indicate that no communication is running on the onter "side" of the coupler

The diagnostic flag Slave_Err does indicate that at least one Profibus slave has an error.

The error could be that the slave(s) is/are not connected to the Profibus network or that the slave(s) is/are connected to the Profibus network but do have diagnostic information’s.

That means that it's possible that a DP or Profi-S-IO Slave does communicate correctly but the diagnostic flag SLAVE_ERR and the corresponding bit on the diagnostic register Base+x is set to high because the slave does send a diagnostic information (for example overload on the output driver) to the master.

The concerned slave(s) number(s) is/are shown on the diagnostic register Base+3.. base+6.

To know the reason for the slave error on the application program it's necessary to perform a scon instruction # 1 "read slave diagnostic data" as described on the manual 26-765.

The configuration of the two devices has to match.

Problem
On the Saia side the DP configuration is made using the DP-network configurator and definig the modules to exchange. The CP 342-5 communicates using FC's.

Example
In the Siemens programming tool the FC 1 is used for sending data to the master. FC 2 is used for receiving data from the master. FC 3 and 4 can be used for diagnostic and control.
Example Siemens:
      CALL  FC     1
       CPLADDR:=W#16#100
       SEND   :=P#DB119.DBX0.0 BYTE 64
       DONE   :=M100.1
       ERROR  :=M100.2
       STATUS :=MW102

CPLADDR: Is the address of the CP 342-5 in hexadecimal (Decimal=256). This has to be defined in the Siemens Hardware Configuration.
SEND: Is the data to send. In this case the data is located in DB119. The amount of data to send is 64 Bytes.
DONE: Indicates if the function was executed
ERROR: Indicates errors
STATUS: Shows the actual status. For more information refer to the Simatic Manager help.

Example Saia:
On the Saia side we have to configure the same amount of BYTES. Since the Slave sends 64 BYTE the configuration on the SAIA site has to be 64 BYTES as well.
There are two possibilities:
32 word AI constcy complet: in this case the data is mapped to registers
or
64 bytes AI constcy complet: in this case the data is mapped to flags.

The same structur can be used if the Siemens Slave receives data from the master:

Example Siemens:
      CALL  "DP_RECV"
       CPLADDR :=W#16#100
       RECV    :=P#DB119.DBX100.0 BYTE 64
       NDR     :=M200.1
       ERROR   :=M200.2
       STATUS  :=MW202
       DPSTATUS:=MB204

Example Saia:
32 word AO constcy complet
or
64 bytes AO constcy complet

Description of a possible malfunction in relation with a DP/Belimo gateway (device S-HER-UN-DP-Belimo Gateway from the company A-M-Systeme)

Description of a possible malfunction in relation with a DP/Belimo gateway (device S-HER-UN-DP-Belimo Gateway from the company A-M-Systeme): 

• Profibus-DP network with a PCD as DP master and a DP/Belimo gateway as DP slave
• DP communication woks fine.
• After a download of the application program to the PCD or a restart cold of the PCD the DP/Belimo gateway does show an error message on his display "SPS stopped" and the Error LED of the DP/Belimo gateway is blinking.
  The DP/Belimo gateway is not able to receive and send DP messages.
• On the DP diagnostic of the PCD there is no indication that the DP slave does not work but it’s not possible to read/write information’s from/to the DP/Belimo gateway.
•  A power off/on of the DP/Belimo gateway or the PCD does solve the problem. 

The problem was on the FW of the DP/Belimo gateway and was fixed on the FW 1.24d of the DP/Belimo gateway.

FW versions < 1.24d could have this problem. 

To update the FW of the DP/Belimo gateway please contact your DP/Belimo gateway supplier.

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

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

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

Solution
Please update the firmware of your

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

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

The S-Net Configurator distributed with PG5 until version PG5 1.4.130 does impose too strong limitations regarding the amount of modules in the configuration. As result the maximal size of exchanged data can not be reached.

Symptom
When trying to configure a Profibus DP or a Profi-S-I/O master station that will exchange more than 160 bytes in- and output data with Profibus DP slaves, the consistency error message
Slave 2 "Slave" :
        Error 601: Configuration too large. Try removing some modules.

appears. Therefore it is not possible configuring the maximal amount of exchanged data.

Reason
There S-Net Configurator does calculate the limits according a very old version of the module PCD7.F750. In this old version (a pilot version) of the module much less memory for the data exchange has been available.

Solution
This wrong calculation of the maximum exchanged data is (will be) corrected in PG5 SP1.4.140. In case you need to configure the network with PG5 SP1.4.130, please contact your local sales office and request an appropriate version of the S-Net configurator (SNet32.exe).

Additional note
The Profibus DP manual states that the maximal amount of exchanged data per PCD7.F750 is 2942 bytes. This limitation does not apply for Saia PCD® COSinus systems (PCD2.M480, PCD3, PCD2.M5xxx or PCD1.M2) where the maximal amount of exchanged data per Profibus DP Master is 2048 bytes.
Note that the maximal amount of exchanged data per Profibus DP Slave is 244 bytes.

To communicate with a Siemens Slave it is necessary to place the modules Kennung generell 1-3.

If you change the baudrate in a SNet the new parameters must be downloaded with "Download hardwaresettings".

Rebuild and download also all programs.

Yes they are and starting in PG5 1.4 these modules are included in the S-Net Configurator by default. When using PG5 1.3 an import of a recent version of the GSE (or GSD) file is necessary. The firmware of the PCD3.T760 must be V 1.019 or later.

Problem
In the S-Net Configurator of PG5 1.3 (DP or S-I/O) the modules PCD3.W800, PCD3.A810 and PCD3.A860 are not implemented.
 
Reason
The mentioned modules are not implemented because at the time PG5 1.3 has been released the modules have not been available.

Solution
Upgrade the firmware of the PCD3.T760 to V 1.019 or later and with right-mouse-click on the T760 device in the SIO-configurator 'Remove Device ...' , delete the actual GSE-file. Then, import the new GSE file into the S-Net Configurator. Note that the new GSE file has to be named exactly 'PCD3.T760'. If the name is different, the S-I/O configurator will not use the new version. Old projects will also work correctly with the new GSE file.

When measuring e.g. the temperature of a Pt1000 sensor with a W-module mounted on a PCD3.T760, the sensor type can be configured in the SBC Network Configurator. If this is done this way, negative temeratures are not interpreted correctly on the PCD. Instead of negative values, very high values around 65000 are shown.

Symptom
The temperature values read from the PCD3.T760 aren't negative but very high (around 65000). Positive values read are interpreted correctly. All modules that do offer the possibility of reading temperature values are affected (PCD3.W220, PCD3.W340, PCD3.W350, PCD3.W360, PCD3.W745).

Reason
The reason for this phenomenon is the fact that the values transmitted over Profibus DP or Profi-S-I/O are signed 16-bit values. These values are copied directly into the signed 32-bit registers of the PCD. Due to the lack of a transfer function that converts the negative values (and copies the sign bit from the 16th to the 32th bit), the negative 16-bit values aren't correctly interpreted when copied into a 32-bit register.

Solution

Firmware versions supporting the transfer function (systems not listed in this table do not support the transfer function mentioned):

On other systems than the ones listed above the following workarounds are possible:

• Reading the raw values from the W-modules (1:1) and then converting these values e.g. in Fupla by using the FBox "20-point-conversion". A table for this conversion accroding to the applied module and senser type can be requested from pcdsupport@saia-pcd.com
• Converting the read temperature values at the very beginning of the COB 0. Because the read values are copied to the PCD registers always right before the start of the execution of the COB 0, this will convert the values always just after the writing into registers. All following COBs created by the user will have the correct values read from the PCD3.T760. An example code for this method is attached to this FAQ. This file also contains guide how to introduce this function into an existing project.

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

On Profibus Network it is important to use the right cable and connector as the communication speed goes up to 12 Mbautes!

Those cable and connectors are used in Profibus DP, FMS, Profis S-Bus, Profi S-IO and MPI!

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

The PCD2.M480 does support the following baudrates:

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

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

There are basically two tools that are required to solve communication issues on Profibus based networks (like Profi-S-Bus, Profi-S-IO, Profibus DP):

• an oscilloscope to locate hardware related problems (see related topics for more information)

• a protocol analyzer specialized for Profibus based networks

The protocol analyzer we recommend is ProfiTrace (www.profitrace.com) with the Oscilloscope Option. This analyzer bases on an up to date hardware and software concept and is easy to use. The oscilloscope option allows to observe telegrams of specific stations on the oscilloscope, ProfiTrace is generating the necessary trigger signals.

In Switzerland ProfiTrace is represented by  Berner Fachhochschule, Hochschule für Technik und Informatik, please refer to labs.hti.bfh.ch/index.php for more details.

If a DP slave has a bus interruption in the space of watchdog time, the master station (PCD7.F750)

doesen’t refresh automatically the diagnostic flags and registers.

In PG5 SP1.2.130 the analogue module PCD3.W745 isn't implemented. To be able to configure the PCD3.W745 on a PCD3.RIO the latest *.gsd file is required.

The corresponding *.gsd file is available on the Support Site under "Browse by product Code/PCD3/Txxx/Txxx".

Ad the new modules using the funtion "Ad device" of the menu "Library" of the SNet32.

Depending the PCD type there are up to 3 interfaces to connect the PCD to a Profibus DP or a Profi-S-I/O (or FDL in general) network.

Please consult the table below for the correct connection of the Profibus cables:

The Profibus network has to be terminated on both sides of it in one of the following ways:

1. Termination boxes that are placed at the begining and end of the line topologie (solution that should be preferd):

2. For baudrates up to 1.5 Mbaud the termination can also be realized directly on the first and last device of the network. Note that there are also specific connectors with housings with come with the resistors already equipped.

3. For higher baudrates the second solution is not suitable. Inductances has to be add to the termination:

Yes, it's possible.

During the import of the *.GSD or *.GSE file to the Profibus-DP configurator you can select in which groupe you want to store the new file.

You can select the existing groups or you can write a name in to the selection text. This will then create a new group on the device list of the Profibus-DP configurator.

Yes, it's possible.
During the import of the *.GSD or *.GSE file to the Profibus-DP configurator you can select in which groupe you want to store the new file.
You can select the existing groups or you can write a name in to the selection text. This will then create a new group on the device list of the Profibus-DP configurator.

<?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" /><shapetype id="_x0000_t75" stroked="f" filled="f" path="m@4@5l@4@11@9@11@9@5xe" o:preferrelative="t" o:spt="75" coordsize="21600,21600"> <stroke joinstyle="miter"></stroke><formulas><f eqn="if lineDrawn pixelLineWidth 0"></f><f eqn="sum @0 1 0"></f><f eqn="sum 0 0 @1"></f><f eqn="prod @2 1 2"></f><f eqn="prod @3 21600 pixelWidth"></f><f eqn="prod @3 21600 pixelHeight"></f><f eqn="sum @0 0 1"></f><f eqn="prod @6 1 2"></f><f eqn="prod @7 21600 pixelWidth"></f><f eqn="sum @8 21600 0"></f><f eqn="prod @7 21600 pixelHeight"></f><f eqn="sum @10 21600 0"></f></formulas><path o:connecttype="rect" gradientshapeok="t" o:extrusionok="f"></path><?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><lock aspectratio="t" v:ext="edit"></lock></shapetype>

If GSD files are imported in to PG4/PG5 then this files are stored in a SBC specific format in the files dpdv.dat and dpsaiadv.dt.

If you want to use the imported GSD files on a other PC (with Saia PG5®) or on a other PG5 version then you have to copy the files dpdp.dat and dpsaiadv.dat from the old PC to the new PC

It's possible to add non SBC Profibus-DP devices to our PG4/PG5 Profibus-DP configurator. This *.GSD or *.GSE files can be added with the option "library, add device" to the device list of the Profibus-DP configurator.
During the import, the information of such *.GSD or *.GSE files are copied from the *.GSD/GSE files in to the SBC specific files dpdv.dat and dpsaiadv.dat which are located in the PG4/PG5 main folder.

If you like to use the stored *.GSD/GSD information on a other PC or on a newer version of PG5 then you have to copy this two files (dpdv.dat and dpsaiadv.dat) from the old PC to the new PC/PG5.

Note:
For PG4 and PG5 (The user himself has to save the files in to the backup project, and have to restore the files manually.

With PG5 V1.3 the files dpdv.dat and dpsaiadv.dat are saved together with the project during the backup of the project.
A restore of such projects will compare the content of the files dpdv.dat and dpsaiadv.dat stored on the PG5 main folder and the content of the saved dpdv.dat/dpsaiadv.dat and complete the files on the PG5 main folder with the additional information's stored on the saved files.

There are confusing screw terminal identifier terminologies around. Depending on the manufacturer the identifiers used are in conflict to the identifiers you can find in SBC manuals.

General
RS-485 is a Bus-system, therefore the signal wires shall not be crossed.

Sometimes "+Data" and "-Data" can be found on devices. Then "+Data" propably has to be connected to "/Rx-/Tx" (or /D) and "-Data" to "Rx-Tx" (or D).

Converters
Some products form other manufacturers (p.e. RS232 - RS485 converters) are often inversly indicated. Therefore it is sometimes necessary to cross the wires.

Profibus and Profi-S-I/O 

Example for the port 3 of the PCD3.M5540 as Serial-S-Bus
RS485 connection (Serial-S-Bus) between PCD3.M5540 port 3 (S-Net D-Sub used as RS485 Serial-S-Bus) and PCD2.M5540 port 2 (connector block X3):

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.

In case more than 32 PCDs are to be connected to a PC using serial connections (with one COM port for every PCD station) PG5 needs to be configured to allow more than 32 COM ports to be used by the SComm driver.

By default the number of accessible ComPort is limited to 32 Com ports. The reason therefore is that with more than 32 COM ports is has been observed that the process which allows to scan the available Com Port on the PC could take up to 1 minute (and more...), depending on the system or devices used. This phenomenon can be observed by clicking the "Setup" button in the dialog box of the "Online Settings" in PG5.

Procedure for increasing the maximum number of Com Ports
=====================================================

PG5 1.4: (Windows XP) 

1. Close all SBC-Software
2. Open the Registry Editor: from the Windwos start menu select "Run...", type "regedit" and click "OK"
3. Browse to --> HKEY_LOCAL_MACHINE --> SOFTWARE --> Saia Burgess --> PG5 --> 1.4 --> SCommDrv
4. In this folder (... --> SCommDrv) create or modify the "PcdLastCom" DWord variable with a value greater than 20 hex (32 dec) for example 40 hex (64 dec)
   This new value represents the maximum number of accessible/scanned ComPorts by PG5

PG5 2.0: (Windows XP)

1. Close all SBC-Software
2. Browse to the folder "C:\Documents and Settings\All Users\Application Data\Saia-Burgess\PG5_20\"
3. Open the file "SCommSettings.ini" and modify the value of the "PcdLastValue" (for example write 64) and save this file under the same format.
   This new value represent the maximum number of accessible/scanned ComPort by PG5
   
   

If you make a online modem connection with PG5, OPC-Server, S-Web-Connect or Visi+ to a PCD then the modem settings of the TAPI (Telephony Application Programming Interface) are used.

TAPI is a Windows standard interface and the TAPI settings are accessible under the control panel, “phone and modem options”.
There you have the possibility to adapt different modem parameters like baud rate, data protocol and so on.

The channel settings menu of PG5 allows modifying the modem parameters of TAPI settings which are used without that the TAPI settings of Windows are changed.

Please not that the channel settings menu of PG5 does store the modified TAPI settings in the registry of Windows under the key name:
HKEY_LOCAL_MACHINE\SOFTWARE\SAIA-Burgess\PG5\x.y\Channels\S-Bus Modem\TapiSettings

PG5 does not change the TAPI settings of Windows.

The registry entry mentioned above is updated after that you have open the menu point “configure line” and you have stored the configuration settings of the modem.



 

PG5 does apply the following rules:

- If PG5 don’t have any entry on the registry key mentioned above or if the registry key mentioned above don’t exist, then PG5 does use the default TAPI settings (defined under the control panel, “phone and modem options”) of the selected modem.

- In the other case PG5 does use the modified TAPI settings stored under the registry key mentioned above.

Due to a problem of Windows XP and Windows Server 2003, the SCOMMDRV.EXE can exhaust all available memory when using "socket communication" (Ether-S-Bus). The memory leak is related to the "Windows XP Themes" and Microsoft provides a patch for this problem.

Symptom
When using the Microsoft Windows XP Theme (see screenshot below), the Scommdrv.exe leaks memory every time a Ether-S-Bus (Socket) connection to a PCD is disconnected. This can lead to a system crash when all available memory is exhausted.


Reason
This problem occurs because of a bug in the implementation of the new Windows XP theming interface. MFC applications leak GDI objects on computers that are running Windows Server 2003 or Windows XP.

Solution
Please refer to the link below which points to the Microsoft Support page which explains the probelm and from where a patch can be downloaded.

Note
This problem concerns all applications using the SCommDrv.exe and communicating with Sockets (--> PG5, OPC Server etc.). WebConnect 2.x is only concerned if the SComm driver is selected.

There is a serious problem with AMD Athlon 64 X2 processors. The timing functions in the BIOS have a bug and can cause the SComm fail with strange status.

Symptom
On a PC equipped with e.g. an AMD Athlon 64 X2 processor it is possible that the SComm driver fails with strange status messages. We have observed this problem on AMD Athlon 64 X2 processors produced in 2006 but the problem can potentially happen on all multi-core processors.

Reason
There is a serious problem with some series of AMD Athlon 64 X2 processors. The timing functions in the BIOS have a bug and can cause the SComm fail with strange status. The problem seems to be related to the variable clock rate feature of the CPU.

Solution
Microsoft and AMD had to fix this problem. Please refer to the links attached to this FAQ and apply the mentioned update on your system if necessary.

How to detect if your CPU is affected?
There is a simple test program that allows to detect if a CPU is affected. Procede as follows:
- store the attached dll vb6fr.dll in your /windows/system32 folder unless it is already present there
- run the attached projet.exe and go to the second screen. If everything is OK the fourth value in form1 is a rather stable value in the order of 350, if you have a negative or very big value the CPU is affected by the problem

You can't connect over any channel to a PCD by using the SCommDll . The software firewall softwares "Zone Alarm Security", "Windows Defender" or "Bitdefender" block the SComm funktionality on PC's running MS XP.

Symptom
If the ScommDll is launched, the PC won't react on key strikes for more than 40 sec. After this time, an error message is displayed saying "SCommDll error, Socket not installed or wrong server IP number".

Reason
The software firewall "Zone Alarm Security" blocks the ScommDll (The SCommDll communicated to the SCommDrv over an IP stream on port 7000 that is blocked).

Solution
Zone Alarm must be uninstalled; only deactivating won't work in most cases. This phenomenon was only observed on Windows XP. On W2k it seems that the ScommDll works also with ZoneAlarm activated.
In case the Bitdefender is used either disabling or appropriately configuring should help.

Hints

• The behavior descripted above does also apply to many other Personal Firewalls (aka Desktop Firewalls, Internet Security Suites etc.). So if socket communication does not work, these security tools should be checked.
• Most Personal Firewalls can be configured by so called "rules", which allow to open certain ports for one or more applications. So instead of totally disable or uninstall der firewall software, it may be a better solution to define apropriate firewall rules which allow SCommDrv to communicate anyway.
  For the relevant PG5 parts SCommDll.dll and SCommDrv.exe to work the TCP port 7000 needs to be enabled on the local host!

It is possible to connect a PCD over a server. This means that the PCD is connected to a remote PC (server).

PG5 on the local PC will connect the SCommDrv on the remote PC and therefore reads the medias of the PCD connected to the remote PC.

• Run ScommDrv.exe on the server by double clicking the file in the installation directory of PG5 server installation.

• Once the icon is visible in the taskbar, open it (context menu of the icon, right mouse button)

• Select tab “Setup”. Set checkbox “Load on startup” (this will cause SCommDrv to be launched on system boot. This is required for that the clients can connect to it)

• Set “Server IP Address” to the interfaces address on which the clients are connected

• Set “Local IP Address” to the same interface, save and close the SCommDrv and unload it (context menu of the icon in the taskbar).

• Restart SCommDrv.exe (this is required for that the new settings will be read and applied)

Now the server is ready to answer to requests from clients (himself included) to establish a connection to a PCD connected to it’s interfaces. Several clients may connect one or several PCD’s at the same time.
The SCommDrv.exe must be running in order to answer these requests.

Setup of the SCommDrv.exe On the client PC :

If you want to use the S-Bus OPC-Server and PG5 on the same PC then you have to make attention to use the correct version of the S-Bus OPC-Server which fit with the corresponding version of the scommdll.

Nerveless it’ possible to run for example the S-Bus OPC-Server v 2.02.09.01 on a PC where PG5 V1.3 was installed.
In this case the S-Bus OPC-Server doesn’t have to use the scommdll of PG5 V1.3 but he has to use the scommdll (V 1.2) stored on the S-Bus OPC-Server installation package.
If PG5 and the OPC-Server use two different version of the scommdll then it’s not possible to go online with a PCD simultaneously with both tools.
To install the scommdll which is stored on the S-Bus OPC-Server installation package, during the installation of the S-Bus OPC-Server you have to select “Install SBC communication driver”.

If the SBC S-Bus OPC server was launched by a request of an OPC client located on another machine, the SCommDll (or SCommDrv) is not available for the user working on the PC where the OPC server is running.

This problem is caused by the fact that the Merz SBC S-Bus OPC Server (SaSBus.exe) was launched under the "Interactive User". As result the SaSBus as well as the SCommDrv and SCommDll will not appear in the system tray of the user (logged in). Nevertheless an instance of the SCommDll is running (under the "Interactive User") and it can't be started again by the logged in user.

The error messages will be something like "The driver is not available" or "Another instance of the driver is already running".

As workaround the logged in user has to launch the SaSBus before the OPC client will request data from the OPC server. Once the SBC S-Bus OPC server is started by the logged in user, it won't be started a second time by the Interactive User and therefore it will be possible to communicate over the same SCommDrv (logged in user and OPC Server).

Yes, the product Saia PCD® COSinus (PCD8.DNET-SUITE) does also contain the SBC S-Bus libraries (S-Bus Master and/or S-Bus Slave) based on the Microsoft .Net framework.

How is the Saia PCD® COSinus structured?
The Saia PCD® COSinus contains different components (S-Bus Master, S-Bus Slave, an interface for CGI calls to the PCD Web Server etc.) for easy integration of the communication interface for PCD systems into Windows applications. All the components are based on the Microsoft .Net framework.

This product (PCD8.DNET-SUITE) does contain the required libraries, documentation, examples (programmed in C#, C++ and VB) as well as access to updates and new features.

How do I get the Saia PCD® COSinus Suite?
The Saia PCD® COSinus Suite is an official product from Saia-Burgess Controls AG and can be optained from your local SBC representative (or support@saia-pcd.com)

Remarks

• The product Saia PCD® COSinus can't be found yet on the support homepage www.sbc-support.ch (the TI will be uploaded soon).
  
• The Saia PCD® COSinus suite is the replacement for the inofficial SCommDll toolkit which has been available until November 2007. The SCommDll toolkit is discontinued and is no longer available.
  

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.

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.

In some situations it is necessary to have access possibilities from external networks to the displays. By factory default, the integrated firewall in Windows CE is activated. With activated firewall, the device will not respond to all TCP-IP remote requests or protocols from another device in the network.

To ensure, that your panel can be reached from a remote device in the network, you have to disable the integrated Firewall. Therefor you must follow the steps below:

1.       Go to “start menu\programs” and open the registry editor

2.       Search for entry “HKEY_LOCAL_MACHINE\Comm\Firewall”

3.       On the right side you will see the entry “EnableIPv4”. Do a right click on it and write a “0”  (“zero” as DWORD) to the DWORD Value Data and click “OK”.

4.       Open the entry again and proof whether the new value was saved by the system. If not do the  operation of point three again.

5.       Go to menu “File” and click “save to flash”

6.       Reboot the panel.

In some situations it is necessary to have access possibilities from external networks to the displays. By factory default, the integrated firewall in Windows CE is activated. With activated firewall, the device will not respond to all TCP-IP remote requests or protocols from another device in the network.

To ensure, that your panel can be reached from remote device in the network, you have to disable the integrated Firewall. Therefor you must follow the steps below:

1.       Go to “start menu\programs” and open the registry editor.

2.       Search for entry “HKEY_LOCAL_MACHINE\Comm\Firewall”.

3.       On the right side you will see the entry “EnableIPv4”. Do a right click on it and write a “0”  (“zero” as DWORD) to the DWORD Value Data and click “OK”.

4.       Open the entry again and proof whether the new value was saved by the system. If not do the   operation of point three again.

5.       Go to menu “File” and click “save to flash”

6.       Reboot the panel.

Situation:
The PCD is configured as Modbus client with the Saia-Modbus client F-Boxes and you have to communicate over Ethernet with a Siemens S7-314C-2 with the Modbus protocol.
Randomly, some read or write F-Boxes are working fine and others not.

Problem:
The problem is that the Siemens device sends a ‘reset’ telegram after sending the response to the PCD.
Since the PCD has received the response from the Siemens, the PCD does exit from the Modbus communication state machine and end the task correctly.

If the PCD now receives this unexpected ‘reset’ telegram from Siemens device, then the PCD thinks, that this is an error message from the Siemens device and does close the communication and the F-Box goes in error state.

The transmission/reception F-Box which is in the queue to proceed the next Modbus request is now no more able to communicate with the Siemens device.

Solution:
Use the Modbus Initialization Client Extended F-Box.
In this F-Box you have the possibility to set a minimum request delay.
Set the minimum request delay to 100ms

This problem occurred for example with a Simatic S7-314C-2 Siemens device.

Symptoms

If we try to send an SMS message with a GSM modem and the FBox SendSms. The CallSMS FBox is in Error with the Error code 535.

Reason

Probably a wrong SMS Service Center Number is configured.

It can be a typing Error or the SMS Service Center doesn't fit to the SIM card because it was exchanged with the card from another provider.

Solution

Use the correct number. The number for SMS Server must normally be divided in at least 2 parts. Tf number 1 / Tf number 2. Each part of the number can have 8 digits. Keep attention that if you do copy / paste from numbers that are available e.g. in the FBox-help that all numbers are correctly copied. Keep attention to use the protocol “GSM Text” in the protocol option of the Call SMS FBox.

You want to change the file name of the attachment. Because you log every day trends and save them daily in a new .csv file. The actually date is coded in the file name. Now you want to send an email every day with the actually file. See the PG5 example below.

Note:

In the attached example the data’s will be stored daily. If you store the data’s weekly or monthly you have to adapt the program especially the file name in the log file inside of the SendMail FBox.

Additionally in the example is the function implemented that you can give directly the SMTP server name and the IP Address is not needed. The advantage is if your provider change the IP address you do not need to adapt the program see FAQ 101850 for more information about this topic.

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)

The MPI communication is no longer working since the firmwares 1.16.xx have been introduced.

Since a long time it is possible to use the MPI communication on the classic PCD.
Unfortunatly this communication is no longer working since the firmwares 1.16.xx have been introduced.
The concerned systems are the PCD1.M2xx0, PCD2.M5xx0, PCD3.Mxxx0 and PCD3.Mxx60.

This bug is now fix and it is once again possible to use the MPI communication with the firmware 1.16.52 or newer.

Remark:
Our PCDs are MPI Server (slave).

In some cases (if the Modbus server is rather slow) a minimum delay between two Modbus requests (which are sent by the Modbus client) is to be respected (e.g. if the server needs some time to correctly prepare its next response).

If the Modbus client (or master) doesn't respect this minimum delay time the Modbus server (or slave) can't treat all requests which will lead to communication errors.

How to define a minimum delay between two Modbus requests?
In PG5 1.4.300 (or higher) with version 1.0.17 (or higher) of the SBC Modbus FBox library it is possible to delay the request sent by a ModBus client to a Modbus server each time the request is sent.
The same function is available for PG5 2.0.110 (or higher) with the version 2.6.101 (or higher) of the SBC Modbus FBox library.

You can configure this Minimum Request Delay parameter either in the Init Client TCP extended FBox or in the Init Client RS extended FBox.

There are several reasons to use the FBox "SASI S-Bus Extended" (see FAQ 101400). But there is a limitation that it is not possible to use this FBox for re-assigning a port as Gateway master port on Saia PCD® COSinus systems.

Symptom
When re-assigning a Gateway master port using this FBox (or even in IL with the instruction SASI) it is not possible to assign the same port as Gateway master port after it has once been unassigned. This is the case if there is a falling and later on a rising edge on the input "Sasi" of the FBox "SASI S-Bus extended". On the second attempt to assing the port as gateway master port the FBox will get an error and the FBox LED becomes red:

• In the case you configure the GATEWAY funtion (in the device configurator and in the "SASI S-bus Extended" Fbox )
• The 1rst rising edge on the "SASI" input assigns the communication port (as serial master gateway)
  --> the Master-Slave communication works well.
• A falling edge (state "1" to "0") on ths "SASI" input de-assigns the corresponding communication port
  --> no communication is possible
• If you apply a 2nd rising edge on the "SASI" input, it will put the "SASI S-Bus Extended" FBox in ERROR. 
  A "Cold Start" is required in order to (re-)assign the communication port as serial Master Gateway port.

Reason
IT IS NOT ALLOWED TO DE-ASSIGN A MASTER GATEWAY PORT (an to re-assign it again) on Saia PCD® COSinus systems (PCD3, PCD2.M5, PCD1.M2 and PCD2.M480). This phenomenon is based on the internal mechanism how the firmware assigns the port. It has not been observed before the usage of the FBox "SASI S-Bus extended" as there are very few (if at all) reasons for un- and re-assigning a port as gateway master port.


Solution
In the case you configure the GATEWAY function (in the device configurator and in the "SASI S-Bus Extended" FBox )
WE RECOMMEND YOU TO CONNECT THE "SASI" TO A BINARY CONSTANT "1".

In this way the above mentioned problem will not occur. Please let us know in case you have an installation where it is required to re-assign a port in runtime as gateway master port.

When establishing Ether-S-Bus communication, the communication works fine, but the S-Bus Master IP FBox is turns red after a certain time.

Symptom
When establishing Ether-S-Bus communication, the communication works fine, but the S-BUS Master IP FBox is turned into red. No no communication problems are observed and registers, flags, etc. are transmitted correctly. But after some time the LED of the "S-BUS Master IP" FBox turns to red.
After a 'Restart cold all' of the CPU, the FBox gets green again.

Reason
On IP-networks, it's absolutely normal that communication retries of telegrams can happen from time to time (due to telegram losts). In this case, the PCD will re-try to send/receive the media automatically.
However, the FBox will indicate every retry with a red LED. Therefore, the red S-BUS Master IP FBox has to be considered only as a warning/information.

Solution
As the loss of a telegram from time to time there is no action required as long as only one retry is executed.
You can check the retry-counter in the Diagnostic FBox of the S-Bus communication library to find out that you're in this kind of situation.

There are several bus protocols that are called "C-Bus". Depending on the system, another philosophy to connect it to a Saia PCD® is to be choosen.

Communication with C-Bus
Please check whether the C-Bus you need to connect is one of the below listed:

• C-Bus from Honeywell
  The SBC PLC's don't offer an interface for C-Bus. To communicate with C-Bus a "MEKS Universal Gateway" can be used. This gateway translates the C-Bus protocol to SBC S-Bus. Please contact MEKS (see link below) for further information.
• C-Bus Cerberus/Siemens
  C-Bus is the internal bus for CS11 alarming systems.  gateway CK11 with DMS7000 protocol offers an RS232 connection and driver with a particular configuration tool is available from Engiby (see link below).
• C-Bus from Clipsal Integrated Systems Pty. Ltd.
  C-Bus is a bus for Lightning Control, A driver with FBoxes exists at Engiby (see link below).

The nowadays obsolete "Mode D" has been used for exchanging data between PCD systems and for accessing the PCD systems from a PC. The PGU mode of early PCD systems has been based on this communication mode.

History
Early PCD systems used the P800 protocol which bases on the Mode D as PGU protocol (for configuring and programming a PCD as well as for data exchange from and to the PCDs). The Mode D telegrams are in accordance with ISO 1745, IBM BSC (first defined by IBM in 1970, in the "IBM bisync publication) and DIN 66019 and has been used on serial lines.
Over the years the mode D became obsolete and has been replaced by much more powerful communication protocols which are not only implemented for serial interfaces (on the PCD these are e.g. Serial-S-Bus, Ether-S-Bus, Profi-S-Bus, FTP, http etc.). Due to this fact, the Mode D is no longer supported by recent PCD systems.

Systems supporting the "Mode D"
The Mode D is no longer used for PGU communication, and PCD systems which have been developed after the PCD2.M110/M120 do use S-Bus as PGU protocol. In a second step, the Mode D (SD/MD mode) has been removed from the firmware. Please refer to the table below which indicates the PCD systems which do support the Mode D:

The library Belimo 2.5.300 does not work with the card PCD3.F281 if you use the both channels of this card.

It is important to know that the Belimo library 2.5.300 is provided by default with PG5 1.4.300.

To use the card PCD3.F281, it is recommanded to install the library Belimo 2.5.301 or a later version.

You can find these libraries on the support site.
The path is: Software -> PG5 -> FBox libraries

Yes. This switch makes a refresh of the signal and the switchs can be used in cascade. The maximum distance between one switch and another is 100m.

In case your PC does not answer to a ICMP ping, it is very likely that your Windows Firewall is blocking the communication. In case you don't have "admin" rights to disable it, this FAQ might be useful...

Symptom
If you boot your computer without having a network connection, the Windows Firewall may block the communication to your computer. As result, even a "Ping" will not be answered by the concerned PC/Laptop.

Procedure for disabling the Windows Firewall
There is a way to disable the automatic Windows Firewall (installed per default for Windows XP) even if you don't have administrator rights.

• Go to the windows "Start" menu and select "Run".
• From there, open "services.msc" and a new window will open.
• On the right side, browse down until you'll find "Windows Firewall/Internet Connection Sharing (ICS)".
• Click on it with right mouse button down and select "Stop".

After having done so, you just disabled the automatic Windows Firewall. Don't forget to enable it again later. SBC does not take any responsability for problems caused by disabling the firewall.

Concerned PCD systems: All LON supported PCD systems

Problem
The Profi S-Link cable is not working anymore with newer firmwares. PCD3.M5xxx: 018; PCD2.M480: 025. The LED's are not switched on. Communication is not possible at all.

Reason
Due to a firmware bug, the 24 V power supply which is needed for the communication over Profi S-Link is no more supported on Port 10.

Solution
In the next official firmwares the problem will be corrected. If you need a urgent fix, contact our support support@saia-pcd.com to get the latest bugfix versions. (PCD3: #1B or higher; PCD2.M480: #26 or higher)

No, on the PCD a reduced RS 232 can be used (PCD7.F520 / one part of PCD7.F522). However, some communication partners will need full RS 232. In this case you can maybe handle it with a bridge or you have to use a Full RS 232 Port on the PCD, too (PCD7.F120 / PCD7.F522).

Yes, there are PCDs that support the transmission of EMails over an SMTP server if they are equipped with Ethernet interface.

The PCD types that support this feature are:

- PCD1.M1x5, PCD2.M150, PCD2.M170 and the PCD4.M170 equipped with PCD7.F650 or PCD7.F655.

- PCD1.Mxxx0, PCD2.M5xx0, PCD3.Mxxx and PCD7.D4xxxT5F (with Ethernet option).

Principle
The PCDs mentioned does support a System Function (SF) for sending (but not receiving) EMails over the SMTP (Simple Mail Transport Protocol). For sending the message, the SF is called and the subject, message content (text only) as well as the (multiple) recipients and the sender of the message are passed to the SF.
After that, the FW will handle the transmission by itself. If the server is not available, it is indicated in the diagnostics.

Programming
There are FBoxes available for sending the mails with or without password and with/without attachement.
It is also possible to use this functionality in IL.

Restrictions
Actually it's not possible to send EMails over SSL.
Therefore it's necessary to connect to a SMTP Server which does not require a SSL connection.

Only the PCD3.Mxxx, PCD1.Mxxx0 and the PCD2.M5xx0 support an authentification method (AUTH LOGIN and AUTH PLAIN) with unencrypted transmission of the password, but without SSL transmission.
Therefore with the other PCD, the SMTP server must allow sending EMails without requiring an authentification.
Since most mail providers found on the internet do absolutely require an authentification, it is possible to use their service for sending EMails only with the PCD3.Mxxx, PCD1.Mxxx0, PCD2.M5xxx or with a PCD7.D4xxxT5F.

PCD firmware versions
The following PCD firmware (FW) versions are the minimal versions that EMail functionality. However, it is strongly recommended using the latest official firmware version of the relevant systems.

For a good communication result the repeater must be configurated

 A repeater is used for decoupling RS 485 network.

The PCD7 T 100 reprocess signals and the electrical isolation of individual selection of the line.

The following settings are important for a good communication result:

Baudrate: (max 500 KBit ) DIL Switch SW1

Switchtime                           DIL Switch SW2

Termination for both networks (SW3 ex. side / SW4 trunkside)

Connection of non SBC devices:
Normally, the following symbols are used:

SBC                 Non SBC devices
D →                         D-
/D →                        D+
Rx →                        -Rx
/Rx →                      +Rx
Tx →                         -Tx
/Tx →                       +Tx

for more details see also: Manual 26_740_E4 RS 485 - Inst. Komp

An oscilloscope is an excellent tool for debugging RS 485 networks, as common errors like missing terminations, crossed lines, missing shield/ground connections can be detected. The attached Powerpoint document contains oscilloscope screenshots of the mentioned wiring problems, so you know what to look for.

The tool tracewin.exe is a small executable that records the communication between Saia PG5® and the S-Bus communicaiton driver. It is very useful in order to analyze the communication between Saia PG5® and the PCD's.

Since it logs the information of the SCommDll, it may also be used for recording S-Bus traffic of the SBC OPC server or any other software using the SBC S-Bus driver.

Opening Tracewin
The tool Tracewin is installed in the installation folder of Saia PG5® (default location: C:\Program Files\SAIA-Burgess\PG5 1_3\Tracewin.exe). It is to be called by double clicking it.

As soon it is called, the follwing window will be opened:

Configuring Tracewin
In order to record only the data needed, the "SComm Trace Options..." of the menu "File" can be adjusted.
E.g. the checkbox "Lock, Event, Critical" is only used in rare situations (but doubles the size of captured data if checked) and therefore narmally may stay unchecked. Below an example of the "SComm Trace Options" that suits in most cases:

In case no communication can be established, it can be helpful enabling all checkboxes in order to receive as many information as possible. As the file will be pretty small anyways, the additional lines won't bother much. 

Storing recorded data
The buffer finally may be stored with "Save as..." and then be viewed by any other text editor.
(The recorded data is very useful for the SBC support team in case you encounter a communicaton related problem.)

Yes, the product Saia PCD® COSinus (PCD8.DNET-SUITE) does also contain the SBC S-Bus libraries (S-Bus Master and/or S-Bus Slave) based on the Microsoft .Net framework.

How is the Saia PCD® COSinus structured?
The Saia PCD® COSinus contains different components (S-Bus Master, S-Bus Slave, an interface for CGI calls to the PCD Web Server etc.) for easy integration of the communication interface for PCD systems into Windows applications. All the components are based on the Microsoft .Net framework.

This product (PCD8.DNET-SUITE) does contain the required libraries, documentation, examples (programmed in C#, C++ and VB) as well as access to updates and new features.

How do I get the Saia PCD® COSinus Suite?
The Saia PCD® COSinus Suite is an official product from Saia-Burgess Controls AG and can be optained from your local SBC representative (or support@saia-pcd.com)

Remarks

• The product Saia PCD® COSinus can't be found yet on the support homepage www.sbc-support.ch (the TI will be uploaded soon).
  
• The Saia PCD® COSinus suite is the replacement for the inofficial SCommDll toolkit which has been available until November 2007. The SCommDll toolkit is discontinued and is no longer available.
  

The choice of communication protocols is huge, and a lot of them can be used together with our products. Please refer to the overview pages section of the supportsite www.sbc-support.ch for more details.

The firmware features of the PCD CPU's allow to realize virtually every protocol based on Ethernet or serial connections. If you don't find the protocol you search for in the above mentioned overview, please contact one of our system partners (for instance www.engiby.ch). They have already created numerous drivers and have got a profound knowledge of our products, which allows them to create new drivers in resonable time.

In some cases, you may need to access the files stored on the filesystem of a PCD where the PCD doesn't have a Ethernet connection.

It is possible to get this access via an USB cable and software SBC.Net.

SBC.Net is installed with Saia-Burgess Controls PG5

To access a RS 485 network from a PC / Notebook a converter is needed.

Problem
Since most notebooks do not have a serial port the PCD7.T120 (RS232-RS485 converter) cannot be used anymore. It is not possible to have a USB-RS 232 converter and afterwards the PCD7.T120 this will not work.

Solution
We successfully tested the following USB - RS 485 converter:

• Moxa UPort 1130. It works well with PG5 1.4 and PG5 2.0 on Windows XP and Windows Vista. 
• ICP DAS I-7561. It works fine with PG5 1.4 and PG5 2.0 on Windows XP SP2 or higher.
   

Important
Please note that the converter from ICP DAS only works for USB - RS 485. The USB - RS 232 option does not work properly.

Serial S-Bus is still very often in use for it's low costs combined with good communication performance. Unfortunately, nowadays it's quite difficult to buy a notebook PC which still has at least one serial COM port!

USB to RS-232 adapters may be a solution, but there is no guaranty that a specific adapter will work with SBC S-Bus properly.

The EXSYS PCMCIA card EX-1352 with 2 serial RS-232 ports has been sucessfully tested at our technical support department. We can recommend this card for use with SBC S-Bus and Saia PG5®. Also available from EXSYS, but not tested, are cards with 1 or 4 RS-232 ports plus a card with 2 surge protected RS-232 ports.

Detailed information about this EXSYS cards can be found at the EXSYS homepage:
www.exsys.ch/index.php

Distribution:
EXSYS Vertriebs GmbH
Industriestrasse 8
D-61449 Steinbach/Ts.
Tel.:+49 (0)6171 975656
Fax:+49 (0)6171 975697

Notebooks without RS232 COM-ports need a USB-Port and a USB to RS converter in order to connect a PCD over a serial line. Our experiences has shown that the driver software from some USB to RS-232 converters do not work in all cases (or not at all). This is why SBC tested various converters.

Please refer to the following list of converters which have been tested and found to be working fine with PG5 1.4, 2.0 and PCD8.D81W (for programming PCD7.D7xx displays, version V4.68 and later).

• Moxa UPort 1110 (RS232) and Moxa UPort 1130 (RS422/485)
  Works on Windows XP and Windows Vista for PG5 1.4 and PG5 2.0
  www.distrelec.ch
  
  
• BAFO BF-810   www.bafo.com
  works on Windows 98, 2000, XP
  
  
• ICP-DAS "I-7560"  www.redacom.ch
  
                               
• Converter USB2.0 to serial #61460 from www.delock.com
  tested on Windows XP, Vista and Windows7 (for Win7 the latest driver is required, see attachment)
  

Remark
Please note that a PCD8.K111 PGU programming cable is still required in order to connect in PGU mode to a PCD (the USB to serial converter does "create" an RS232 port on the PC but it does not cross the Rx/Tx lines which is necessary for RS232 connections).

Our USB driver cannot be installed, if is F-Secure Antivirus installed on your PC

The same behaviour occurs also if the Comodo Firewall is installed on the PC

The same behaviour occurs as well if the Client/Server Security Agent from Trend Micro is installed on the PC

A possible solution is to boot Windows in Safe prior to installing the driver

If a PC uses F-Secure Antivirus 5.40 then SBC USB installation hangs the whole operating system (only reset button can be used). If F-Secure is uninstalled, USB driver can be installed without any problem.

No. The standard USB cables type A-B available on the market can be used, but they shouldn't be too long (see related FAQ).

At the moment it is not possible to connect to several PCD's at the same time using the S-Bus USB channel.

Reason
Until now the communication "S-Bus USB" is realized as point to point connection. The communicaition driver (ScommDrv) will select the first SBC USB device that is listed by Windows and will establish a connection only to this device.
As conclusion, only one PCD may be attached to the PC over USB. In case two PCD's are to be prgrammed, the cable has to be unplugged of the first PCD and then be connected to the second PCD.

If a PCD is connected to the PC via USB cable, the new firmware PCD3 V010 and PCD2.M480 V020 do send a unique ID in their StringVendorRequest (iSerialNumber).

This has to be done this way because it's the only way to distinguish between several devices with the same VID/PID (VendorID/ProductID) in a USB bus system.

By default Window finds a new hardware for every new SerialNum. Therefore the user is prompted to re-install the USB driver every time a new PCD is connected to the PC. For sure that's not nice and we have modified the driver in a way that Windows won't ask for a reinstallation of the driver every time a new PCD is connected.
PG5 versions up to 1.3.120 will install the old version of the USB driver. For this versions it is recommended to uninstall the existing USB driver and afterwards installing the one attached to this FAQ. To do so, please follow the instructions below:

Procedure for updating the USB driver

• Close your PG5 and Web Connect applications but keep the PCD connected to the usb port of the PC

• Uninstall the actual USB driver from the Windows Device Manager.

  • Select the Window menu: Start, Settings, Control Panel, System
    §ix100214§

  • Select the Hardware dialog sheet and the button: Device Manager

  • Select the USB driver present under: DriverX USB (xxx)

  • To uninstall the driver, select the context menu: Uninstall
    §ix100215§

  • Unplug the PCD from the USB port of the PC

• Install the new driver

  • Store the new driver files attached to this FAQ into a temporary directory
    (files: SaiaDevice.inf, drvxusb-sys, Dxusb10.dll)

  • Plug your PC to the PCD and wait for the "Found New Hardware Wizard"

  • Select the radio button "Install from a list or specific location"

  • On the following window, select the radio button "Don't search. I will choose the driver location"

  • Browse to the directory with the new files listed above

  • In case the installer has found several files, select the correct source files from your temporary directory

After this procedure Windows won't prompt the user for re-installing a USB driver for every PCD as long as always the same USB port (PC side) is used. However, Windows appears to recognise a new device for every USB port on the PC/USB hub (also if exactly this device has been installed on the same USB hub but attached to another port.)

The tool tracewin.exe is a small executable that records the communication between Saia PG5® and the S-Bus communicaiton driver. It is very useful in order to analyze the communication between Saia PG5® and the PCD's.

Since it logs the information of the SCommDll, it may also be used for recording S-Bus traffic of the SBC OPC server or any other software using the SBC S-Bus driver.

Opening Tracewin
The tool Tracewin is installed in the installation folder of Saia PG5® (default location: C:\Program Files\SAIA-Burgess\PG5 1_3\Tracewin.exe). It is to be called by double clicking it.

As soon it is called, the follwing window will be opened:

Configuring Tracewin
In order to record only the data needed, the "SComm Trace Options..." of the menu "File" can be adjusted.
E.g. the checkbox "Lock, Event, Critical" is only used in rare situations (but doubles the size of captured data if checked) and therefore narmally may stay unchecked. Below an example of the "SComm Trace Options" that suits in most cases:

In case no communication can be established, it can be helpful enabling all checkboxes in order to receive as many information as possible. As the file will be pretty small anyways, the additional lines won't bother much. 

Storing recorded data
The buffer finally may be stored with "Save as..." and then be viewed by any other text editor.
(The recorded data is very useful for the SBC support team in case you encounter a communicaton related problem.)

More and more products are equipped with an USB port for programming, which is very useful.

The limiting factor for USB connections is the length of the cable. We recommend to use standard cables with a maximum length of 3 meters to ensure proper operation. There are longer cables on the market, but they can cause communication problems. You can as well buy active cables that extend existing USB cables and act like a hub. One of them with a length of 5 meters has been tested successfully, so this kind of active cable is worth a try if 3 meters are not enough.

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.

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

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

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

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

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

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

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

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

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

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

Instead of SBUS, Wireshark shows GVSP telegrams

Symptoms

You have installed the Software Wireshark Version >= 2.0.0 for analyzing the Ether-SBus IP-Traffic but you don’t see any SBus telegrams, the protocol is decoded as “GVSP” (GigE Vision Streaming Protocol)

Reason

From version 2.0.0 Wireshark has included a new dissector GVSP, which is apparently also working by default on the port 5050. Probably Wireshark gives precedence to the GVSP because comes earlier in the alphabetic order. (Sbus dissector was present already in Wireshark 1.0.0. …)

Solution

To ensure that the Ether-S-BUS is decoded correctly, you have to disable the GVSP protocol. On the following print screens it's shown how to do it:

If DHCP is enabled in the PG5 device configurator, then the PCD is no longer accessible via the SOCKET connection.

The problem occurs with FW1.22.28 and PG5 version < 2.1.310.

Reason:
If DHCP is enabled, the Parameter "CFG-SBusIp,Enabled" and CFG-SBusIp,PGU" are written to 0 and therfore the S-Bus IP is turned off.

Solution:
The problem has been corrected in the PG5 version 2.1.310

After a PG5 Update to the version PG5 2.1.210, the Ether S-Bus Communication is no more working.

The S-Bus client and server functionality is disabled in the Device Configurator.

Reason:

In the TCP/IP Setting Table in the column "0" there is no entry.

§Ix101578§

This entry is generated from the Device Configurator.
You can find it under Ether S-Bus, when you click on the row Ethernet in the onboard communication.

§Ix101579§

Solution:
The setting should be "default" and when you open it, Client and Server should be checked.

§Ix101580§

After saving this settings in the device configurator, the TCP/IP setting Table should be corrected.
To activate the new settings it's necessary to compile and download the project in to the PCD.

§Ix101581§

In seltenen Fällen ist die Ether-S-Bus Kommunikation bei Programmen die aus PG5 2.0 oder 2.1.200 in die PG5 2.1.210 importiert wurden nach einem Rebuild All und anschließendem Download nicht mehr in Funktion

Problem:
Hier ist beim Import des Projektes in PG5 2.1.210 die Einstellung der Netzgruppen verloren gegangen.
Dies ist ersichtlich, wenn in der 'TCP/P Settings Table' in der Spalte '0' kein Eintrag vorhanden ist.
§Ix101578§

Abhilfe:

Im Device Configurator bei der Onboard Kommunikation Ethernet auswählen

Anschließend in den Eigenschaften die Netzgruppe wählen und 'Default' auswählen.

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)

Sometimes Network administrators ask for the MAC address of PCD devices with Ethernet connections for setting up their network devices.

There is a sticker at the backside of the PCD that indicates the MAC address but if you aren't on site this isn't helpful.

With older version of PG5 1.4 and with PG5 2.0.220 and newer it is possible to check the address in the Online Configurator with the button information. This works for PCD1.M2120, PCD2.M5540 and all PCD3.Mxxxx with Ethernet connection. In PG5 1.4.301.15 the field MAC address remains empty.

There is another way to get the MAC address of a PCD with Ethernet connection.
Open the Online Debugger and enter D for Display and S for CPU-Status. This works for PCD1.M2120, PCD2.M5540 and all PCD3.Mxxxx with Ethernet connection




Remark:

There is a more general way to find the MAC address of any intelligent network device with the help of the ARP protocol.
It's also the only possible way to to find the MAC address of "not NT PCD's" (PCD1.M1, PCD2.M1, PCD4 and PCD6) devices that are equiped with a PCD7.F655 Ethernet module.
With Microsoft Windows NT 4.0 or newer you can open a cmd-Window and execute the 2 following commands:
ping ip-address_of_device
-> There must be a relpy from the device
arp -g ip-address_of_device
-> the MAC address of the device will be displayed

If the S-Bus communication over TCP/IP between PCD’s does not work, then do check on the TCP/IP settings table of the PG5 project manager that the field “use” is checked for each line (device) which have to communicate over S-Bus TCP/IP.

It’s possible that after an import of a PG5 1.4 project in to PG5 2.0 the field “use” on the TCP/IP settings table is unchecked and therefore the communication over S-Bus TCP/IP doesn’t work.

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

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

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

The first generation of PCDs with integrated S-Web server did not support http-direct (e.g. the PCD1.M125, PCD1.M135, PCD2.M150, PCD2.M170, PCD2.M480) . Therefore the access of the S-Web Server must be realized using the free software "S-WebConnect" which is to be installed on a PC (accessing the PCD using e.g. Ether-S-Bus). Alternatively, an MB Panel can also access the S-Web Server (e.g. using Ether-S-Bus).

However, it is important to know that only one S-Bus client can access the S-Web Server over Ether-S-Bus at the same time!

Problem
By desing the S-Web Server of a PCD can only be accessed by one S-Bus connection per physical port (Serial-S-Bus, Profi-S-Bus, Ether-S-Bus). As result it is possible to access the S-Web Server over Serial-S-Bus and in parallel over Ether-S-Bus, but it is only possible to have one Ether-S-Bus Master which connects the S-Web Server.

That means it is not possible to access the S-Web Server of a PCD at the same time with the S-WebConnect (Ether-S-Bus) and the MB panel (Ether-S-Bus) because in this case the S-Web Server is accessed 2 times trough the same physical port (Ethernet Port).

Work around 
Here you can use the Web Connect as frontentd. The S-WebConnect will serialize the web requests and therefore avoid two parallel connections.

• The WebConnect creates only 1 connection to the Eternet Port of the PCD (Ether-S-Bus to a PCD1.M135 for example)
  --> there is no problem, because only one connection was created
• With the MB panel, instead to accessing the WebServer of the PCD directly (with the Ether-S-Bus protocol), the MP panel can be accessed indirectly via the S-WebConnect.

Example
For this example the following configuration is to be done in the MB panel configuration:

• HTTP direct
• Remost host IP of the PC (where the WebConnect is installed)
• as html file to open, you have to write: WebConnect_Connection_Profil/File_Name.html (htm)

For more information please refer to the manual for the "Web Server Classic" (26/790).

Since summer 2010 the PCD3 family (PCD3.M2xxx, PCD3.M3xxx, PCD3.M5xxx and PCD3.M6xxx) do support the "full-duplex mode" and Auto-MDIX on the Ethernet port.

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

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

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

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

Remark

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

When establishing Ether-S-Bus communication, the communication works fine, but the S-Bus Master IP FBox is turns red after a certain time.

Symptom
When establishing Ether-S-Bus communication, the communication works fine, but the S-BUS Master IP FBox is turned into red. No no communication problems are observed and registers, flags, etc. are transmitted correctly. But after some time the LED of the "S-BUS Master IP" FBox turns to red.
After a 'Restart cold all' of the CPU, the FBox gets green again.

Reason
On IP-networks, it's absolutely normal that communication retries of telegrams can happen from time to time (due to telegram losts). In this case, the PCD will re-try to send/receive the media automatically.
However, the FBox will indicate every retry with a red LED. Therefore, the red S-BUS Master IP FBox has to be considered only as a warning/information.

Solution
As the loss of a telegram from time to time there is no action required as long as only one retry is executed.
You can check the retry-counter in the Diagnostic FBox of the S-Bus communication library to find out that you're in this kind of situation.

For connecting a PCD to the internet a router is required. In case this router "knows" a DynDNS service, it is possible to find this this router by name.

The attached document contains an example of a step by step procudure for configuring dynamic DNS on a router (which "knows" DynDNS).

Remarks

• Note that the choice of the router or the DynDNS service from this document is sheer coincicence and does not mean that only this router works with PCD systems.
• Saia-Burgess Controls AG can not give support for the router configuration or the DynDNS setup. For support request regarding the router functionality or DynDNS please contact the according provider. 

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

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

For more information please refer to the FAQ 100785

Depending of the applications different ports are used on the PCDs:

The use of DNS (Domain Name Service) is very convenient for remembering the address of a host (e.g. a PCD3 connected to the internet with a DSL router). However, in some cases it is necessary to know the IP address of this host rather than the domain name.

How to translate the URL of a host to its IP address?
This task can be done by the tool "nslookup" which is installed on every Windows system:

• Open the DOS console (from the "Windows Start menu" select "Run..." and type in "cmd") 
• Type in the the instruction
  nslookup myname.dyndns.com.
  
  (don't forget the point after the URL)

As response you will receive the IP address of the requested name. In the screenshot above the IP address of the host "durrer.dyndns.tv" is 83.222.146.209.

As a PCD system does feature various "Internet communication features" (Web Server, Ether-S-Bus, SMTP etc.), it suggests itself to connect it to the Internet using e.g. an (A)DSL router. This FAQ is aimed to explain some key-points to be considered for accessing a PCD over the Internet.

General introduction
For connecting a PCD to the internet using an ADSL router, the principal understanding of the functionality and tasks of a router need to be understood. In a second step, the communication protocol for the connection is to be defined because
every of the following protocols does require other configurations of the router. The attached document tries to explain the router functionality and tries to point out relevant information for connecting a PCD to the Internet and realizing the communication over the following protocols:

• http direct (for accessing the Web Server of the PCD, don't forget the password protection of the Web Server)
• Ether-S-Bus (not recommended unless you are using a secure VPN connection)
  - for programming the PCD with PG5
  - for connecting a PCD which does not feature http direct with WebConnect)
• SMTP (for sending EMails from the PCD)

For each of these protocols, please refer to the corresponding chapter in the attached document.

Important remark concerning security
Please consider the fact that the connectivity of a PCD on the internet does also mean that everyone can connect to the system. Therefore the interfaces over which the PCD can be reached from the internet need to be protected additionally (if the web server can be reached from the internet and no security is implemented, everyone can e.g. modify Register values on the PCD which can lead to malfunction of the application).

We therefore recommend whenever possible to use a VPN connection rather than just forwardig ports.
If this is not possible:

• Enable the password protection of the S-Web server (this can be configured in the PG5 Device Configurator)
  Note that the password macro in the Web Editor does NOT secure the access to the media of the PCD (but only the access to the Web Editor Pages)
• Remove the default user "root" from the FTP server (can also be done in the PG5 Device Configurator)
• Do not enable Ether-S-Bus unless the PCD is connected over a VPN connection only (because even with the password protection of S-Bus will still allow everyone to modify media values as e.g. Register Values)

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

Due to a problem of Windows XP and Windows Server 2003, the SCOMMDRV.EXE can exhaust all available memory when using "socket communication" (Ether-S-Bus). The memory leak is related to the "Windows XP Themes" and Microsoft provides a patch for this problem.

Symptom
When using the Microsoft Windows XP Theme (see screenshot below), the Scommdrv.exe leaks memory every time a Ether-S-Bus (Socket) connection to a PCD is disconnected. This can lead to a system crash when all available memory is exhausted.


Reason
This problem occurs because of a bug in the implementation of the new Windows XP theming interface. MFC applications leak GDI objects on computers that are running Windows Server 2003 or Windows XP.

Solution
Please refer to the link below which points to the Microsoft Support page which explains the probelm and from where a patch can be downloaded.

Note
This problem concerns all applications using the SCommDrv.exe and communicating with Sockets (--> PG5, OPC Server etc.). WebConnect 2.x is only concerned if the SComm driver is selected.

It is possible capturing the traffic on a Ethernet network and stop this capture based on a specific condition, like e.g. the lack of Ether-S-Bus telegrams from a specific station for a certain time. However, this can't be done within Wireshark itself, but by using its command line tool TShark which is piped to a Perl script.

Introduction
The attached script written in Perl (a free dynamic programming language) does call TShark which is the command line interface of Wireshark. TShark will then output the interpreted telegrams to the script, which will load a timer every time an Ether-S-Bus telegram from the station in question is "seen". If this timer elapses, the capture is stopped.

Usage
In order to use this script, execute the following steps:

• Install Wireshark 0.99.2 or later (latest possible is 1.4.9; 1.6 does no longer work)
• Install the scripting language Perl (ActivePerl)
• Open the script with a text editor and adapt the IP addresses
• Run the script 

In case that two IP addresses are assigned to the same Ethernet card (Ethernet port) on a PC, it is possible that the communication does only work on one of the two IP addresses. This problem is caused by the operating system (Windows XP) and is due to insufficient buffers.

Symptom
Only one Ether-S-Bus communication is working if there are two addresses assigned to the same Ethernet interface on the PC (running Windows XP or W2k). A tracewin log indicates the error message:
Error Message 10055 (WSAENOBUFS)

Reason (according to microsoft support)
An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full (as the SBC driver is concerned because it is using TCP port 7000 to communicate with its dll). Please refer to the microsoft support page (link below) for furhter information.

Solution
Please refer to the link below (pointing to the microsoft support site, as this is a problem of Windows and not from PG5).

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

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

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

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

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

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

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

If the local station communicates in Open Data Mode with more than one remote stations, so respect priority in handling the content of the "Channel Register" (indicator for which Channel the data did arrive).

If the local station communicates in Open Data Mode with more than one remote stations, so respect priority in handling the content of the Channel Register (indicator for which Channel the data did arrive).

The global diagnostic flag RDATA is set to high to indicate that some data did arrive from a remote station. The Channel Register (see CSF InitODM) contains the value to which channel the data is to deliver. Be careful and copy this value into a local register before reading the data with the CSF ReceiveData/ReceiveDataRev. Otherwise, the Channel Register risks to contain already the next value, for the next  pending telegram. After executing the ReiceiveData/ReceiveDataRev CSF, combine the captured data with the channel stored in the local register. 

Also the Saia PCD® COSinus based PCD systems (PCD2.M480, PCD2.M5xx0, PCD3.Mxxx0) do feature 16383 registers, not all these registers can be accessed from systems which do only feature 4095 registers over S-Bus.

For analyzing Ether-S-Bus communication or Ethernet communication in general, we recommend using the free software Wireshark.

For analyzing Ether-S-Bus communication or Ethernet communication in general, we recommend using the free software Wireshark (which is the successor of Ethereal). While a special plugin for Ether-S-Bus is required and has to be installed manually when working with Ethereal, Wireshark "knows" Ether-S-Bus automatically because the according dissector is installed by default.
The software Wireshark can be downloaded from www.wireshark.org and offers the possibility of recording the network traffic of your ethernet network.
A very high number of different protocols are supported by this analyzer. This allows you not only to see the single telegrams but also understanding what is going on on your network.

Ether-S-Bus and Wireshark
Version 1.0.0 and all later versions of Wireshark do "understand" Ether-S-Bus:

Important note
Wireshark can only "see" telegrams that do reach the ethernet port of the PC on which it is installed! In case a switch is used in your network, this switch will not forward all telegrams on all ports but only on the ports on which the according device is connected.
Therefore you either have to install a hub or you have to connect your PC to the "service port" of the switch (if available).

Updated version of Ether-S-Bus dissector in Wireshark 1.5.0 an later
The Ether-S-Bus dissector has been improved and extended in Wireshark version 1.5.0 (development release) with the following features:

• Added the display filter sbus.retry for finding re-sent request telegrams
  In order to get a better overview over the Ether-S-Bus traffic the telegrams displayed by Wireshark can be filtered by the "Display filter" (in the above screenshot the display filter is "sbus" which leads to the fact that only Ether-S-Bus telegrams are displayed.

• Added the possibility to jump from the request telegram to the response telegram

• Added response time to the response telegram

• Added expert info (menu "Analyze" --> "Expert Info")
  Lists telegrams with wrong CRC, Ether-S-Bus retries or NAK responses from the PCD.

• Added telegram types "Read/Write Block" (e.g. downloaded files to T665 or PCD.SCFG)

• Support for extended packet size for read/write block telegrams

• Corrected the "Read System Info" telegram (CRC was not correctly calculated)

How to get Wireshark 1.5.0?
Please note that 1.5.x is a development release and therefore it might be that not all functionality is guaranteed.
An installer for the latest development release from Wireshark can be downloaded from the automated build section (link below) from the Wireshark homepage (link below).

In order to achieve a high and constant data throughput with S-Bus, the following guidelines can be helpful for the programmer of S-Bus communication.

S-Bus in Fupla

• Fupla handles all Transmit- and Receive FBoxes equally. By default, all requests are handled cyclically and are serialized automatically.
  This means that the value of an alarm flag is sent as often as the value of an outside temperature (that generally doesn't change within minutes).
   
• S-Bus communication is always commanded by the user program. The performance can be influenced by the cycle time of the user program.
  Given the cycle time of the user program is 300 ms, in maximum one telegram will be sent every 300 ms, too.
   
• Every FBox creates one telegram per communication cycle.
   
• A telegram can hold up to 128 bytes (array of 32 registers or 128 flags).
  The transmission of a telegram that contains 128 bytes doesn't take much longer than the transmission of a telegram with 1 bit data (the times are depending on the baud rate).
  On the other hand, sending two telegrams take double the time than sending one telegram.
  This results in the fact that the performance is rather depending on the amount of  telegrams than on the bytes transmitted.

Conclusions

• Send multiple medias with one FBox whenever possible.
  Use the FBoxes "Transmit- respectively Recive quick".
   
• In order to increase the communication performance, it is recommended sending slowly changing values in intervals.
  
  One possible solution for this could be two or more send- or receive FBoxes that are enabled alternatively (see fupla page above). Make sure the enable time of each of these FBoxes is at least equal to the communication cycle. 
   
• Transmit In- and Outputs as flags (in an array). Or, even better, map them into registers.
  This way telegrams (and therefore communication time) can be spared.
   
• Use the "S-Bus station (-IP)" FBox in order to avoid massively higher communication cycle times in case of a slavestation failure!
  This FBox does not constantly send telegrams to a station known as missing but only in intervals (after a short- or long reconnect time). Also refer to FAQ 100496 in case PCD7.Lxxx modules are used.
   
• For receiving slowly changing values consider using the FBox "Receive Integer Multiple" (only PG5 1.4 and higher)

Depending on the project not all or only few of these actions can/should be taken.

The Ether-S-Bus plugin allows filtering the captured telegrams based on one or several properties of the telegram such as the command code contained in the telegram and/or the value of a transmitted media etc.

Principle
Wireshark basically offer two different possibilities for filtering Ethernet traffic:

• Capture filter:
  Filtering while capturing based on the source/destination IP or the TCP/UDP ports used). Telegrams that do not match the filter are not stored to the capture file! Please refer to FAQ 100224 for more information.
• Display filter:
  Filtering  the telegrams of a captured file based on the telegram contents (command code, presence of values etc.). The display filter will not affect the data captured, it will only select which packets of the captured data are displayed on the screen.

Display filters
The plugin for dissecting (interpreting) Ether-S-Bus traffic offers a wide range of telegram properties and filter conditions. Below a small selection of the most used fields:

• Command code
• Source- destination S-Bus address
• Baseaddress of transmitted media
• Values of transmitted media
• etc...

Using filter strings
The filter strings, written in a special display filter language are entered in the "filter field" (green region in the picture below) of Wireshark:
§ix100349§
By pressing the "Expressions" button, the following window shows up. From this window, the available filter expressions and conditions can be selected.
§ix100350§
It is also possible combining multiple filters by using the AND- and OR operands:

• And operand: && (Example: sbus.cmd == 0x6 && sbus.destination == 1)
• Or operand:  || (Example: ip.addr == 207.1.1.222 || sbus.destination == 1)

Everytime you change the filter string and click the "Apply" button, all packets will be reread from the capture file (or from memory), and processed by the display filter "machine". Packet by packet, this "machine" is asked, if this particular packet should be shown or not.

Yes it’s possible to modify the TCP/IP settings like “IP Address”, “Subnet Mask” or “Default Router” of the PCD trough the application program.

The change of the TCP/IP settings can be performed during start up of the PCD (XOB 16) or during the normal program cycle (COB).

• It’s only possible to change the parameters “Subnet Mask” or “Default Router” trough the application program if on the PCD either no extension memory is plugged or if a RAM extension memory is plugged on the PCD.
• If the PCD is equipped with EPROM or Flash extension memory then the parameters “Subnet Mask” or “Default Router” can’t be changed trough the application program.
• After the execution of the CSF instruction the new settings of “Subnet Mask” or “Default Router” are not taken in account from the PCD7.F650 module until the PCD is powerd off/on.
• To activate the new settings of “Subnet Mask” or “Default Router” a power off/on of the PCD is required.

• It’s possible to change the parameters “Subnet Mask” or “Default Router” independent of the type of extension memory or if a extension memory is equipped or not.
• The new setting for the “Subnet Mask” or “Default Router” are taken in account immediately after the execution of the CSF instruction.
• No power off/on of the PCD is required to activate the new settings.

Yes, the company "M+S Industrielle Automation AG" has developped a WinCC driver for Classic Saia PCD® devices.

The driver is realized as plugin for WinCC and supports S-Bus (S-Bus USB, Ether-S-Bus, Serial-S-Bus). Among others a version for WinCC 7.0 SP1 is available. The current documentation is in German.

For more information contact M+S, Winterthur, Switzerland:
URL:   www.msia.ch/
EMail: info[at]msia.ch

TCP/IP communication is generally possible on the PCD1.M120 and M13x, on PCD2.M150, PCD2/4.M170, PCD2.M480 and on all PCD3 with TCP/IP communication port.

Minimal firmware- and hardware version for TCP/IP communication:

Generally we recommend to use always the most recent firmware available for download on our supportsite.

The instruction nslookup allows to find out the TCP/IP address of a public e-mail server.

To know the e-mail address of a public e-mail server enter the following string on the command window of windows.

nslookup

After this you have to enter the smtp address of the e-mail server.
(On the example below it's the address smtp.green.ch)

The TCP/IP address of the e-mail server is shown on the next line below the name of the smtp server.
(On the example below it's the address 81.221.250.52)

§ix100292§

If there is only one CPU in the project you are not able to asign a SASI S-BUS Master IP.

Problem
An error is assigned after the download of a project with SASI S-BUS Master IP implementation. Error Message in History: IP Fail Sasi DBX.

Reason
If only one CPU is in the project and in the IP Table, the master has no communication partener an therfore it will indicate an error.

Solution
Add a second CPU with TCP/IP configuration to the project (it can be a dummy station). Afterwards you have to rebuild and download the programm of your first CPU, since the new IP-Table has to be downloaded to the station.

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

The PCD2.M480 does support the following baudrates:

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

You can't connect over any channel to a PCD by using the SCommDll . The software firewall softwares "Zone Alarm Security", "Windows Defender" or "Bitdefender" block the SComm funktionality on PC's running MS XP.

Symptom
If the ScommDll is launched, the PC won't react on key strikes for more than 40 sec. After this time, an error message is displayed saying "SCommDll error, Socket not installed or wrong server IP number".

Reason
The software firewall "Zone Alarm Security" blocks the ScommDll (The SCommDll communicated to the SCommDrv over an IP stream on port 7000 that is blocked).

Solution
Zone Alarm must be uninstalled; only deactivating won't work in most cases. This phenomenon was only observed on Windows XP. On W2k it seems that the ScommDll works also with ZoneAlarm activated.
In case the Bitdefender is used either disabling or appropriately configuring should help.

Hints

• The behavior descripted above does also apply to many other Personal Firewalls (aka Desktop Firewalls, Internet Security Suites etc.). So if socket communication does not work, these security tools should be checked.
• Most Personal Firewalls can be configured by so called "rules", which allow to open certain ports for one or more applications. So instead of totally disable or uninstall der firewall software, it may be a better solution to define apropriate firewall rules which allow SCommDrv to communicate anyway.
  For the relevant PG5 parts SCommDll.dll and SCommDrv.exe to work the TCP port 7000 needs to be enabled on the local host!

There have been some limitations according the IP norm that allowed only certain combinations of IP adresses and subnet masks (only classful networks with subnetting were allowed). However, these limitations are (or will be) removed in recent firmware versions according the Classless Internet Domain Routing (CIDR).

Introduction
The IP stack of our PCD controllers (PCD3 and PCD7.F655) was only supporting "classful networks with subnetting" according to the official IP standards. As result only IP address/subnet masks that conformed to the "classul networks with subnetting" were allowed in certain firmware versions of the PCD3 and the PCD7.F655. If the address/subnetmask was not conform to the rules (because e.g. supernetting was applied), the communication didn't work.
We are now introducing the "Classless Internet Domain Routing" CIDR to our stack which provides increased flexibility when dividing ranges of IP addresses into separate networks.

Classful networks
In classful networks (without subnetting) it is possible deriving the subnet mask based on the IP address accoring to the table below.

Further on, subnetting can be introduced by extending the "network portion" by using a part of the "host portion" (the right side of the subnet mask, in the classful network filled with "0"). Subnetting works with all PCD firmwares but supernetting does not (see example below).
The PCD3 firmwares older than the one mentioned in the table below does not allow class A or B subnet masks if the IP adresses are not in the defined range (because this would be supernetting).

Classless networks
For the "Classless Internet Domain Routing" CIDR the network classes mentioned above aren't relevant for the subnet mask any more. Therefore it is possible to define any subnet mask (subnetting and supernetting is allowed). Of course the network will only work properly if all the devices are configured correctly.
When in doubt about the required subnet mask for your PCD, please contact your network adminstrator.

Example
§ix100487§

Firmware versions introducing CIDR

In a S-Bus network, programmed with FUPLA, when a slave station is disconnected or powered off, the communication can be very slow.

all requests to the disconnected stations will cause a dead time in the polling cycle.
This dead-time is at least equal to 3 times the timeout for each request. When programmed with Fupla, each SND/RCV Fbox send one request. The dead times are specially long with low baudrate and over Modems. How to avoid this dead-time ? There a useful but often unknown function in Fupla. It's the Station Fbox. You need to place one of this Fbox for each Slave station. A disconnected or powered off station will automatically be disabled after a failing request and further dead times are avoided. The station is automatically reconnected after an adjustable delay.

Read the Help for more details.

In order to synchronize all PCD clocks on a network (Serial S-Bus, Profi-S-Bus or Ether-S-Bus) the FBox "Broadcast Clock" from the standard family "Communication" may be used. Depending on the range where the Broadcast message shall take effect the parameter "IP Node/Profi-S-Bus Address" has to be set correctly.

Depending on which kind of network this Fbox is used, different values for the parameter "IP Node/Profi-S-Bus Address" are to be entered. Below you can find a description of the different usages:

Use on Serial-S-Bus network
Genarally the FBox generates a S-Bus broadcast telegram (to the address 255 which is the broadcast address of the Serial-S-Bus network). On a Serial-S-Bus network the parameter "IP Node/Profi-S-Bus Address" has to have the value 0 since no Ether-S-Bus nor a Profi-S-Bus network is present. 

Use on Ether-S-Bus network
On a Ether-S-Bus network we can decide whether the broadcast shall be sent to the whole IP-subnet (including all Serial-S-Bus subnets connected to it) or only to one Ether-S-Bus station and all its sub stations (if present):
§ix100348§

• Given the Node 3 is time master, it is possible to send the broadcast to all Ether-S-Bus stations and their subnet stations (region B in picture above). In this case the Parameter "IP Node/Profi-S-Bus Address" of the Broadcast Clock FBox has to be set to 65535 (IP Node for broadcast address).

• If only the PCD clocks of region A in the picture have to be set, the node of the gateway to the subnet A (in this case the node 1) has to be set in the parameter "IP Node/Profi-S-Bus Address" of the Broadcas Clock FBox.

Use on Profi-S-Bus network
In order to send the telegram to all stations connected the Profi-S-Bus network, the "IP Node/Profi-S-Bus Address" needs to have the value 127 (which is the broadcast address for the Profi-S-Bus network). At the moment the possibility for sending only to the subnet of one station isn't introduced.

Note that since the sent telegram is a broadcast telegram the slaves won't answer with a "ACK" (acknowledgement) telegram. Therefore the LED of the FBox will remain green also if not all of the slaves have received the telegram.

The tool tracewin.exe is a small executable that records the communication between Saia PG5® and the S-Bus communicaiton driver. It is very useful in order to analyze the communication between Saia PG5® and the PCD's.

Since it logs the information of the SCommDll, it may also be used for recording S-Bus traffic of the SBC OPC server or any other software using the SBC S-Bus driver.

Opening Tracewin
The tool Tracewin is installed in the installation folder of Saia PG5® (default location: C:\Program Files\SAIA-Burgess\PG5 1_3\Tracewin.exe). It is to be called by double clicking it.

As soon it is called, the follwing window will be opened:

Configuring Tracewin
In order to record only the data needed, the "SComm Trace Options..." of the menu "File" can be adjusted.
E.g. the checkbox "Lock, Event, Critical" is only used in rare situations (but doubles the size of captured data if checked) and therefore narmally may stay unchecked. Below an example of the "SComm Trace Options" that suits in most cases:

In case no communication can be established, it can be helpful enabling all checkboxes in order to receive as many information as possible. As the file will be pretty small anyways, the additional lines won't bother much. 

Storing recorded data
The buffer finally may be stored with "Save as..." and then be viewed by any other text editor.
(The recorded data is very useful for the SBC support team in case you encounter a communicaton related problem.)

In order to connect PCDs and PCD7.D7xxET terminals on a remote TCP/IP network the use of an ISDN router possible. Internal tests have proven that this is no problem.

In order to get an overview of possible problems that might occur while setting up and working wiht a remote IP network connected via two ISDN routers or an ISDN TA (terminal adaper) and an ISDN router the following  constellations were set up:

§ix100165§

§ix100166§

In this test we used two AR140 ISDN routers (model number: AT-AR140S-513) of the manufacturer Allied Telesyn. This routers do have an integraded 4-port hub and a firewall (that wasn't tested in our test).

We didn't encounter problems for this constellation and found the following test results:

• It is possible to download projects of the PCD8.D81W (VTWIN) to PCD7.D7xx equipped with an Ethernet interface without someone on site

• The connection is established automatically in case of the use of two ISDN routers

• It is possible to download PG5 projects to PCDs (Ether-S-Bus stations) having an Ethernet interface

• A connection can also be established by first activating a dial-up connection and then adding a route (while the tests the added route over a Dial-up connection was removed at disconnecting)

• The networks can be defined by the user (no DHCP is required) on either network constellation

• Proxy servers and already existing network functions aren’t affected if properly configured (exception is the setup procedure of the ISDN routers due to the need of DHCP and set proxy addresses onto the routers!)

• All cables in the installation aren’t crossed (since the internal hub of the routers do feature an uplink which has to be set to “Hub” in case the connection PC-Router is going over an hub (hub-hub connection which would require a crossed cable if no uplink port were available))

For further information please refer to the test report (attached to this FAQ, file "ISDN-Router.pdf").

Under some circumstances (if e.g. a connected switch is locked to 100 MBits and has no auto negotiation mode) it may be required that the autonegotiation mode of a PCD7.F65x is swiched off and the speed and Duplex mode are set by the user program. In this FAQ the procedure to do so is described.

The configuration of the Physical Chip of the PCD7.F65x is to be configured by using the System Function ConfigurePHY. This function first was introduced in the following FW versions. Make sure the PCD used has the concerned FW (or a later version).

Below you can find the syntax of the relevant CSF:

Where the following values are possible

Note:
On the PCD3 or PCD2.M5 systems it is not possible to switch off the autonegotiation. This option has been realized because in some very rare cases some problems occurred in relation to the PCD7.F650 interface card. As no such problems have been observed on PCD3 and PCD2.M5 systems, it was decided not to implement this mechanism on these systems.

The free ethernet analyzer Wireshark do offer a capture filter that allows capturing telegrams on an IP network based on the source- and destination station or the TCP- or UDP port.

Capture filters
Capture Filters are used to filter out uninteresting packets already at capture time. This is done to reduce the size of the resulting capture (file) and is especially useful on high traffic networks or for long term capturing.
Wireshark as well as Ethereal do use the pcap filter language for capture filters. This language is explained in the tcpdump man page (www.tcpdump.org).

Procedure
For configuing a capture filter open the "Capture Options" window from the menu "Capture" --> "Options". In this window a capture filter can be set:
§ix100351§
This filter will be applied for the next capture.

Filter expressions

• Filtering telegrams coming from or going to a specific IP address (traffic from both, TCP/IP and UDP/IP will be captured).
  host 172.18.102.55
• Filter expression for capturing only Ether-S-Bus telegrams:
  udp port 5050

Combining filter expressions
It is also possible combining several expresions. One often used expresion could be:
<font style="BACKGROUND-COLOR: #ffffff">host 172.18.102.55 and udp port 5050
</font>

Storing capture filters
In Wireshark open the menu point "Edit" --> "Capture filters", and enter there a name which you want and for the Filter string. After that, edit your filter:
§ix100358§<font style="BACKGROUND-COLOR: #ffffff">
</font>

Note
It is also possible to filter the telegrams of an already captured file. In this case the "display filter" is to be used (refer to FAQ 100535). The display filter syntax is not identical to the capture filter syntax. The equivalent example of the mentioned "host 192.168.12.89" for the display filter is "<font style="BACKGROUND-COLOR: #ffffff">ip.addr == 192.168.12.89</font>"

Also this option can be useful for viewing only the telegrams that belong to the device to be debugged, it is possible that the troubles of a station are caused by telegrams that are not directed to the station in questions (e.g. Broadcasts). Therefore it makes sense also having a look at the rest of the traffic on the network.

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

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

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

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

If a S-BUS master IP is placed in a fupla file you will absolutely need a second CPU in this project. Otherwise the FBox won't work due to a SASI error.

If ther is a S-BUS master-IP FBox in the program of  your CPU and no second CPU (equipped with an IP interface) is part of the project (or at least entered in the IP-table), the PCD will get a SASI error because the PCD can not communicate.
The reason for this behavior is the lack of any other known IP address except of the address of the CPU itself.

To avoid this problem in case you need to have only one single CPU per project the IP table of the partner station(s) have to be exported and then imported in the concerned CPU.
Note that this has to be done also vice versa in order to avoid the same error on the other stations.

For IL programmers: The same problem occurs with the IL instruction SASI in the mode IPM.

The whole Ethernet network must be defined in

the same project in the project manager.

An Ethernet station needs an allocation table containing the IP address and IP node of allstations in the network. This allocation table is generated automatically by the hardware configurator and downloaded in a DBX on the PCD.<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

The hardware configuration of all PCD systems in the Ethernet must therefore be defined in

the same project in the project manager.

If several people are programming different PCD stations in the same project, it is

recommended that the whole network configuration should first be defined on one

programming PC. This configuration should then be copied or imported onto the other

programming PCs.

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.

How to figure out which firmware version a PCD7.F65x does have?

The FW version can be read out using the Online Debugger of Saia PG5® Controls Suite.

Depending on the CPU type on which the PCD7.F65x is mounted the memory range where the FW version is written in changes. To read out the corresponding memory range type:

Display Byte [ADDRESS] [ENTER]
As result you'll see something like:
00940010  50 43 44 37 46 36 35 30-00 32 05 24 20 48 FF 00   PCD7F650..2.$0Hy.
where the above yellow marked part is the FW version of the PCD7.F650.

Find below the address ranges of the IP module FW signature according to the different CPU's:

*) On a PCD2.M480 the FW of the PCD7.F650 is listed in the "CPU Status". Note that this only works with FW versions of the PCD2.M480 newer than V010 and only with PG5 1.3.

Very cheap Ethernet network components are available on the market, but they are not suitable for infrastructure and industrial applications.

If only a switch for conneting PCDs within small distances is required we recommend applying the 5 port switch Q.NET-TX5 for DIN Rail mounting available from Saia-Burgess Controls AG. More information regarding these switches can be found on the support page, in the section "Programmable controller" --> "PLC Accessories".
For connecting Ethernet devices, CAT5 patch cables (other better) are recommended. Please note that the maximal distance between two Ethernet devices connected with a patch cables is 80 to 100m. This distance can be extended by placing a repeating device in-between (e.g. a Q.NET-TX5).

For bigger distances and we recommend to use fibre optics products from Hirschmann ( portal.hirschmann.com ) as switches or routers, as they are designed for

• industrial environment (high immunity)
• 24 VDC supply
• DIN Rail mounting (top hat rail according to DIN EN 60 715 TH35, formerly DIN EN 50 022)
• with solid housing

Ethernet problems are difficult to chase, so it is worth spending some money on suitable and reliable hardware.

Hint
Note that a PCD2.M5xxx does feature an integrated switch with two connectors which allows so-called "Daisy-chaining".

The default Timeout on Profi-S-Bus is baudrate related:

Baudrate

9'600 Baud: 500 ms

93,75 kBaud: 500 ms

187,5 kBaud: 250 ms

500 kBaud: 250 ms

1,5 MBaud: 100 ms

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 achieve a high and constant data throughput with S-Bus, the following guidelines can be helpful for the programmer of S-Bus communication.

S-Bus in Fupla

• Fupla handles all Transmit- and Receive FBoxes equally. By default, all requests are handled cyclically and are serialized automatically.
  This means that the value of an alarm flag is sent as often as the value of an outside temperature (that generally doesn't change within minutes).
   
• S-Bus communication is always commanded by the user program. The performance can be influenced by the cycle time of the user program.
  Given the cycle time of the user program is 300 ms, in maximum one telegram will be sent every 300 ms, too.
   
• Every FBox creates one telegram per communication cycle.
   
• A telegram can hold up to 128 bytes (array of 32 registers or 128 flags).
  The transmission of a telegram that contains 128 bytes doesn't take much longer than the transmission of a telegram with 1 bit data (the times are depending on the baud rate).
  On the other hand, sending two telegrams take double the time than sending one telegram.
  This results in the fact that the performance is rather depending on the amount of  telegrams than on the bytes transmitted.

Conclusions

• Send multiple medias with one FBox whenever possible.
  Use the FBoxes "Transmit- respectively Recive quick".
   
• In order to increase the communication performance, it is recommended sending slowly changing values in intervals.
  
  One possible solution for this could be two or more send- or receive FBoxes that are enabled alternatively (see fupla page above). Make sure the enable time of each of these FBoxes is at least equal to the communication cycle. 
   
• Transmit In- and Outputs as flags (in an array). Or, even better, map them into registers.
  This way telegrams (and therefore communication time) can be spared.
   
• Use the "S-Bus station (-IP)" FBox in order to avoid massively higher communication cycle times in case of a slavestation failure!
  This FBox does not constantly send telegrams to a station known as missing but only in intervals (after a short- or long reconnect time). Also refer to FAQ 100496 in case PCD7.Lxxx modules are used.
   
• For receiving slowly changing values consider using the FBox "Receive Integer Multiple" (only PG5 1.4 and higher)

Depending on the project not all or only few of these actions can/should be taken.

If you change the baudrate in a SNet the new parameters must be downloaded with "Download hardwaresettings".

Rebuild and download also all programs.

Since the Profi-S-Bus protocol is multi-master capable, the question about the amount of possible masters/slaves per station comes up.

Amount of masters that can access one Profi-S-Bus station
A PCD configured as Profi-S-Bus slave (using the on-board S-Net port) is able to handle 16 different master stations. This number is definde in the firmware in order to avoid an overflow of SAPs (Service Access Points).

Amount of slaves that can be accessed by a Profi-S-Bus master
A Profi-S-Bus master station can connect to all the Profi-S-Bus slave stations on the net (which means that it can communication to 124 stations).

Note
This numbers do only concern Profi-S-Bus stations. The same station can in parallel communicate with Serial-S-Bus and/or Ether-S-Bus stations.

On Profibus Network it is important to use the right cable and connector as the communication speed goes up to 12 Mbautes!

Those cable and connectors are used in Profibus DP, FMS, Profis S-Bus, Profi S-IO and MPI!

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

The PCD2.M480 does support the following baudrates:

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

You can't connect over any channel to a PCD by using the SCommDll . The software firewall softwares "Zone Alarm Security", "Windows Defender" or "Bitdefender" block the SComm funktionality on PC's running MS XP.

Symptom
If the ScommDll is launched, the PC won't react on key strikes for more than 40 sec. After this time, an error message is displayed saying "SCommDll error, Socket not installed or wrong server IP number".

Reason
The software firewall "Zone Alarm Security" blocks the ScommDll (The SCommDll communicated to the SCommDrv over an IP stream on port 7000 that is blocked).

Solution
Zone Alarm must be uninstalled; only deactivating won't work in most cases. This phenomenon was only observed on Windows XP. On W2k it seems that the ScommDll works also with ZoneAlarm activated.
In case the Bitdefender is used either disabling or appropriately configuring should help.

Hints

• The behavior descripted above does also apply to many other Personal Firewalls (aka Desktop Firewalls, Internet Security Suites etc.). So if socket communication does not work, these security tools should be checked.
• Most Personal Firewalls can be configured by so called "rules", which allow to open certain ports for one or more applications. So instead of totally disable or uninstall der firewall software, it may be a better solution to define apropriate firewall rules which allow SCommDrv to communicate anyway.
  For the relevant PG5 parts SCommDll.dll and SCommDrv.exe to work the TCP port 7000 needs to be enabled on the local host!

There are basically two tools that are required to solve communication issues on Profibus based networks (like Profi-S-Bus, Profi-S-IO, Profibus DP):

• an oscilloscope to locate hardware related problems (see related topics for more information)

• a protocol analyzer specialized for Profibus based networks

The protocol analyzer we recommend is ProfiTrace (www.profitrace.com) with the Oscilloscope Option. This analyzer bases on an up to date hardware and software concept and is easy to use. The oscilloscope option allows to observe telegrams of specific stations on the oscilloscope, ProfiTrace is generating the necessary trigger signals.

In Switzerland ProfiTrace is represented by  Berner Fachhochschule, Hochschule für Technik und Informatik, please refer to labs.hti.bfh.ch/index.php for more details.

In order to synchronize all PCD clocks on a network (Serial S-Bus, Profi-S-Bus or Ether-S-Bus) the FBox "Broadcast Clock" from the standard family "Communication" may be used. Depending on the range where the Broadcast message shall take effect the parameter "IP Node/Profi-S-Bus Address" has to be set correctly.

Depending on which kind of network this Fbox is used, different values for the parameter "IP Node/Profi-S-Bus Address" are to be entered. Below you can find a description of the different usages:

Use on Serial-S-Bus network
Genarally the FBox generates a S-Bus broadcast telegram (to the address 255 which is the broadcast address of the Serial-S-Bus network). On a Serial-S-Bus network the parameter "IP Node/Profi-S-Bus Address" has to have the value 0 since no Ether-S-Bus nor a Profi-S-Bus network is present. 

Use on Ether-S-Bus network
On a Ether-S-Bus network we can decide whether the broadcast shall be sent to the whole IP-subnet (including all Serial-S-Bus subnets connected to it) or only to one Ether-S-Bus station and all its sub stations (if present):
§ix100348§

• Given the Node 3 is time master, it is possible to send the broadcast to all Ether-S-Bus stations and their subnet stations (region B in picture above). In this case the Parameter "IP Node/Profi-S-Bus Address" of the Broadcast Clock FBox has to be set to 65535 (IP Node for broadcast address).

• If only the PCD clocks of region A in the picture have to be set, the node of the gateway to the subnet A (in this case the node 1) has to be set in the parameter "IP Node/Profi-S-Bus Address" of the Broadcas Clock FBox.

Use on Profi-S-Bus network
In order to send the telegram to all stations connected the Profi-S-Bus network, the "IP Node/Profi-S-Bus Address" needs to have the value 127 (which is the broadcast address for the Profi-S-Bus network). At the moment the possibility for sending only to the subnet of one station isn't introduced.

Note that since the sent telegram is a broadcast telegram the slaves won't answer with a "ACK" (acknowledgement) telegram. Therefore the LED of the FBox will remain green also if not all of the slaves have received the telegram.

The tool tracewin.exe is a small executable that records the communication between Saia PG5® and the S-Bus communicaiton driver. It is very useful in order to analyze the communication between Saia PG5® and the PCD's.

Since it logs the information of the SCommDll, it may also be used for recording S-Bus traffic of the SBC OPC server or any other software using the SBC S-Bus driver.

Opening Tracewin
The tool Tracewin is installed in the installation folder of Saia PG5® (default location: C:\Program Files\SAIA-Burgess\PG5 1_3\Tracewin.exe). It is to be called by double clicking it.

As soon it is called, the follwing window will be opened:

Configuring Tracewin
In order to record only the data needed, the "SComm Trace Options..." of the menu "File" can be adjusted.
E.g. the checkbox "Lock, Event, Critical" is only used in rare situations (but doubles the size of captured data if checked) and therefore narmally may stay unchecked. Below an example of the "SComm Trace Options" that suits in most cases:

In case no communication can be established, it can be helpful enabling all checkboxes in order to receive as many information as possible. As the file will be pretty small anyways, the additional lines won't bother much. 

Storing recorded data
The buffer finally may be stored with "Save as..." and then be viewed by any other text editor.
(The recorded data is very useful for the SBC support team in case you encounter a communicaton related problem.)

To power on the PCD8.K120 Profi-S-Link adapter you have to enable the Profi-S-Bus of the corresponding port on the "Profi-S-Bus" folder of the PG5 Hardware settings and you have to downolad the Hardware settings to the PCD.

The PCD8.K120 Profi-S-Link adapter needs to be powered with 24VDC.
The 24VDC for the PCD8.K120 is available on the PIN # 7 of the 9-pol D-Sub connector of the PCD2.M480 /PCD3.M where you connect the PCD8.K120 adapter.
To switch on the 24VDC on the Pin # 7 you have to enable the Profi-S-Bus of the corresponding port on the "Profi-S-Bus" folder of the PG5 Hardware settings and you have to download the Hardware settings to the PCD.

After downloading the program, the PCD goes in "Halt" with the halt reason "MGWY INIT FAIL". This is because the S-Bus gateway is defined on a port where no interface is present.

Problem
After downloading the program, the PCD goes in "Halt" with the halt reason "MGWY INIT FAIL". This is because the S-Bus gateway is defined on a port where no interface is present.



Solution
Plug a communication module in the slot/socket where the communication port is used as gateway.

On the PG5 device configuratior it’s possible to activate/deactivate the RS485/RS422 Bus termination of the port 3 (D-Sub #2 connector; RS485/RS422) of the PCD3.M5340.

If the Bus termination is activated then the following resistors are used.

For RS485 and RS422:

Remark for the RS422:
The following resistors are always used, independent if the bus termination is activated or deactivated on the device configurator.

As the hardware probes do work as USB dongles for the software Serialtest Async (version 10.12.22.0 and later), the according USB drivers need to be installed before starting the installation of the software.

Procedure for installing Serialtest Async

• Make sure your hardware probe (USB probe for RS232 or RS485 networks) is up to date
• Get the right USB device drivers for Windows
  in case you'll install Serialtest Async 10.12.22.0 you can use the driver files attached to this FAQ
• Plug the USB probe to your PC
• When Windows asks you for the driver files, browse to the (unzipped) driver files (e.g. the ones from this FAQ)
• Once the USB device is successfully installed, launch the installer for Serialtest Async from Frontline Test Equipment, Inc.

It's possible to get connected to and to program a PCD that is placed behind a Gateway of another PCD. There are some Device-, Timeout- and Connection-Settings to be taken into consideration. This handling's best illustrated, just below, in a small example.

Let’s imagine to download the user program of a PCS1, placed behind a RS-485 Gateway configured on a PCD2.M150.

Local computer --> PGU cable --> PCD2.M150 through Gateway, Port #3 --> RS-485 cable --> PCS1, Port #3.

Download the below attached "Program a PCS1 behind a RS-485 Gateway of a PCD2.pdf" file to see the configuration printscreens.

Analysing Serial-S-Bus communication can be done in several ways, depending on the focus of analysis (what shall be analysed; the telegrams on the wire, the requests sent by a PC software or the signal levels of e.g. Rx/Tx).

The following possibilities do exist in order to analyse Serial-S-Bus. Which possibility to use depends on the problem which occurs. While the oscilloscope is a good tool to find quality problems on the wire, the software serialtest is very useful to analyse the telegrams and frames which are sent from one device to another.

• Analysing the traffic on the wire
  This can be done by using the software Serialtest from the company Frontline (link below). Starting with version 10.12.22.0 the software "SERIALTEST ASYNC" supports Serial-S-Bus modes (Parity-, Data- and Secure Data-mode) as well as Modbus RTU and ASCII.
  The software uses a USB hardware probe (one for analysing RS232 and one for RS485) which also works as dongle for the license of the software.
  
  With this software it is possible to "see" and "understand" what is sent on the network, but the quality of the signals are not monitored (in case of a corrupted telegram, a wrong CRC is indicated).
  
• Analysing the signal levels on the wire
  In case the focus of the analysis is the quality of the signals on the wire an oscilloscope can be used. Please refer to FAQ 100297 which contains a document with screenshot of the most common error indications (such as crossed cable, bad cable etc.)
  
  By analysing the signals on the network/bus the quality of the signals can be monitored, and possible reasons for corrupted telegrams can be seen. "Reading" the content of the frames is not easily possible).
  
• Analysing the messages from the SComm
  In case PG5, Visi.Plus or the OPC server is used it is possible to get further information regarding problems by analysing the output of the tool Tracewin (which comes with PG5).
  Please note that this information can be useful for the support but it is rather hard to interpret without additional background knowledge.

In the most cases the "Sasi ..." FBox can be used (which is recommended due to the fewer possibilities for wrong configuration). However, there are some specific reasons for using the FBox "Sasi S-Bus extended"

The "SASI S-Bus Extended" FBox has to be used only in 3 following cases:

1. If you need to configure the S-Bus timing by using this FBox
   (-> Timeout -> TS-Delay -> TN-Delay -> Break length )
2. If you want to disable the "Secure S-Bus Data mode"
3. If you want to de-assign the communication port during runtime
   --> ATTENTION: in this case it is not possible to re-assign the port as GATEWAY (master) port (see FAQ 101399)
   

There are several reasons to use the FBox "SASI S-Bus Extended" (see FAQ 101400). But there is a limitation that it is not possible to use this FBox for re-assigning a port as Gateway master port on Saia PCD® COSinus systems.

Symptom
When re-assigning a Gateway master port using this FBox (or even in IL with the instruction SASI) it is not possible to assign the same port as Gateway master port after it has once been unassigned. This is the case if there is a falling and later on a rising edge on the input "Sasi" of the FBox "SASI S-Bus extended". On the second attempt to assing the port as gateway master port the FBox will get an error and the FBox LED becomes red:

• In the case you configure the GATEWAY funtion (in the device configurator and in the "SASI S-bus Extended" Fbox )
• The 1rst rising edge on the "SASI" input assigns the communication port (as serial master gateway)
  --> the Master-Slave communication works well.
• A falling edge (state "1" to "0") on ths "SASI" input de-assigns the corresponding communication port
  --> no communication is possible
• If you apply a 2nd rising edge on the "SASI" input, it will put the "SASI S-Bus Extended" FBox in ERROR. 
  A "Cold Start" is required in order to (re-)assign the communication port as serial Master Gateway port.

Reason
IT IS NOT ALLOWED TO DE-ASSIGN A MASTER GATEWAY PORT (an to re-assign it again) on Saia PCD® COSinus systems (PCD3, PCD2.M5, PCD1.M2 and PCD2.M480). This phenomenon is based on the internal mechanism how the firmware assigns the port. It has not been observed before the usage of the FBox "SASI S-Bus extended" as there are very few (if at all) reasons for un- and re-assigning a port as gateway master port.


Solution
In the case you configure the GATEWAY function (in the device configurator and in the "SASI S-Bus Extended" FBox )
WE RECOMMEND YOU TO CONNECT THE "SASI" TO A BINARY CONSTANT "1".

In this way the above mentioned problem will not occur. Please let us know in case you have an installation where it is required to re-assign a port in runtime as gateway master port.

In case more than 32 PCDs are to be connected to a PC using serial connections (with one COM port for every PCD station) PG5 needs to be configured to allow more than 32 COM ports to be used by the SComm driver.

By default the number of accessible ComPort is limited to 32 Com ports. The reason therefore is that with more than 32 COM ports is has been observed that the process which allows to scan the available Com Port on the PC could take up to 1 minute (and more...), depending on the system or devices used. This phenomenon can be observed by clicking the "Setup" button in the dialog box of the "Online Settings" in PG5.

Procedure for increasing the maximum number of Com Ports
=====================================================

PG5 1.4: (Windows XP) 

1. Close all SBC-Software
2. Open the Registry Editor: from the Windwos start menu select "Run...", type "regedit" and click "OK"
3. Browse to --> HKEY_LOCAL_MACHINE --> SOFTWARE --> Saia Burgess --> PG5 --> 1.4 --> SCommDrv
4. In this folder (... --> SCommDrv) create or modify the "PcdLastCom" DWord variable with a value greater than 20 hex (32 dec) for example 40 hex (64 dec)
   This new value represents the maximum number of accessible/scanned ComPorts by PG5

PG5 2.0: (Windows XP)

1. Close all SBC-Software
2. Browse to the folder "C:\Documents and Settings\All Users\Application Data\Saia-Burgess\PG5_20\"
3. Open the file "SCommSettings.ini" and modify the value of the "PcdLastValue" (for example write 64) and save this file under the same format.
   This new value represent the maximum number of accessible/scanned ComPort by PG5
   
   

After installing the patch 8 for PG5 it is no more possible to compile a project which contains FBoxes for Bettschen midi RIOs.

Symptom
After installing patch 8 for PG5 1.4.300 the following error message appears while the build of a project containing Midi RIO FBoxes:
Error 31: xxx.fbd: Line 39: Syntax error, in Block: BL 0, Page: 1, FBox: Initialisierung (MR_Init) 

Reason
The PG5 compiler which is included in the patch 8 or later patches does check more details on the program code. A wrong declaration which is included in the program code for the midi RIOs causes the error.

Solution
The Problem is solved in a library version Midi_Rio_V1.63 or newer. Please contact your supplier of the FBox library, EUF Software or Bettschen Elektonik.

Another way to solve the problem is, you open the file "Midi-RIO.LIB" with a text editor.
There you have to change the syntax of the line:

; Definitionen
FlagEnable  EQU    F [128] S+10        ;+127

The syntax "S+10" is wrong

Either you delete the syntax or your do define it as text with a ";" like:

; Definitionen
FlagEnable  EQU    F [128] ;S+10        ;+127

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.

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

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

If the communication on both ports of a PCD3.F281 does not work then it's possible that the PCD3 does contain a FW which not does recognise the PCD3.F281 module.

Symptom
The communication on both ports of the PCD3.F281 does not work at all. The firmware installed is 1.08.23.

Reason
The firmware does not recognize the Belimo MP Bus module.

Solution
To solve the problem please install PCD3 firmware version 1.10.16 (the first firmware solving the problem was  version 1.08.51).

Yes it is possible to deactivate the "secure S-Bus Data Mode".

Introduction
In some special cases it can be desired to deactivate the "secure S-Bus Data Mode". This is possible by adding a specific parameter to the SASI text.

Usage
The additional parameter is placed after the parameter "destination register" (the "destination register" is R20 in the example below)

TEXT 0 "UART:9600;MODE:SM2,R20,0;DIAG:F0,R0"

Default value is 1 (Secure Data Mode activated)!
When the SASI text does not have this option or does have an option different than zero, the "secure S-Bus Data mode" is activated.

The option has to be a constant.

This option is only available for the SM2/GM mode.

Firmware dependency
Minimum firmware supporting the possibility to deactivate the "secure S-Bus Data" mode can be found in the table below (systems not listed in this table do not support this option).

Usage in Fupla
For Fupla users the version 2.6.101 of the communication library does feature a new parameter in the FBox "Sasi S-Bus extended" to activate and deactivate the secure S-Bus Data mode (mode "Data No Secure"):

• For PG5 1.4 the FBox library 2.6.101 is available from the support site
• PG5 2.0.110 contains this version by default
  

In one RS485 network it is possible to use 100 PCD7.H104S without using repeaters.

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.

The first versions of the PCD3.M5340 controller have been delivered with a firmware that does not support the usage of the RS485 port on port 3.

Problem
The communication RS 485 on port 3 of the PCD3.M5340 is not working correctly. 

Reason
Due to a problem in the firmware, the port is not correctly initialized to RS 485.

Solution
Upgrade the PCD3 firmware to version 1.08.23 or higher.

Remark
There is no problem for the usage of the port 3 as RS422 port.

Serial S-Bus is still very often in use for it's low costs combined with good communication performance. Unfortunately, nowadays it's quite difficult to buy a notebook PC which still has at least one serial COM port!

USB to RS-232 adapters may be a solution, but there is no guaranty that a specific adapter will work with SBC S-Bus properly.

The EXSYS PCMCIA card EX-1352 with 2 serial RS-232 ports has been sucessfully tested at our technical support department. We can recommend this card for use with SBC S-Bus and Saia PG5®. Also available from EXSYS, but not tested, are cards with 1 or 4 RS-232 ports plus a card with 2 surge protected RS-232 ports.

Detailed information about this EXSYS cards can be found at the EXSYS homepage:
www.exsys.ch/index.php

Distribution:
EXSYS Vertriebs GmbH
Industriestrasse 8
D-61449 Steinbach/Ts.
Tel.:+49 (0)6171 975656
Fax:+49 (0)6171 975697

An external device like scada or supervision sytem can know the status of the PCD (Run, Halt, Stop or Conditioanl Run) by using a special item of the S-Bus OPC-Server or by using a special S-Bus telegram.

If a OPC-Server is used then you can use the item "status" of the station.

§ix100539§

The status will be shown as follwoing on the Scada System:

R    Run
C    Conditional Run
H    Halt
S    Stop
           

If the supervision system don't use the OPC-Sever then the status of the PCD can be knwon with the use of a special S-Bus telegram.
SRXM S-Bus channel
            0
            7
            Destination_register

More informations can be found on the S-Bus manual 26/739, chapter 3.4.1

The "secure S-Bus Data Mode" has been introduced in order to clearly identify a Serial-S-Bus response telegram as answer to a certain request telegram (by introducing a sequence number). This FAQ explains the difference between the "standard S-Bus Data Mode" and the "secure S-Bus Data Mode".

Why has the secure Data Mode been introduced?
The secure data mode prevents the situation that a Serial-S-Bus response telegram who's timeout had exceeded (and therefore a new request has been sent) is interpreted as the response to the following request. This situation could occur if e.g. radio modems are used and the master port timeout is not set adequately (if the transmission time of the request and the response are longer than the timeout).
How does the secure Data Mode work?
The secure data mode introduces a new (additional) header to the existing S-Bus data mode telegram. A secure S-Bus data mode telegram has the following structure:

• One byte of framing character (B5, used as frame synchronisation) 
• One byte "AT character" indicating that this is a secure data mode header (0x10 = Request; 0x11 = Response)
• One byte indicating the telegram length of the following (standard S-Bus data mode) telegram
• One byte for the sequence number of the telegam
• A complete standard S-Bus data mode telegram (again starting with a framing character B5 and including the CRC)

If the master does support the secure data mode, it will use it for all request telegrams it sends on all serial ports. The slave does answer in the same mode as the request is sent, if possible. If a slave that does not support the secure data mode, it will answer all requests with the standard data mode.

Example
Below you can find two samples that show the request- and response telegrams of stations supporting the secure data mode. The black parts of the telegrams are common standard data mode telegrams that are extended by the secure data mode header (blue).
The speciality of the second request telegram is that the register address is equal to 181 ( = 0xB5, which corresponds to the data mode framing character). In order to avoid the value B5 in the telegram, a DLE (Data Link Escape) character is used for replacing the "B5" inside the telegram. This DLE character (0xC500, red in the second example) is two bytes long but is only counted as one byte in the secure data mode header.

Is it a problem if the master talks "secure Data Mode" and the slave talks "standard data mode"?
No. In this case the master sends the secure data mode header which is not interpreted by the slave.
After the slave reads the framing character, it tries interpreting the AT command which does not have a value he recognizes. The slave therefore stopps the interpretation and again starts waiting for the next framing character which will be the one of the standard S-Bus data mode telegram. The slave will answer this request with a standard S-Bus response telegram which will be detected by the master as standard S-Bus telegram (due to the AT character).

              (the blue part is ignored by the slave)

Firmware versions supporting the secure Data Mode
The secure data mode is introduced in the following firmware versions. The "deactivate option" indicates the first firmware version where the "Secure S-Bus Data mode" can be deactivated (see FAQ 101084).

^*) On PCD3 systems, the Secure S-Bus Data mode has been first implemented as server and later also as client. The table above indicates the first client-implementation. The Secure S-Bus data mode server functionality has been implemented in version 03C (first pilot version has been $31).

In order to achieve a high and constant data throughput with S-Bus, the following guidelines can be helpful for the programmer of S-Bus communication.

S-Bus in Fupla

• Fupla handles all Transmit- and Receive FBoxes equally. By default, all requests are handled cyclically and are serialized automatically.
  This means that the value of an alarm flag is sent as often as the value of an outside temperature (that generally doesn't change within minutes).
   
• S-Bus communication is always commanded by the user program. The performance can be influenced by the cycle time of the user program.
  Given the cycle time of the user program is 300 ms, in maximum one telegram will be sent every 300 ms, too.
   
• Every FBox creates one telegram per communication cycle.
   
• A telegram can hold up to 128 bytes (array of 32 registers or 128 flags).
  The transmission of a telegram that contains 128 bytes doesn't take much longer than the transmission of a telegram with 1 bit data (the times are depending on the baud rate).
  On the other hand, sending two telegrams take double the time than sending one telegram.
  This results in the fact that the performance is rather depending on the amount of  telegrams than on the bytes transmitted.

Conclusions

• Send multiple medias with one FBox whenever possible.
  Use the FBoxes "Transmit- respectively Recive quick".
   
• In order to increase the communication performance, it is recommended sending slowly changing values in intervals.
  
  One possible solution for this could be two or more send- or receive FBoxes that are enabled alternatively (see fupla page above). Make sure the enable time of each of these FBoxes is at least equal to the communication cycle. 
   
• Transmit In- and Outputs as flags (in an array). Or, even better, map them into registers.
  This way telegrams (and therefore communication time) can be spared.
   
• Use the "S-Bus station (-IP)" FBox in order to avoid massively higher communication cycle times in case of a slavestation failure!
  This FBox does not constantly send telegrams to a station known as missing but only in intervals (after a short- or long reconnect time). Also refer to FAQ 100496 in case PCD7.Lxxx modules are used.
   
• For receiving slowly changing values consider using the FBox "Receive Integer Multiple" (only PG5 1.4 and higher)

Depending on the project not all or only few of these actions can/should be taken.

Yes, the company "M+S Industrielle Automation AG" has developped a WinCC driver for Classic Saia PCD® devices.

The driver is realized as plugin for WinCC and supports S-Bus (S-Bus USB, Ether-S-Bus, Serial-S-Bus). Among others a version for WinCC 7.0 SP1 is available. The current documentation is in German.

For more information contact M+S, Winterthur, Switzerland:
URL:   www.msia.ch/
EMail: info[at]msia.ch

The S-Bus Data-Mode was the last implemented S-Bus protocol. Therefore not all PCD's and not all firmwares are supporting the Data-Mode.

Below a list of the first firmware version supporting S-Bus Data-Mode:

Note: The S-Bus Data-Mode is not supported by PCD4.Mxx0 and PCD6.M1xx and M2xx

Configuration:
PCD3
PCD3.F121 Port 1
or on Port 0 (just with FW $26)

Problem
When using a Sasi Slave F-Box for the configuration of channel 1 and choosing RS Type RS 232, it will generate an error and the communication will never work. Otherwise the same configuration works on a PCD2.

Reason
There is a difference in the Firmware of the PCD3 which doesn't allow this configuration

Solution
Choose RS Type Default in the Sasi Slave F-Box and it will work.

In principle, it is possible to use RS422 as physical layer for Serial-S-Bus communication. But note that the S-Bus full protocol is not fully applicatively due to the reason described below!

Configuring a serial port to use RS422
In order to switch the communication module (PCD7.F110, PCD3.F110, PCD7.F520 or PCD7.F530) from RS485 to RS422, the following code lines are to be used:

As commented, this code is placed into the startup program block XOB 16 and will cause the port to work in RS422 mode. This means that it is only possible to use this port after the XOB 16 has been executed.
Please note that either the port is to be configured as PGU port or a SASI has been applied on <portnr> before executing the code above!
For further information, please refer to the S-Bus manual, 26/739.

Restriction for S-Bus full protocol
Given the situation that a program is to be downloaded to the PCD over such a port, we are faced with the following scenario:
Before downloading the code, PG5 will restart the PCD. This restart will reset all communication ports (and the concerned port will not be in RS422 mode any more). This leads to the fact, that PG5 won't get any response any more (and cannot send to the PCD, either). The PCD is to be restarted manually for establishing the communication again!
The same problem occurs after every restart command executed by PG5! This is why the RS422 is not really applicatively for real S-Bus full protocol actions. However, there is not problem in using all command except of the restart (and of course the S-Bus reduced protocol will not cause any problems).

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

The PCD2.M480 does support the following baudrates: