Serial RS485 / RS232 communication with TDK-Lambda ZUP very slow only in Linux

[LastStarDust]

In our experiment, we use many ZUP power supplies to power up the electronics. The exact models are TDK-Lambda ZUP80-2.5 and ZUP6-33. They are remotely controlled and monitored by a server running Linux.

The problem is that the serial communication is very slow. By slow I mean that the ZUP baud rate can be set between 300 and 9600. To communicate (almost) reliably with the PSU I have to set the baud rate to the minimum 300 bps.

At first, I was suspecting a hardware or wiring issue but nothing seemed to improve the situation. Then I tested the PSU with the official proprietary Windows application (using the very same hardware setup) and I could communicate at 9600 baud rate without problems. So the problem lies undoubtedly in the Linux driver or in my code.

The ZUP can communicate with the PC using RS232 or RS485. I tried them both with the same results. I tried to use a cheap RS485-USB adapter, the RS232 serial port of a desktop PC and a professional-grade PCIe RS485 card, all without success.

As a programming language, I am using Python. I tried to use pyvisapy and a scientific software called Pyrame that essentially provides a wrapper around the serial Python module.

Here is a minimal example to show how I am accessing the unit in pyvisapy:

#!/usr/bin/env python2
# -*- coding: utf-8 -*-

import visa
from visa import constants
rm = visa.ResourceManager('@py')
inst = rm.open_resource('ASRL/dev/ttyUSB0::INSTR')
inst.baud_rate = 9600 # 300
inst.write_termination = ''
inst.read_termination = '\r\n'
inst.set_visa_attribute(constants.VI_ATTR_ASRL_FLOW_CNTRL, constants.VI_ASRL_FLOW_XON_XOFF)
inst.stop_bits = constants.StopBits.one
inst.parity = constants.Parity.none
inst.data_bits = 8

print(inst.write(":ADR01;"))
print(inst.write(":REV?;"))
print(inst.read())

In Linux, the above code works with 300 bps but not with 9600 bps (the situation get worse and worse gradually as I increase the baud rate). Even with 300 bps, sometimes I get some timeout or data corruption errors when sending or receiving long commands.

PS our DAQ runs only in Linux so using Windows is not an option.

[MatthieuDartiailh]

Not sure what can be causing this issue. If you can post some analysis of the packet in the working and non working version that would be great. Keysight provide a VISA implementation on Linux, that may provide better performances. Let me know if you can make it work.

[LastStarDust]

Hi Matthieu. Thank you for your feedback and sorry if it took some time to answer.

I think the source of the problem is pyserial itself. I have tried to communicate with the power supply using minicom (in Linux) and I can set the baudrate to the max. I was told that pyserial might have some issues with software flow control but I am not sure if that is really the cause of my problem.

Then I tried to use this python module called arduino-serial that does not depend on pyserial and I could set the baud rate to the max as well.

You asked for some analysis of the packets. I have run this serial sniffer when I run the TDK-Lambda proprietary application in Windows. You can download the output from here

In linux this is the output of jpnevulator when running the python script.

jpnevulator --ascii --timing-print --byte-count --tty /dev/ttyCom0 --read
2019-10-26 19:09:27.857848:
56 65 72 20 38 30 2D 32 2E 35 20 31 2E 30 0D 0A Ver 80-2.5 1.0..

If you need further info do not hesitate to ask. It may take some time but I will answer.

[Phillip-Smelt]

Hi,

I had similar issues with 9600 Baud until I discovered Paragraph 5.6.1 from TDK-Lambda's Zup User Manual https://product.tdk.com/en/system/files?file=dam/doc/product/power/switching-power/prg-power/instruction_manual/zup-user-manual.pdf

There's a Python library for Zup control at https://github.com/Amphenol-Borisch-Technologies/Zup-Python-Library

Look at class Zup's _write_command() method.

Per Zup Manual, paragraph 5.6.1:

• 10mSec minimum delay is required before sending ADR command.
• 15mSec average command processing time for the Zup Series.
• 30mSec delay required after sending ADR command.

[LastStarDust]

Dear Phillip, thank you so much for pointing that out. I had read the manual but I missed that bit of information. If I had realized that two years ago, it would have saved me a lot of time. But I will keep it in mind for the future. I eventually gave up on using Python and developed a C++ library from scratch. I am not sure how but the problem was mitigated. Cheers

[LastStarDust]

I noticed that you are the developer of that Python library. Thank you so much for releasing it to the public. I might use it in future projects.