Virtual Remote Pendant -- SetActiveTimeout

  • This one's really odd. I just tried to connect to my 8.3.20 OfficePC using VRP (1.1.2 Build 83) for the first time in a couple months, and it won't connect -- just keeps throwing the error at me. If I plug a monitor and keyboard directly into the OPC, everything's fine. This OPC has been untouched since the last time I successfully used VRP with it, and I'm using the same laptop with the same install of VRP that worked before. I even tried installing VRP onto another laptop entirely, and got the same result.


    WorkVisual, OTOH, has no issues connecting to this OPC from either laptop. I'm really quite puzzled as to why it would have quit. I could see it if I'd made changes somewhere, but nothing's been changed.




    pasted-from-clipboard.png

  • As I already said, nothing has been changed on the OPC. There've been no updates to VRP, either. It could perhaps be a Windows issue, but one laptop is running Win7, and the other Win10. Both are throwing the same error.

    I was thinking exactly for something changing on the windows side of things... I hope you find a solution.

  • Could it be the result of a network problem? Do you connect your laptop directly to OfficePC? Or through a network switch, router or chain of switches?

    Unfortunately, I don't have the VRP, but I have studied the mechanism of remote control on the HMI side. There is a lot of attention to tracking the state of the connection.

  • maybe some windows update or policy change ruined it.


    personally i am not a big fan of VRP. it does not work with 8.5 (which imho is a ripoff for anyone who purchased VRP, only to find out later that they are stuck with a dud). connectivity is another issue, it requires that controller is in EXT mode. why the heck is that needed to establish .... connection?

    it should be able to connect ANY TIME, regardless of operating mode. ability to assume control may be conditioned etc to maintain SPOC but it should be able to to connect regardless of operating mode. and it should be able to assume control...

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

  • Direct connection. It's even the same cable that worked for WV and RVP a couple months ago.

    Would you like to try to catch an error using a network sniffer? You can put Wireshark on your laptop and watch the exchange of network messages, or at least make sure that this exchange takes place.

  • This one's really odd.

    Do you care to try again?

    If so, it's time to increase the detail of the VRP log a bit.

    1. Make backup copy of VirtualRemotePendant.exe.config in the directory "C:\Program Files (x86)\KUKA\KUKA Virtual Remote Pendant"
    2. Open the file "C:\Program Files (x86)\KUKA\KUKA Virtual Remote Pendant\VirtualRemotePendant.exe.config" in a text editor (Notepad, Notepad++, etc...). It's an XML file.
    3. Locate <switches> subtree, it looks like:
    4. Change values for Application, Loading, GeneralTrace, Ade.AdeComponentFramework, Ade.Commands, Ade.Exceptions, DeviceRepository, DeviceSelection, KcpControl, RdpSessionView, DeviceEntry, General to "Verbose".
    5. Try to use the VRP as usual, wait for a connection error.
    6. Look at "C:\Users\<USERNAME>\AppData\Roaming\KUKA\VRP\VirtualRemotePendant.log" for detailed description (attach this file here or send me via PM, so I'll try to understand what's wrong).

Advertising from our partners