What I'm missing about HLAs

[ngblume]

Hej hej,

since I am currently working on an CANopen HLA, that uses basically the EDS file (a reduced version in TOML) to dissect the CAN frames and provide the individual values in the xPDOs as frames, I noticed a couple of things about the HLA, that I would like to list and get feedback on, if I am missing an obvious solution or if there is one in the making currently… Sorry, if I just missed a solution …

But before I start the list, thanks for the great product and the LLAs and HLAs until now… let’s make them even better

Using a “hidden” Python installation
If I understand it correctly, the HLAs are executed by a Python 3.8 installation, that is part of Logic, and I was not able to use that environment directly (see later why I wanted to do that)
Why is Logic structured that way and will there be chances soon, that one can provide an environment? For example 3.10 with the switch/case options would be really nice for state machines in HLAs… or installing packages the easy way and being able to use them with HLAs as well…
I found the environment somewhat around here: C:\Program Files\Logic\resources\windows-x64, but no obvious, at least for me, to directly call it… from the structure is looks like the “Windows embeddable package (64-bit)”… Though that one has a python.exe “exposed”…
and it reports the following as the version:

python version:
3.8.2 (default, Apr 18 2020, 17:07:21) [MSC v.1925 64 bit (AMD64)]

Fixed Issue

When using the exact python version “3.8.2”, the workaround works as well for the bitstring module…

Additional issue with that:
I am trying to use the module “bitstring” (Overview — bitstring 4.2 documentation)…
I installed it via PIP with python38 and python312 and added the folder to the PATH, but Logic still reports

"ModuleNotFoundError("No module named 'bitarray._bitarray'")" from
File "C:\ZZZ\..\lib\bitarray\__init__.py", line 14, in <module> from bitarray._bitarray import (bitarray, decodetree, _sysinfo,

I suspect, there is an issue with these precompiled C-Libraries…

No IntelliSense / auto complete in editors
Given, that the saleae python modules “saleae.analyzers” and “saleae.data” are in that hidden installation, VS Code cannot find them directly, which makes auto complete not working (I’m sure that there is a solution, it just is one of the things, I like to work out-of-the-box…

no good option to use additional python modules
Python lives and dies with its large ecosystem of additional modules, all easily installed via pip or something similar… But due to the hidden Python environment, this is not so easy…
There are workarounds (install them from a different python environment into a folder and add the folder at runtime to your path), which work, until the installed packages depend on the python version, you use (for example due to CPython PYDs…)
Then installating from your own environment requires you to have the same / correct version of python so that the CPython PYDs are correct version…
For now, I am trying to get a similar embedded distribution going and perform the pip from there to folder, that is than added again to the PATH variable at runtime…

Creating multiple AnalyzerFrames at the same time
Given the nature of fieldbusses in general (i.e. CAN), it is a given, that within a packet, you get tightly packed data, and unpacking that is the beauty of a HLA…
So it came as a somewhat of a disappointment, that I cannot use the CAN frame overall start_time and end_time, but need to do artifical timing to get them shown after each other instead of on top of each other… The HLA row might get quite large vertically, but if it would be collasible (all visible or just a single line), it would make it so much better…

Thanks for any input / pointer to solution!

Cheers
Niels Göran

[BitBob]

I’ll let Saleae provide an official response, but my guess is that the embedded python environment for HLAs is a restricted subset of a full python install, and the version is fixed at build time of the Logic 2 application itself to be compatible across all supported PC targets (Windows, MacOS, and Linux) and all users that use it and who are on various different Logic 2 releases as well.

I’m guessing they could upgrade from 3.8 to 3.10+ for newer python feature support, but not sure if/when they’d choose to do this. Each bump in version might cause compatibility issues with existing users, installations and/or marketplace HLA extensions. Again, I’ll defer to Saleae to manage their own upgrade roadmap . However, you can promote the idea in a feature request: Logic 2 - Ideas and Feature Requests - Saleae

… and in this case, you and anyone else who agrees could upvote this existing one:

Update Python to version 3.10 for Software Extensions - Logic 2 - Ideas and...

Likewise, I’m guessing they hand selected the pre-bundled libraries & packages and haven’t prioritized figuring out a portable way to allow user-driven upgrades and/or new package dependencies. Maybe they could at least support ‘local HLAs’ that could extend python vs. marketplace HLAs, but the release version of python will still be fixed at build time of the Logic 2 application as it’s embedded within it.

Note: It looks like that idea was also already submitted (upvote if interested):

HLA: support Python dependencies - Logic 2 - Ideas and Feature Requests - Saleae

The Automation API is not as tightly coupled, and thus allows you more freedom to extend w/ ‘pip’ and/or update the base language release version as desired. In theory, they could expose the full HLA interface through some type of gRPC APIs, but not easily done and could have negative performance impacts using a ‘lite’ network layer vs. optimized built-in bindings within the executable itself (and some people already complain about the extra overhead of electron vs. a native UI).

Meanwhile, I think you can technically ‘hack’ your own Logic 2 python installation to add more libraries/packages, but then your HLA will only work on installations ‘patched’ the same way, and wouldn’t work as a marketplace extension. Also, your still limited to the base version of python pre-installed in the Logic 2 application (unless you really hack it at a much lower level ). Here’s a post discussing this concept, and a suggested work around:

Third party libraries with HLAs

Hi Scarzer, Thank you for the kind words! We don’t currently have a supported way of installing Python dependencies. This is made harder on Linux, as you discovered, by the fact that the AppImage installs to a separate temporary directory each run. For an easier workaround in the meantime, you can modify the sys.path in your extension file to include the directory that you installed the Python package to: import sys MY_ADDITIONAL_PACKAGES_PATH = '/packages/install/location' if MY_ADDITIONAL_P…

As for better VScode integration & IntelliSense support, check out this:

Logic 2 python api stubs

Would you consider publishing python api stubs for the full saleae HLA interface? When developing python HLA extensions, it is useful to have intellisense / autocomplete. Python supports stub files, that can be used for this. Attached is an initial setup for this, which is manually extracted from API Documentation Drop the attached files in a folder ‘saleae’ and autocomplete / type hints should mostly be working. Example of it in action: [image] saleae.zip (1.5 KB)

Finally, was your desired HLA frame layering something like:

HLAs - Overlapping frames

I am working on an HLA to parse serial packets, and had this idea to show parts of the packet, and then an additional frame that says what the entire packet is generally. Right now it seems that returning frames in the same time, whichever one is return last will get painted on top. The idea being that in the case of fragments or bad packets, I can still at least display whatever data was successfully parsed. Does this exist somehow already, or could it be planned? [image] [image]

If so, then not sure on latest status of the planned feature to support such capability.

Hope these pointers help you enough for now, while maybe Saleae (@timreyes or @markgarrison?) can chime in with more specifics or any longer term Logic 2 roadmap plans.

[ngblume]

Hey BitBob,

thanks for your reply!
Just to be on the safe side…
My post was mostly looking for explanations and timelines, than being really unhappy with Saleae and the software at all…

I’ll let Saleae provide an official response, but my guess is that the embedded python environment for HLAs is a restricted subset of a full python install, and the version is fixed at build time of the Logic 2 application itself to be compatible across all supported PC targets (Windows, MacOS, and Linux) and all users that use it and who are on various different Logic 2 releases as well.

I agree that keeping it consistent is necessary and an issue in itself.
If I remember correctly, there was the idea out in the forum, to allow the user to switch between built-in Python environment and providing its own environment, with all benefits and responsiblities… Especially, given that Python emphasizes virtual environments to heavily, this seems rather logical as a conclusion / solution…
Also curious for an official answer from @timreyes or @markgarrison …
I also upvoted the entries, but 2 or 3 votes… not sure, how extensive this voting is used by user…

Likewise, I’m guessing they hand selected the pre-bundled libraries & packages and haven’t prioritized figuring out a portable way to allow user-driven upgrades and/or new package dependencies.

I get the feeling in the last months / years, that several important features aren’t high on the list… or rather fundamental features… what separate Python environments and therefore easier import would unlock in terms of solutions / high-level analyzer I can only imagine…

Meanwhile, I think you can technically ‘hack’ your own Logic 2 python installation to add more libraries/packages, but then your HLA will only work on installations ‘patched’ the same way, and wouldn’t work as a marketplace extension.

I did this (as outlined in the spoiler) and it solved my issue, but I would really like som eproper documentation on this (including a starting point for getting the proper packages installed locally)…

Python stubs seem like a great idea, but again, no progress since June 2023…
Doesn’t seem like a large issue to fix, but definitely worthwhile…

When trying to get overlapping frames to work, I cam across the discussion with answered my question why I was getting an errror message… It didn’t really answered the question why it has not been addressed since than… July 2021…

HLAs - Overlapping frames

I am working on an HLA to parse serial packets, and had this idea to show parts of the packet, and then an additional frame that says what the entire packet is generally. Right now it seems that returning frames in the same time, whichever one is return last will get painted on top. The idea being that in the case of fragments or bad packets, I can still at least display whatever data was successfully parsed. Does this exist somehow already, or could it be planned? [image] [image]

I am OK with software not having certain features immediately, and adding them later is fine, if there is consistent progress towards the essential features…
And as long these limitations are clearly communicated up-front…
In the documentation of the HLA frames, it says “Decode a frame from an input analyzer, and return None or 1 or more AnalyzerFrame objects.”… no mention of none parallel frames only…

API Documentation | Saleae Support

Nevertheless, I got my CANopen dissector working…

Cheers and a nice weekend
Niels Göran