Note: We are holding off on auto-updating this version until we see the how our error rate changes. Please download and use this version to help us gather stability metrics.
2.3.17 was a tremendous under-the-hood effort. This probably affected more functionality in the application than any recent previous release. Please let us know if you have any trouble with it at all!
We’ve spent over a week manually testing every feature to ensure the most stable experience possible.
What’s New
We don’t select simulation devices by default! No more confusion around real devices vs. simulation devices
New about dialog
New device information dialog
Improvements
Device selection moved to sidebar
New sidebar icon for device settings
Huge under the hood refactor of session management
Huge under the hood refactor of device management
Improved application responsiveness when closing tabs with large amounts of data
Bug Fixes
Fix issue where click & dragging on a timing marker context menu would move the marker
Reloading a local extension will now properly cause all instances of the extension to re-run with the latest source
Fixed issue with SPI analyzer when trailing edge of last bit occurred after enable de-assertion (non-standard)
Logic16 (original, discontinued 2014) IO voltage support selection fixed
Fix issue where some results are missing from the analyzer results table for very sparse protocol data
I can’t wait to try it out. Out of pure nerdy curiosity, what was the main goal of the under the hood changes - what sorts of neat features await us because of this Herculean effort?
I did a capture of a UART session on 2.3.16, and when I load it into 2.3.17 and try to export either of the two directions, I get an "Error while exporting analyzer: "
Hi Brian! Thanks for asking! Most of the under the hood changes were related to removing the behavior where we automatically select a demo device if no device is connected at start up. This was quite a thorn for some people who might have thought their device was connected but ended up getting demo data. Sounds like it should be simple to change, but it turned out that changing that behavior required us to change a lot of things ‘under the hood’.
@Kai Thanks for reporting that. That’s certainly strange. I wasn’t able to reproduce the issue in 2.3.17 and was successful in exporting your analyzers.
@timreyes Yes, this is 100% reproducible for me - for good or for bad. I haven’t tried on a different computer though.
I’m running this without the LogicPro 16 device attached (shouldn’t make a difference).
The system is running Windows 10 64bit, including the 2020H2 feature update and all available updates from MS. It has the (ancient) 1.2.29 software on it as well.
Hi. How or where to set up to automatically jump to trigger start after measurement? It’s annoying on every measure to jump to start (CTRL+J). In 1.x version the position remained always on the same place between measurements. This is for me desired behavior.
@timreyes I compared the export from v2.3.16 and v2.3.17, and my exports versus yours. 2.3.16 and 2.3.17 produce exactly the same export, and it is (modulo a dos2unix thing) identical to the output you got.
So it would seem that the error message that I am seeing is bogus for some reason.
The message “Error while exporting analyzer:” indicates that the analyzer export function threw an exception, and it’s supposed to be followed by the exception message.
What’s really odd is that the front end only displays the message if the error string is assigned to something - it doesn’t make sense to display an empty string!
One more question, and this is a long shot, but what locale/language settings are you using on your computer? It’s unlikely that this is a problem, but if there actually is an error, there is very small chance that the error string wasn’t transferred properly to the UI if it contained non-ascii characters. Again, it’s a stretch.
If an error occurs where, we would expect it to be a common disk-write error, with such causes as insufficient permissions, invalid path or non-existent folder, network location disconnected, no disk space left, etc.
Actually, taking a closer look at the code, it does look like we have an undefined behavior bug. I’m not sure why it’s consistently broken on your machine but not ours, but that could indicate we have slightly different Microsoft C++ runtimes installed. I’ll get this fixed for the next release, hopefully that will fix it.
Locale is not a bad assumption, as I’m located in Denmark. However, my Windows is in (US) English, but the keyboard is in Danish mode (to match my Nordic keyboard and access those pesky æøå).
In the Windows 10 settings, my “Country or region” is set to Denmark, with “Regional format” set to “English (Denmark)”.
Microsoft C++ runtimes:
Microsoft Visual C++ 2008 Redistributable - x86 9.0.30729.4148
Microsoft Visual C++ 2008 Redistributable - x86 9.0.30729.6161
Microsoft Visual C++ 2010 x86 Redistributable - 10.0.40219
Microsoft Visual C++ 2013 Redistributable (x64) - 12.0.30501
Microsoft Visual C++ 2013 Redistributable (x86) - 12.0.30501
Microsoft Visual C++ 2015-2019 Redistributable (x64) - 14.22.27821
Microsoft Visual C++ 2015-2019 Redistributable (x86) - 14.23.27820
Let me know if I can turn on some debug flags or something to nails this thing down.
@Kai, thanks for the details. In C++ we’re de-referencing an std::optional that is empty. I’ve got a fix into our codebase for it, and right now this is my lead suspect. We will likely cut a release in about 2 weeks. In the mean time, you may want to stick with 2.3.16 if this feature is blocking you.
Also, you can export the data table itself. This is a different system, and should not have any issues.
@engycz Thanks for bringing this up. The Logic 2 software doesn’t have the ability to automatically jump to the trigger directly after a capture.
At the moment, CTRL+J, or clicking the small yellow trigger icon on the timebar directly after a triggered capture, are the two ways you can navigate quickly to the trigger point. Definitely a pain… I agree completely.
We certainly need a way to automatically jump to the trigger. We’re tracking the feature request in the idea post below, and it looks like several users have expressed interest in it. I actually added a comment for you in the idea post below to make sure we got your “vote” in. Feel free to vote and add your own comments as well. It helps with visibility. https://ideas.saleae.com/b/feature-requests/jump-to-trigger-point-after-capture/
Personally for me, I find that jumping to the trigger after a capture should be the default behavior. My reason for this is that, if I’m triggering on something, then that trigger point is obviously of interest to me, so I’d like the software to jump to it. It’s nice to have a sense of consistency in that sense, rather than the data capture showing me some random point after the capture that would not be of interest to me 99% of the time.
Do you find that your use case for this is similar to mine above? I’d like to get use cases recorded for this to present to the team here. Otherwise, let me know if you have a very specific need for this as well. We’d be interested to hear that.
@markgarrison thanks for the update. 2.3.16 does this for me as well, so I might as well stay on 2.3.17 I guess - especially since the output is correct.
@Kai Understood. You’re right, we forgot you mentioned 2.3.16 and 2.3.17 produce the same export. Go ahead and stick to 2.3.17 for now then. As Mark mentioned, we’ve got the fix planned for 2.3.18 so hopefully that solves it for you once we release it.
@Kai The new version 2.3.18 is ready to test! Would you mind giving this version a try and letting us know if that solves the issue for you? https://ideas.saleae.com/f/changelog/
