UDL is acronym of User Defined Logic.

The reason of its existance is that, since all edinn installed platforms have the same core, it was necessary a way to introduce logic defined by the user, with these characteristics:

  • Independent to the arrival of new versios of the edinn platform: if the version of the platform is updated, there is no risk of deleting the logic of the user.
  • Not compromising the stability of the edinn platform: if the logic of the user fails, the system keeps working.
  • Provides the user with all the power of the market: because you can use your own development tools, instead of being limited by an edinn proprietary source code editor.

To achieve these objectives, in the edinn platform you can use source code compiled into DLLs. For more information, you can search on the internet about dynamic-link library (DLL).

UDL and API: regarding the relation between UDL and API, please consider that UDL is the logic defined by the user and the place where it is located. The edinn API is the way in which programs (for example UDLs) read or write from and to the platform.

Add-on or App: in some documents you will find that UDLs are called add-on or App. The reason is that more persons know these concepts rather than UDL.

WARNINGS:

Please remember that any issue related with a UDL is not included in the basic support of edinn, and therefore, its revision and/or reparation could imply additional costs.

Knowledge of programming is required to be able to edit, change, compile, install and debug a UDL.

These are the places where the user can introduce his UDL:

  • Monitor: it is a UDL called by the monitoring service. It allows the execution of actions in a synchronized manner, and at a high speed, with the monitoring. These are just some examples of what can be done:
    • To define virtual signals and counters, which are calculated based upon a user defined logic.
    • To define complex ways of calculating production, based on multiples counters, signals and fields typed by users or read from other systems.
    • Stop and start machinery and turn on and off acoustic and visual beacons.
    • Integration with other systems, where reading and writting from physical devices is required.
    • In general, any other need which is required and is related to monitoring.
  • Fields: it is a UDL called by the fields configured by the user which appear in certain windows of the operation terminals. These are just some examples of what can be done:
    • To calculate the expiration dates and complex lot numbers which are later printed on the results (products) of the process.
    • To read available lots from other systems.
    • To print and scan labels.
    • In general, any other need which is required and is related to the user operation.
  • Scheduler: it is a UDL called by the automatic scheduler. These are just some examples of what can be done:
    • To setup a matrix of changes by families, so that the scheduler considers, for example, that if a result is changed to the same family of the previous result, the setup time for the change is less.

Please note that in this document only basic indications and examples are given, and thus, the user can create thousands of possibilities and additional uses.

Note: If you think that your need cannot be satisfied with any UDL, please consult us through our support, because the calls done by the platform to execute UDLs can be extended.

Note: Some examples of UDL are available for download with its source code in the edinn Academy web site, section installers and developers, downloads, Add-ons. These UDLs are typically developed with the Microsoft Visual Studio IDE in VB.NET, as it is easier to learn. There are also older UDLs developed in Microsoft Visual Basic 6.