We are using an e-series robot for the first time. The touchscreen is being very annoying. It registers only about 70% of our touches. It tends to go in waves. It will be fine for 20 seconds and then not move the cursor for a while. Has anyone else seen this? It’s not normal, is it?
Rob
We’ve been using the e-Series for a while now and never noticed such behavior except in situations with intense background activity. Did you try to use another PolyScope Version?
I am not aware of any such cases.
This may be a hardware defect on the particular TP.
If so, please contact your support channel.
Notice, that the e-Series TP is capacitive touch, where CB-series is resistive.
On CB3 you had to use a pointer/pen or nails, where you actually have to use the fingers (not nails) in e-Series for capacitive touch to read your touch.
I have seen instances where the e-series teach pendant will go unresponsive to touch for noticable periods of time. The time I first noticed it I was switching back and forth quickly between a few different controls or “tabs”. I might also have tried toggling some of the general purpose IO as well. The behavior seemed less like a touch problem and more like a UI responsiveness issue because occassionally touches made while the UI was unresponsive eventually passed through.
Yes, I was told to use pressure on the CB-series and to be gentle on the e-series. Deep touch being considered as a “not click” alike palm check on laptops track pad.
For delay on the input. Letting the controller some time and rebooting can help.
Regards,
Teach, locate & pick faster with the new Robotiq Wrist Camera. Have a look!
David Gouffé
Integration Coach
Coach en intégration
1-888-ROBOTIQ #275 (762-6847)
1-418-380-2788 #275 (Outside US and Canada)
There are some Polyscope performance improvements with 3.9.1/5.3.1 release that will be out soon.
Improvements are mainly for eSeries running programs with large number of waypoints, and programs using large number of nodes configured with modbus signals.
Contact your support if you can reproduce specific scenarios where UI performance is below acceptable.
Hi, we are experiencing the same problem in a brand new UR10 E series, Polyscope version 5.11.5.1010327. The touch panel goes unresponsive randomly, with no UR caps installed and even when the cobot is just powered on with no program loaded or running (No communications used).
I would really appreciate any information on how to solve this issue or when it is going to be available the next Polyscope release solving this bug.
Best Regards
Anibal
I recall having significant response delays with one of our UR5e units a while back.
One of our other engineers I believe ended up re-doing a Polyscope upgrade - might have done a complete reinstall.
If you have no urcaps installed and no program running and no external device communicating to the controllers client interfaces then I would suspect a hardware issue with the teach pendant or TP cable.
Hello Anibal, I bought a new UR10e with 3TP and I have had the exact same issue since I got it. I can rule out a hardware problem because all buttons in the software work as expected on other tabs (settings, programming etc.).
The issue is exclusively on all of the movement buttons - they will go unresponsive in waves as others have described here. They will be fine for a few seconds, then get unusable for a few seconds, then be fine again. Not just on that screen, it’s really every button that is supposed to move the arm. But no non-movement button elsewhere is affected.
I made a video showing this: https://youtu.be/X1lBtCAqQuQ
FYI: My hand is far away from the screen, only the fingertip gets near to it. Hard to see on video, I included a scene at the end where it is shown from the side. I tried both a very soft touch and a normal touch, doesn’t matter.
Technical info: The “Button Up” events are usually registering fine, but the “Button Down” events are not always registered. This means the touchscreen is working as expected, but the software isn’t. It doesn’t matter whether or not the robot is running.
I’m running the newest PolyScope version, have nothing installed, no program running, and no external device connected. It’s as clean as it gets.
The case you’re showing in your video has always been around.
I don’t think it’s a case of unresponsiveness, though. It is more a case of the interface not registering the click. After programming the robots for many years, I don’t mind it anymore but simply just lift my finger and press again.
I, at one point, suspected the issue to be worse when you click the middle of the buttons, where there usually is a text box with X+/Y+/X-/etc when using a feature with axes.
But I know a lot of our customers have mentioned it, as well. So it’s a good thing that it’s being clarified here. 
As EFN states this might just be the response of the capacitive touchscreen on our TP. I often see some people in our training classes struggle with the touch action (if they are new users). Try using an appropriate stylus and see if that gives you better results.
The touchscreen is registering my finger just fine, you can even see the mouse cursor jumping to the right spot in the video. Furthermore, I’m having zero issues clicking any buttons on all the other screens. This was also shown at the start of the video. This issue is exclusively related to buttons that move the robot, not buttons in general. This alone should be enough info to understand it is not related to the input method or hardware.
As EFN pointed out, this issue is well-known, and buttons with labels (forgot to mention that myself) are especially affected / hard to use. When you click on a button and hit the label on it, the label is selected, but the button isn’t. The label shouldn’t be selectable and it should not block the button.
I don’t understand why this issue is blamed on hardware/finger/user here since years when it is so obvious in my video that the software is registering my finger correctly, just not changing the button-down state accordingly to the down state sometimes, but all up-states are always registered. That should be 100% proof that it is not the touch screen or the input method, but the software. Otherwise, how do you explain that the software knows that my finger is lifted, but failed to register when it was pressed down, except that the OS still moved the curser correctly? This can only be the case if the OS knows the touchscreen is currently being pressed, but the application failed to register that event.
There should be a bug report possibility, but I can’t find any category for bug reports on this forum here. I would appreciate it if UR would take a look at this issue and create a bug report. It’s not good to always just search for the problem elsewhere and not accept the possibility that there might be a problem in the software that should be investigated after proof is provided. This doesn’t give me a lot of confidence to even report bugs (of which I found plenty).
I’ll happily provide more videos of the problem if needed. I will also buy a pen if you promise us that you take the issue seriously then and bring it up to the developers if it still happens with a pen.
