ScreenMaker / RAB / UAS issue

Kevin

Further to my previous comments on ScreenMaker 5.11 (http://forums.robotstudio.com/forum_posts.asp?TID=3055), a UAS issue arises when using a ScreenMaker window as a sophisticated replacement for the functions of TPReadFK and TPReadNum.

A user with minimal access rights is able to enter a numeric value via TPReadNum, but the same user is denied the right to enter a numeric value via a NumEditor in a ScreenMaker window.

In order to access this function, the user must be given the 'Modify current value' grant which allows access to the Program Data window, and will therefore enable modification of any data value in the system.

Similarly, in order to toggle a digital output via a bound ScreenMaker button, the user must be given the 'I/O write access' grant, which gives access to all I/O via the Inputs and Outputs window.

It is not an option for me to block access to the ABB menu.

It would be good to have a ScreenMaker screen able to be fully controlled by the Rapid program, with the UAS system bypassed for actions coming from that screen.

It would be interesting to read comments from an ABB developer on my suggestions.

Regards,

Kevin

carlosmtz2000

This is a interesting scenario. 

 

ScreenMaker and RAB runs with the same privileges as the FlexPendant's Program Data.  Currently, from the controller' point of view, the command to change a data comes from either RAPID, the FlexPendant Client (Standard FP UI, RAB or ScreenMaker) or any other client (RSO, PC SDK, etc ..).

 

I know this does not provide you with an answer, I am trying to explain the facts "under the hood" ..

 

Kind Regards

 

 

 

 

carlosmtz2000

This is a interesting scenario. 

 

ScreenMaker and RAB runs with the same privileges as the FlexPendant's Program Data.  Currently, from the controller' point of view, the command to change a data comes from either RAPID, the FlexPendant Client (Standard FP UI, RAB or ScreenMaker) or any other client (RSO, PC SDK, etc ..).

 

I know this does not provide you with an answer, I am trying to explain the facts "under the hood"

 

Kind Regards

 

 

 

 

Steve_Murphy

Hello,

 

There is a significant design difference in the two scenarios.  In the first case, with TPReadNum, it is the RAPID program asking 'any available user' to enter a number.  In the second case, the ScreenMaker client is granted rights to modify a RAPID data, regardless of whether the RAPID program has requested modification or not.  This is why there is UAS protection. 

 

Admittedly it is clumsy but part of a larger issue of granularity of the UAS grants when a client is running independently of RAPID.  There many such independent clients in the IRC5.

 

But the interesting case here comes when the ScreenMaker screen is not seen as an running independently of the controller, but is called by the controller, then it should have the grants and priviledges of the RAPID execution. 

 

Giving access to the individual screens from RAPID would require a solution to this problem.

 

Kind Regards,

 

  Steve

 

Kevin

Hi Steve,

Thanks for your comments. You leave me with the hope that a solution will be developed ...

It would be necessary to provide a mechanism for automatically closing screens opened from Rapid if execution stops unexpectedly, otherwise bound controls may still operate on data and outputs.

Regards,

Kevin

Steve_Murphy

Hello Kevin,

 

There a great number of interesting issues that arise when RAPID opens and closes screens. One such case is as you mentioned, when the RAPID execution stops, shall the screen be automatically closed?  I believe there are cases both for and against, meaning that it would need to be selectable for the specific screen.  This is possible.   ScreenMaker screens are different from the UI and TPWrites in that they contain more information, more operation capability and more state.

 

What is harder to handle is what should happen if the Program Pointer is moved, to Main or to another line in the RAPID program?   If the RAPID state is lost, shall the ScreenMaker screen state also be lost?

 

Currently the ScreenMaker screen state is mostly separate from the RAPID state and can be connected by I/O signals and ActionTriggers and RAPID data variables but if we mix these states more and more, a common state handling of the GUI and controller modes/states will be necessary. 

 

There a split in how people view the FlexPendant and ScreenMaker balances two views.  On one hand the FlexPendant is seen as a  'window' into the controller and reflects the state (up/down, happy/sad, etc) of the controller and RAPID execution, for example, when the RAPID stops, the production window stops too. 

 

The other view is the ScreenMaker application as a 'panel' or 'client' towards the controller, and where it is always active even if RAPID is stopped or the controller has no RAPID program.

 

This is the issue of 'liveness' of the GUI application and was seriously discussed in the ScreenMaker design.

 

Kind Regards,

 

  Steve

 

Kevin

Hi Steve,

Thanks for your detailed reply.

The two opposing views of the FlexPendant (which I think are equally important) are covered by my suggestion of two 'classes' of ScreenMaker project (here). The second class would replace the TP**** instructions and would typically be used for sophisticated data entry and message display. In common with the behaviour of the TP*** instructions these screens would have to close automatically when Rapid execution stops.

I think that they would also close if the PP were moved, as this cannot be done (at least via Debug) while Rapid is executing. This is the same behaviour exhibited by e.g. the TPReadNum screen.

If Rapid execution is stopped and re-started on a TP**** instruction, the input window is re-displayed 'as new'. Perhaps a new argument to the UIShow intruction could be provided which would cause Rapid to wait for a 'finished' boolean from the ScreenMaker project before  advancing the PP. Stop and restart of Rapid would then result in closure of the ScreenMaker window then re-opening of the main screen. It would be necessary to re-initialise variables, probably via the main screen Load event. The Rapid programmer would have to validate data which might have been changed from the ScreenMaker screen(s) in subsequent code.

The issue of dependencies between Rapid and ScreenMaker as explained by you (here) would still have to be resolved, but on that subject I am out of my depth!

Regards,

Kevin