07-11-2025 04:39 PM
I'm trying to connect my laptop to the Cascade Summit 12000 Probe Station through a GPIB-USB-HS cable, and I was facing some issues. The intended final setup is as shown below, with "My Laptop" being the CIC:
I have currently disconnected the GPIB cable from the VNA to get that out of the equation when debugging (purely testing the connection between the Probe Station Controller PC and my laptop), so the current setup looks like this:
Now, to get straight to the point, my ibwrt "*idn?" is giving me an error every single time, and I have no clue why. I had no knowledge of the GPIB standard before starting this project, so I can't tell if this is a hardware/software issue/bug, or if I'm incorrectly using the devices and commands.
The commands I'm using on the interactive control for each of the devices are as shown below:
#on my laptop
ibfind gpib0
ibsic
ibrsc 1
ibdev 0 28 0 13 1 0
ibwrt "*idn?"
ibrd 100
#on the cascade probe station controller PC
ibfind gpib0
ibrsc 0
ibpad 28
ibrd 100 #used to debug
Here are some things to note:
07-14-2025 02:18 PM
I have controlled Cascade probers running Nucleus, but have since migrate to their newer Velox software.
The initial setup of the controller in charge settings were complicated for Nucleus. If I remember the prober has option to control instruments directly as CIC, and you need to make changes to setting in the Nucleus software to disable this. It cannot be done thru NIMAX or a software command. Once you make the change in Nucleus, the prober should respond to SCPI commands from a remote laptop. You should see the prober in NIMAX as device listed under your USB-GPIB-HS device when you scan for instruments.
Personally I decided to use the Prober PC to run my code, cutting the need for another computer out of the equation and controlling the prober movement thru DDE commands, and controlling my instruments through GPIB/USB/LAN. One of the reasons was the remote command set was more limited than the set of commands supported by DDE. (This may have been for taking images, or thermal control or turning the microscope light off but there was a show stopper for me that moved me to DDE.)
What language are you planning to code in? I have LabVIEW DDE examples that ran on a Nuclues PC under Windows 2000 then WIndows 7.
07-16-2025 02:54 PM
I'm planning to use either Python or C; below is the (mostly AI-generated) Python code I've been using so far to try and verify the communication.
import ctypes
import time
ERROR_CODES = {
0: "EDVR - System error",
1: "ECIC - Not CIC",
2: "ENOL - No listener",
3: "EADR - Address error",
4: "EARG - Invalid argument",
5: "ESAC - Not system controller",
6: "EABO - I/O aborted (timeout)",
7: "ENEB - No GPIB board",
10: "EOIP - Async I/O in progress",
11: "ECAP - No capability",
14: "EBUS - Bus error",
15: "ESTB - Serial poll status byte lost",
16: "ESRQ - SRQ stuck on",
20: "ETAB - Table problem"
}
# Load the NI-488.2 driver DLL
gpib = ctypes.windll.LoadLibrary("gpib-32.dll")
# Load GPIB status variables from the DLL
ibsta = ctypes.c_short.in_dll(gpib, "ibsta")
iberr = ctypes.c_int.in_dll(gpib, "iberr")
ibcnt = ctypes.c_long.in_dll(gpib, "ibcnt")
# Constants
BOARD_INDEX = 0 # Your controller is on GPIB1
DEVICE_ADDR = 28 # GPIB address of the target machine
TIMEOUT = 17 # 10-second timeout (T10s)
EOT_MODE = 1 # Enable EOI at end-of-transmission
EOS_CHAR = 0 # No EOS character
# Step 1: Clear the bus and become Controller-in-Charge
gpib.ibsic(BOARD_INDEX) # Interface Clear (assert IFC)
time.sleep(0.5) # Optional pause for bus to settle
gpib.ibrsc(BOARD_INDEX, 1) # Request Controller-In-Charge (CIC)
time.sleep(0.5) # Optional pause for bus to settle
if ibsta.value & 0x8000:
print(f"[ERROR] ibrsc failed — iberr = {iberr.value}")
exit(1)
# Step 2: Open connection to device
dev = gpib.ibdev(BOARD_INDEX, DEVICE_ADDR, 0, TIMEOUT, EOT_MODE, EOS_CHAR)
if dev < 0 or ibsta.value & 0x8000:
print(f"[ERROR] ibdev failed — iberr = {iberr.value}")
exit(1)
# Step 3: Send a message
message = "*idn?".encode("ascii")
time.sleep(0.5)
gpib.ibwrt(dev, message, len(message))
if ibsta.value & 0x8000:
err_msg = ERROR_CODES.get(iberr.value, "Unknown error")
print(f"[ERROR] ibwrt failed — iberr = {iberr.value} ({err_msg})")
# Step 4 (optional): Try to read a response
buffer = ctypes.create_string_buffer(100)
gpib.ibrd(dev, buffer, 100)
if ibsta.value & 0x8000:
print(f"[WARN] No response — iberr = {iberr.value}")
else:
reply = buffer.value.decode(errors="ignore")
print(f"[INFO] Received reply: {reply}")
# Step 5: Close connection
gpib.ibonl(dev, 0)
print("[INFO] GPIB session closed.")
The above code always fails during ibwrt or timeout.
I have enabled GPIB communication from the hardware configuration window in Nucleus, following the instructions provided in their communication guidelines. Is this what you meant by changing the settings of Nucleus, or is there another setting I have to alter?
07-18-2025 12:39 PM
Yes, that looks like the right setting to put the prober into the listener state. Did it work? Confirm using NI-MAX. Do you see your USB-GPIB-HS interface? Do you see an instrument listed under that at address 28? (This part has to work before bothering with any code!) If you do see an instrument listed at something like GPIB1::28::INSTR, then try to communicated with it using the "Communicate with Instrument". Once the prober is responding to "*IDN?" then you can try communicating with it through code.
Glancing at the code, a few comments.
- BOARD_INDEX = 0 # Your controller is on GPIB1 --> If board index is actually GPIB1 then set 1, not 0. In NIMAX you will see the USB-GPIB-HS with the proper listing and the instrument string will be GPIB0::28 for index 0 or GPIB1::28 for index 1..
- EOS_CHAR is likely \n, but check the manual. Almost all SCPI compliant instruments use a termination character.
Hope that helps,
Craig
07-21-2025 02:08 PM
I do see the USB-GPIB-HS interface, but there are no instruments listed under that. Scanning for instruments, it says no instruments were found. Below are some notes I wrote attempting to debug the device today.
4. Start the cascade pc -> I try nimax "scan for instruments" on laptop -> "error performing scan for instruments" -> start Nucleus -> "scan for instruments" again on the laptop -> no instruments found -> uncheck "talker/listener" and "response on" in Nucleus Remote Communication settings -> "scan for instruments" again on the laptop -> "error performing scan for instruments" -> ibrsc 0 and ibpad 28 on NIMAX of cascade pc -> I see that cic and atn status is on and does not disappear -> I try to ibrsc 1 and ibsic on the laptop -> still no cic status given -> ibdev errors with ECIC
4.1 (continuing from 4) I restart Nucleus -> I open interactive control on cascade pc and ibfind gpib0, ibwait 0 to check cic status -> the cascade PC is not cic, (which is good) -> I scan for instruments on laptop NI MAX -> "no instruments were found"
07-21-2025 04:28 PM
That's a bit of progress.
You have a USB-GPIB-HS plugged into the prober PC and your laptop?
Your laptop sees the USB-GPIB-HS. What is the board number? Can you plug the VNA (or any other gpib instrument) in and find it as an instrument?
Does NI-MAX on prober PC see the USB-GPIB-HS?
Nucleus needs to be running on prober PC for it to be recognized as an instrument. Basically, Nucleus is a server running in the background that does the prober control once a SCPI command is received. So only try scanning for instruments when its running.
After that, no much I can do to help debug since its been 8yrs since I had a nucleus prober and I only tried the remote control for a few days before moving to DDE and running my control software on the prober PC. But you can call FormFactor, manufacturer of Cascade and get some help and advice. They will likely want to seel you the Velox upgrade, which to be honest is quite nice, but not necessary.
Craig