Programming Interface?

[KarlKarpfen]

Hi, I digged through the website but could not find what I'm looking for. so: I plan to use LaserShark from within an completely own application. For this I'm looking for an API/DLL/Shared Library that provides some functions to send vector and control data to the board. Is something like that (together with documentation) available?

Thanks!

Karl

[Macpod]

Hi Karl,

What OS will you be running this custom software on?

The api used for LaserShark communications requires LibUSB so you should install this. The api can be seen on my github repo area under this project:
https://github.com/macpod/lasershark_hostapp

Specifically....
https://github.com/macpod/lasershark_hostapp/blob/master/lasershark_lib.h
https://github.com/macpod/lasershark_hostapp/blob/master/lasershark_lib.c

Demonstrations on how to use this api in conjunction with libusb can be seen with lasershark_jack (shows off isochronous transfers):
https://github.com/macpod/lasershark_hostapp/blob/master/lasershark_jack.c

....and lasershark_stdin (shows off bulk transfers):
https://github.com/macpod/lasershark_hostapp/blob/master/lasershark_stdin.c

I would encourage you to start off with the lasershark_stdin code.


The usage page will explain how to compile these examples:
http://www.macpod.net/electronics/lasershark/lasershark_usage.php

No documentation is present aside from comments, but the interface is relatively simple. There is no support in this api to send vector data, only points. If you need to draw lines/curves/etc you should consider running the lasershark_jack client and reviewing the openlase api:
https://github.com/marcan/openlase

No api documentation is provided for that project but there are a few good samples:
https://github.com/marcan/openlase/tree/master/examples

Overall that api isn't too bad, it's similar to working with opengl primitives.

[KarlKarpfen]

Hm....OK, it took me some time to understand it - but when I'm correct you're still accessing your card as audio-device!?

So when I want to communicate with it directly I would need an other approach. May be you can point me to these files in your firmware where the data frames from host arrive? Probably it is a solution for me to communicate with the card directly and send the raw data to it...

Thanks for your help!

[Macpod]

Pardon the delayed response, I was out of town for Thanksgiving.

The LaserShark is not accessed as an audio device. I'm guessing you are confused by the use of JACK? The JACK audio components are only present in order to interact with OpenLase. The lasershark_jack host app reads off the JACK audio system, converts the samples to something the LaserShark can read, and then uses lasershark_lib.[c/h] plus libusb calls to send the data. Since OpenLase is more focused towards real-time events (i.e. games or interactive displays) I use isochronous transfers to send data.


I haven't gotten a good feel for what you are attempting to accomplish but talking directly with the LaserShark seems to be within the realm of your objectives. In this case you can ignore the lasershark_jack application and focus on the lasershark_stdin application code.

So stepping back, first you should check out  the lasershark_stdin_circlemaker app:
https://github.com/macpod/lasershark_hostapp/blob/master/lasershark_stdin_circlemaker.c

This code continuously spits out data to stdout that the lasershark_stdin application can interpret. The format of this data can be read about in the example file:
https://github.com/macpod/lasershark_hostapp/blob/master/lasershark_stdin_input_example.txt


The lasershark_stdin application...
https://github.com/macpod/lasershark_hostapp/blob/master/lasershark_stdin.c
parses data passed to it via stdin and converts it into a format suitable for transfer to the lasershark. Utilizing lasershark_lib.[c/h] and libusb it then sends this data to the LaserShark. I'm using bulk transfers here because the applications that would need to do this (i.e 3d printers) require the guaranteed display of data vs. real-time information display.

Check out the handle_sample() function to identify the format of the data sent over the usb line. In short to control the galvos and lasers you must send "samples". A "sample" is a set of values used to update the state of the x, y, a, b, c, and intl_a outputs.

Multiples of these samples which are bundled together into a "packet" are sent as one or more bulk transfer to the LaserShark. You can see how this happens by reviewing the send_samples() function.


The main function of lasershark_stdin will contain examples of how to use lasershark_lib.[c/h] to setup the LaserShark. An example of an attribute that should be setup before using the LaserShark is the ilda rate. This is a volatile attribute and must be configured every time you power-on the LaserShark.


Inside of the lasershark firmware, received packetized samples via isochronous or bulk transfers (your choice which ultimately will depend on your application) are stored in a ringbuffer. Please see  lasershark_process_data() for how this is done.
https://github.com/macpod/lasershark_firmware/blob/master/lasershark/src/lasershark.c

Based on set ilda rate, a timer fires repeatedly and removes a sample for display from the ringbuffer. You can review TIMER32_1_IRQHandler() to identify how this is done.

[KarlKarpfen]

Hi Macpod,

OK, got it - the missing link why I did not understand the stdin-code was the bulk transfer function with endpoint 3 you are using for sending sample data (comparing to endpoint 1 for sending control commands).

Thanks!

Karl