Hello!
What plans do you have for the socket scripting API in version 2.0?
We are planning to use the Logic Pro 16 for an automated test jig, where we perform automated tests for a safety PLC we are developing. The purpose is to automatically perform the tests and save the test data for later review. The Logic Pro 16 together with the scripting API would be great for this purpose.
I have wondered earlier if there was a chance that the scripting API could be extended with some additional commands. If these commands could be included if/when the scripting API is ported to v2.0, it would be great.
The most important command for us is to be able to configure channel names and glitch filter for each test. When the channels have descriptive names for each test, the manual review afterward is much easier. So one command “CONFIGURE_CHANNEL”, or two commands “SET_CHANNEL_NAME” and “SET_CHANNEL_FILTER” would be perfect.
A simple ping command or get status command would also not hurt, to check that the application is responding and ready, or if it is already busy capturing. For example “GET_STATUS” or simply “PING”.
If those commands were to be implemented I would be happy to make a pull request to the C# git repo with the new commands.
Thanks for a great product, and good luck with the development!
Thank you so much for posting, and I’m sorry I somehow missed this! I’ll see if I can get these to cc with our support just in case.
Understood, thanks!
Yep, makes sense.
The plan for the 2.0 software (the Alpha) is to make an amazing application-API that will use JSON Actions - probably a subset of the same actions that are used in the app itself - so that full application control will easily be possible. We’ll also want to make a subsection of the application State visible - things like what tab we’re on, are we recording or not, etc. I personally can’t wait to get started on this and I don’t even think it will take very long. That said, right now we’re in a bit of flux on the schedule so I can’t give a great estimate for this.
If you have concerns around the timing let me know.
Thank you again for the feedback and specific requests!
Hey Joe,
Thanks for your detailed answer.
That sounds great! It’s really good to hear that you plan to use JSON. I think that’s a great idea.
Regarding the timing, our plan is to finish the testing software and hardware setup before next year. Of course the new API would be great to have then, but the current API is still usable in the meantime.
Thanks again for your answer, and for having this forum for feedback and suggestions. I will be sure to keep an eye here for updates on the development!
Hi Jason, thanks for checking on this. Unfortunately, we don’t have any updates on this yet for Logic 2. Right now, our hands are tied with some higher priority tasks before officially releasing Logic 2 as a stable version.
In the meantime, we’re keeping an eye on user need for this in the idea post below:
Feel free to vote/comment on it in the meantime. If enough users comment and vote, we might have to move it up in priority. I also just linked this forum post to that idea post to make sure we get this logged as well.
Thanks again for checking in on this, and apologies for not having an update.
@drew Apologies we don’t have an update on this…
Since my last reply to this forum thread, we’ve added quite a lot of customer use cases and requirements in this idea post below:
Would you mind sharing some details about your use case and requirements? Also, do you currently use our Automation API on our Legacy Logic 1.x software? If so, I’d also be curious to know about how you currently use it, and what improvements you would like to see.
I think the comment in that feature request from #67608 captures it: we are basically hunting for rare undesirable behavior and need to record on trigger for hours or days, preferably capturing all instances of the issue. The script API lets us trigger, record for a reasonable period of time, and then resume waiting for another trigger. It’s simply too data heavy to do logs for this long most of the time, considering most of the time is spent waiting for triggers.
Said another way, I’d say these devices are fundamentally used for two purposes:
development: sitting in front of hardware that’s supposed to behave in a certain way, testing that it does, and fixing it when it doesn’t
debugging: waiting seconds, minutes, hours, days, weeks, etc for a situation to occur and gathering as much information as possible from the hardware signals to figure out what the issue is, whether that is hardware, firmware, or something else.
While we spend more time using this in development, debugging is where a tool like this can save a ton of money and pay itself off many times over. Without scripting, your product only solves the development use case. With scripting, it solves both. You definitely have a sense of this given the scripting available on 1.x software, so we encourage you to consider this a required feature for 2.x and all releases going forward. It’d actually be better if this capability was built into the app GUI, but we don’t mind scripting at all if the hooks are there in the API.
Mostly unrelated: it’d be great if you could trigger on more than one line at the same time, whichever comes first.
To summarize, we don’t really need an API and sockets. Our primary need is repeated triggering and logging capabilities to make your hardware product useful for debugging rare bug signals. Having an API, if already running under the hood, is helpful for letting developers like us tailor the tool to our needs but much, much less important to us than repeated triggering and logging.
If repeated triggering and logging is already available in 2.x natively, we must have missed it, so please let me know!
We unfortunately don’t have this feature readily available in the way that you need it. Right now, we have a feature called “Trigger View” which looks for a specific analyzer result and keeps the most recent occurrence that matches that search item in the viewport. You can find more information about this below:
We’re tracking a different feature request for repeated triggers below:
It looks like what you need is a combination of the repeated trigger idea above, along with an improvement to our current Trigger View feature that would allow you to trigger on protocol errors.
Hopefully I understood that correctly! We’re taking notes over here and really appreciate all of the detailed feedback you provided.
@timreyes good summary. In our current use case, we’re looking for behavior on GPIO lines, so we don’t necessarily need trigger on protocol error in the sense of SPI/I2C/UART protocols, though that’d be a very powerful feature that we could use. Sorry if I was vague about what we were analyzing.
And yep, 100%, repeated triggering as described in the blurb above is exactly the “minimum viable feature” that would solve our use case.
Just an idea for some basic built-in automation could be very useful in your cases (and also in mine) without the need for complex capture segmentation:
Save and repeat: if the trigger occurs, the software will finish the current capture (post-trigger capture and pre-trigger trim), then save the capture to pre-configured file (adding counter to avoid overwriting the last file), and start the capture again.
Restart after failure: if the capture is stopped by any other means than the user clicking the stop button (buffer overflow, timeout, USB error, system reboot), the software will save the current capture (if possible), and try it’s best to start the capture again (if USB error, try to reset the hardware, if everything fails, try to reboot the system).
This would allow running the captures for weeks and months without the need for a human checking every few hours.
+1 for a socket api in logic2
preferably something that can run without the “GUI” part in case you wanna deploy it on a lighter weight raspberry pi and such
I’ll see if I can get these to cc with our support just in case.