Bench PSU remote control application for TTi PL-P series (Win/Linux/Mac)

[voltsandjolts]

I have access to some of the new style TTi PL series power supplies with the -P ethernet option, mostly PL303QMD-P.
I like them but strangely the web interface doesn't provide a user interface for controlling the psu other than a simplistic 'send LXI command' 

The attached python program controls the PSU over the ethernet interface but could easily be adapted to the USB interface if required (same commands, different transport).
Written with the intention of being small (no bloated VISA etc.) and minimal dependencies - just needs python3.
It's functional but not pretty 

Forum doesn't allow '.py' extension so renamed with '.txt' extension, just remove that.
You can change the default IP address easily enough, its at the top of the python file.

Edit: 27JAN17 Minor update, added 3rd channel (untested), better entry validation, set maximum allowed volts/amps settings at top of python file (helps keep the magic smoke in)

Edit: 04FEB17 Moved python file to https://github.com/kevinee/tti-plp-remote

[jc101]

This is interesting as I have recently bought a MX180TP, with some tweaking I think that may well work on that too....

[voltsandjolts]

Nice PSU.
Looks like the same command set and port (9221) so I think it should work without any mods at all - although I have only put the option for two channels, I could add a third easy enough.

[Edit: Ahh, some commands are different, there is no IRange but has a VRange. So will need some changes to work with MX series.]

I needed this when we had some kit on test at client location, just used LogMeIn to get remote PC access and controlled the psu from there. Useful for reboot when firmware fails 

The TTi webpage for your PSU links to a review of it here on the EEVBlog forum!
http://www.aimtti.com/product-category/dc-power-supplies/aim-mxseries
https://www.eevblog.com/forum/testgear/tti-mx100tp-triple-power-supply-teardown-and-review/

[jc101]

I like the MX180TP, it is also beautifully quiet as I'm next to it most of the day. 
I read the MX100 review when looking around for a new PSU, that led me to the 180, handy for higher power ranges.  The 180 is much the same as the 100, internally they are not much different as far as I can tell.  Just a different main power board it seems.

I mainly use the interfaces as part of scripted testing of products, and it's interesting how you avoid using pyVISA, which can be a bit of a pain, I'll take a closer look at that...

[voltsandjolts]

For command line scripts (no gui) all you need is the class "ttiPsu()" which you can use like this:

Code: [Select]

#Example usage:
tti = ttiPsu('192.168.128.30', channel=2)
print(tti.getIdent())
print('Output: {0:2.2f} V'.format(tti.getOutputVolts()))
print('Output: {0:2.2f} A'.format(tti.getOutputAmps()))
print('OverV: {0:2.2f} V'.format(tti.getOverVolts()))
print('OverI: {0:2.2f} A'.format(tti.getOverAmps()))
print('Config: {}'.format(tti.getConfig()))
print('isEnabled: {}'.format(tti.getOutputIsEnabled()))
print('AmpRange: {}'.format(tti.getAmpRange()))
print('TargetV: {0:2.2f} V'.format(tti.getTargetVolts()))
print('TargetI: {0:2.2f} A'.format(tti.getTargetAmps()))

tti.setTargetVolts(3.14)
tti.setTargetAmps(1.234)
tti.setOutputEnable(True)
tti.setAmpRangeHigh()
tti.setLocal()


[voltsandjolts]

27JAN17 Minor update
added 3rd channel (untested)
better entry validation
set maximum allowed volts/amps settings at top of python file (helps keep the magic smoke in)

See first post for python file.

[Simon]

Not tried it yet but very nice idea. Any way to control multiple supplies and have further controls ?

[voltsandjolts]

To control multiple supplies just run multiple copies of the program.
The python code is open source to allow new features. Error handling could be improved too but it does all I need for now.

[Simon]

Yes well thank you for your efforts, I'll have to learn python in able to modufy it. I was just asking as it is not uncommon to use more than one supply in parallel, with the power of LXI you could get total currents etc.

[Svenito]

Sorry for waking a sleeping beauty, but I figured I could find competent help under this topic, since you guys used the remote control feature of some TTi devices.
My concerns are about the programming performance of the TTi MX100TP. Is it really as slow as the datasheet says (<120ms until the Output starts changing)?
Currently I'm favoring the MX100TP in evaluating several power supplies for my company. But this could really be a deal breaker as other power supplies offer much lower programming delays (even from TTi) or even have a built-in arbitrary wave form generator.

[lundmar]

Sorry for waking a sleeping beauty, but I figured I could find competent help under this topic, since you guys used the remote control feature of some TTi devices.
My concerns are about the programming performance of the TTi MX100TP. Is it really as slow as the datasheet says (<120ms until the Output starts changing)?
Currently I'm favoring the MX100TP in evaluating several power supplies for my company. But this could really be a deal breaker as other power supplies offer much lower programming delays (even from TTi) or even have a built-in arbitrary wave form generator.

To evaluate the minimum amount of requests that your instrument can perform per second you could give lxi-tools a try (http://lxi-tools.github.io) - it includes a simple but useful benchmark feature:

Code: [Select]

$ lxi benchmark --address 10.42.1.20
Benchmarking by sending 100 ID requests. Please wait...
Result: 24.7 requests/second

By the way, does the TTi power supplies still include an extraordinary noisy fan?

Some years ago I played with one and I absolutely hated it because of its noisy fan and non-intelligent fan control. Everything else is good though.

[jc101]

As I have an MX180P here I can give it a try, but I'll need to wire up a serial cable to control it with, then I can just use the scope to decode the command and see how long before it responds.  Not easy to do over ethernet.

How much of a problem does the delay actually cause in day to day use?

And the fan is nice an quiet in mine, I sit next to it all day.

[Svenito]

I'm less concerned about the actual delay than about the maximum frequency at which i can give new commands. If I can give only around 6 commands per second, I am limited in the shape of the waveform i can achieve.
I am currently comparing the MX100TP with the HMC8043 which has a function called EasyArb. I allows you to define up to 512 steps  in a custom arbitrary waveform, which can be as close as 10ms. Thats the reason I'm asking about programming speed.

@jc101
Maybe you could perform the test lundmar is proposing. I think it would show what I'm really looking for.
Nevertheless, the actual delay is also of some importance. For example in a measurement application, where you want to react on something received by RS232 by triggering a voltage change. If you add up the delays on all stages (RS232toUSB adapter --> custom measurement software on PC --> MX100TP) you could end up with pretty long reaction time.

[lundmar]

I'm less concerned about the actual delay than about the maximum frequency at which i can give new commands. If I can give only around 6 commands per second, I am limited in the shape of the waveform i can achieve.
I am currently comparing the MX100TP with the HMC8043 which has a function called EasyArb. I allows you to define up to 512 steps  in a custom arbitrary waveform, which can be as close as 10ms. Thats the reason I'm asking about programming speed.

@jc101
Maybe you could perform the test lundmar is proposing. I think it would show what I'm really looking for.
Nevertheless, the actual delay is also of some importance. For example in a measurement application, where you want to react on something received by RS232 by triggering a voltage change. If you add up the delays on all stages (RS232toUSB adapter --> custom measurement software on PC --> MX100TP) you could end up with pretty long reaction time.

Programming speed is important, especially if one wants to create a "poor mans data logger" by periodically polling measurements remotely from a PC. The programming speed of various instruments can vary quite a bit. That's why I've added the benchmark feature to lxi-tools so it is possible to get some sort of metric representing the programming performance which can be used to evaluate or compare instruments.

A recent and interesting benchmark example involves the following highly popular instruments:

Code: [Select]

lxi benchmark --address <ip>

Rigol DS1104Z:	~25 requests/s
Siglent SDS1204X-E:	~340 requests/s

Clearly, only the Siglent instrument makes it possible to sample data remotely at e.g. 100Hz or more. The benchmark results are worth considering when buying a new instrument.

http://lxi-tools.github.io

[Neomys Sapiens]

Does it work with the CPX400DP? That would be nice!

[jc101]

Oddly I try the lxi benchmark against my MX180TP and all I get back is the error below.

Error: Failed to receive instrument ID

This is a virtual Linux box mind, although it can ping and get into the webpage of the MX180TP.

[lundmar]

Oddly I try the lxi benchmark against my MX180TP and all I get back is the error below.

Error: Failed to receive instrument ID

This is a virtual Linux box mind, although it can ping and get into the webpage of the MX180TP.

The benchmark relies on the "*IDN?" command working for the instrument. Also the instrument must speak standard VXI-11 protocol (as defined by LXI standard).

You might also want to make sure that the ethernet adapter of your VM is of bridged type (not NAT).

I'm curious, does the "lxi discover" command find your TTi instrument?

[jc101]

Oddly I try the lxi benchmark against my MX180TP and all I get back is the error below.

Error: Failed to receive instrument ID

This is a virtual Linux box mind, although it can ping and get into the webpage of the MX180TP.

The benchmark relies on the "*IDN?" working for the instrument. Also the instrument must speak standard VXI-11 protocol (as defined by LXI standard).

You might also want to make sure that the ethernet adapter of your VM is of bridged type (not NAT).

I'm curious, does the "lxi discover" command find your TTi instrument?

Firewalls was the first thing I checked, turned everything off and it is bridged.  I talk to it all the time in Python so the *IDN? works for sure, and no the discover didn't see it.

I'll look at installing the lxi tools on my Mac, it's just I had a linux VM open so thought I'd give it a go while I remembered.  I will try and remember to give it another go tomorrow.

[lundmar]

Firewalls was the first thing I checked, turned everything off and it is bridged.  I talk to it all the time in Python so the *IDN? works for sure, and no the discover didn't see it.

I'll look at installing the lxi tools on my Mac, it's just I had a linux VM open so thought I'd give it a go while I remembered.  I will try and remember to give it another go tomorrow.

VM is a good and flexible choice. The VM shouldn't prevent lxi-tools from working as long as it does not in any way restrict the network. It sounds like you are on top of that so I'm thinking the issue must be elsewhere.

It would be nice to get lxi-tools working with the TTI instruments.

Could you try this command?

Code: [Select]

lxi scpi --address <ip> "*IDN?"


[jc101]

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...

Code: [Select]

LXI Extended Functions   None
LXI Version              1.4 LXI Core 2011


[jc101]

The lxi discovery only sees the 34465A too, although I can see both the 34465A and the MX180TP if I use the LXI Discovery tool from the www.lxistandard.org website though...

[lundmar]

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...

Code: [Select]

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:

Code: [Select]

$ 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:

Code: [Select]

$ 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.

[jc101]

Thats interesting, it would be good to pass these observations on. They are just down the road from me, and I did get software fix for an mDns issue so I know that won't work, as the updated code ignored these.  This version is now on the website.

The command below does indeed elicit a response as expected.

Code: [Select]

$ lxi scpi --address 1.2.3.4 --raw --raw-port 9221 "*IDN?"
The benchmark command doesn't support a different port, so I can't try that.

In the connection table on the web interface it shows listeners on ports 80, 111, 1024, and 9221 and there is no option anywhere to alter the port used.

It might be quirky but I really like the unit, it's quiet, accurate, and can handle everything I've asked of it.

[lundmar]

Thats interesting, it would be good to pass these observations on. They are just down the road from me, and I did get software fix for an mDns issue so I know that won't work, as the updated code ignored these.  This version is now on the website.

The command below does indeed elicit a response as expected.

Code: [Select]

$ lxi scpi --address 1.2.3.4 --raw --raw-port 9221 "*IDN?"
The benchmark command doesn't support a different port, so I can't try that.

In the connection table on the web interface it shows listeners on ports 80, 111, 1024, and 9221 and there is no option anywhere to alter the port used.

It might be quirky but I really like the unit, it's quiet, accurate, and can handle everything I've asked of it.

Yeah, I like their units too and their pricing is fair. It's just a shame they don't take the last steps to fully adhere to the standards - I mean, it's seems like such a small thing to do and it is important for functionality. Perhaps we can try convince TTi to provide a firmware update that complies more with the standards.

That being said, for both the scpi and benchmark sub commands I can introduce a port option so that it is possible to use VXI-11 on non standard ports. However, for the discover subcommand I'm not keen on going down the road of probing all sort of non-standards ports because that will effectively make it a port scanner and I don't want users to unwillingly trigger attack alerts in case they run this tool in a professionally managed network environment.

Also, I can make the lxi discover feature find the TTi instrument but it will just be listed as "Unknown" ID.

[lundmar]

The benchmark command doesn't support a different port, so I can't try that.

The latest lxi-tools snap from the edge channel now supports using raw/TCP in benchmark mode:

This means you can now do something like:

Code: [Select]

$ lxi benchmark --address 10.0.0.56 --port 9221 --raw
Benchmarking by sending 100 ID requests. Please wait...
Result: 157.9 requests/second

Eventually, it will also be possible to change the port for normal VXI-11 operation but for now you can only change the port in combination with --raw.

Actually, the VXI-11 implementation in use makes it quite hard to reconfigure the VXI-11 port different from the standard RPC port 111 and for good reason.

Also, I've found out that even though the TTi device responds on port 111 making it possible to detect and list it as "Uknown device" during discovery it is not really a practical solution because in most systems you already have one or more RPC port mapper services listening on port 111. This means one would typically get one or more "Unknown device" listings for each network being searched. So, I've decided to keep the discovery feature as it is, adhering to the standards. It will only confuse users to get a long listing of unknown devices, some which might be an instrument but most will just be generic RPC port mapper services.

My best advice for TTi is to stop violating the standards and start using standard ports. Anything else is in direct violation.