I have used Logic 1 for a couple of years and built up an automated test setup where I use a Pro 8 device for nightly verification of a stepper motor control. I verify both speed, acceleration and motor current.
I use 1 analog and 4 digital channels, where the digital channels need very high sample rates (at least 50 MS/s) - but the analog channel needs a very low rate (down to 100 S/s) to allow sampling for long durations.
This is working alright but as I have discovered that Logic 2 has been updated with automation, I want to migrate to Logic 2. However, I see that Logic 2 is not (yet) supporting the sample rates I need.
How are your plans for additional combinations?
Another approach (which I only dare to dream about):
What if the analog sampling could be triggered by the edges of a digital channel. That would be perfect for me
@jcbruun53 We’re glad to hear you’re getting started with the newer Logic 2 Automation API!
I’ve added a comment for you in the feature request post below to track your need for this (I’ve written up some notes in the link below as to the challenges we face with implementing this feature, which makes it a non-trivial addition).
We unfortunately don’t have this on our roadmap at the moment. Out of curiosity, and to understand your use case properly, can you share your reasoning for needing a 100 S/s analog sampling rate, while also sampling at 50 MS/s digital? For example, I’d be curious to know what kind of signal frequency you are working with.
You could consider a workaround by using our Automation API to record several smaller captures instead of a single, longer capture. This would help save on RAM usage at the time of the capture (since each recording can be closed and cleared from RAM), but wouldn’t save on hard disk space if that was what you were going after.
If I understand your request correctly, triggering by the edge of a digital channel is in fact the only method to trigger recordings (we don’t have a method for triggering on analog channels at the moment). For example, in the scenario you mentioned (“I use 1 analog and 4 digital channels”), the edge trigger could be enabled on one of the 4 digital channels, which would trigger the entire capture to start.
I suspect I could be misunderstanding a part of your request, so feel free to correct me if I made an incorrect assumption about your setup! Hope this information all helps.
Thanks for your quick response. And for your curiosity:
I am verifying the sw-driver for a steppermotor, driving a rotating device. During each round the rotational speed (stepper pulse frequency) is varied from 1Hz to 33kHz.
I need to measure the acceleration/deceleration of stepper pulses with 0.1% accuracy, which leads to the requirement of at least 33MS/s, digital.
We also measure an analog voltage, which controls the current in the motor windings. To optimize the torque, this current is varied multiple times during one round.
To verify this, an analog channel is used, but here we can live with a lower accuracy.
Now, the duration of one round is varied from 0,3 seconds to 1 hour in different use cases. To measure a full round I need to sample for up to 1 or 2 hours.
This is actually possible if the analog sample rate is kept at 100S/s.
I really hope you will be able to lower the analog sample rate significantly - until then I will stick to Logic 1.
Regarding the last part: My mistake, sorry I Should have written:
What if each analog sample was triggered by an edge of a digital channel. Then we would only get as many analog samples as there are edges on the selected digital channel,
and sometimes that is all one needs. But I know that is a huge change to ask for
100S/s for a couple of hours is only on the order of 1.5MByte. With a modern computer 100x that size shouldn’t be much of an issue. Is there something else going on that I’m missing?
Note that only edges are recorded for digital channels so bumping the digital sampling rate to 125MHz shouldn’t impact the size of the recorded data.
I agree. I don’t have to go as low as 100S/s, but the point is: With a digital rate of 125MHz Logic-2 will not allow me to go below 3.125 MHz analog… and doing that for 1 hour requires 11.25 GB of RAM - and I don’t have that.
My bad! I missed that this issue was in the context of automation where the rules and allowed rates are different. I’ll shut up now and go back to my corner.
@jcbruun53 Ah, I get it now, thanks for describing your use case in more detail. That all makes sense. I’ll ping the team about your request, but unfortunately, we’ll likely not be able to work on it soon due to other priorities at the moment. You’ll unfortunately need to stick with Logic 1.x is this is an absolute must.
The ability to trigger samples via an external input clock is something we’ve wanted to support for quite some time now, but just haven’t gotten to working on it.
Ok, I will stick with Logic 1.2.29 for now but as I expect my test to be running every night the next couple of years (testing on a developing product), I will look for your upgrades and hopefully be able to switch to Logic 2 at some point.
Please help.
It’s been almost 2 years now and I am still running the same automated tests using Logic 1.
But now Logic 1 is not working anymore (a new PC, new IT policies etc…), so I decided to try Logic 2 again.
As described in above history, I need a high digital sample rate combined with a low analog sample rate - and I thought Logic 2 might support that by now.
So I configured my Logic Pro 8 with 4 digital channels at 500MHz plus 1 analog channel at 50 Hz.
It was actually possible to make a capture manually, so I was very excited.
But then I tried to automate it… and sadly I received the same old message:
“saleae.automation.errors.InvalidRequestError: Invalid supplied sample rate - sample rates <= 31250 are currently unsupported from the automation API”
Now, could it be that you just need to update your parameter checker? Because it seems to work manually, while the automation part rejects my arguments.
Any chance Saleae is internally using WebDriver / ChromeDriver for automated testing? If so, could this be extended into a published python wrapper to provide an interactive automation framework? Maybe this needs something like Selenium to accommodate languages outside of native Electron/JavaScript? I’m not an Electron developer, so maybe this is not the right use case for these tools, but thought it might be an easy way to provide more end-user scripting/automation features for the UI … ?
Meanwhile, there are other UI automation frameworks out there, but any 3rd party solution risks needing rework if Saleae refreshes the GUI and moves buttons or textboxes, remaps settings, etc. It can also become a maintenance nightmare if you want to support multiple/old versions of Logic 2, depending on how much things change between releases.
This same issue might affect Saleae trying to provide long-term support with WebDriver, as I think the scripting would bind directly to UI elements vs. more abstract/standardized APIs … but this could be encapsulated in a python wrapper, and the complexity to maintain would depend on how radically the UI changes over time vs. adding more script-friendly controls.
Another option, is Saleae could add a ‘console’ window/back-end within the GUI for more built-in/native application control and possible future headless mode? This could facilitate scripts run interactively by the user or remotely invoked via the Automation API. Could possibly just extend the HLA/python scripting engine for this w/ a new UI/display object/class? (or, may want to isolate it within a separate context/sandbox)?
Ultimately, it depends on how Saleae wants to implement/publish a standard API vs. stay internally agile for maximum flexibility w/o backward compatibility risks (as internal devs likely mostly care about maintaining the latest release vs. supporting all prior ones still in use). Also, they may not want to proliferate too many APIs for different use cases either.
@jcbruun53 Let me ping our software team to get their thoughts on this and we’ll get back to you! The background on why this limitation exists is explained briefly in the Feature Request post that @BitBob posted above.
@BitBob I’ll shoot your notes over to our software team as well. Thanks for the suggestions!
Sorry for the long delay on this! I’ve finally found time to fix this. The next release will include automation support for all sample rates, including the extra low ones.
If you would like access to this right away, without waiting for the next release, please let us know using our contact form and we can provide you with an interim build.
