FP SDK and UAS

labu

Hi All,

We are currently looking at an efficient way to have an FP application having more access rights than the logged in operator.
Our customers are expecting that data and I/Os can't be modified by the default screens but we need to have the access rights within our application.

Is there a solution like in PC SDK to define the user at application level?

BR

Laurent

John Wiberg

Unfortunately that would go against the design of the UAS. Any custom screens will have the same grants as the 'default' screens, both dependent on who is logged on.

 

A complex solution to that would be to have a PC SDK application as well, where the FP SDK app tells the PC SDK app to do stuff that the FP SDK app is not allowed to.

labu

Hi,

I was nearly sure of this. Another way to do it could be to have some additionnal access rights to enable or disable the default edit, IO and data screens.

It is obvious that when a specific package is developped (robot code and HMI app), we can fully control the coherency of the entered datas within our app, which is not the case with the default screens.

I do feel this could be a significant improvement for the safe operation of robot applications controlled via FP SDK.

John Wiberg

Agreed.

Back in the day when this was designed the assumption was that FP SDK would be mostly used to create apps which would be deployed to several systems. Which would make their context similar to that of the default ones.

But most FP apps that I have seen are for single specific robot systems. Which is a completely different context.

labu

In our case, we have the same FP app in nearly all our machines, only differing in some screens.

See example for our palletizing version.

labu

Up

Any hope to be able to raise the Access Rights for a FPSDK App?

John Wiberg

[QUOTE=labu]Any hope to be able to raise the Access Rights for a FPSDK App?


[/QUOTE]
None.

 It's too big a change and lots of security issues involved. So it's going to be the way it is.