CDCE6214-Q1: automated programming using ticspro from command line prompt with batch file

There's no usage model for the TICS Pro executable that support the kind of command line programming you're describing. I have a feeling that what you really want is the TI equivalent of the ClockBuilder Pro command line tools, but these supporting tools have not been constructed for TICS Pro. At this time, we can offer guidance and support for the programming process, or review of programming sequence/procedure.

Hi Derek,  I develop board level test solutions using LABVIEW.  I have the ability to launch this application from LABVIEW using SYSEXEC.vi but I need to automate as much as possible the programming sequence of TICS Pro.  It already works as a GUI, but I would like it to have default settings for the device and the configuration file .tcs.  The DEVICE_NAME00-CDCE6214-1Q is already set in the SETUP of TICS Pro.ini file, can I do the same thing for the .TCS file too?  It would be nice if I could set a mode in the TICS Pro executable to automatically start the register-to-program-eeprom operating when launched.  Thanks for your help in advance.  -Pat

There is a single command line flag that can be applied to specify a custom settings file, which can control some startup behaviors. The one I could potentially see being of use to you is the locally-bound TCP socket server API, which can do things like set field values, write registers, load configurations, etc. We include a python wheel, ti_ticspro, within the installer (installed to C:\Program Files (x86)\Texas Instruments\TICS Pro by default), which includes an example python client implementation for the socket server communication. I think you could review this client file and come up with an equivalent vi that can TCP Open Connection to the local TICS Pro socket server, TCP Write the message, and TCP Read the response. Then you can load the configuration and press the "BTN_EEP_REGCOMMIT" button via TCP server APIs from within labview. The actual mechanics of the APIs are extremely straightforward, and merely requires string join/split and prepend/append or strip of some standard ascii characters. Please give the python client file a quick look, and let me know if this seems like a reasonable proposal.

Hi Derek,  I've got a LABVIEW TCP client working (sort of) the TICSPRO server.  The handshaking is a little suspect but the basic TCP command interface is working for the most part.  I have a few more questions please:

1. Is there a variable I can set in the settings.ini file to allow me set the device configurate file (.tcs) to insure it loads automatically? 

2. How do I know when the write to EEPROM (via BTN_EEP_REGCOMMIT) has completed the programming sequence (status call maybe)? 

3. Finally, is there an API command that allows me to terminate (close)  TICS Pro.exe cleanly?

Thanks,

-Pat

1. Not exactly in settings.ini, but there is roughly a way to do this. On startup, TICS Pro looks at C:\ProgramData\Texas Instruments\TICS Pro\Configurations\TICS Pro.ini to determine the startup device, and on exit the current device is written to this INI file. There is some automation in the ti_ticspro package that shows how to update this INI file with an alternate startup device, though I think it's sufficient to just open the software, select CDCE6214-Q1, and close the software to ensure that CDCE6214-Q1 is used as the startup device. On exit, TICS Pro saves the current state of the GUI to a .tcb file in C:\ProgramData\Texas Instruments\TICS Pro\Configurations\Devices\<path to device>\<device>.tcb, with a folder structure that mirrors the device selection menu in the GUI. You could overwrite the .tcb file with your own .tcs file (they are the same file format, just a different extension).
   Alternately, you could just use the RestoreSetup TCP API and point it to the tcs file you need.
2. Looking at how the PressButton API is implemented, the server thread blocks until the PressButton API call completes, and the API call blocks until the whole process triggered by the button completes. I believe this means you get a response only once the software completes the programming sequence.
   Trying it out now, it seems to return only once the function tied to the button call completes. However, I see that there is an unskippable confirmation dialog which pops up. This is very annoying, because it prevents automation from proceeding. I think for automation purposes you should disable this dialog. Fortunately the code which executes this dialog is just IronPython script files included with the CDCE6214-Q1 profile data, so it can be edited by hand. In C:\ProgramData\Texas Instruments\TICS Pro\Configurations\Devices\Clock Generator-Jitter Cleaner (Single Loop)\CDCE6214-Q1\EEPROM.py, in the function BTN_EEP_REGCOMMIT_Update, there is a line "if eewriteconfirm():" which spawns the dialog; you can comment this line out and replace it with "if True:" to bypass the dialog for automation. Alternately, you could modify eewriteconfirm function to just return True.
3. A long time ago when this API was implemented as 32-bit COM automation, there was a way to close TICS Pro via API... the TCP API was put together to make it possible to interact with 64-bit programs, but we didn't have a clean way of communicating that the program had shut down after the server stopped, so now I think there is no such way to cleanly exit the process. I think you'll need to resort to some tasklist / taskkill sysexecing.