Saleae Logic 2 Automation API

Hi Ryan

That sounds like a good plan. In the meantime, can you point to where I could patch this 10 second timeout to make it something like 30 seconds?

Hi Robert,

Yes, you can find it here: logic2-automation/manager.py at develop · saleae/logic2-automation · GitHub

Ryan

Great, thanks.
On a separate note, what is (or what will be) the licensing model for these python automation libraries?

No problem. The current plan is to license it as Apache 2.0. If you have concerns over this licensing, we’d love to hear it!

Thanks,

Ryan

I have a question in analyzer option in the automation code.

How can I uncheck the ‘Show in protocol results table’ and ‘Stream to terminal’?
I’d like to enhance the speed by uncheck those options.

@pangipark I replied below:

Hi:
Just wondering if it is absolutely necessary for the logic2-automation package to be pinned to use grpcio & grpcio-tools versions 1.46.3?
Thanks

Hi @northernboy,

No, we don’t need to pin it to this specific version. Is this causing conflicts for your setup? We’d like to hear more about it if it is causing issues. Thanks!

Ryan

Hi Ryan:

Yes, I am getting these errors:

Traceback (most recent call last):
File “/Users/robertd/development/sandbox/salaea-3.9/salae.py”, line 3, in
from saleae import automation
File “/Users/robertd/venv/pip/lib/python3.9/site-packages/saleae/automation/init.py”, line 1, in
from .manager import *
File “/Users/robertd/venv/pip/lib/python3.9/site-packages/saleae/automation/manager.py”, line 12, in
from . import errors
File “/Users/robertd/venv/pip/lib/python3.9/site-packages/saleae/automation/errors.py”, line 5, in
from saleae.grpc import saleae_pb2
File “/Users/robertd/venv/pip/lib/python3.9/site-packages/saleae/grpc/saleae_pb2.py”, line 5, in
from google.protobuf.internal import builder as _builder
ImportError: cannot import name ‘builder’ from ‘google.protobuf.internal’ (/Users/robertd/venv/pip/lib/python3.9/site-packages/google/protobuf/internal/init.py)

For a variety of other reasons/dependencies we unfortunately have to pin protobuf to version 3.15.7. My guess is that this is causing a mismatch between the Saleae/grpc/protobuf interface?

@northernboy Right now the minimum version that should work is 3.20, but I have it on my list to take a look at that.

My guess is that this is causing a mismatch between the Saleae/grpc/protobuf interface?

Yes, that is correct. If you want to try to resolve this immediately, you could try regenerating the saleae.grpc package from the saleae.proto in GitHub - saleae/logic2-automation at v1.0.0 using 3.15.7, and making any other necessary updates. If this is the only protobuf dependency in your project, you might also be able to use it inside of a virtual environment to separate it from the 3.15.7 dependency.

I will be taking a look at this in the next couple days and will post here when I have updates.

Ryan

Hi Ryan:
So I was able to cycle back and try your suggestion of …“you could try regenerating the saleae.grpc package from the saleae.proto…”. So I did that against the following versions:
grpcio 1.35.0
grpcio-tools 1.35.0
protobuf 3.15.7
And that seemed to work. I am able to start up and control the Saleae from a python script. However, going forward, I guess I would need to package up a new logic2_automation wheel with the updated saleae_pb2* as our own internal wheel to use and install. I don’t like this approach as I would be diverging from the official release and it would be hard to maintain and apply any new updates. Just wondering if you had a chance to explore further with your own investigation? I don’t know much how python wheels are generated but just thinking out loud, rather than packaging the gRPC stubs in your wheel, could that not be something that you generate on the fly when the Saleae automation wheel is installed using the pre-existing grpcio-tools?

Regards,
Robert

Hey Robert,

Just wondering if you had a chance to explore further with your own investigation?

We have an in-review change to downgrade the grpc requirement to >=1.13.0 (and generate grpc+protobuf files from that version). I’ve tested that on 1.13.0 and the latest grpc release successfully.

I don’t know much how python wheels are generated but just thinking out loud, rather than packaging the gRPC stubs in your wheel, could that not be something that you generate on the fly when the Saleae automation wheel is installed using the pre-existing grpcio-tools?

I think this is the ideal solution. The one area I wasn’t sure about is regeneration when updating grpc - that is, if I install logic2-automation with grpc 1.13.0 installed, and then later update grpc, how can we make sure the logic2-automation protos are regenerated? It’s on my list to do more research on this.

From my testing, though, the newer grpc releases are backwards-compatible with code generated from 1.13.0, so I think it will be an improvement over the current situation.

Thanks for testing that out!

Ryan

hey,
i was excited about this api, until i found out that it doesn’t allow streaming of captured data over the socket.

this is what i want to achieve: we have multiple hardware products speaking the same serial protocol, with a unique message set per product. if i could control saleae to capture data on some specific channels, and in my case parse it using the async serial analyzer (could be omitted - i could do it myself in ‘my’ python code), transferring out to my code, i could parse this correctly depending on what product i happen to be working on at the time. the data must be streamed over the socket, writing it to a file for later processing won’t do unfortunately.

i think it makes sense to provide streaming data transfer at different levels - raw (digital) data, and/or parsed data from analyzer(s).

i really hope this can be figured out.

thanks, jacob

@jacob Sorry we don’t have the ability to stream captured data in real time. However, I’m curious to know if writing a Python High Level Analyzer (HLA) might fulfill your need to parse your serial data depending on the product you are working on. In your case, it would sit on top of our Async Serial Low Level Analyzer (LLA).

hello @timreyes ,
the issue is that it’s hard to get it context aware, since ‘your’ python is running in some internal environment. we have a HLA running already, but it’s hard coded for one specific product.

i want our users to be able to run something like start-saleae-logging which will bring up Logic, enable the correct channels, and log parsed serial data to the terminal. since the serial data is somewhat product specific it must be parsed in our python environment.

thanks, jacob

Hello!
Is it possible to connect to Logic 2 from a remote PC? By default, it seems that the automation API binds on local host IP address.
Thanks!

Hi Jacob,

Just to clarify, does the streaming need to happen while recording, or can it happen after the recording has stopped? I’m assuming the former, but I wanted to double check.

Live streaming is on our list, but we don’t have a timeline for it yet.

Yes, you can do this, but it is currently undocumented. There are 3 flags you can pass to the Logic application to control automation:

  • --automation - Enable automation
  • --automationPort - Port to use for the automation API
  • --automationHost - Interface to bind to for the automation API

So to enable automation on port 12000 on all interfaces:

Logic.exe --automation --automationHost 0.0.0.0 --automationPort 12000

We will make sure to get this in the documentation.

Hope that helps,

Ryan

It works now!
Thank you very much!

@huffman
to be useful streaming of data must happen more or less live, while recording.

thanks, jacob