Well the lxi works fine against by 34465A with a result of 30.7, but no go with the MX180TP.
Looking at it's webpage it reports this if it help diagnose the problem...
LXI Extended Functions None
LXI Version 1.4 LXI Core 2011
Hmm, what an odd instrument the MX180TP is. According to the documentation it implements bits and pieces of the LXI standard but in key areas they diverge from the standard.
For example, the MX180TP documentation states:
The instrument has very limited support of VXI-11 which is sufficient for the discovery protocol
and no more.
It implements a Sun RPC Port-mapper on TCP port 111 and UDP port 111 as defined in
RFC1183. The calls supported are:
NULL, GET PORT and DUMP.
On TCP port 1024 a very simple VXI-11 protocol is implemented, sufficient only for instrument
discovery. This implements the following calls:
CREATE LINK, DEVICE_WRITE, DEVICE_READ and DESTROY_LINK.
Once a link has been created anything written to the device is ignored and any attempt to read
from the device returns the same identification string as the *IDN? query.
So they have a limited VXI-11 protocol implementation, which is perfectly fine. However, then they choose to offer it on port 1024 and that is just silly. They should stick to port 111 as dictated by the VXI-11 standard.
This is why the lxi discover feature does not show the instrument - it can't resolve the instrument ID because it does not use standard ports (see
http://www.lxistandard.org/About/LXI-Protocols.aspx)
Also, to compensate for the partial/limited VXI-11 implementation the instrument offers a raw TCP socket (SCPI-RAW) service which is perfectly acceptable and within the LXI standard. However, again TTi fails to place the service on the suggested standard port of 5025 and instead they have placed it on port 9221.
This means you should be able to send SCPI commands using the lxi tool like so:
$ lxi scpi --raw --raw-port 9221 "*IDN?"
I have no idea why TTi choose to not use standard ports - it seems very silly to me. I mean, they almost got everything right but because of these minor details it is out of reach of LXI/VXI discovery tools that adhere to the standards. Ultimately I could of course make the tool check on these non-standard ports but then the lxi discover feature could fast become a port scanner and that is not the intention of the tool nor the standard
Finally, it is not mentioned in the documentation, but there is a small chance that the instrument supports mDNS discovery (the next gen discovery protocotol). You can test this by doing:
$ lxi discover --mdns
It might find the instrument but considering how TTi diverge from the standards I wouldn't be surprised if that does not work either.