|
libinco_32
|
|
libinco_32
|
As already mentioned before, only some of the functions provided by libinco_32 are actually useful for our customers. This pages describes which one and their purpose.
Writes the value of an INCO variable. Every variable registered in the INCOTree which has not been defined with the characteristics 'read only' can be set by using the PutVariable() function. The function is able to write the following data types:
It is not able to write other data types. Most notably, it lacks the possiblity to write
As a workaround for the lack of (u)int64 support, the customer can reigster an (u)int64 variable in the INCOTree by a uint32 array of size two. This variable array can then be written to by calling PutVariable twice.
GetVariable() can read the value and further properties of any registered variable in the INCOTree. The supported data types are the very same as described in PutVariable.
Execute a function (or procedure) programmed on an Indel target. CallProcedure() is able to pass up to 15 arguments to the function and return one result. The supported argument data types are:
Therefore, by defining a customer specific 'string encoding', it's possible to pass (almost) arbitrary data to a registered procedure. The supported return types are:
It's not possible to return strings (char*).
Note that the function execution on the target is not allowed to block the calling task (INCODispatcher). Therefore, any function execution should have completed 'fast'. As a rule of thumb, it's a bad idea to use Sleep() within such a function. Also, it's usually a bad thing to wait for CINOSSync object or to use other thread synchronisation mechanisms such as mutex, etc.
CallProcedureEx() is similar to CallProcedure, just that it can cope with so called 'asynchronous procedure execution' (see Synchronous Calling of Asynchronous Procedures). Let's take a short detour to explain what is meant by that expression:
In case that a function needs to perform long-duration things, it should perform that work in it's own task context (in contrast to the calling task of the registered function, which is the INCODispatcher task). To achieve this, the registered function usually just puts a 'message object' (i.e. CINOSTaskExMessage) into the 'job queue' of the customers object which is usually (inderictly) derived from CINOSTaskEx. Putting such a message into the queue doesn't take much time and is therefore allowed to do. The long duration work is then performed by the customer task. That part of the work is referred to as 'the asynchronous part' of the CallProcedure().
A typical example is to "move an axis and wait until the axis reached the target position". Where the 'synchronous part' would just create the message, the 'asynchronous part' would actually start the move and wait for the move to finish.
While CallProcedure() only allows one to call the 'synchronous part' of the registered function and thereby only allows to 'initiate' the execution of the 'asynchronous part', CallProcedureEx() additionally offers the possibibitly to return a unique identifier (the ticket) to the asyncronous part. That ticket can later be passed to CallProcedureExResult() & friends to wait for its completion and to get (optional) results.
The 'asynchronous function execution' is described in detail here: CallProcedureEx & friends.
1.8.8
