LabVIEW
My GPIB will not control my device.
There exists no Standard Body that can mandate instrument manufacturers to use the IEEE-488.2 standard commands. *IDN? Is such a command, but the fact that HP, Agilent, KeySight, Tektronix, Keithley, R&S and many others are using this standard since the 90ies of last century pretty consistently, does not mean that your device implements that too. You will need a Programmer Reference manual for your device to see what commands it supports.
The reaction you see pretty clearly indicates that it is NOT an IEEE-488.2 conforming device.
This doesn’t mean that you can’t communicate with it, but you need the documentation about its commands it can understand.
It seems impossible to find any manuals online as PDF. Seeing that this device was manufactured somewhere in the first half of the eighties of last century it is not so surprising. Back then you got printed manuals with every such device. Sometimes several of them.
Considering that IEEE 488.2 was only approved by the IEEE board on 1987-06-11 and by ANSI on 1988-02-02 it is absolutely safe to assume that this device does NOT support IEEE 488.2 commands. Your attempt to send it an "*IDN?" query command is therefore doomed to fail.
These are threads about this device here:
https://forums.ni.com/t5/LabVIEW/k-20/m-p/1024157
https://forums.ni.com/t5/LabVIEW/mmr-k20-labview-temperature-reading/td-p/417257
Looking at the VIs in the second post it gets even more obvious that this device does not support any IEEE 488.2 or SCPI commands but has its own fairly crude set of commands.
DEx Reset device
SR 100x Set Resistance to 100 Ohm
TEx Query for temperature
SK ###.##x Set Temperature
WKx Query setpoint temperature
POx Query Power value
That's all there is in the VI on commands. Possibly the manual would explain more commands.
What seems obvious:
Every command is supposed to be terminated with a lower case x
There is no specific indication that a command is going to return a response. It is implicit from the command.
To make matters even more interesting, up into mid 90ies of the last century GPIB devices tended to be rather particular in how they needed to be operated in terms of message termination, signaling and other low level GPIB parameters that you had to properly select in for the GPIB session in question. IEEE 488.2 was supposed to make that all much more standardized too, but it took until about 1995 until most (definitely not all) manufacturers were more or less developing new devices to that standard. Old models were almost never reworked with new firmware to be more convenient to use. If anything you could buy a newer, shinier, more capable device instead!
The best bet for a command to try to get an identification string back might be something like IDx. This is however a wild guess, seeing the logic of the few device commands mentioned above it could also by anything else, except that the command almost certainly is terminated with a lower case x. Of course it could also be that they did not implement any device identification query. Those microcontrollers back then were very restricted, memory was scarce including the ROM space for the firmware, so not implementing an extra command for some "unneeded" feature could make all the difference of being able to fit the firmware in the existing ROM or not. But only the manual can really tell you if it did.
