Trouble Connecting to X20CP1483 via PVI / ANSL – Port 11169 Visible but Unable to Establish Connection

alx_mcqueen · January 22, 2026, 4:25pm

Hello everyone,

I’m currently working on a system using a B&R X20CP1483 CPU, and I’m trying to establish a reliable connection from a C# application in order to pull production data continuously (24/7 monitoring of a critical process).

Goal

Use C# (PVI / ANSL) to connect to the PLC and read production-related variables throughout the day.

Current Situation

Software

Automation Studio available
PVI previously provided by B&R (license/security files were sent to us a few years ago)
PVI currently appears to still be in trial mode
Attempting to connect via:
- Automation Studio
- C# application using PVI

Where I’m Stuck

From my understanding:

Port 11159 (UDP) → Legacy INA protocol
Port 11169 (TCP) → Current ANSL protocol (used by X20 / Automation Runtime)

Currently:

Port 11169 (TCP) is reachable and visible via port scan
Port 11159 (UDP) does not appear to respond
The last configuration file I have references 11159, which makes me think it may be outdated or tied to an older communication method

At this point I’m unsure whether:

The PLC is still configured for legacy INA
The ANSL service is not fully enabled on the PLC
PVI licensing is preventing communication
There is a mismatch between Automation Studio version, runtime, and PVI version

What I’m Looking For Help With

Confirmation of the correct communication method
- For X20CP1483, should I be using:
  - ANSL over TCP (11169)?
  - Or INA / UDP (11159)?
What must be enabled on the PLC side
- Required Automation Runtime settings
- Services that must be active
- Whether the PLC needs to be in RUN mode
PVI Licensing
- How to confirm whether PVI is properly licensed vs trial
- Whether an expired PVI license would prevent connection entirely
Networking Requirements
- Any special routing or port forwarding considerations
- Whether UDP 11159 is still required at all
- Expected behavior when everything is configured correctly
Best Practice for C# Connectivity
- Recommended approach for stable 24/7 data acquisition
- Whether PVI is still the best option or if OPC UA is preferred

End Goal

A stable, supported way to:

Connect to the X20 PLC
Read production data continuously
Use C# for monitoring and reporting
Avoid trial-mode or licensing issues

Any guidance from someone who has successfully implemented this (especially with X20 + PVI/ANSL) would be greatly appreciated.

Thank you in advance.

valerio.manenti · January 22, 2026, 5:53pm

Hi @alx_mcqueen ,
welcome to the community!
I worked almost 10 years ago with a customer that used our system with an HMI developed in c# with PVI Services.
When you download the PVI Development Setup

There is a folder with list of help files, please check in particular the PviServices one

Whether PVI is still the best option or if OPC UA is preferred
I guess now we recommend OPC UA communication.

Ciao
Valerio

alexander.hefner · January 22, 2026, 6:24pm

Hi,

can you tell us the Automation Runtime version in use?
I’m asking because the CP1483 is quite old and discontinued, so I assume the AR version has some restrictions / differences compared to todays functionality ( for example if ANSL is already available for variable communication, if a older PVI version is needed, and so on).

Best regards!

alx_mcqueen · January 26, 2026, 3:23pm

Hello,

Thanks for the response.

I have Automation Runtime 3.0.80

alexander.hefner · January 27, 2026, 6:33pm

Hi @alx_mcqueen

Thanks for your response!
3.0.80 sounds more like a Automation Studio version, not Automation Runtime.
But that’s not so important, I think you’re using “some 3.xy” version anyhow, because for X20CP1483 the last Automation Runtime available was 3.10 as I remember (this PLC type was discontinued and haven’t had any Runtime 4 version available).

I can’t swear, but as I remember, ANSL wasn’t available for process variable communication in 3.x versions (maybe it was already used for enhanced project transfer, unfortunately I can’t remember. But I’m relativly sure that the possibility of using ANSL for other communication services than online transfer was introduced somewhen later with 4.x versions).

So I think, INA has to be used in your use-case.
A communication with INA should be possible independent of if the PLC is in RUN, in SERVICE or in DIAGNOSE (but not in every mode all communication services are available; for example in DIAG, you can’t connect to a task or a variable, as the user software is not loaded by Automation Runtime in that mode).

As you mentioned, the standard INA port is 11159 UDP (except of using the simulation, then it’s 11160). It’s hard to say why this port isn’t responding, but maybe it’s important to know that the INA port can be changed, and the whole communication can also be deactivated in the project (which makes not too much sense because then you need to go online over RS232 for example) or by using a library call at runtime… hard to say if this was done without having the original project, but I thaught it’s worth to mention.
Using PVI Services .NET with C# and INA is possible: it’s many years ago since I did it the last time, therefore unfortunately I haven’t any sample code available.

About the PVI license topic: everything should work for 2 hours, independent if you’re in licensed or in trial mode (I’ve no idea why it doesn’t work as expected, I just know that PVI licensing was changed in past from a license file to technology guarding, so maybe you need an older PVI version for using the licence file?).

I’m sorry that I can’t give more concrete advise right now.
But I would at least recommend to setup a minimal project (e.g. one task, one variable) with the simulation processor in your Automation Studio version, start the simulation, try to connect with a minimal C# code and check if that works (please remember, if using simulation the INA port is different)… if yes, we at least now that it works in common, and we have to go deeper into detail why it doesn’t work with the real system.