Why Does Keithley 2700 Serial Communication Return No Data?

The panel shows a framing error when the VISA application requests data. In the second failure mode, commands appear to reach the instrument, but the VISA byte count remains zero after *IDN? or READ?. Treat these as two checkpoints: first prove the serial framing, then prove the query-and-read sequence.

Start with the panel indication

Start here. A framing error occurs while the serial receiver is assembling characters. The instrument has not yet reached SCPI command execution, so changing measurement commands is wasted effort at this branch.

The working IVI driver is your control test. It proves that a viable instrument, cable, interface, and configuration combination exists. It does not prove that the new VISA session uses the same framing, flow control, termination, timeout, or read behavior.

Match every serial framing field

Read the active serial configuration from the instrument and the working IVI session. Then compare it with the VISA resource settings field by field. Do not compare only the baud rate.

1. Read the configured baud rate at both ends. A mismatch changes the sampling position within each character and commonly raises a framing indication.

2. Compare data bits, parity, and stop bits. One different field is enough to corrupt a command even when the cable and port open normally.

3. Compare flow control. A flow-control mismatch can leave the transmitter waiting or prevent a response from reaching the application.

4. Verify that the VISA application opened the intended serial resource. An open operation only proves that the operating system granted access; it does not prove that the selected port reaches the instrument.

If the panel still reports a framing error, stay at this checkpoint. Do not tune READ?, trace setup, or LabVIEW buffer handling yet. If the error disappears, move to command termination.

Prove that one complete command reaches the parser

A serial write can complete at the PC while the instrument still waits for the end of the command. Append the same termination character or sequence used by the working IVI session. Configure write termination explicitly instead of relying on a driver default.

1. Open a fresh VISA session with the matched framing and flow-control settings.

2. Clear stale application-side receive data using the normal VISA session operation.

3. Write *IDN? with the required command terminator.

4. Perform a VISA read immediately after the write. Do not use the pre-read byte count as the only condition for deciding whether to read.

If the framing error returns during the write, go back to the serial fields. If the panel remains clear but no response arrives, inspect read termination, timeout handling, flow control, and query sequencing next.

Interpret an empty receive buffer correctly

A zero byte count is an observation, not a root cause. It says that no bytes were available to the application at the instant it checked. It does not distinguish between an unexecuted query, an instrument that has not completed the operation, a response blocked by handshaking, and a read configured around the wrong termination behavior.

Use a blocking VISA read with an intentional timeout path. The read should finish when it receives the configured response terminator, reaches the requested byte count, or times out. Record which condition ended it.

1. If data arrives, log the exact returned bytes and termination characters. The transport path works.

2. If the read times out with no bytes, repeat *IDN? through the working IVI path and compare every session attribute that affects serial transmission and reads.

3. If partial data arrives but the read times out, correct the read-termination configuration or read-length strategy.

4. If writes stall or never leave the PC, correct the flow-control configuration before changing SCPI commands.

An empty instrument error queue does not clear the serial layer. A framing fault happens before a valid command reaches the SCPI parser, so the parser may have no command error to report.

Separate communication tests from measurement tests

Use *IDN? as the first query because it isolates the command-and-response path from measurement and trace configuration. When that query returns correctly, stop changing the serial port. The remaining fault belongs to command setup, trigger state, measurement completion, or the selected data source.

Test the measurement commands in increasing order of dependency:

1. Send *IDN?. A valid response proves bidirectional communication and the basic write/read sequence.

2. Apply the required measurement setup, using the working example sequence as the reference.

3. Send READ? and perform the read. If identification works but this query does not, inspect the configured measurement and trigger state.

4. Use :Trace:Data? only after configuring the trace and completing the operations needed to place data in it. This query can fail when its prerequisite setup is incomplete even though serial communication is healthy.

Do not use the most configuration-dependent query as the port test. It mixes a transport diagnosis with instrument-state diagnosis and sends you back to settings that may already be correct.

Apply the fix and verify both paths

1. Copy the baud rate, data bits, parity, stop bits, flow control, write termination, read termination, and timeout behavior from the working IVI session into the VISA implementation.

2. Close any competing session, then reopen the VISA resource so the intended attributes take effect from a clean connection.

3. Send one terminated *IDN? query and execute one read. Confirm that the panel remains free of framing errors and that the response is nonempty.

4. Repeat the query several times using the same write/read transaction. Confirm that each query produces one complete response without leftover bytes entering the next transaction.

5. Apply the measurement setup and test READ?. Check the instrument state if identification continues to work but measurement data does not.

6. Configure and populate the trace before testing :Trace:Data?. Treat a failure here as a setup-sequence problem unless the earlier identification test also fails.

The resolving branch has three pass conditions: no panel framing indication, a nonempty response to *IDN?, and repeatable one-query/one-response alignment. Only then move the driver into measurement and trace operations.

FAQ