Page 1 of 1

Possible Bugs in KXCI V9.1?

Posted: September 23rd, 2015, 9:49 am
by ebawolek
We operate three 4200-SCS units, one was recently had a complete chassis refurb (SN0983837). The unit now has Kite version 9.1.

We have a number of legacy GPIB control routines which we operate through Labview. When we attempted to run these routines on the newly rebuilt system, they failed to operate properly. I did some investigating and determined the following:

*) When using the "DR1" in our code to enable the status byte to assert RQS, it appears that KXCI is not setting B6 is the status byte register properly at the conclusion of a measurement (in our case triggered by "ME1").

*) So, I set the condition "DR0" and polled the status byte B0 as a workaround. That seems to provide reliable operation.


*) When reading data back from the system, there appears to be another error - this time with a random characteristic. Specifically, although the system screen reports correct responses, we frequently note that the first, and only the first, character returned on the bus following a read ("DO" with an associated GPIB read) to the PC can be dropped.

When the system shows an output like "N 250.0447E-03,..."
The value which is reported on the PC is " 250.0447E-03,..."

Only the first character is dropped, and randomly. If the "DO" command is repeated with another GPIB read, the error may disappear.

This does not appear to be a bus noise or timing issue, because all other parts of the data transfer are un-corrupted.

Our legacy KITE 7 and 8 machines work fine, so we are stumped.

In the interim, I programmed a workaround by testing the data output following a "DO" command. If the very first character is not one of the valid "N,L,V,X,C,T" we re-send the "DO" and read the data again. In some cases the system may read 3 or 4 times before the data are valid.

Any ideas would be appreciated.

Re: Possible Bugs in KXCI V9.1?

Posted: October 1st, 2015, 8:00 am
by Vince W
There are known problems related to status polling in KXCI in release v9.1:

AR41841 / PR53996
In certain instances, it was possible for a KXCI test to be complete, but still cause an error message when attempting to retrieve data after the test. The error message was “ERROR: Command not valid during test execution. (-980).” When accessing KXCI via Ethernet and calling the SP command (or the Serial Poll status byte command via GPIB) within a loop to determine test complete status, use a 100 ms sleep or wait call with the SP status loop, positioned before the SP call.
Resolution: This issue has been addressed.

PR53996 / PR55475
When controlling the 4200 via KXCI and determining when the test is complete using the Serial Poll for the GPIB Status Byte or the SP command from Ethernet, add a 100 ms delay before each serial poll command.

I'm not sure if this is related to your DR1/DR0 workaround, but will report what you found. Does a 100mS delay before polling help in your situation?

Haven't seen the DO command issue you reported. I will report this as well.

Re: Possible Bugs in KXCI V9.1?

Posted: January 30th, 2017, 1:23 pm
by Vince W
We have verified fixes for the KXCI communication problems described in this post.
AR51327 / PR59035 / PR59037 / PR59038 are internal Keithley references to various forms of this fix:

PR59037 includes the fix in release KTEI V9.1 SP2 for 4200-SCS models (available Feb 6, 2017).

PR59038 includes the fix in release Clarius V1.1 for 4200A-SCS models.

Note that if you send your 4200-SCS or 4200A-SCS in for calibration or repair, we can install a software update by request - be sure to back up your files prior to the upgrade.

As this forum post ages, please watch for newer 4200-SCS and 4200A-SCS downloads at and click the Downloads button on the right edge of the page to create your download search.

Re: Possible Bugs in KXCI V9.1?

Posted: January 31st, 2017, 7:26 am
by ebawolek
FYI to the user community - I tested these fixes and everything works fine on my systems now.