TICSPRO-SW: Scripting improvements

Hi Christian,

I appreciate the feedback. Currently the python library is publicly accessible by the user but is not really recommended for use because of the "RAW" state of it. We do not have enough documentation or an API handy yet. It is in our to-dos to release a driver or API for these devices in the coming months.

For bullet #1, are you referring to a way to export the register settings using the python library or in the GUI itself?

For bullet #2, can you share a screenshot? If there is more than 1 freq plan, then several options show up like below. Select an option from each VCO then click the button.

For bullet #3, noted.

Regards,

Jennifer

Thanks for pointing these out. The APIs that are exposed in ti_ticspro are the ones we use the most in internal automation. There are unimplemented behaviors, typically because we haven't encountered a need for them internally, or we had an alternative workaround available. It's worth noting that the TCP automation interface was added several years into TICS Pro's existence, so many behaviors were not designed with automation in mind, and adapting them correctly to API is sometimes challenging - it might take some time to satisfy change requests. I have taken an API-first approach to the in-progress next generation software with TICS Pro 2, so hopefully this kind of thing will be less hit-or-miss in the near future.

I'll work on implementing the requested feedback and push an update in the coming weeks. If you haven't already, I recommend using the notification feature of the website to watch for the next release.

Christian Ryffel said:

I found no way to export the register settings like tp.SaveSetup().

Indeed, I did not expose APIs for this. There are some complicating factors within TICS Pro that made exposing an API challenging in the past, so the import/export functions were skipped. An extremely roundabout way to export registers exists:

• Set the interface to simulation mode to avoid performing I/O
• ReadRegister each register in the device, one at a time (ReadAllRegisters doesn't return results) - this will read back the same value as currently cached
• Manually write these register readback values to a file

It would be better to add ImportRegisters and ExportRegisters APIs like what the GUI exposes, and ReadAllRegisters should return values, so I'll put these on the to-do list.

Christian Ryffel said:

Under "Set Outputs" it's not possible to select a different frequency plan. I found no way to select them under "D)"

There's a lot about tables that doesn't work the same as all the other visual controls like comboboxes or checkboxes. The API-level interactions with tables were never defined, because it doesn't come up often in our use cases. Consequently, there's no workaround for this issue.

I think what should be done is:

• Add GetTable API, which sends the contents of the table over the wire as a TSV string, and unpacks it as some straightforward python data structure (dict of lists with column header keys, probably)
• Support GetIndex and SetIndex to get and set the table row
• Add mouseover event to display name for tables in context window

I'll see what can be done about this. I'm confident mouseover events and GetTable are straightforward; get/set index for table row may need to be different APIs.

Christian Ryffel said:

The tcp.py has a hard coded timeout of 10s.

This isn't actually hard-coded, that's just the default initialization value - there's a timeout property on the TICSProTCPClient object which gets and sets the underlying socket timeout. In fact, this timeout property was added specifically because of the long DPLL calculation.

class TICSProTCPClient:
    ...
    
    @property
    def timeout(self) -> int:
        """Get or set the client timeout for the socket server connection.
        The units of the timeout are seconds. Default is 10."""
        return self._sock.gettimeout()

    @timeout.setter
    def timeout(self, value: int):
        self._sock.settimeout(value)

Thanks Derek. Cool to have such a fast and detailed feedback. I'm happy.

I've tried the notification in the past. It's broken. Also adding it on https://www.ti.com/myti/docs/myAlerts don't work.

It's so cool to have an API for TICS Pro. In the past it was a pain to create a new configuration with the GUI. We had a separate document where we listed all the settings and their reason. And then also which register have to be changed manually. And which button has to be pressed. This was a bad way to generate settings for a live product. Also version control was really bad because comparing two tcs files is hard because you have to understand every register. Comparing two python files which only contains necessary settings or tweaking the setting is much more comfortable and safe. 

Thanks for your work and help

Christian Ryffel said:

I've tried the notification in the past. It's broken. Also adding it on https://www.ti.com/myti/docs/myAlerts don't work.

I recall in the past it was broken, but I was recently told it had been updated. Anecdotally, team members have suggested it still doesn't work. I'll test the notification behavior myself as well, then query the web team about this and compare our answers.

Regardless, I've made a reminder to update this thread when the TICS Pro API updates are done.

Hi Derek

Thanks for the improvements. I've tested the ExportRegisters and everything works as expected. Thank you.

I've just noticed that the execution of the DPLL script is now instant. I can change all the settings, but the registers stay always the same. I think there's something broken now.

I've also implemented a version check of TICS pro to be sure we are using the correct version in the future. Unfortunately I didn't get these information from your API and had to grab it via win32api.GetFileVersionInfo. It's ok for me, but maybe worth to implement in the future.

There were no profile code changes between July  release (1.7.9.1) and most recent release (1.7.10.0). I've tested on my machine, after a fresh installation, on 1.7.10.0 - I still get a DPLL calculation on both LMK05318B and LMK5B12204 profiles, along with register writes. I'm not sure why you'd be having trouble with the DPLL script not executing, do you get any error messages in the textbox below the button? I know the script won't run on first load unless the "calculate frequency plan" button was pressed, and there may some latch on that state when certain settings are changed - this should be reported in the textbox below the calculate button.

If there's no obvious causes, we can check a few things:

• Is the MATLAB runtime on the path? Is the correct version (9.0 r2015b 64-bit) on the path ahead of any other MATLAB runtimes?
• Are you seeing the executable spawn a shell? If you delete the text files generated by the DPLL script, and re-run the script, are these files regenerated? In C:\ProgramData\Texas Instruments\TICS Pro\Configurations\Devices\Network Synchronizer Clock (Digital PLLs)\LMK5B12204:
  • closelp_pts_dpll1_romdump.txt
  • error_pts_dpll1_romdump.txt
  • romdump.txt
  • matlab_inputs_lmk05x18.m

TICS Pro version in API noted, I'll plan to include in a future release.

Yes the shell spawns. But disappears immediately. Only the matlab_inputs_lmk05x18.m will be generated. Nothing else. But there's no error or so in the text box. Just wrong numbers.

I will completely remove TICS pro and reinstall it. I've done just an upgrade.

I started the LMK05x18_ROM_Gen.exe in a command line. And got the error "Could not access the MATLAB Runtime component cache." Following https://www.mathworks.com/matlabcentral/answers/2142116-how-to-resolve-the-error-could-not-access-matlab-runtime-component-cache-fl-filesystem-invalidargum I was able to delete the cache. It's now working as expected. I'm able to work again now, so for me it's fixed. But there should be some checks to see if the script executed correctly.

We're not happy with the MATLAB-based DPLL coefficient calculation for a variety of reasons (system path and runtime version dependence, slow warm-up time for the runtime, installer size inflation due to single-line changes in the binary source, cryptic errors like yours requiring arcane workarounds, an extra software dependency that takes up 1.6GB and requires installation/privileges which can't be bundled with the original installer). The specifics are still being worked out, but in TP2 we are targeting a python-based solution for computing the DPLL coefficients. This will hopefully be much less trouble for everyone.