Scripting

Question

How does scripting work?

Answer

Scripting support in the Gocator allows you to provide code to extend the existing measurement tools, just like the Manhattan example in the user manual. However, scripting has a limited scope. It is not possible to access the actual data from the sensor in the script, that is, there is no access to the encoder count, time stamp, or profile data points. The only inputs available in the script are the results from the measurement tools that have been configured.

Another important point is that the script has no state. This means that there is no memory across consecutive frame captures. It only executes on one frame at a time independently. Finally, there can only be one script measurement. 

PicoC is used as the scripting engine, which is a very small C interpreter, suitable for embedded devices. The language is very similar to C, with these notable differences:

• Explicit type casting (e.g., (int)afloat) is not supported. Values are cast implicitly.
• Tertiary operation (a ? b : c) is not supported.
• The “const” keyword is not supported.

The scripting language allows the definition of functions; everything outside of a function definition is executed in order of parsing. The script is executed once when a full set of real measurements are available. The following functions are built-in: output(), exists(), value(), decision(). As a result, these identifiers cannot be reused for functions or global variables.

For more advanced processing that requires state to combine data from consecutive frames, you must use the Gocator Software Development Kit, which is open source and can be downloaded online from the LMI website. The Go2API provides functions to access the raw profile data, encoder counts, and time stamps. Memory can be allocated in a program to buffer data for a full scan of an object and process this data with custom or third-party algorithms.