For the DAQ-templates in generic you need to create a representing object of the device into the Logical controller module and to select the proper template from the templates library. Next, to correct configuration, follow to specific of the template into its individual description. The conception of accessing the data by a user protocol we can imagine like to Figure 1.
As you can see from Figure 1, interaction with devices carried out through some transport on which their physically based. Requests to the transport you can send:
- Directly by OpenSCADA system API function of the transport object string messIO( string mess, real timeOut = 0 );, if the protocol specific part is very simple and you need only the data extract.
- Wrapped data request req by function int messIO( XMLNodeObj req, string prt ); and for protocol prt, if the protocol part is complex enough and already presented in OpenSCADA.
- Wrapped data request specific for user by function int messIO( XMLNodeObj req, "UserProtocol" ); and the user protocol implementation, if the protocol part is complex enough and not yet present in OpenSCADA. The user implements here itself of the protocol specific part in the module UserProtocol and the data specific part in the template for the Logical Level module or directly in controller's procedure on the internal language of the module JavaLikeCalc.
-
This latter method is currently developed to the possibility of forming a protocol code part directly in the same code of the template as a separate built-in function with call the requesting function of the first method, if there is no need for reuse, or even if such a need exists and it makes sense to create a complex template that can combine the role of the output protocol, through its connection to the user protocol module. And it will be completely stored in a single template library.
-
Working directly with the output transport of the string messIO(string mess, real timeOut = 0); function does not imply blocking the output transport outside this function call and, therefore, for complex protocols with response packets more than in one packet, which requires the "waiting" process, can not be used a shared transport, at which can be sent packets of different protocols or even one, but for different tasks (controller objects). Therefore, if you need to use shared transport, place the poll parameters in one controller object (task), or use the user protocol module to which this remark is irrelevant, since it performs such blocking at the time of the call of the processing procedure, as well as other modular protocols of OpenSCADA.
To place a protocol implementation here you need to do and to follow for the shown demands:
- be the copyright holder or the author of the code and distribute it under any free license, GPL preferred;
- prepare and store into a separated DB file of SQLite, or as a text file, for: the parameters (IO) description, the procedure's code wrote and formed in some system way;
- write a short description and instruction for connect a device by the protocol in way like to the other ones here;
- write a direct request to the forum topic "OpenSCADA development" for placing the protocol here, include a proving of its ability to work from any OpenSCADA developer or a short demonstration video.