Saleae Logic 2 Automation API

Logic 2 Software
63

Ok, I think I understand what is going on here.

To clarify, the situation is:

  • If you start the capture from the automation API, the analyzer data is incorrect, in both the UI and the exported data.
  • If you start the capture from the GUI, it works as expected.

The problem is that in order for the analyzer simulated data to be used, the analyzer needs to be added before the capture starts. Unfortunately we don’t currently support adding analyzers before a capture starts. Can you confirm that this is what you are seeing?

Ryan

64

Hi Ryan,

Yes, you are correct about the situation I’m in. And as you described why it is so, now it makes sense as per the automation sequence the analyzer configuration comes after the capture is done, so with this sequence I won’t be able to generate the analyzer-specific data (from APIs).

Thanks for clearing this out!

Just want to know do you guys have any plan to add support for configuring analyzers before the capture? Is this something targeted for near future releases or low priority as of now?

Thanks,
Abhiram

65

Hi Abhiram,

Just want to know do you guys have any plan to add support for configuring analyzers before the capture? Is this something targeted for near future releases or low priority as of now?

Being able to configure a capture separate from starting it is something we’ve talked about. I think we will do it eventually, but it is not on the list of features to build in the near future.

Ryan

66

Hi
I’ve been trying to use the automation API (downloaded 0.9.0 wheel and installed in python3.9.13, with Logic 2.3.59) on an M1 Mac. When I try and use the python API to launch Logic2

manager = automation.Manager.launch(application_path="/Applications/Logic2.app/Contents/MacOS/Logic")

It fails about 50% of the time with this message:

Traceback (most recent call last):
  File "/Users/robertd/development/sandbox/salaea/salae.py", line 5, in <module>
    manager = automation.Manager.launch(application_path="/Applications/Logic2.app/Contents/MacOS/Logic")
  File "/Users/robertd/development/sandbox/salaea/lib/python3.9/site-packages/saleae/automation/manager.py", line 362, in launch
    return cls(address=_DEFAULT_GRPC_ADDRESS, port=_DEFAULT_GRPC_PORT, logic2_process=process)
  File "/Users/robertd/development/sandbox/salaea/lib/python3.9/site-packages/saleae/automation/manager.py", line 296, in __init__
    raise exc from None
  File "/Users/robertd/development/sandbox/salaea/lib/python3.9/site-packages/saleae/automation/manager.py", line 281, in __init__
    app_info = self.get_app_info()
  File "/Users/robertd/development/sandbox/salaea/lib/python3.9/site-packages/saleae/automation/manager.py", line 380, in get_app_info
    reply: saleae_pb2.GetAppInfoReply = self.stub.GetAppInfo(saleae_pb2.GetAppInfoRequest())
  File "/Users/robertd/development/sandbox/salaea/lib/python3.9/site-packages/grpc/_channel.py", line 946, in __call__
    return _end_unary_response_blocking(state, call, False, None)
  File "/Users/robertd/development/sandbox/salaea/lib/python3.9/site-packages/grpc/_channel.py", line 849, in _end_unary_response_blocking
    raise _InactiveRpcError(state)
grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with:
	status = StatusCode.UNAVAILABLE
	details = "failed to connect to all addresses"
	debug_error_string = "{"created":"@1662738152.548349000","description":"Failed to pick subchannel","file":"src/core/ext/filters/client_channel/client_channel.cc","file_line":3218,"referenced_errors":[{"created":"@1662738152.548349000","description":"failed to connect to all addresses","file":"src/core/lib/transport/error_utils.cc","file_line":165,"grpc_status":14}]}"

The other 50% of the time it runs to completion and grabs my traces. Note, I don’t see this problem if I instead manually start the APP and then use run my remaining automation script to capture traces.

automation.Manager.connect()

I’m wondering if it is possibly a timing issue waiting for the Logic.app to start, connect to the logic device, etc, before it starts querying it? I do notice about 10 seconds of delay for the app to get spawned and perform it’s initialization, connection, etc.

Regards,
Robert

67

Hi Robert,

Thanks for reaching out!

When creating a Manager (via connect or launch) it will try connecting to the app for up to 10 seconds before failing - it sounds like this is right at the edge of how long it is taking for the app to be ready in your case.

I think we should make 2 changes to the API:

  • Add a parameter for the connect timeout time.
  • Increase the default timeout to 30 seconds.

Let me know if you have any other suggestions, or if you think there is a better solution.

Ryan

68

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?

69

Hi Robert,

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

Ryan

70

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

71

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

72

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.

image
image867×333 17.1 KB

73

@pangipark I replied below:

74

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

75

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

76

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?

77

@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

79

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

80

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

81

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

82

@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).

83

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