Debugger activation problems in AS6.3.4.31

Ask Questions B&R Software & Runtime
1

Hello,
I have a problem with the debugger in AS 6.3.4.31.
Previous issues with the simulation were resolved by properly installing AS (as an administrator) and the security software suite FortiClient (by our IT department).
This setup also helps occasionally run the debugger on the PLC.

However, most of the time, activating the PLC debugger ends with the following dialog:

obrázok
obrázok486×208 6.46 KB

An even worse situation occurs with the simulation debugger, which cannot be activated at all — it always ends with a timeout:
obrázok
Has anyone experienced similar issues?
According to the security software status, it does not block any processes or ports, and the same applies to the Windows 11 firewall.

Thank you.

2

Hi Michal,

This is a known issue of AR 6.4.2. You have to options:

  1. Go back to AR 6.3.4
  2. Use the workaround

Workaround:

  1. Open Powershell as Administrator
  2. Start Debugger with AS6 AR 6.4.2
  3. Check connection
1..50 | % {

$c = Get-NetTCPConnection -LocalPort 2323 -ErrorAction SilentlyContinue

if ($c) { $c | ft State,LocalAddress,LocalPort,OwningProcess; break }

Start-Sleep -Milliseconds 200

}
  1. Execute the follow command to start service for Portproxy (copy/paste the two lines in powershell and press enter)
Set-Service iphlpsvc -StartupType Automatic
Start-Service iphlpsvc
  1. Set-up the forwarding
netsh interface portproxy add v4tov6 `
listenaddress=127.0.0.1 listenport=2323 `
connectaddress=::1 connectport=2323
  1. Check if creating the portproxy was successful

netsh interface portproxy show all

From the ticket:

  • Issue was introduced with AR 6.4
  • It depends on Windows IPv6 prefix policies, which is the reason why it does not happen on all PCs, Customers, …
  • GDB Client in Automation Studio does not support IPv6
  • Issue will be fixed with AR 6.5
  • Fix: IPv4 mode will be enforced when starting GDB
3 Likes
3

Hi Simon,
I’ve marked the issue as solved, but that’s only true for the PLC. When downgrading to version 6.3.4, the simulation enters a strange state — it appears to be in run mode (both in ARsim and AS), and all programs on the target match those in the project, but it doesn’t actually run. The debugger shows this dialog:

obrázok
obrázok552×319 11.9 KB

I’ve tried all the usual tricks (rebuild, restart PC, offline commissioning, clear configuration, delete Temp and binary files, etc.), but none of them work.
Do you have any idea how to deal with this?
Thank you
Regards
Michal Malek

4

Hi,

just for the record, I ran into the same issue today.

Thanks @Michal_Malek for reporting this here so I know it’s not related to my specific installation. The “strange state” that you observed after downgrading resulted for me without downgrade but with modifications in the PVI Manager properties, cf. B&R Online Help . (specifically after enabling “Use TCP/IP Communication” with port 2323). So the text might just be a common symptom of some invalid configuration.

Since AR6.5 is supposed to fix this: For when is this scheduled?

Best regards

Lukas

5

Hi Lukas,
I’m happy too — at least there are two of us experiencing these problems :-). Unfortunately, these aren’t the only ones, and with every step I take in AS6, I’m solving a new issue. Hopefully AR6.5 will fix most of them :-).
Regards
Michal Malek

6

This should be released in the first week of December.

2 Likes
7

I have installed Automation Studio 6.5.0.306, but the same problem persists:

First attempt:

(gdb) target remote 127.0.0.1:2323
127.0.0.1:2323: Connection timed out.
(gdb) set print raw-frame-arguments on
(gdb) set python print-stack full

Then, when I try again, the simulator (ARSim) becomes unresponsive and needs to be restarted.

8

Hi,
The problem has been fixed with the new Automation Runtime version.
AR = Automation Runtime
AS = Automation Studio
Do you also have the new AR version?

image
image552×606 51.6 KB

2 Likes
9

Hi Rickard and Simon,

It seems that Rickard is right. I have installed all the 6.5 upgrades, but simulation debugging is still not working and shows the same dialog as it did with version 6.3.4.

obrázok
obrázok938×353 37.9 KB

Regards
Michal Malek

10

Hi again!
It’s working for me now, but I’ve only tested it in the simulator.
I installed Automation Runtime 6.5.1 and, just to be safe, deleted the Temp folder. Then I performed a rebuild (initial install).
Thanks for the advice!
Best regards,
Rickard

2 Likes
11

Hello,
unfortunately we have the same problem(or it at least looks the same) also with recently installed Automation Runtime 6.5.1 and Automation Studio V 6.5.0.306.
Now we are not able to activate Debugger with PLC(X20CP0484_1) at all.
It ended always with this error:

image
image400×149 4.39 KB

Here are our current versions:

image

image
image517×693 23.1 KB

We have also deleted Temp subfolder with the same result.

Debugger works fine with Simulator(ArSim) after removing Temp subfolder.

Some background info: I have reinstalled AS 6.5.0.306 from the official zip file from BR web, before reinstallation we used AS 6.3.something and runtime on X20CP0484_1 ‘6.1.1’. My colleague installed AS 6.5.0.306 on completely new reinstalled W11 (so no previous version of AS was installed on his PC), also with the same result - Debugger ended with error during connection with PLC. Also we don’t have admin rights for developers in our company (installation has been made by our IT team) but we also tried to run AS 6.5.0.306 with admin rights with the same result. We have also tried Powershell’s commands from this thread(though I assume they are useless in Runtime 6.5.1) with the same result.

Any suggestions on how to get it to work?

Thank you in advance.

12

Hi @Marek_Hluchnik ,
Welcome to the community!
It seems R&D has fixed debugger issues on the new Automation Runtime, but unfortunately you still are facing new debugger issue.
In Czech republic we have strong B&R team, I recommend to report new issue to them so they can create a CASE and International Support can link your issue to the one already reported.
In the mean time on our side we will update you if we find possible work around.
I know it’s not the answer you need but I see your case required deep investigation.
Ciao
Valerio

1 Like
13

Hello,
Finally, together with our B&R support team, I found a solution to the original simulation debugging problem, and the debugger in simulation mode is now working as expected.

In my case, the issue was related to the TCP port 2323 being occupied by the iphlpsvc service. I stopped this service and released the port for simulation purposes.

Hopefully, this can help someone else.

Regards
Michal Malek

1 Like
14

@Michal_Malek I told you we have strong team In Czech republic.
Thaks
Ciao
Valerio

15

I suppose this is only related to debugger connection with simulator(ArSim) and it is not related to debugger running on PLC.

16

Important: Disable Old Portproxy Workaround When Using AR 6.5.x and newer

Explanation

In older Automation Runtime versions ( AR 6.4.x), a workaround was sometimes used that configured a Windows port forwarding (portproxy).
This redirected incomming IPv4 connections to an IPv6 port to work around a networking issue where windows ip preferences caused gdbserver to open an ipv6 port
instead of an ipv4 port.

Starting with Automation Runtime 6.5.x, gdbserver was changed to use IPv4 only. Because of this change, the old workaround is no longer compatible and
no longer needed.

If the portproxy workaround is still configured on the system, Windows will redirect the IPv4 connection to an IPv6 port that is no longer used. This prevents gdbserver from accepting connections and can cause connection failures.

What this means

If this workaround is still active on a system running AR 6.5.0 or newer, it will break the gdbserver connection.

Recommended action

Please check whether a Windows portproxy (IPv4 → IPv6 forwarding) is still configured.
If it is present, it must be removed or disabled to restore normal gdbserver connectivity.

Check if portproxy is aktive (if it lists entries with port 2323 it is aktive):
netsh interface portproxy show all

Disable portproxy:

netsh interface portproxy delete v4tov6 listenaddress=127.0.0.1 listenport=2323

Verify again that the portproxy for port 2323 is now cleared.

2 Likes
17

Hello,

thanks for noticing this topic: ”Disable Old Portproxy Workaround When Using AR 6.5.x and newer”.

I have checked if this is not our case but we don’t have this setting active:

image

and we are still facing the issue that debugger could not be started:

image
image404×155 4.98 KB

or better to say it worked just on Thursday last week with only one specific PLC but I tried it today and it is not working again (with no PLC - we have four pieces of X20CP0484-1 with AR 6.5.1).

Just for curiosity today I tried to run Wireshark during debugger initialization from AS 6.5.1.7 (Wireshark records in screen shot: No. 1..208) and it seems there is no record mentioning IP port 2323(which should be gdb if I am not wrong):slight_smile:
PC running AS 6.5.1.7 has IP 10.107.8.100.

PLC has IP 172.16.147.73

(there is routing set between 10.107.x.x and 172.16.x.x networks according our IT and in fact everything regarding debugger worked fine with 6.1.x before upgrade to 6.5.x)

image
image1107×987 85.3 KB

image
image535×212 11.8 KB

Unfortunately I don’t have Whireshark’s record from last week when it worked to compare things.
Maybe just a question, couldn’t be a short timeout before AS starts to communicate with PLC and sometimes it is on the border and worked as last week?
It seems timeout is set to 10sec. before we see the message “Debugger could not be started…“
Debugger with simulator (Arsim) works fine.

Thanks for any hints.