B&R PLC(X20CP0484) IEC 104 Communication – Sending Data to Two Servers (Primary & Secondary)?

MDParvezSarkar · August 25, 2026, 5:49am

B&R PLC (X20CP0484) IEC 104 Communication – Sending Data to Two Servers (Primary & Secondary)

Hello B&R Community,

I am working on an IEC 104 communication project using a B&R PLC (X20CP0484). Currently, my B&R PLC is configured to send IEC 104 data to one server IP address.

Now, I have a requirement to send the same IEC 104 data to two different servers for redundancy:

Primary Server: Server IP 1
Secondary Server: Server IP 2

Current Communication

B&R PLC (X20CP0484) → IEC 104 → Primary Server

At present, my B&R PLC(X20CP0484) IEC 104 program is configured with only one destination/server IP address.

Required Communication

I need the B&R PLC (X20CP0484) to send the same IEC 104 data to both servers:

B&R PLC → IEC 104 → Primary Server
B&R PLC → IEC 104 → Secondary Server

Both servers should receive the same process data from the B&R PLC (X20CP0484).

My Questions

Is it possible to configure two IEC 104 server/client connections in a B&R PLC so that the same data can be transmitted to two different IP addresses simultaneously?
Can I configure two separate IEC 104 communication instances/channels in the B&R PLC program, one for the Primary Server and another for the Secondary Server?
If the IEC 104 library/function block supports multiple connections, what is the recommended B&R configuration and programming method?
Is there a recommended way to implement Primary/Secondary server redundancy using B&R IEC 104 communication?
If the Primary Server is disconnected, can the B&R PLC continue communicating with the Secondary Server without affecting the IEC 104 data transmission?
Are there any limitations regarding multiple IEC 104 connections, TCP ports, connection IDs, ASDU addressing, or data mapping when sending the same data to two servers?

I would appreciate it if anyone could share a B&R Automation Studio example, recommended architecture, function block configuration, or sample code for this type of IEC 104 dual-server communication.

Thank you in advance for your support.

kovarj · August 26, 2026, 7:46am

TBH I have no experiences with IEC 104 Communication and I have not found anyting in official documentation. Is this APROL application? Is this communication based on IEC 60870-5-104 server/client?

MDParvezSarkar · August 27, 2026, 4:19am

Dear B&R Support Team,

Thank you for your response.

Yes, we are using the B&R X20CP0484 PLC with Automation Studio for the IEC 60870-5-104 communication. We are not using an APROL application.

We are using the IEC104 driver and configuration format referenced in the official B&R documentation, including drv104Init, cfg104000, cfg104001, IEC104.STATIONS, STATIONIP, STATIONCONTROL, COMMONADDR, etc.

Our requirement is to send the same IEC 104 data from one B&R PLC to two SCADA servers simultaneously:

Primary SCADA Server: 192.168.68.244
Secondary SCADA Server: 192.168.68.245

Currently, we can successfully establish the IEC 104 communication and transfer data to one server. However, both servers cannot establish and maintain the connection simultaneously. When one connection is active, the other connection does not connect properly.

According to our understanding of the B&R documentation, multiple stations/connections should be possible, which is why we created two station configuration files.

Server 1 – cfg104000 :

Station: DHKRT_PRIMARY
IP: 192.168.68.244
Station Index: IEC104.STATIONS[0]
Common Address: 0.1

Server 2 – cfg104001 :

Station: DHKRT_SECONDARY
IP: 192.168.68.245
Station Index: IEC104.STATIONS[1]
Common Address: 0.1

The configuration structure for both stations is essentially the same, with the corresponding station index and IP address changed.

We have already tested the communication with each server individually, and the communication works. Our issue is specifically that both IEC 104 connections are not working simultaneously.

We are sharing our configuration with you because we could not find a clear example in the official B&R documentation showing how to configure two simultaneous IEC 60870-5-104 connections from the same B&R PLC to two different controlling stations.

Could you please help us confirm the following?

Does the B&R IEC104 driver support two simultaneous IEC 60870-5-104 connections from the same PLC to two different server/client IP addresses?
Is our approach of using IEC104.STATIONS[0] and `IEC104.STATIONS[1] correct for this requirement?
Do we need separate DataMod/data-point configurations for each station?
Is there any additional PLC code or driver configuration required to activate both stations simultaneously?
If possible, could you provide a B&R example or recommended configuration for one PLC communicating simultaneously with two IEC 104 controlling stations?

Our purpose is not to change the existing working communication. We can already communicate with one server successfully. We mainly need your guidance or an example/idea for making the Primary and Secondary IEC 104 connections active at the same time.

We would appreciate your technical guidance on this.

Best regards,
Md Parvez Sarkar

alexanderstieglbauer · August 27, 2026, 10:05am

Hello Parvez

In principle, it should be possible to communicate with multiple participants/clients.
However, only one instance of the driver may be created, i.e., only one drv104Init FUB.
See page 9 of the documentation for more information:

In the data object being used, an additional file with the corresponding configuration must then be inserted.
This way, you still have the same data object, which is attached to the single Init FUB → thus, only one instance is created.
However, the additional `file` in the data object still allows communication with another client.
This is described in the documentation on page 29:

If this has already been implemented as described in the documentation, I would ask you to contact your local support team.

Best Regards
Alexander

MDParvezSarkar · August 27, 2026, 10:22am

Hello Alexander,

Thank you for your clarification.

We have carefully reviewed the documentation references you provided, including Page 9 and Page 29, and we have tried the recommended configuration methods. We are also using only one drv104Init FUB instance, as you mentioned.

However, we are still unable to share data with two IEC104 clients simultaneously. Only one client communicates at a time.

Configuration 1 – Server 1

#STATION=DHKRT_PRIMARY
#STATIONIP=192.168.68.244
#STATIONCONTROL=CONTROLLING

#BROADCASTTIME=IEC104.STATIONS[0].BROADCASTTIME
#STATIONSTATUS=IEC104.STATIONS[0].STATIONSTATUS
#STATIONITELSENDCNT=IEC104.STATIONS[0].STATIONITELSENDCNT
#STATIONITELRECCNT=IEC104.STATIONS[0].STATIONITELRECCNT

#COMMONADDR=0.1
#GIRESULT=IEC104.STATIONS[0].CA[0].GIRESULT
#VARBUFFERING=ENABLED

This configuration is saved as:

cfg104000

Configuration 2 – Server 2

#STATION=DHKRT_SECONDARY
#STATIONIP=192.168.68.245
#STATIONCONTROL=CONTROLLING

#BROADCASTTIME=IEC104.STATIONS[1].BROADCASTTIME
#STATIONSTATUS=IEC104.STATIONS[1].STATIONSTATUS
#STATIONITELSENDCNT=IEC104.STATIONS[1].STATIONITELSENDCNT
#STATIONITELRECCNT=IEC104.STATIONS[1].STATIONITELRECCNT

#COMMONADDR=0.1
#GIRESULT=IEC104.STATIONS[1].CA[0].GIRESULT
#VARBUFFERING=ENABLED

This configuration is saved as:

cfg104001

Single `drv104Init` implementation

We are using only one drv104Init FUB:

void _INIT ProgramInit(void)
{
    IEC104.GLOBALLOGGERFILTER = 0x00000000;


 

    strcpy(drv104Init_0.CfgName, "cfg1040");

    drv104Init_0.MaxPercentTimeOfTC = 40;
    strcpy(drv104Init_0.EthernetDevices, "ANY:2404");

    drv104Init_0.ActVarMode = 1;
    drv104Init_0.RedMode = 0;
    drv104Init_0.AllowReconnection = 1;

    drv104Init_0.pTotalITelRecvCounter = &IEC104.TOTALITELRECCNT;
    drv104Init_0.pTotalITelSendCounter = &IEC104.TOTALITELSENDCNT;
    drv104Init_0.pGlobalLoggerFilter = &IEC104.GLOBALLOGGERFILTER;
    drv104Init_0.pAcceptsCounter = &IEC104.ACCEPTSCOUNTER;
    drv104Init_0.pDeniesCounter = &IEC104.DENIESCOUNTER;

    drv104Init(&drv104Init_0);
}

And the same station list is used by the single cyclic FUB:

void _CYCLIC ProgramCyclic(void)
{
    drv104Cyclic_0.pStationsList = drv104Init_0.pStationsList;
    drv104Cyclic(&drv104Cyclic_0);
}

We have tried the documented approach, but both clients are still not communicating simultaneously.

We also tested by swapping the server IP addresses:

Test 1:
cfg104000 → 192.168.68.244 → OK
cfg104001 → 192.168.68.245 → FAIL

Test 2:
cfg104000 → 192.168.68.245 → OK
cfg104001 → 192.168.68.244 → FAIL

So the problem appears to be related to cfg104001 / STATION[1] rather than the server IP address.

Could you please advise us how to properly activate/enable the second configuration (cfg104001) in the same Data Object, so that both IEC104 clients can communicate simultaneously using the single drv104Init instance?

We have tried the methods described in the documentation, but we may be missing a specific Data Object / additional file / #INCLUDE configuration step.

Thank you for your support.

Best Regards,
Md. Parvez Sarkar

alexanderstieglbauer · August 28, 2026, 11:36am

After analyzing your code I might have an idea where the problem comes from.

The driver takes CfgName and appends a 3-digit index. With CfgName = "cfg1040":

Logical station	Driver builds (base + index)	Your real file	Effect
0	`cfg1040` + `000` = `cfg1040000`	`cfg104000`	The extra `0` is absorbed into the zero-run — depending on how the name is matched/truncated, it still resolves to the `cfg104000` content → works
1	`cfg1040` + `001` = `cfg1040001`	`cfg104001`	Now the misalignment lands on the meaningful digit: the driver is effectively looking for the wrong name / wrong index. The `...001` file is never correctly resolved → STATIONS[1] silently missing

In other words: for index 000 the “off-by-one-character” collides with a 0 and does no harm; for index 001 the same shift hits the significant 1, so the second station is lost. That’s exactly why:

Swapping IPs made no difference (the problem follows the file index, not the IP), and
Only ever one station comes up.

Conclusion — fix

strcpy(drv104Init_0.CfgName, "cfg104");

With the correct 6-character base, the driver builds cfg104 + 000 / 001 = cfg104000 / cfg104001, both aligned exactly to your data objects. STATIONS[0] and STATIONS[1] should then both load.

kovarj · August 28, 2026, 11:53am

Can you test it @MDParvezSarkar and provide us feedback?

MDParvezSarkar · August 30, 2026, 6:37am

Hello Alexander Stieglbauer,

Thank you for your analysis and for identifying the CfgName indexing issue.

We have tested your suggested change:

strcpy(drv104Init_0.CfgName, "cfg104");

However, after changing CfgName from "cfg1040" to "cfg104", neither of the two servers connects.

Our previous configuration was:

strcpy(drv104Init_0.CfgName, "cfg1040");

With this configuration:

cfg104000 → Server 1 (192.168.68.244) → Connected
cfg104001 → Server 2 (192.168.68.245) → Not connected

After applying your suggested fix:

strcpy(drv104Init_0.CfgName, "cfg104");

cfg104000 → Connected
cfg104001 → Not connected

Could you please advise whether there is any additional configuration required when using:

CfgName = "cfg104"

or whether the configuration file naming/Data Object structure needs to be changed accordingly?

We can provide the updated Watch screenshot and configuration if required.

Best Regards,
Md. Parvez Sarkar

MDParvezSarkar · August 30, 2026, 6:45am

Hello Jaroslav Kovar,

Thank you for your analysis.

We have tested your suggested change:

strcpy(drv104Init_0.CfgName, "cfg104");

`cfg104000` – Primary Server

#STATION=DHKRT_PRIMARY
#STATIONIP=192.168.68.244
#STATIONCONTROL=CONTROLLING

#BROADCASTTIME=IEC104.STATIONS[0].BROADCASTTIME
#STATIONSTATUS=IEC104.STATIONS[0].STATIONSTATUS
#STATIONITELSENDCNT=IEC104.STATIONS[0].STATIONITELSENDCNT
#STATIONITELRECCNT=IEC104.STATIONS[0].STATIONITELRECCNT

#COMMONADDR=0.1
#GIRESULT=IEC104.STATIONS[0].CA[0].GIRESULT
#VARBUFFERING=ENABLED

`cfg104001` – Secondary Server

#STATION=DHKRT_SECONDARY
#STATIONIP=192.168.68.245
#STATIONCONTROL=CONTROLLING

#BROADCASTTIME=IEC104.STATIONS[1].BROADCASTTIME
#STATIONSTATUS=IEC104.STATIONS[1].STATIONSTATUS
#STATIONITELSENDCNT=IEC104.STATIONS[1].STATIONITELSENDCNT
#STATIONITELRECCNT=IEC104.STATIONS[1].STATIONITELRECCNT

#COMMONADDR=0.1
#GIRESULT=IEC104.STATIONS[1].CA[0].GIRESULT
#VARBUFFERING=ENABLED

Current C configuration

We are using only one drv104Init FUB:

#include <bur/plctypes.h>

#ifdef _DEFAULT_INCLUDES
    #include <AsDefault.h>
#endif

void _INIT ProgramInit(void)
{
    IEC104.GLOBALLOGGERFILTER = 0x00000000;

    strcpy(drv104Init_0.CfgName, "cfg104");

    drv104Init_0.MaxPercentTimeOfTC = 100;
    strcpy(drv104Init_0.EthernetDevices, "ANY:2404");

    drv104Init_0.ActVarMode = 1;
    drv104Init_0.RedMode = 0;
    drv104Init_0.AllowReconnection = 1;

    drv104Init_0.pTotalITelRecvCounter = &IEC104.TOTALITELRECCNT;
    drv104Init_0.pTotalITelSendCounter = &IEC104.TOTALITELSENDCNT;

    drv104Init_0.pGlobalLoggerFilter = &IEC104.GLOBALLOGGERFILTER;
    drv104Init_0.pAcceptsCounter = &IEC104.ACCEPTSCOUNTER;
    drv104Init_0.pDeniesCounter = &IEC104.DENIESCOUNTER;

    drv104Init(&drv104Init_0);
}

void _CYCLIC ProgramCyclic(void)
{
    drv104Cyclic_0.pStationsList = drv104Init_0.pStationsList;
    drv104Cyclic(&drv104Cyclic_0);

}

void _EXIT ProgramExit(void)
{
    drv104Exit_0.pStationsList = drv104Init_0.pStationsList;
    drv104Exit(&drv104Exit_0);
}

Best Regards,
Md. Parvez Sarkar

alexanderstieglbauer · August 31, 2026, 7:58am

Hello @MDParvezSarkar

That is interesting, thank you for testing.

For further analysis please capture (try this with both CfgName settings):

drv104Init_0.ConfigStatus (file name + line + text) right after boot. This will show whether cfg104001 was parsed at all, or rejected with an error/line number.
drv104Init_0.pStationsList — how many stations are actually in the list? If it contains only one entry, the second file was never loaded/appended. If it contains two, the problem is in station 1’s runtime activation instead.
IEC104.STATIONS[1].STATIONSTATUS value (raw number) — does STATIONS[1] populate at all, or stay 0?

I will try to provide more information based on these data points.

MDParvezSarkar · August 31, 2026, 11:01am

Hello Alexander Stieglbauer,

Thank you for your guidance. We have completed the requested checks, and we believe we have now identified the issue more clearly.

The total number of stations is 2, and both STATION[0] and STATION[1] are created in the station list.

However, our testing shows that only cfg104000 is actually loaded and processed. The cfg104001 file does not appear to be loaded.

We tested this by changing the station reference inside cfg104000:

When cfg104000 uses IEC104.STATIONS[0], Server 1 connects successfully.
When we change the same cfg104000 file to use IEC104.STATIONS[1], the connection is established using STATION[1].

Therefore, both STATION[0] and STATION[1] can work correctly.

This confirms that the problem is not with STATION[0] or STATION[1] runtime activation. The issue appears to be that:

cfg104000 → Loaded and processed
cfg104001 → Not loaded / not processed

So we believe the final issue is how to correctly load or append cfg104001 to the same Data Object configuration.

Could you please advise us on the exact method required to ensure that the driver loads both files:

cfg104000
cfg104001

using the single drv104Init instance?

Specifically, we would appreciate an example of the correct Data Object structure, file naming, or additional file configuration required to load cfg104001 together with cfg104000.

Thank you for your continued support.

Best Regards,
Md. Parvez Sarkar

alexanderstieglbauer · August 31, 2026, 11:47am

That points to one of these concrete causes. Check them in order:

1. `cfg104001` **is not actually a build data object / not deployed (most common)**

The file existing in your AS project tree is not enough — it must be a Data Object that is built into the configuration and downloaded to the PLC, exactly like cfg104000. Verify:

cfg104001 is a binary Data Object (same object type as cfg104000), not just a text/description file.
It is assigned to the same CPU/configuration and is active in the physical view (not excluded from build).
After download, it physically exists on the target. In AS you can check the deployed modules; cfg104001 must be present alongside cfg104000.

Quick decisive test: temporarily rename the content — put the secondary station definition into a fresh copy of the working object. I.e. duplicate cfg104000 (which you know deploys correctly), rename the copy to cfg104001, and paste the secondary station’s directives into it. If it then loads, the original cfg104001 object had a build/deployment problem, not a content problem.

2. The data object name/index isn’t contiguous or is mis-typed

Enumeration is strictly 000, 001, 002… with no gaps and an exact 3-digit suffix. Confirm the object is named literally cfg104001 (digit “one” 001), not cfg1041, cfg104_1, cfg104100, or with a differing case. A single character off and the driver won’t find index 001 and stops after 000.

3. `cfg104001` fails to parse, so it’s dropped

If the object exists and is named right but has a syntax problem, the driver discards it. This is what drv104Init_0.ConfigStatus reports (file name + line + text). You mentioned the station list shows 2 — but that count can come from your variable-side STATIONS[] array, not from successfully parsed files. ConfigStatus is the authoritative source for “was cfg104001 parsed, and if not, why.”

The correct structure (for reference)

A single drv104Init with CfgName="cfg104" and these Data Objects:

Data Object (name)	Type	Content	Purpose
`cfg104000`	Data Object	primary station directives	STATIONS[0], IP .244
`cfg104001`	Data Object	secondary station directives	STATIONS[1], IP .245

No #INCLUDE, no extra init call, no second drv104Init is needed — the running index is the mechanism.
Both objects must be the same object type, in the same configuration, built and downloaded.
Contiguous indices starting at 000.

Please confirm these three things

In the AS Physical View / Configuration, is cfg104001 the same Data Object type as cfg104000, assigned to the same CPU, and not excluded from build?
After download, does cfg104001 actually exist on the target (deployed module list)?
What does drv104Init_0.ConfigStatus say after boot — any reference to cfg104001 with a line/error, or nothing at all?

Topic		Replies	Views
Cpu x2p cp1484 does not connect online B&R Software & Runtime automation-studio	31	1654	April 2, 2024
RS485 communication x20 series Controls & Vision plc , modbus	37	1929	May 15, 2024
AUtomation studio V2.7/Software and Ethernet communication for X20CP3485-1 B&R Software & Runtime automation-studio-6	5	117	September 9, 2026
Read variable value from old B&R PLC B&R Software & Runtime automation-runtime	8	250	April 10, 2026
TCP/IP data read/write in 4PPC70 display Programming automation-studio	19	1198	May 13, 2024

B&R PLC(X20CP0484) IEC 104 Communication – Sending Data to Two Servers (Primary & Secondary)?

B&R PLC (X20CP0484) IEC 104 Communication – Sending Data to Two Servers (Primary & Secondary)

Current Communication

Required Communication

My Questions

Configuration 1 – Server 1

Configuration 2 – Server 2

Single drv104Init implementation

Conclusion — fix

cfg104000 – Primary Server

cfg104001 – Secondary Server

Current C configuration

1. cfg104001 is not actually a build data object / not deployed (most common)

2. The data object name/index isn’t contiguous or is mis-typed

3. cfg104001 fails to parse, so it’s dropped

The correct structure (for reference)

Please confirm these three things

Related topics

Single `drv104Init` implementation

`cfg104000` – Primary Server

`cfg104001` – Secondary Server

1. `cfg104001` **is not actually a build data object / not deployed (most common)**

3. `cfg104001` fails to parse, so it’s dropped