# Scripting socket API **URL:** \ **Category:** Logic 2 Software\ **Created:** [August 20, 2019, 11:12am UTC](https://discuss.saleae.com/t/scripting-socket-api/108 "2019-08-20T11:12:54Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![wilfor](https://avatars.discourse-cdn.com/v4/letter/w/57b2e6/32.png) [@wilfor](https://discuss.saleae.com/u/wilfor)\ **Post date:** [August 20, 2019, 11:12am UTC](https://discuss.saleae.com/t/scripting-socket-api/108/1 "2019-08-20T11:12:54Z")
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! ---
**Author:** ![joe\_garrison](https://yyz2.discourse-cdn.com/flex030/user_avatar/discuss.saleae.com/joe_garrison/32/12_2.png) [@joe\_garrison](https://discuss.saleae.com/u/joe_garrison)\ **Post date:** [September 11, 2019, 10:59pm UTC](https://discuss.saleae.com/t/scripting-socket-api/108/2 "2019-09-11T22:59:12Z")
Hi Wilfor! 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. > [@wilfor](#): > > 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. Understood, thanks! > [@wilfor](#): > > 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”. 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! Joe ---
**Author:** ![wilfor](https://avatars.discourse-cdn.com/v4/letter/w/57b2e6/32.png) [@wilfor](https://discuss.saleae.com/u/wilfor)\ **Post date:** [September 12, 2019, 5:04pm UTC](https://discuss.saleae.com/t/scripting-socket-api/108/3 "2019-09-12T17:04:19Z")
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! William ---
**Author:** ![jsmith.liberty](https://avatars.discourse-cdn.com/v4/letter/j/7ab992/32.png) [@jsmith.liberty](https://discuss.saleae.com/u/jsmith.liberty)\ **Post date:** [December 4, 2020, 5:52pm UTC](https://discuss.saleae.com/t/scripting-socket-api/108/4 "2020-12-04T17:52:04Z")
Hi Joe, Checking to see if we can get an update on the application-API implementation. Thanks, Jason ---
**Author:** ![timreyes](https://yyz2.discourse-cdn.com/flex030/user_avatar/discuss.saleae.com/timreyes/32/108_2.png) [@timreyes](https://discuss.saleae.com/u/timreyes)\ **Post date:** [December 5, 2020, 2:12am UTC](https://discuss.saleae.com/t/scripting-socket-api/108/5 "2020-12-05T02:12:10Z")
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: > **[Application / Automation API - Logic 2 - Ideas and Feature Requests - Saleae](https://ideas.saleae.com/b/feature-requests/application-api/)** 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. ---
**Author:** ![jsmith.liberty](https://avatars.discourse-cdn.com/v4/letter/j/7ab992/32.png) [@jsmith.liberty](https://discuss.saleae.com/u/jsmith.liberty)\ **Post date:** [December 7, 2020, 7:51pm UTC](https://discuss.saleae.com/t/scripting-socket-api/108/6 "2020-12-07T19:51:10Z")
Thank you for the update Tim. ---
**Author:** ![drew](https://avatars.discourse-cdn.com/v4/letter/d/b19c9b/32.png) [@drew](https://discuss.saleae.com/u/drew)\ **Post date:** [March 16, 2022, 10:00pm UTC](https://discuss.saleae.com/t/scripting-socket-api/108/7 "2022-03-16T22:00:41Z")
Any update on this? ---
**Author:** ![timreyes](https://yyz2.discourse-cdn.com/flex030/user_avatar/discuss.saleae.com/timreyes/32/108_2.png) [@timreyes](https://discuss.saleae.com/u/timreyes)\ **Post date:** [March 17, 2022, 12:44am UTC](https://discuss.saleae.com/t/scripting-socket-api/108/8 "2022-03-17T00:44:19Z")
@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: > **[Application / Automation API - Logic 2 - Ideas and Feature Requests - Saleae](https://ideas.saleae.com/b/feature-requests/application-api/)** > > Add an API to interact with the app and the device without using the GUI directly. > This was supported in Logic 1 Socket API 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. ---
**Author:** ![drew](https://avatars.discourse-cdn.com/v4/letter/d/b19c9b/32.png) [@drew](https://discuss.saleae.com/u/drew)\ **Post date:** [March 23, 2022, 2:45pm UTC](https://discuss.saleae.com/t/scripting-socket-api/108/9 "2022-03-23T14:45:08Z")
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: 1. 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 2. 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. ---
**Author:** ![drew](https://avatars.discourse-cdn.com/v4/letter/d/b19c9b/32.png) [@drew](https://discuss.saleae.com/u/drew)\ **Post date:** [March 23, 2022, 2:56pm UTC](https://discuss.saleae.com/t/scripting-socket-api/108/10 "2022-03-23T14:56:48Z")
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! ---
**Author:** ![timreyes](https://yyz2.discourse-cdn.com/flex030/user_avatar/discuss.saleae.com/timreyes/32/108_2.png) [@timreyes](https://discuss.saleae.com/u/timreyes)\ **Post date:** [March 23, 2022, 11:18pm UTC](https://discuss.saleae.com/t/scripting-socket-api/108/11 "2022-03-23T23:18:57Z")
Thanks for the detailed feedback! > [@drew](#): > > Mostly unrelated: it’d be great if you could trigger on more than one line at the same time, whichever comes first. I added a comment for you in the idea post below: > **[More Complex Digital Triggers (One Shot, Protocol Results / Errors, State...](https://ideas.saleae.com/b/feature-requests/more-complex-triggering/)** > > I'm very happy using the Saleae analyzer > One missing feature (even on the new software logic 2.3.8) is having the possibility to not only trigger on rising or falling edge of the signal > but also trigger on sequential condition or bus value > The NCI > [@drew](#): > > Without scripting, your product only solves the development use case. With scripting, it solves both. This is a fantastic point. Agreed! > [@drew](#): > > 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: > **[Capture Modes](https://support.saleae.com/user-guide/using-logic/capture-modes#trigger-view-triggering-on-a-protocol-result)** We’re tracking a different feature request for repeated triggers below: > **[Repeated trigger capture - Logic 2 - Ideas and Feature Requests - Saleae](https://ideas.saleae.com/b/feature-requests/repeated-trigger-capture/)** > > Similar to the "normal" trigger mode of an oscilloscope, it would be useful if Logic could be set capture an amount of time around a trigger event, and then re-arm the trigger and do it continually. Logic could save each trigger to a file automati 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. ---
**Author:** ![drew](https://avatars.discourse-cdn.com/v4/letter/d/b19c9b/32.png) [@drew](https://discuss.saleae.com/u/drew)\ **Post date:** [March 24, 2022, 3:48pm UTC](https://discuss.saleae.com/t/scripting-socket-api/108/12 "2022-03-24T15:48:37Z")
@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. ---
**Author:** ![kazink](https://yyz2.discourse-cdn.com/flex030/user_avatar/discuss.saleae.com/kazink/32/519_2.png) [@kazink](https://discuss.saleae.com/u/kazink)\ **Post date:** [March 25, 2022, 9:08am UTC](https://discuss.saleae.com/t/scripting-socket-api/108/13 "2022-03-25T09:08:30Z")
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: 1. 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. 2. 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. ---
**Author:** ![timreyes](https://yyz2.discourse-cdn.com/flex030/user_avatar/discuss.saleae.com/timreyes/32/108_2.png) [@timreyes](https://discuss.saleae.com/u/timreyes)\ **Post date:** [March 25, 2022, 6:11pm UTC](https://discuss.saleae.com/t/scripting-socket-api/108/14 "2022-03-25T18:11:02Z")
Thanks @kazink! I took note of your comment in two different feature request posts below. > **[Continue Capture if ReadTimeout occurs - Logic 2 - Ideas and Feature Requests...](https://ideas.saleae.com/b/feature-requests/continue-capture-if-readtimeout-occurs/)** > > In case a ReadTimeout error occurs, it would be great to continue the capture. > \- Perhaps leave gaps in the capture when ReadTimeouts occur > \- Automatically re-start the capture upon a ReadTimeout error > > A quick solution with current hardware might be... > **[New trigger mode - Repeat triggering after hit. (Save all triggered captures.)...](https://ideas.saleae.com/b/feature-requests/continuously-triggering-start-mode/)** > > 1. Waiting for trigger.(Showing waveform in realtime like now. including pre/post capture after trigger.) > 2. When trigger hit, capture/save/show.(save waveform with sequence number or current date, time.) > 3. Go to #1 until stop. > > It will enable to... ---
**Author:** ![janny-bb](https://avatars.discourse-cdn.com/v4/letter/j/e9c0ed/32.png) [@janny-bb](https://discuss.saleae.com/u/janny-bb)\ **Post date:** [April 15, 2022, 8:31am UTC](https://discuss.saleae.com/t/scripting-socket-api/108/15 "2022-04-15T08:31:41Z")
+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