Bench PSU remote control application for TTi PL-P series   (Win/Linux/Mac) - Page 1
Forum section: electronics / testgear

author: voltsandjolts
author_rank: Unknown
timestamp: January 17, 2017, 07:57:43 pm
content: 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 prettyForum 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:04FEB17Moved python file tohttps://github.com/kevinee/tti-plp-remote

author: jc101
author_rank: Frequent Contributor
timestamp: January 17, 2017, 10:19:54 pm
content: This is interesting as I have recently bought a MX180TP, with some tweaking I think that may well work on that too....

author: voltsandjolts
author_rank: Unknown
timestamp: January 17, 2017, 10:38:39 pm
content: 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 failsThe 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-mxserieshttps://www.eevblog.com/forum/testgear/tti-mx100tp-triple-power-supply-teardown-and-review/

author: jc101
author_rank: Frequent Contributor
timestamp: January 17, 2017, 11:00:44 pm
content: 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...

author: voltsandjolts
author_rank: Unknown
timestamp: January 18, 2017, 08:57:03 am
content: For command line scripts (no gui) all you need is the class "ttiPsu()" which you can use like this:Code:#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()

author: voltsandjolts
author_rank: Unknown
timestamp: January 27, 2017, 10:48:39 pm
content: 27JAN17 Minor updateadded 3rd channel (untested)better entry validationset maximum allowed volts/amps settings at top of python file (helps keep the magic smoke in)See first post for python file.

author: Simon
author_rank: Unknown
timestamp: April 27, 2017, 04:45:16 pm
content: Not tried it yet but very nice idea. Any way to control multiple supplies and have further controls ?

author: voltsandjolts
author_rank: Unknown
timestamp: April 27, 2017, 05:13:57 pm
content: 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.

author: Simon
author_rank: Unknown
timestamp: April 28, 2017, 12:19:55 pm
content: 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.

author: Svenito
author_rank: Newbie
timestamp: December 05, 2017, 02:23:39 pm
content: 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.

author: lundmar
author_rank: Frequent Contributor
timestamp: December 05, 2017, 02:54:09 pm
content: Quote from: Svenito on December 05, 2017, 02:23:39 pmTo 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:$ lxi benchmark --address 10.42.1.20Benchmarking by sending 100 ID requests. Please wait...Result: 24.7 requests/secondBy 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.

author: jc101
author_rank: Frequent Contributor
timestamp: December 05, 2017, 03:30:05 pm
content: 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.

author: Svenito
author_rank: Newbie
timestamp: December 11, 2017, 10:55:46 am
content: 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.@jc101Maybe 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.

author: lundmar
author_rank: Frequent Contributor
timestamp: December 11, 2017, 12:23:04 pm
content: Quote from: Svenito on December 11, 2017, 10:55:46 amProgramming 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:lxi benchmark --address <ip>Rigol DS1104Z:~25 requests/sSiglent SDS1204X-E:~340 requests/sClearly, 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

author: Neomys Sapiens
author_rank: Super Contributor
timestamp: December 11, 2017, 11:02:09 pm
content: Does it work with the CPX400DP? That would be nice!

author: jc101
author_rank: Frequent Contributor
timestamp: December 14, 2017, 03:58:13 pm
content: Oddly I try the lxi benchmark against my MX180TP and all I get back is the error below.Error: Failed to receive instrument IDThis is a virtual Linux box mind, although it can ping and get into the webpage of the MX180TP.

author: lundmar
author_rank: Frequent Contributor
timestamp: December 14, 2017, 04:22:22 pm
content: Quote from: jc101 on December 14, 2017, 03:58:13 pmThe 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?

author: jc101
author_rank: Frequent Contributor
timestamp: December 14, 2017, 04:28:36 pm
content: Quote from: lundmar on December 14, 2017, 04:22:22 pmFirewalls 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.

author: lundmar
author_rank: Frequent Contributor
timestamp: December 14, 2017, 04:35:27 pm
content: Quote from: jc101 on December 14, 2017, 04:28:36 pmVM 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:lxi scpi --address <ip> "*IDN?"

author: jc101
author_rank: Frequent Contributor
timestamp: December 15, 2017, 10:17:32 am
content: 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:LXI Extended Functions NoneLXI Version 1.4 LXI Core 2011

author: jc101
author_rank: Frequent Contributor
timestamp: December 15, 2017, 10:25:52 am
content: 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 thewww.lxistandard.orgwebsite though...

author: lundmar
author_rank: Frequent Contributor
timestamp: December 15, 2017, 01:59:43 pm
content: Quote from: jc101 on December 15, 2017, 10:17:32 amHmm, 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:QuoteSo 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 (seehttp://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:$ 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 standardFinally, 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:$ lxi discover --mdnsIt might find the instrument but considering how TTi diverge from the standards I wouldn't be surprised if that does not work either.

author: jc101
author_rank: Frequent Contributor
timestamp: December 15, 2017, 02:23:00 pm
content: 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:$ 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.

author: lundmar
author_rank: Frequent Contributor
timestamp: December 15, 2017, 02:56:16 pm
content: Quote from: jc101 on December 15, 2017, 02:23:00 pmYeah, 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.

author: lundmar
author_rank: Frequent Contributor
timestamp: December 16, 2017, 04:14:49 pm
content: Quote from: jc101 on December 15, 2017, 02:23:00 pmThe 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:$ lxi benchmark --address 10.0.0.56 --port 9221 --rawBenchmarking by sending 100 ID requests. Please wait...Result: 157.9 requests/secondEventually, 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.

author: jc101
author_rank: Frequent Contributor
timestamp: December 18, 2017, 03:49:26 pm
content: Well with the lxi benchmark tool (updated to 1.15) it seems the MX180TP is quite nippy...Code:lxi benchmark --address a.b.c.d --port 9221 --rawBenchmarking by sending 100 ID requests. Please wait...Result: 358.4 requests/secondFor actual time to change to a command I think I'd need to try and work something out over serial though.

author: lundmar
author_rank: Frequent Contributor
timestamp: December 18, 2017, 05:57:35 pm
content: Quote from: jc101 on December 18, 2017, 03:49:26 pmNot bad at all. I would think you should have enough room for implementing a poor mans data logger by remote polling voltage and amp readings at maybe 100 Hz, provided the measurement operations do not add significant delays.

author: lundmar
author_rank: Frequent Contributor
timestamp: December 19, 2017, 09:04:51 pm
content: Quote from: jc101 on December 15, 2017, 10:25:52 amBesides VXI-11 and mDNS there is a 3rd way to retrieve the instrument ID and that is by retrieving an XML file hosted by the instrument via http.Can you please try visit the following page of your TTi instrument:http://<instrument ip>/lxi/identificationIf you see an XML file here it is working and I can implement a way for lxi discover to find and resolve it.Thanks.

author: jc101
author_rank: Frequent Contributor
timestamp: December 20, 2017, 09:48:05 am
content: Quote from: lundmar on December 19, 2017, 09:04:51 pmYes, I do get an xml file back.Code:<LXIDevice xmlns="http://www.lxistandard.org/InstrumentIdentification/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.lxistandard.org/InstrumentIdentification/1.0 http://x.x.x.x/LXIIdentification.xsd"><Manufacturer>THURLBY THANDAR</Manufacturer><Model>MX180TP</Model><SerialNumber>000000</SerialNumber><FirmwareRevision>1.02-1.00-1.03</FirmwareRevision><ManufacturerDescription>375W Multi Range Triple Output PSU</ManufacturerDescription><HomepageURL>http://www.aimtti.com/go/lanxi</HomepageURL><DriverURL>http://www.aimtti.com/go/lanxi</DriverURL><UserDescription>THURLBY THANDAR-MX180TP-000000</UserDescription><IdentificationURL>http://t000000.local/lxi/identification</IdentificationURL><Interface xsi:type="NetworkInformation" InterfaceType="LXI" IPType="IPv4" InterfaceName="eth0"><InstrumentAddressString>TCPIP::x.x.x.x::9221::SOCKET</InstrumentAddressString><Hostname>x.x.x.x</Hostname><IPAddress>x.x.x.x</IPAddress><SubnetMask>255.255.255.0</SubnetMask><MACAddress>80:E4:DA:22:23:16</MACAddress><Gateway>x.x.x.x</Gateway><DHCPEnabled>true</DHCPEnabled><AutoIPEnabled>true</AutoIPEnabled></Interface><Interface InterfaceType="" InterfaceName=""><InstrumentAddressString>x.x.x.x:9221</InstrumentAddressString></Interface><Domain>1</Domain><LXIVersion>1.4</LXIVersion></LXIDevice>

author: lundmar
author_rank: Frequent Contributor
timestamp: December 20, 2017, 11:03:17 am
content: Quote from: jc101 on December 20, 2017, 09:48:05 amGreat thanks - it is a bit convoluted but I can make it work. I'll implement it as a fallback solution to retrieving the ID in case retrieving ID via VXI-11 fails. I'll get back to you once its ready to be tested.

author: lundmar
author_rank: Frequent Contributor
timestamp: December 21, 2017, 04:37:21 pm
content: Quote from: lundmar on December 19, 2017, 09:04:51 pmIf you feel brave, the latest snap on the edge channel includes the new HTTP/XML ID fallback implementation for discovery. It has been partially tested with my Rigol scope. It should discover your device but if it does not work perhaps we should move any continued debug discussions to the lxi-tools thread. Thanks.