We could not find any option to disable the local touch input.
Question:
Is there any Automation Runtime parameter, system setting, driver option or service configuration to disable the local touchscreen while keeping the display and VNC active?
I don’t think there’s any Automation Runtime setting where you can directly influence the connection / functionality of the physical connected touch on the display.
What setup do you use in detail:
what APC/PPC you’re using? PanelPC (PC directly mounted on the back o the panel), or AutomationPC (PC is connected via cable to display, display uses a receiver module on the back)?
what kind of APC/PPC you’re using? APC/PPC 900/2100/2200/3x00?
I’m asking because I could imagine, that some kind of disabling the touch via the PC BIOS (if ARembedded only is used, but I think so) could be possible.
But even if that would be possible:
it would be a permanent setting → no chance to change it via software, only with access to the PCs BIOS it could be changed later
as the named display is a multitouch device → multitouch works via USB, so if there’s a possibility to switch of the internal USB hub, it could / would be possible that you also loose access to some external USB plugs (if the’re routing via the same hub then the touch)
I’m not sure if a BIOS setting would really be possible or suitable, because I don’t know the concrete setup by now. To evaluate it, you have to check the concrete PC’s user manual (section BIOS settings) to find out more.
I would like to explain the situation in more detail.
The local touchscreen is normally used by the operators and works correctly during standard operation.
However, we have a specific operating mode – during test execution the operators take control of the system remotely via a PC using VNC. In this mode we would like to temporarily block / deactivate the local touchscreen input by software, so that the system cannot be operated simultaneously directly from the panel.
It is still the same shared VC4 visualization. We would like to control this behavior by software, for example with a variable:
Normal mode:
local touchscreen = active
VNC = active
Remote mode:
local touchscreen = disabled
VNC = active
The preferred solution would be without BIOS modifications and controllable directly from the application.
So far we have not found any Automation Runtime or VISAPI solution.
We normally do not use the User Role System, therefore I would like to ask:
Would it be possible to implement this functionality using the User Role System (for example disabling local touch interaction in a certain operating mode or user level)?
Or is there any other software solution available for temporarily blocking local touchscreen input while keeping VNC operation active?
I did a quick check, and unfortunately I’m quite sure that there’s no possibility to solve your use-case as described, I’m sorry - there’s no setting / function in AR to “interrupt” the touch signals from the physical touch interface as I know (this is also valid with UserRole system, as also this system cannot interrupt the touch signals on a AR / driver level).
The only solution that I see is using a 2nd VNC visualization object that is just accessible via VNC (the 1st visualization object could still be used with VNC, e.g. for remote assistance use-cases).
If using a 2nd VC4 object, you then could “block” the touch inputs from the 1st VC4 visualization connected to the display by using a transparent hotspot button on all pages in the highest z-order of the 1st visualization: if the 2nd VC visu is used, enable the hotspot → the hotspot will then receive every click on the touch and “eat it up” without any reaction in the software. In “normal operation”, the hotspot has to be disabled and therefore everything in the lower z-layers is accessible.
As I’m not longer doing programming every day, maybe I’ve overseen something (honestly spoken I don’t think so, but never say never)?
So let’s wait a bit more time if someone else has some (more / better) ideas on your use-case.
Hi, thank you very much for your help and detailed explanation, this information was very useful and we will evaluate and test the proposed workaround on our side.