UI is not working

[eMichx]

Hello,

We have a licence for 20 UI fat clients (checked also the shield.txt file), but (independently of the computer where the UI is installed),
UI is not running on the 11th PC!

WCCOAui (11), 2015.06.25 19:27:07.018, PARAM,WARNING, 7, Datapoint does not exist, CtrlDbg::init, _CtrlDebug_UI_11.Command
WCCOAui (11), 2015.06.25 19:27:07.050, PARAM,FATAL, 48/uim, Le datapoint d'interface utilisateur interne _Ui_11 n'existe pas: no such name
(to english : the internal user datapoint interface _Ui_11 doesn't exist: no such name)

regards
Emmanuel

[fmulder]

These internal _CtrlDebug datapoints are made per UI and can be used to attach the script debugger.
This is no problem. The UI will work fine.
If you want, you can manually create tghese _CtrlDebug datapoints for the UI's with number 1 to 255 (or just ignore this message)

[tmalone]

You will also need to create more _Ui instances too. The default maximum is _Ui_10

Open the PARA. Check the box for Internal Datapoints. Find the datatype _Ui. See that there are only so many with numbers. You need _Ui_11 and more!

Todd Malone
Siemens HMI CoC USA

[leoknipp]

Hello,

when creating new datapoints for type _Ui you have to configure a _archive-config for the element ".UserName".
If the _archive-configured is not added an configured the login/logout statistic will not work for the UIs started with a number > 10.

Best Regards
Leopold Knipp
Senior Support Specialist

[tmalone]

Wow, this is pretty complex for a regular customer (I did not know the archive part). Maybe we should make an example panel that customers can run to extend their UI counts that does all the right things! I would rather point them to such a panel than to remember these details.

Sincerely,

Todd Malone
HMI CoC USA

[fmulder]

Todd,

I will pass you an extra idea. I think in general that customers/users should not worry about stuff like this. In most applications you need to create some datapoint types and/or instances before it works. In our department I'm a big fan of 'self repairing' applications. Welways have a function that is called something like 'guiInit()'. In this function we do all the necessary stuff. You could easily do all the configuration there.

This means ; simply start an Ui and everything will work

I will give you another example: we have our own dutch(!) trending panel. This panel requires a datapoint for its configuration. When you start this panel then a function 'trendInit()' is called. This function will automatically create or correct(!) the required datapoint type. This means : I can give my panel to any colleague without any preparation. They don't even realise that they just made a datapoint type.
Also, when I change my code, and add an element to the type, then they just open up the new panel and the datapoint type gets ciorrect automatically.

Our current project has roughly 20 datapoint types but .... no Ascii manager files. This works perfect and makes our mutual development much easier. I don't have to tell them about datapoint types nor do I need to tell them to manually correct stuff nor can there be a mismatch between version of datapoint type and version of script

Frenk
share the fun !

[leoknipp]

Hello,

you have to differ between internal and project specific datapoints.
It is correct that you can write scripts which create application specific dp-types and datapoints automatically when it is necessary.

In the case described in the first posting internal datapoints are missing. As long as the _Ui-datapoint does not exist you cannot start the UI and therefore it is not possible to create the required datapoints automatically.
Also you do not get an information (in other managers) if a UI could not connect because of a missing _Ui-datapoint.
Therefore a "self repairing" application cannot be made for this special case.

Best Regards
Leopold Knipp
Senior Support Specialist

[fmulder]

I do not fully agree. You can easily write a functions that makes the 255 _UI datapoints and the _CtrlDebug datapoints together with many other appliation specific datapoints. You can then call this function:

* When the GEDI starts (simply call it from a menu handler)
* When the runtime user interface starts

The first GEDI or the first runtime to start will repair/prepare the database for the others.

We do this for two reasons:

* To help my colleagues. I can simplify engineering because they don't have to worrt about certain things
* To help myself. I do not have to check that the datapoints that they have on their local laptop are correct. They are auto-corrected whenever they start their GEDI or runtime

[Gertjan van Schijndel]

I think it would be possible to run a 'SecurityPlugin' in the database manager, which automatically creates the '_Ui' datapoint. However this plugin does not know if the manager number was automatically assigned or perhaps the user has specified a (wrong) manager number. So you could create some datapoint more then necessary.
I assume that the database manager would be able to create the datapoint in time before the dpContainer is send to the manager.

[fmulder]

i think we are now floating of into phantasyland. Looking for the most complex solution for a simple issue.
My advise : make them datapoints by hand !

good luck