FAQ Keithley Datalogger/Initial State Integration

I may have entered the wrong access key. How do I check it? How do I change it?

You can send updated access keys through a TSP commands. On a computer connected to the same LAN, go to the LXI page by typing the instrument IP address into a browser URL. On the left side of the page click "Send Command". Send the following command to the instrument:

userstring.add("InitialStateAccessKey", "your_access_key")

note: You need the "quotes" around the Access Key string. 

You can verify that your key is set correctly by reading the Access Key back from the instrument using the following command: 

print(userstring.get("InitialStateAccessKey"))

Error 2403 TSP-Net failure?

• Update the device clock to the correct time. Secure SSL transfer requires the client to send a valid timestamp in order to validate certificates. This means that the clock on the 6510/6500 needs to be set properly. See the screenshot below, and notice how the clock is reset to "0" (which for this device is Jan 1, 1970).

• There are other reasons you may get this generic error including: 
  • Network connection issues. 
  • API Key incorrect or revoked. 

Can I user the Front Terminals on my 6500 or 6510? 

• This integration requires a scan to be configured. You cannot configure a scan to directly target front panel inputs as channels. You need to have a supported scan card installed in your 6500 or 6510 to create a scan, and thus to use this integration. However, with a scan card, in many cases you will be able to direct front panel input to one of the channels on the card. 

What is the default bucket name?

• The default bucket name is a string that represents the reading buffer name used to store readings while scanning or running the trigger model.  For example, is storing readings in defbuffer1 then the default bucket name is “defbuffer1”

What is the default bucket key?

• The default bucket key is a string that represents the date and time when the script/app starts to run in the format of YEAR.MN.DY HH:MM:SS where YEAR is year, MN is month, DY is day, HH is hour, MM is minutes and SS is seconds.  The month, day, hour, minutes and seconds will include the leading zero to make a 2 digit number.

How do I start logging data to Initial State if I do not want to use the App?

• Run the script named, Initial_State_Upload_Data_Script, as Initial_State_Upload_Data_Script()
• After running script in step a then, call the function name, start_initial_state(interactive_mode_setting, bucket_name_setting, bucket_key_setting).  All parameters are optional and if not specified will use the default value.  Parameters are:

  • interactive_mode_setting 

    set true if want display prompts to appear for user information, status messages or event messages.  Set false, default setting, to have these not appear.

  • bucket_name_setting

    string that specifies the bucket name to use when log data to Initial State.
• If interactive mode is true and bucket name setting is nil, the user will be prompted on the  display for default or user specified name.
• If interactive mode is false, and bucket name setting is nil, uses the default bucket name.

  • bucket_key_setting

string that specifies the bucket key to use when log data to Initial State. 

• If interactive mode is true and bucket key setting is nil, the user will be prompted on the  display for default or user specified key.
• If interactive mode is false, and bucket key setting is nil, uses the default bucket key.

During acquisition, I am seeing operation time out, tsp-net read or write failure event messages..  What is wrong and how do I resolve these?

• Nothing is wrong.  Those are normal error events.  Occasionally, while writing data to Initial State or reading status on a previous write, these error events may happen.  The App or script will keep trying to send the request packet again until it is successful.  These error events will no cause any loss of data.

I get the message "The instrument is set up to make infinite readings. To avoid data loss, reading rate must be less than Initial State limits."

• Hitting an API rate limit is reported as an error. So, you don't need to worry about silently losing data. The rate limit error depends on a few variables. The primary drivers are number of channels, sampling rate, and Initial State subscription tier. Click to learn more about Initial State Rate limits.  In general, the instrument will automatically stay under the rate limit by buffering and sending multiple events in the same API call, as well as buffering and sending events even after an acquisition is complete. If you are worried about buffer overruns and intermittent network issues that might also cause errors, you should check out the Initial State Bucket Watchdog Alert in order to get a notification if your data is not being received on the cadence you expect. 

The scan or trigger model has finished running, how do I know if all of my readings are logged to Initial State and it's safe to do other things on the instrument? 

• If you used the Initial State App to log the data then, the active script indicator at the middle top of the home screen will show “InitialStateApp” until the App stops running.  When done logging all of the readings and the App stops running, the active script indicator will show “No Script”.
• If you started the data logging from  a remote interface and you enabled prompts (localnode.prompts = 1) then, you will see TSP> when the script finishes logging all of the readings to Initial State.  If you don’t have prompts enabled, you can send print(“DONE”) on the remote interface used to start the data logging and when all readings have been logged. You will have DONE outputted on the remote interface.

How do I stop logging data when I am logging an infinite number of readings?

• You need to abort the script which will stop the scan and trigger model from running.  It will also stop logging readings to Initial State.  Make sure you have all the readings you want logged to Initial State.  Any reading buffer data that hasn’t been sent since logging lags the storing of readings in buffer, will be lost.  However, this is okay since you normally have already captured the data you care about and it has been logged.  If a key data point just happened, then maybe let run for a few more minutes before abort.

Can I set the UTC offset (i.e. timezone) that will be sent to Initial State from the device?

• You can use the remote interface to adjust the UTC timezone offset we apply to our timestamps sent to Initial State. First execute the script to create the function to call to set the offset value. Once you run/execute the script on a remote interface you can send the following command

  • set_utc_timezone_offset(<string value in hours for offset>)

• For example

  • set_utc_timezone_offset("4")

• Parameter needs to be specified as a string and be in hours for offset - the valid range is +/- 15.