The FBox 'MP Single' does indicate a Error and the code 23 (Timeout error) is displayed on the FBox.

This might happen when importing an older PG5 project (PG5 1.4.300 or 2.0) which work fine before in PG5 2.1.3x0.

Of course also this might happen with a brand new project created with PG5 2.1.3x0.

 

Reason:
An error was introduce in the Belimo library version 2.7.154!

Solution
Use the Belimo library version $2.7.304 in attachment or newer!

Remark:
This error was not present in PG5 2.0.xxx Belimo library 2.6.xxx
In PG5 2.1.xxx in the Belimo library version 2.7.155 an additional freeze bit was implemented to avoid inter-characters gaps when for example MP-Bus and Bacnet are used on the CPU.
If this new functionality is needed also on a PG5 2.0.xxx project please use the Belimo library 2.6.224 or newer available on our support site under:

www.sbc-support.com/en/product-category/archive/software/saia-pg5r-controls-suite/pg5-20/fbox-libraries/

 

In case a current transformator and a transfomer ration other than 1 (5:5) is used for measuring the energy with an AWD3 (with Serial-S-Bus interface) the FBox from the library 2.6.156 or older do not correctly display the current.

 

Symptom
The current displayed in the FBox is not correct if a current transformator is used for measuring the energy with an AWD3 (with Serial-S-Bus interface). Instead of e.g. 50 Ampere, 5.0 Ampere are displayed.
 
Reason
In case a transformer ratio other than 1 is used the AWD does send the current as [Ampere] (if the tratio is 1:1 the current is in the format x.x Ampere.
The FBox library version 2.6.156 (or 2.5.156 for PG5 1.4) and older do not consider this difference.

Solution
This problem will be corrected in the next FBox library version. 

 

Yes, the EnOcean radio receivers from Omnio, APG03U-RS485-Eno (unidirectional version) and APG03B-RS485-Eno (bidirectional version) are supported by the FBox library for EnOcean from Saia-Burgess Controls AG.

 

Points to be considered when using the Omnio radio receivers
The expreiences during the pilot phase have shown that: 

• It is important to use the EnOcean ID filter of the Omnio receivers
• In dependance of the version of the receiver, an according FBox version is to be selected (sending Acknowledge telegrams or not, see FAQ 101453)
• It is not possible to mix receivers from Omnio and Thermokon on the same RS485 bus. 

Can I order the Omnio receivers from Saia-Burgess Controls AG?
No, please order these devices from Omnio directly as Saia-Burgess Controls AG is no longer able to provide these products (unfortunately these products are still listed in the price list for 2010/11).

 

In case the PG5 2.0 FBox library version 2.6.150/151 (or PG5 1.4 version 2.5.100/101) is used the change from "autonomous" to "slave" mode does not work correctly. This problem is corrected in the PG5 2.0 FBox library version 2.6.165.

 

Symptom
After having changed the operation mode of a PCD7.L60x Room controller from "autonomous" to "slave" the output values for the heating and cooling signal are not stable (in fact they are changing between the values from the master and the ones calculated by the room controller). In this situation the Room controller is not working correctly.
After changing back from "slave mode" to "autonomous mode" the fan speed is blocked to to the level from the master.

Reason
This is a bug of the FBox library for the PCD7.L60x. The bug is present in the first FBox library version supporting SW 1.12 (PG5 1.4: 2.5.100; PG5 2.0: 2.6.150).

Solution
Please update the FBox library to the version listed below:

• PG5 1.4: FBox library version 2.5.165 or later
• PG5 2.0: FBox library version 2.6.165 or later

The output of the L60x Room Controller FBox switches from 1 to 0 when the temperatur setpoint is modified. This phenomenon appears on the new hardware V2.0 and SW 1.12!

 

Symptom
The output of the L60x Room Controller FBox switches from 1 to 0 when the temperatur setpoint is modified. This phenomenon appears on the new hardware V2.0 and SW 1.12!

Reason
The software version 1.12 does not identically treat the state of the occupancy input in case of changed setpoints (written by the PCD).

Solution
A new FBox library version takes this different behaviour of the room controller into account; please use the below mentioned FBox library which is available on the support site!
FBox library which solves this issue:

• PG5 2.0: 2.6.151 or later
• PG5 1.4: 2.5.101 or later

The memory requirement of a "HDLog to File" FBox (log in csv format) is calculated as follows:

Possible records = 50% of memory capacity (in bytes) / required characters per record (in bytes). Further on the maximum amount of files per file system is to be considered (around 850 files per SD card).

 

Memory available on a 1 GByte SD card
1 GB SD Card (PCD3.R600 with PCD7.R-SD1024) has 1’073’741’824 bytes
Note: It is not recommended to fill the SD card completely; in general we recommend only using 50% of the available memory in case data is written (and deleted) regularly.
Further on the maxumum amount of files per SBC file system is 900 in total, and every directory counts as 20 files (because the folder "WEBPAGES" and "CONFIG" always exists, the maximum amount of files which can be created on a SD card is around 850 (860 to be precise).

Memory requirement of log files
The memory requirement of files created by the "HDLog to File" FBox (log in csv format) is calculated as follows:
Possible records = 50% of memory capacity (in bytes) / required characters per record (in bytes)

Examples

• Writing 30 values to an SD card
  In case 30 values are to be recorded:
  Each value has an average number of six characters (exp. 123,4).
  Each HD Log File FBox requires 30 characters for the date and timestamp.
  So 30 record sets, subdivided into 3 FBoxes requires about 270 bytes per record (rounded about 300 bytes per record, including date and time stamps).
  1 GB SD Card (PCD3.R600 with PCD7.R-SD1024) = 1’073’741’824 bytes
  This results in about 3,500,000 entries. Due to the fact that you should not fill the SD card over 50% there remain effective 1'700'000 entries.
  At a recording interval of 5 minutes the SD card has space for about 16 years, given one file per month is generated (--> 16 years * 12 files/year * 3 FBoxes = 576 files)
  
  

  Remark regarding this example
  In case one file is generated per week, after around 5.5 years it won't be possible creating more files because of the maxumum number of files per file system has been reached (5.5 years * 52 files/year * 3 FBoxes = 858).

  
  
• Writing 3 values to a PCD7.R550 memory card
  In case 3 values are to be recorded:
  Each value has an average number of six characters (exp. 123,4).
  Each HD Log File FBox requires 30 characters for the date and timestamp.
  So 3 record sets can be recorded with one FBox and requires 48 bytes per record (rounded about 50 bytes per record, including date and time stamps).
  1 PCD7.R550 module = 4'000'000 bytes
  This results in about 80'000 entries. Due to the fact that you should not fill the SD card over 50% there remain effective 40'000 entries.
  At a recording interval of 1 minute the memory module has space for about 1 month (28 days) 

 

In case the dynamic space of registers is defined below 1000 or above 9999 the FBox HD Log to file cannot create the Logfiles correctly

 

Problem
If the dynamic space of registers is defined <1000 or >=10 000 the FBox HD Log to File is not able to create the Logfile correctly. The FBox is using interpreted text with $R commands. Due to a problem in the FBox this won't work for registers below 1000 since they only have 3 digits $Rxxx and the interpreted text needs 4 digits. Also in case the dynamic space is defined above 9999 the interpreted text won't work correctly, because the last digit is cut off by the firmware.

Solution
At the moment the dynamic space has to be defined >=1000 and <10 000 otherwise the FBox HD Log to File will not work correctly. The FBox library will be corrected for a dynamic space below 1000. To define the dynamic space above 10 000 a correction in the firmware will be necessary. As soon as a correction is available, this FAQ will be updated.

 

With PG5 1.4.300 it is possible that after the installation of a library (e.g. the HDLog library) PG5 indicates a message such as "S-FUP: Warning 28: Family 'HDLog.def' already defined in 'c:\Program Files\ ... \Libs\App\HDLog.def"

 

 

Symptom
When opening the Fupla Editor a message window with a text similar to this one gets displayed:

S-FUP: Warning 28: Family 'Historische Datenaufzeichnung' already defined in 'c:\program files\SAIA-Burgess\PG5 1_4\Libs\App\HDLog.def", file 'c:\program files\ ... \Libs\Usr\HDLog.def' will be not loaded.
S-FUP: Error 161: New macro name '_HDA_FILE_V22' is not part of library

Reason
In the past some libraries (HDLog in this example) which were located in the User-section of the FBox library were moved to the "app" (Application tab of the FBox Selector) section. As the old files weren't deleted the library is defined twice.
Concerned are the libraries "HDLog" and "RoomControler PCD7.L6x".

Solution
In order to avoid this message the FBox libraries need to be deleted from the "Usr" Folder. The FBox library consists of all files with the name *.def (HDLog.def in this example) which are located in the folder
c:\Program Files\SAIA-Burgess\PG5 1_4\Libs\Usr\
and all the sub-folders. Alternatively to deleting the files maunally, you can also use the attached batch file to rename the outdated files in your installation.

 

The TME Ethernet Thermometer can be connected over Modbus TCP to a PCD that supports Modbus.

 

Problem
Since the documentation for this thermometer is very limited regarding Modbus it is only possible to connect it via reverse-engineering. This is why we did a test.

Solution
The thermometer has a Web-Interface. With the base IP address it is possible to connect to the thermometer and set an IP address that corresponds to the network.
Afterwards the thermometer can be connected to the network. The temperature is available over Modbus TCP on "Input Register" 0. It is a 16 bit signed value. If more than one thermometer is in the network, each thermometer needs a different IP address, since they all have UID 1. A small demo project for the SBC-Modbus and Engiby-Modbus solution is attached to this FAQ.
In the attached PG5 program example the thermometers have the addresses 172.16.1.66 and 172.16.1.64.

Status Register
The following "Input Register" 1 contains the status of the thermometer. It is 0 if the thermometer is working correctly and it changes to 1 in case of error. If necessary you can read 2 "Input Registers" 0 and 1. The first will contain the temperature and the second the status.

 

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.

 

The main application of this FBox is replacing a DX system by a PCD without the need to replace all the XT extensions, too. Therefore the FBox library for the Johnson Controls JCI N2-Bus is designed to connect XT 9100 extension modules (where the PCD is the master and the XT9100 is the slave).

 

General
The main application of this FBox is replacing a DX system by a PCD without the need to replace all the XT extensions. The FBoxes do support the N2 bus but not the N2 Open protocol.

Master functionality of the FBoxes
The FBox library for the JCI N2-Bus is mainly designed to connect XT 9100 extension modules (where the PCD is the master and the XT9100 is the slave).
Additionally it is possible to read out single items (but not data structures such as e.g. schedulers) from other devices (such as DX) as well, given this device has the connected port initialized as slave (the PCD is the master).

Slave functionality
The slave functionality has been implemented to provide a possibility to exchange data on the N2-Bus between PCDs, but it is not possible to connect a PCD to a SCADA system from JCI or to a JCI NAE or NCM controller (because this SCADA or NAE is first of all reading a Johnson ID together with a specific set of parameters, which the PCD does not provide; if the ID and the specific set of parameters is not received by the SCADA or NAE, no furhter communication will be executed by the JCI SCADA or the NAE).

 

The online paramters of the "Call SMS" FBox should be adapted in runtime. Per example inserting another destination for the "Call SMS" FBox. For some reason the updating of the callnumbers is not working. The values are overwritten by the offline parameters imediatly.

 

Problem
The phone numbers in the "Call SMS" FBox can normally be overwritten in runtime. Means that a user can change the destination phone numbers. If the "Ini" input of the "Modem Driver 18" FBox is permanently high and the option "Evaluate Ini Input" is set to "In runtime" the online parameters are each cycle overwritten by the offline parameters.

Reason
Due to a malfunction of the FBox the Ini Input is not only reacting on a rising edge but always. Therefore the Modem FBoxes are initializing each cycle and all parameters are reset to the initial parameters (offline parameters)

Solution
As a workaround change the "Evaluate Ini Input" to at startup or insert a dynamize FBox in front of the Ini input. A correction has been implemented in the Modem FBox Library and is present in the following two versions (and later versions, too):

• PG5 1.4
  Modem FBox library version 2.5.304
• PG5 2.0
  Modem FBox library 2.6.102 or higher

The FBox libraries can be downloaded from the Support page in the section "Software" --> "PG5 x" --> "FBox Libraries". 

 

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

 

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

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

Remarks

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

 

When placing an FBox "PCD7.D120" it is not possible to build the project anymore with PG5 1.4.300 due to a syntax error.

 

Symptom
When placing an FBox "PCD7.D120" it is not possible to build the project anymore. On build the error message "Error 31: C:\Program Files\SAIA-Burgess\PG5 1_4\Libs\Std\sfupdis5.srx: Line 323: Syntax error" is shown and the build fails.

Reason
The error message is shown because of an error on the SFup base library which is distributed with PG5 1.4.300.

Solution
To fix the error please install the library S-Fup Base Library version 2.6.100 or higher (installer file "S-Fup Base Library_V2_6_100_ml.exe").
This FBox library can be obtained from the support site www.sbc-support.ch (Section "Software"-->"PG5"-->"PG5 1.4"-->"FBox libraries").

 

The fan optimizer COU24-A-MP from Belimo is used together with VAV controllers. However, this device is optimizing the fan based on a signal given from the VAV and can not be addressed and controlled by a PCD (or another DDC master) over the MP Bus.

 

General
Since the fan optimizer does optimize the fan speed based on the signal given from the VAV controller (e.g. from the VRP-M) there is no need (and no possibility) to send any information to this device over the MP Bus. Therefore there is no FBox for the fan optimizer (seen from the PCD, the fan optimizer is "invisible"). The fan optimizer does not have/use an address on the MP bus.

Remark
The task for optimizing the fan can also be done by the user program on the PCD.

 

Due to incompatible communication parameters used by the Omnio "RS232/485 to EnOcean" converters the FBox library version 1.0.0 is not working in every situation with the converter from Omnio.

 

Symptom
The communication between a PCD and an Omnio “RS232/485 to EnOcean” converter does not work with the EnOcean FBox library version 1.0.0.

Reason
The communication protocol/parameters which is used by the Omnio "RS232/485 to EnOcean" converter is not the same as for other "RS232/485 to EnOcean" converters (e.g. the one from Thermokon).

Solution
Since the EnOcean F-Box Library 1.0.20 the FBox "EnOcean Init" does feature an adjust parameter called "manufacturer". This selection will then adapt the communication protocol of the PCD.

 

Only FLS devices with automatic supports MP-Bus communication.

A new FBox library is needed

 

Problem
1. There is a confusion in the actual catalogue about which FLS devices supports MP-Bus.
2. Actual FLS devices need the FBox library 2.5.303E or higher.

Solution
1. The correct statment is, that only FLS devices with automatic supports MP Bus communication. Future catalogues will be corrected.
2. Note that 2.5.303E is not an official version, please ask the support team if you need this library. The next official version will contain this correction.

 

If the PCD2.F2610 or PCD3.F261 Dali communication modules are used:

There is no need to use a Tridonic interface.

The whole DALI configuration is done with the Dali F-Box over the F2610/F261 modules

 

If the DALI communication is done over the serial line of the PCD and a external DALI interface:

For the programmation of the lights in the DALI network Tridonic offers a tool.

Additionaly an USB interface is necessary.

For the communication with the PCD a serial interface is needed.

 

If the DALI communication is done over the PCD2.F2610 or PCD3.F261 DALI communication module:
The configuration of the Dali device can be done over the PG5 F-Boxes and/or the Web-page.
There are F-Box for the addressing, and configuration of the Dali devices as for the definition of groups and scenes.
There is no need to use a external tool.

The solution with the PCD2.F2610/PCD3.F261 does replace the solution with the external DALI interface from Tridonic.

If the DALI communication is done over the serial line of the PCD and a external DALI interface:

Preparation of the Dali devices:
To use a DALI device with the PCD it is necessary to set some parameters in advance.
At least the device address has to be configured.
Additionally it is possible to create groups and scenes. If some devices are in a group, it is possible to switch them off/on together etc.
For this configuration you will need a tool from TRIDONIC, which is freeware www.tridonicatco.com an USB interface order number 24138923 and the power supply order number 24034323 from TRIDONIC. Note that the serial interface is not supported by the new configuration tool and the old tool is not available anymore.

PG5 programming and operation:
In PG5 there are FBoxes available for DALI.
The DALI Bus has to be connected to a serial port on the PCD. Therefore you will need the SCI interface from TRIDONIC: order number 24033463. This device is not listed in the TRIDONIC catalogue because it is not supported by the current programming tool, otherwise it is still available and not obsolete.

Updates

• 18.12.2010
  Please note that there is also an SCI2 interface available (which will replace the SCI1 interface).
  The SCI2 interface is not supported by the FBox library.
  When ordering an interface, please specify that you need a SCI1 interface (which will be available until summer 2011 at least). 
• 12.05.2010
  The tool for the configuration of the DALI lamps over the serial interface is available again on the TRIDONIC homepage. Search for WinDim in orderr to find it.

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

PCD type	minimal Firmware version
PCD1.M1x5	0F0
PCD2.M150	0F0
PCD2.M170	0F0
PCD2.M5xx0	1.10.16
PCD3.Mxxx	1.10.16
PCS1	0F0

 

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"):

Availablility of the FBox

• 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
  

The VRP-M is a universal variable air volume controller (universal VAV controller). For connecting this controller to a PCD over the MP Bus the FBox "MP Actuator VAV" is to be chosen.

 

General
Since the VRP-M is used for controlling the air volume the FBox to be used for accessing and controlling this device is the "MP Actuator VAV". This FBox allows to pass the required volume as input (the VRP-M will calculate the required position of the damper by itself).


Remarks

• It is not possible to command the position of the damper from the user program (except to close (input "Cls") or open (input "Opn") it completely)
• In case a VRP-M STP (for constant pressure) is used, the same FBox can be used and the input "Vol" is given as % in pressure instead of volume as for the VRP-M VAV

After the installation of the version 1.4.300 of the "JCI N2-Bus" FBox library, it is no longer possible to build the Saia PG5® project but the error message "Protected library used: _SBC_JCI_N2BUS" is shown.

 

Symptom
After having installed the version 1.4.300 of the FBox Library for the JCI N2-Bus (and having done the steps explained in FAQ 100973), it is no longer possible building the PG5 project. At the end of the build process, the following message is shown:

Linking: _CPU1.obj + Source.obj + Untitled1.obj + Untitled2.obj + _TCPIPDBX.obj
Fatal Error 391: Protected library used: _SAIA_JCI_N2BUS

Reason
The reason is that this library requires a specific license (user.key file which is to be registered from menu "Help"-->"Register Software..."). The FBox library which has been available on the support site until June 2008 has by mistake not requested this license.

Solution
Please contact your local Saia-Burgess Controls AG Sales office for obtaining the license for the JCI N2-Bus.

 

This FAQ contains the updating procedure in case the JCI N2-Bus library is updated to version 1.4.300 (and an older version of this FBox library has been installed).

 

Symptom
After having installed the version 1.4.300 of the FBox library "JCI N2-Bus", Fupla always reports Warning 28:

CPU 'CPU1 - PCD3.M3330 - IPNode 0, Station 11' Activated
S-FUP: Warning 28: Family 'JCI N2-Bus' already defined in 'C:\Program Files\SAIA-Burgess\PG5 1_4\Libs\App\JCI_N2_Bus.def', file 'C:\Program Files\SAIA-Burgess\PG5 1_4\Libs\Usr\JCI_N2_Bus.def' will be not loaded.

Reason
The reason for this warning is that previous versions of the N2-Bus library have been installed to the "User" folder of the FBox Selector. Because this library will be installed by default in future PG5 versions, the target folder has been changed to the "Application" folder.
If a previous version has been installed in the "Usr" folder and the new version 1.4.300 has been installed to the "App" folder, PG5 detects the same library installed twice and therefore informs the user with the Warning 28:...

Solution
In order to avoid this doubled presence of the library, please uninstall the previous version which is installed in the "Usr" folder. This can be done by deleting all files named with "JCI N2 Bus.*" and "JCI_N2_Bus.*" from the folder:
c:\Program Files\SAIA-Burgess\PG5 1_4\Libs\Usr\

Remark
In case you are working with the override libraries, please make sure that the new library is installed in the "Libs/App" folder from your project and that the according library files are deleted from the "Libs/Usr" folder in your project.

 

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

 

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

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

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

 

The DALI FBoxes offer the possiblility to access the lights with broadcast (every light on the bus), short (just a single light) or group (a defined group of lights). This different addressing is only possible if the lights are configured.

 

Problem
DALI lights can only be accesed using broadcast commands. How is it possible to address the lights?

Solution
The addressing of the lights is possible using the tool from TRIDONIC www.tridonicatco.com. Additionally the serial communication modul from TRIDONIC is needed. Either the communication modul for the serial port which can be used for the PCD communication as well, or the more comfortable module for USB communication which can not be used on the PCD. Otherwise the USB programming tool offers more possibilities. It is per example possible to change the addressing of the lights. With the serial tool the addressing is random and cannot be adapted by the user.

Important to know
The WinDim tool from TRIDONIC which must be used for the addressing and group/scene configuration is addressing the groups and scenes from 1 to 16. In fact on the bus the addresses are from 0 to 15. As well our F-Boxes are working with addresses from 0 to 15. So keep in mind that if you configure a group/scene in the WinDim tool you have to use the address -1 in the F-Boxes. Per example: WinDim address: group 3, FBox address: group 2

A short description and a program example is available on request from pcdsupport.

 

A broadcast to the DALI Bus does reach all lights/devices on the bus. But how is it possible to create groups and how can individual devices be addressed?

 

Problem
If the FBoxes are sending broadcast messages, all lights on the bus will be switched on or off at the same time. But usually it is more convenient to address single lights or even better groups of devices.

Solution
DALI offers the possibility to have light-groups and to address each light individually. In order to configure the addresses of each light and to build groups, a configuration tool from the light manufacturer is required.

 

The library of the "RAG Einzelraumregelung" (for the obsolete product PCD7.L71x) is not distributed with recent PG5 versions. In case a project is to be updated and this FBoxes are still needed, please download it from this FAQ.

 

Symptom
After importing an old PG5 project containing the FBoxes for the obsolete PCD7.L71x room controllers, not all FBoxes are found. During the build, PG5 prints the following error messages:
Compiling: D:\Projects\PG5_1_4_Projects\CustomerCPUs\MyProject\MyFupla.fup
S-FUP: Error 65: MyFupla.fup: Page 1(47,28-1): FBox not in library.
After double-clicking the error messages, Fupla opens and e.g. an FBox "PCD7L712" or "EZRCOM2" like in the screenshot below is shown:


Reason
As the products PCD7.L71x are obsolete, the according FBoxes are not installed by default (in order to avoid confusion with the current, similar products).

Solution
Download the library from this FAQ and launch the self-executable "Ragezr.exe". It will extract the library files directly into the same folder as the "Ragezr.exe" is stored. Cut these files and paste them in the folder "c:\Program Files\SAIA-Burgess\PG5 1_4\Libs\Usr\" (for PG5 1.4).
Once this is done, you'll be able to compile the project.

Additional information
The library contained in "Ragezr.exe" contains the following Fupla Macros: _EZRCOM2, _RAGEZR, _RAG12, _RAG11, _RAG10.

 

The new EIB FBox library 2.5.142 (distributed together with PG5 1.4.200) does support the FT1.2 interface (also known as BCU2). Further on also EIBnet/IP (also known as KNXnet/IP) is supported with this library.

 

Supported interfaces
The interfaces listed below are supported by the library version 2.5.142 and higher. The version 2.5.142 is distributed together with PG5 1.4.200.

BCU1
Using the standard BCU1 interface, this well known driver FBox now has been extended to reinitialize the communication by triggering a re-poll all inputs and re-send all outputs using a single trigger input into the driver FBox.

In case communication problems are encountered, the EIB driver FBox can be exchanged with the EIB Extended where specific options are available to tune the interaction with the BCU.

Note: It is NOT recommended to use a BCU1 interface anymore if a higher bandwidth is expected OR if NO telegrams from EIB should get lost! Instead choose a FT1.2 (BCU2) or an KNXnet/IP (EIBnet/IP) solution (see below) for those projects!

FT1.2 (also known as BCU2)
A new driver FBOX for the SIEMENS Gamma Instabus Interface 5WG1 148-1AB04 using the FT1.2 protocol is available from the EIB library version 2.5.142 on. Since this protocol is far more performant than the one specified for the BCU1, no more telegrams are expected to be lost even if the PCD is well charged so Fupla is running below 30 cycles per second.

Note: This solution is recommended for installations without Ethernet and for those where the BCU1 solutions fails to meet the expectations.

KNXnet/IP (also known as EIBnet/IP)
As of today this driver FBox has been tested with the SIEMENS Gamma Instabus Interface 5WG1 148-1AB21. Field tests have also reported that the same FBox can be used with the SIEMENS Gamma Instabus Router 5WG1 146. No more serial cable is needed since the Ethernet port will be connected to the EIB Interface/Router.

Note: This solution is the recommended solution for all new installations with Ethernet!

Other new features of library version 2.5.142

• All driver FBoxes now have two additional trigger inputs. With them the initial polling or sending commands at startup (to be configured in each RCV/Send FBox) can be forced anytime at running time. This is very useful if a communication problem, such as a partial power outage and power return has been detected.
• When the communication interface is to be changed in an existing project, such as the migration from a BCU1 to a BCU2 or KNXnet/IP (EIBnet/IP) , ONLY the driver FBox needs to be replaced! All other EIB FBoxes do not need any modification!

ETS requirements
In order to have the latest components available it's recommended to use ETS3.0 Patch A. The component libraries for ETS can be found on the respective manufacturers home pages.

 

If a existing customer buy a new PG5 library (e.g. the S-Web Editor Advanced) and he had already a licence number for a Modbus library, does he need a new licence number from Engiby?

 

 

No, in case the customer name (user name) has NOT been changed it isn't needed to get a new licence number from Engiby because the licence number from Engiby checks the user name in the User Key.

 

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

 

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

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

Solution

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

 

Yes, starting in the Heavac FBox library version $2.6.153 for PG5 2.0 (or $2.5.318 for PG5 1.4) the FBox "Fan Optimizer PI" features the option to start with a initialization value.

 

Minimal FBox library versions where an initialisation value for the "Fan Optimizer PI" can be provided:

• PG5 2.0: Heavac library version $2.6.153 or newer
• PG5 1.4: Heavac library version $2.5.318 or newer
  

With the HVC FBox 'Clock write' one can set the internal time and date of the PCD.

 

You can apply time and date to the FBox and write those settings into the PCD by triggering the 'EnT' and 'EnD' entries of the 'Clock write' FBox. Notice, that it's not possible to enable time and date instantaneously together with one flag. Time and date have to be enabled one after the other. This FAQ's valid until this phenomenon is corrected with a PG5 version or a specific Firmware.

 

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

 

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

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

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

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

 

In some cases the introduction of "Application Symbols" (A-symbol, such as A.HVC.FBoxName.Error) may be required for a created FBox. These symbols will be available (but not modifiable) in the "System" tab of the Symbol Editor.

 

 

How can an A-symbol be used?
The A-symbols are special global symbols and similar to the System Symbols (S-symbols). The can be used in all program files belonging to the according CPU of the project. A part of the symbol (a group name after the registered prefix) is defined by the Fupla programmer. This is done by defining an FBox name that will be used to build the A-symbol specific to the FBox.
Since the symbols are written and used by the according FBox, they are not ment to be modified by the user program!
§ix100344§

 

How can an A-symbol be created?
It can only be created if the FBox is designed to do it (e.g. most of the Heavac FBoxes).
If this is the case, it is sufficient to give the FBox a name (right mouse click on the FBox and select "FBox properties..."). After the next Build, the according A-symbols will be available.

 

The PI controllers of the Heavac library was modified in the version step from PG5 1.1 to PG5 1.2. This seems a bit disturbing on the first sight. This FAQ explains the changes and their reasons.

 

Explanation
For historical reasons, the "old" PI controller from PG5 version 1.1 and before didn't have the same parameters as the rest of the controllers of the Heavac library. Among others, the only way to set the ampification factor was the option "Amplification F_p" whle the option "X_p range" was absent. This didn't really fit into a library dedicated to the building automatisation, where the "Xp range" is the common specification for the proportional factor of a P controller.
An additional weakness of the old PI controller from PG5 1.1 was the missing dead range of the FBox. There was also a rather complicated specification of the minimal- and maximal percentage of the I-portion of the controller output.
In order to increase the functionality and to reduce the complexity of the PI controller, its implementation got changed.

 

Points to be considered when updating the FBox
Since not only the interface but also some default values were changed, the following points are to be considered when applying the new version of the PI controller:

• The new default value for the proportional factor is "Xprange" and not any more the "Amplification Fp"
  (formula for conversion: Xp = ( Ymax - Ymin ) / Fp).

• The new FBox does have a default dead range of 1% (in order to have the same behaviour as the old FBox had, choose 0%).

• The default value for the integration time Ti is 999.9 seconds in the new FBox while it was only 60 second for in the old FBox (in order to avoid a too agressive controller behaviour with default values, the default value was increased).

Are all existing FBoxes in the existing Fupla programs to be modified?
No, Fupla will leave already existing FBoxes as they are; they will work as before (also after an update of PG5 the old file can be compiled and the old FBox implementation will be used).
Note that PG5 will not insert the old FBox any more. Once an (old) FBox is deleted, the only possibility is using the new version.

 

When using PG5 1.3.120 and having installed the old library "Heavac Dialog", the "S-FUP Error 161: New macro name '_HEAINI6' is not part of library" could appear when opening the Fupla Editor.

 

Symptom
When opening a Fupla file, the following message is shown: "S-FUP: Error 161: New macro name '_HEAINI6' is not part of library."
§ix100212§
most likely, this message is followed with the indication that Fupla couldn't open the desired file:
§ix100213§

 

Reason
This error is caused by a bug in the library Heavac Dialog that is installed by executing the library Installer "HeaDl0D23140SP.exe". The problem only occurs if this library is installed and a new version of the Heavac library is installed, too.

Solution
The problem is easy to fix. In order to do so,

• Open the file:
  C:\Program Files\SAIA-Burgess\PG5 1_3\Libs\App\HEAVDL0.sxg with e.g. Notepad

• Change the line 4 from
  _Dl0Vers=_HeaIni6 to 
  _Dl0Vers=_HeaIni7
  (Don't change anything else in this file! this would lead to unpredictable behaviour of Fupla!)

• Save the file and re-open the Fupla Editor

This problem will be fixed in the next version of the Fupla libraries.

 

In case the parameters of the "Validity scope" of the Heavec-Init FBox are set to the value "External" but no Heavec-Init FBox having these parameters set to "Public" is present (linked) in the CPU, the build will fail due to unresolved externals.

 

The error message of PG5 Project Manager will look similar to the list below:

Assembly complete. Errors: 0 Warnings: 0
Linking: _2_M150.obj+IP_Watchdog.obj+fuplafile.obj+
_Global.obj+_TCPIPDBX.obj+heavac5.obj
Lib files: sfuplib3.obl
To: 2_M150.pcd 2_M150.map

Unresolved Externals:
_HEAVAC._SAMPLING._ONESEC in module fuplafile.obj
_HEAVAC._PERFORM._CYNUMBER in module fuplafile.obj
_HEAVAC._RESET._EXEC in module fuplafile.obj
_HEAVAC._SAMPLING._OVERRUN in module fuplafile.obj
_HEAVAC._SAMPLING._INTERVAL in module fuplafile.obj
_HEAVAC._RESET._SIGNALING in module fuplafile.obj
_HEAVAC._SAMPLING._FIRSTSMPL in module fuplafile.obj
_HEAVAC._SAMPLING._SAMPLE in module fuplafile.obj

Linkage complete. 8 errors, 0 warnings.
Build failed. Total errors: 8 Total warnings: 0
==========================================================

Solution
The problem can easily be solved by setting the "Valitity scope"-parameters to the appropriate setting ("Local" does always work).

 

The FBoxes of the Modem- or Heavac-library (HVC, CVC or HLK FBoxes) must be placed in a cyclically called program block (but not in an XOB or SB!). The reason for this restriction is the initialisation procedure and the internal code structure of the libraries.

 

Since the initialisation of the adjust parameters of the FBoxes is done in the first program cycle, the concerned FBox must be processed while this program cycle.

A further point to be considered it the fact that some of the FBoxes do need several program cycles until their task is processed (e.g. FBoxes for reading analogue input values do only process one channel per program cycle).

As result of those facts it is absolutely necessary that the FBoxes of the HVC and Modem library are processed cyclically in an COB. Also a permanently called FB or PB is possible.
It is not allowed to place FBoxes of the HVC or Modem library in a XOB or in an SB! If they are placed in a XOB the initialisation isn't guaranteed; if they are placed in a SB the code of the FBoxes don't work correctly.

 

the HVC reset option applies to the adjust parameters of the HVC FBoxes. Depending on the mode selected the adjust parameters modified by the end user will be reset to the values entered in the Fupla program.

 

The reset function applies to the adjust values of all FBoxes that belong to the HVC library or the DDC Suite library.
In normal (default) case the values programmed in the FBoxes are set on every startup of the PCD. In case either the end user or the programmer has modified the online values, these modifications will be lost on next startup (or rising edge of the Res input if the "Evaluate Reset Input" was set to "In Runtime").
This behavior does make sense if the values never were initialized or if the programmer did upload the adjust parameters into his program and downloaded it again.
In case the PCD was powered off for an other reason, it may be annoying for the end user because he has to re-adjust all his settings.
This annoyance easily may be avoided by correctly using the Reset options!

In the HVC Init FBox there is the option "Evaluate Reset Input" which refers to the input  "Res" of the input.
The possible selections are "At Startup", "In Runtime" or "Never". The option "At startup" could be used together with an Input connected to the FBox. If the PCD is started while this input is high, the reset will be executed. On "normal" boots of the PCD the values modified by the end user won't be changed.

Further on there is the option "Automatic Reset" which is by default "activated". This causes the program to reset the adjust parameters on startup after a download of the program by PG5.
If the reset input is used, this option won't be used anymore and can be switched to "not activated".

 

When moving PG4 projects to PG5 where the FBox library HVC/CVC/HLK Dialog is used in the PG5 project, then the FBoxes have to be installed manually (because the mentioned library isn't automatically installed with PG5).

Symptom

In a PG5 1.4 or 2.0/2.1 Fupla program there are some FBoxes crossed because the FBoxes with the macro prefixes _Dl0xxx are not available. E.g. the FBox _DL0EDI2I such as shown in the screenshot below (the macro prefix can be displayed by showing the "Advanced info" from the context menu. 


Reason
The FBoxes of the library "HVC/CVC/HLK Dialog" aren't automatically included into the installation of the PG5 1.4 and 2.0/2.1. This is because the program for controlling displays (PCD7.D1xx and PCD7.D2xx) now may be done by using the HMI Editor, which is much more comfortable and efficient. Also all displays are supported by the HMI Editor.

Solution
In case the FBoxes of this library are already used in an existing (PG4 or PG5)-project it is possible to install the "CVC Dialog" library also in PG5 1.4 or PG5 2.0.

 

• PG5 2.1
  Download the file from this FAQ and execute the file
• PG5 2.0
  The executable installation file (HeaDlg_V26100.saiazip) is placed in the folder /PG5 Stand Alone/S-Libraries/Fboxes/ of the PG5 2.0 installation CD.
• PG5 1.4.300
  The executable installation file (HeaDl0_23141.exe) is placed in the folder /Pg5/libs/Old/ of the PG5 1.4 installation CD.

Remark concerning PG5 1.4 on Windows7 (64 bit)
Unfortunately the PG5 1.4 installer for the Dialogue FBoxes can not copy the files to the right directory. Therefore the files need to be extracted manually:

• Rename the installer file from HeaDl0_23141.exe to HeaDl0_23141.zip
• Unzip the files
• Copy the files to the folder where the libraries are installed
  by default c:\Program Files (x86)\SAIA-Burgess\PG5 1_4\Libs\App\

Sometimes it is necessary that the callnumber can be changed in runtime from a webproject, hmi, visualisation... Since the phone numbers are stored in hexadecimal the number can not be easily overwritten.

 

Problem
A phonenumber should be changable in runtime, per example the destinations of the "Call SMS" FBox. Since the phone numbers are stored as hexadecimal values they cannot be overwritten without a conversion.

Solution
The modem library offers FBs for the conversion of the phonenumber. The following FBs are available (after placing the "Modem18" FBox in a Fupla and having rebuilt the program once):

• s.mdm.hextoasc Convert Phone number from HEX to ASCII in 2 reg
• s.mdm.hextotxt Convert Phone number from HEX to ASCII in text
• s.mdm.asctohex Convert Phone number from ASCII 2 reg to HEX
• s.mdm.txttohex Convert Phone number from ASCII 2 reg to HEX

More information about this FBs can be found in the help of the FBox "Update Callnumber". A small example for the use of this FBs is available on request.

 

Yes, the FBox Family "Modem" features an FBox "Read GSM Level".

 

This FBox allows reading the signal quality of the GSM signal.

The Output of the F-Box is a signal quality value (possible values are 0 to 31 and 99)

• Value 0 is the worst
• Value 31 is the best
• Value 99 indicates that the signal level is not known or not detectable

Information about the signal quality

Marginal - Values of 9 or lower.
At these sort of levels, it is very likely that you may suffer low throughput and disconnects due to cell loading/breathing.

Workable under most conditions - Values of 9 to to 14.
Could suffer poor throughput and disconnects due to cell loading/breathing.
Probably worth considering an outdoor gain type antenna.

Good - Values between 14 and 19.
Normally no problem holding a connection with this sort of level (even with cell breathing).

Excellent - Values above 19.
Should not be affected by cell breathing/loading.

 

In some special cases an adaption of the initialization strings used by modem FBox library are required. This FAQ explains the necessary steps for such an adaption.

 

For adapting the strings which are used for a specific modem (by an FBox), the file "modmbase.dat" is to be adapted. The procedure explained in this FAQ involves copying the file "modmbase.dat" into the "CPU directory". By doing so, the modification does only apply for the CPU but not for all programs (with the advantage that the modification will not be removed the next time the Modem FBox library is installed).

• Add the file "modmbase.dat" to the CPU in the PG5 project (right-click the folder "Program Files" and select "Add Files...").
  
• Browse th the file "modmbase.dat" which can be found in the folder:
  c:\Program Files\SAIA-Burgess\PG5 1_4\Libs\App\modmbase.dat
  
  Note that you have to select "All files *.*" as "File Type"
• Once the file is added to the project, open it by double-clicking it (note that this file shall not be "linked" but only present).
  
  It may be that the ".dat" files are not associated to a program; in this case, select "Notepad.exe" as program for opening the modmbase.dat which is a text file.
• Search the section which defines the strings for your modem (the Q.M716-KS1 in this example):
  
  Select the section beginning with the line after "$elseif..." until the last line before "$elseif..." and copy it into the clipboard.
• Search the section [User 1] and replace the section starting below ;; [User 1] until the last line before the next "$elseif..." with the content of the clipboard (the string definition for the modem to be edited).
  
• Edit the string which you want to change:
  
• Save and close the file "modmbase.dat"
• In the modem driver FBox (Modem 18), select the modem type "User 1" instead of the original one:
  
• Save and rebuild your PG5 project.

Remark
If the file "modmbase.dat" which is stored in the FBox library folder (c:\Program Files\SAIA-Burgess\PG5 1_4\Libs\App\modmbase.dat) is modified, this procedure will principally also work. But please note that the next time the FBox library is installed (or its language is changed), the modified file will be overwritten with the original one.

 

In the adust window of the FBox "Call SMS" the actual- and the "last end"-status of the SMS transmission is shown if PG5 is online with the PCD. These states are directly shown as string for better readability. This FAQ contains the according values of the register in the PCD.

 

 

When visualizing this status on a SCADA system such as Visi.Plus, the translation form the read value to the according string must be done. The tables below shows the possible values and their meanings (strings):

 

"Last End" status of "Call SMS" FBox

	Value	String
	0	Standby
	4	Error
	5	Lost
	6	Abort
	9	End
	20	End OK
	21	Error Code
	22	End No OK

 

"Actual Status" of "Call SMS" FBox

	Value	String
	0	Standby
	2	Connect
	4	Error
	5	Lost
	6	Abort
	9	End
	19	Waiting
	40	Command
	322	Call SMS
	800	Call
	900	Aborted

 

 

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

 

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

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

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

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

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

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

 

If an incomplete SMS message text is received, perhaps the necessary delimiter character is wrongly choosed or not set at all.

 

As descripted within the online help for the Modem Library, every SMS message text must be enclosed by a delimiter character:

 

"The message must be marked by delimiters. A character set at beginning and at the end of the message, can be freely selected by the user except some characters reserved for the assembler ( $ @ and " )."

If no delimiter is used at all, a text defined like "Attention! Attic temperature too high!" will be truncated at the second 'A' and the first 'A' is suppressed. So only "ttention! " is transmitted by the Send SMS FBox. The message with ampersands ('&') used as delimiters - "&Attention! Attic temperature too high!&" - will be transmitted completely.

The delimiter character should be choosed carefully, since it must not appear in the message text itself. Otherwise the message will be truncated at this position.

 

In the adust window of the FBox "Modem Driver 14" the status of the modem is shown if PG5 is online with the PCD. The modem status is directly shown as string for better readability. This FAQ contains the according values of the register in the PCD.

 

When visualizing this status on a SCADA system such as Visi.Plus, the translation form the read value to the according string must be done. The table below shows the possible values and their meanings (strings):

Value	String	Value	String
0	Standby	34	Blacklisted
1	Dialing	40	Ring
2	Connect	80	ICC Voice
3	HangUp	81	ICC DATA
4	Error	82	DTMF
5	Lost	90	Init
7	Executed	91	Init MSN
10	Go in AA	92	Load PIN
11	Incoming	94	Life check
12	Assigning	95	No Modem
13	PGU Used	97	HW-Reset
30	Busy	99	Fatal Error
32	No Dialtone	190	Abort
33	No Carrier

SMS can't be sent, the Call SMS Fbox gives an error: End No OK and also Last end Status = Error Code, Last error Code = 96.

 

This error comes when the server number has no land prefix. For Switzerland it has to be +41 79 4999 000 and not only 079 4999 000!

 

 

The FBoxes of the Modem- or Heavac-library (HVC, CVC or HLK FBoxes) must be placed in a cyclically called program block (but not in an XOB or SB!). The reason for this restriction is the initialisation procedure and the internal code structure of the libraries.

 

Since the initialisation of the adjust parameters of the FBoxes is done in the first program cycle, the concerned FBox must be processed while this program cycle.

A further point to be considered it the fact that some of the FBoxes do need several program cycles until their task is processed (e.g. FBoxes for reading analogue input values do only process one channel per program cycle).

As result of those facts it is absolutely necessary that the FBoxes of the HVC and Modem library are processed cyclically in an COB. Also a permanently called FB or PB is possible.
It is not allowed to place FBoxes of the HVC or Modem library in a XOB or in an SB! If they are placed in a XOB the initialisation isn't guaranteed; if they are placed in a SB the code of the FBoxes don't work correctly.

 

During the year 2003 SBC has delivered PCD2.T813Z42 modems. This is also an analogue modem like the PCD2.T813. The differrence is that the PCD2.T813Z42 in fact is a 56k modem while the PCD2.T813 is a 33.6k modem.

 

In the hardware settings only the type PCD8.T813 is available. This selection also fits when using the PCD2.T813Z42.

 

For using the modems with the modem FBox library both types can be configured in the "Modem 14" FBox.
The main difference between the AT commands of the two types is the handling of the DTMF commands. Therfore it is important to select the correct type in the "Modem 14" FBox when using the DTMF driver FBox. 
In case the modem only is used for going online and DTMF isn't used, it doesn't make a difference which  modem is selected in the "Modem 14" FBox.

 

By using the filed "confirmation option" you can define the behaviour of the PCD for received SMS.

 

There is the possibility that the PCD does send back a confirmation SMS for each received SMS. On this confirmation SMS you will see if the received DTMF instruction was performed correctly or not.

How to activate?
To activate the confirmation SMS you have to choice the filed "confirmation option" on the FBox "Poll SMS".

• If you select the option "Replay" then the confirmation SMS will be send back to the originator of the SMS.
• If you select the option "Destination" then the confirmation SMS will be send to the to the defined destination number.

Remark
Don't forget to set the FBox input "EnR" (Enable Reply) to 1 to enable this option.

 

The GSM standard does not support the receiption of DTMF tones by a GSM modem. This means that it isn't possible to send DTMF tones to a PCD which is equipped with a GSM modem.

 

Can a GSM modem (terminal) receive DTMF tones?
It's not possible to receive DTMF tones with a GSM modem (mounted on a PCD). This is due to the fact that the GSM standard doesn't support the reception of DTMF tones on a GSM modem.

 

Can I still have a similar functionality when I use a GSM terminal?
If you want to have the DTMF funcionaltiy (set binary/numeric values on the PCD or know the status of binary/numeric values of the PCD) on a PCD equipped with GSM modem then you can take advantage of the SMS service:
You can send a SMS message containing DTMF commands to the PCD (in the same way as you would use the phone keys for the DTMF). The PCD then can respond with a SMS to e.g. the originator of the command (for the acknowledgement of the command).

How can I realize that?
On the PCD you have use the FBox "PollSMS" to receive the SMS and the FBox "DTMF Driver" and "DTMF user xy" to handle the text on the received SMS. For further information please refer to the example available in the "Getting started" area of the support site www.sbc-support.ch and to the online help of the relevant FBoxes.