This is intentional. The JavaScript API hasn't stabilized, and we didn't want to publish the details yet. If you are OK with a breaking your app when upgrading, here's how you get a list of functions and definitions available to JS code in the JavaScript tool:

for (var i in VisionAppster)
  print(i);

If you put this code to a JavaScript tool and run it, you'll see all API entries in the console.

For example, this creates a new color image:

var img = VisionAppster.image(640, 480, VisionAppster.Rgb32);

When it comes to using external libraries, the answer is yes in principle, but the feature isn't publicly available. Integrating something like Node.js modules may or may not be supported in the future.

Nothing to be sorry about. This is really valuable feedback to us. I cannot directly tell what's going on, but we are trying to reproduce the problem in a controlled setting. The two issues could indeed be related. Thanks for reporting.

I see. While I'm still unsure which part of the whole pipeline is failing, this is a good description that will help us dig it deeper. Thanks for reporting.

It's hard to say exactly what happens. But I wonder if this is what you actually wanted to do. When you call the MyInput function, JavaScriptMyInput gets executed. The results will be passed back to your client code using a callback function. This is how tool function APIs work, please see here for details.

The outputs of the tool that is exposed as an API function are available to the processing graph. In your case, they will trigger the rest of the graph, producing a signal at the end. If clients connect to this signal, they will be delivered whatever comes out of the pipe independent of who triggered the graph. Thus, there is no 1:1 correspondence between what you sent to what you receive.

Another thing that may cause a discrepancy is your script code at the end. If it does not set the output parameter, it will not be sent. In this case, the parameter must be flagged asynchronous.

What you probably want to do is to bundle your graph into a single compound tool and make that a function API.

The answer is "it depends".

va-run is the way to run stand-alone apps, which are usually UI apps. You can run stand-alone server apps with it as well (like you did by va-run main.qml), but they are not hugely useful without a web server that provides a remote interface.

The web server is started by the Engine service that runs in the background. There is a web-based management interface through which you can install, start and stop apps.

The .vapkg file contains a component that in your case is an executable app. You can upload .vapkg files to the service through the web interface or directly from the Builder. Once you install the uploaded packages, the front page automatically shows you all installed apps.

Hope this helps.

Hi,
Yes and no.

We are currently closing the 3.0 release, which brings in major changes. GigE support is still there, but we won't be able to include prebuilt drivers in the release. Pylon and Pleora GigE driver support is planned to be back in 3.1. We are also planning to support GenTL as a way to implement custom camera drivers.

Meanwhile, if you aren't afraid of C or C++, you can use the tool API to get images from cameras.

BR,
Topi

A fix to this bug will be included in the next release (2.9).

I can confirm that this really is the case. In fact, adding that declaration seems to cause a crash. This is undoubtedly a bug we need to investigate more. Thanks for reporting.

For the time being, you need to find a work-around for example by using a matrix as input. It is definitely not convenient, but at the bottom, strings are just sequences of numbers.

To declare an input parameter as a string, you can say e.g. FIXED_INPUT(kuvio_string, fileName, ""). Your function will receive the string as a UTF-8-encoded const char*.
The only way to create dynamically typed arrays from C is currently kuvio_array_from_json. Dynamically typed arrays aren't really intended to be used in processing. Few tools can actually make use of them, Script being perhaps the only useful one.
If you want to output an array of numbers or Boolean values, the correct data type to use is a matrix. For example, the ConvexHull tool in the OpenCv example plugin declares a matrix output: OUTPUT(kuvio_fmatrix, hull). The convention is to use a 1×N matrix if you need to output a vector of numbers.

Great
We may consider making zero the default frame rate in a future release. It could be the least surprising value after all.