0

I am attempting to read data off of a Love Temperature Controller either Model TS2 or TS3. The devices have a 4 wire port on the back that I am attempting to communicate. I have been informed by the manufacturer that this is possible using a proprietary protocol that is supposedly a Modbus protocol. I have received documentation from the manufacturer Dwyer stating the serial configuration, memory map layout, functions implemented, how to set a variable etc. My problem so far is that I have not been able to communicate with the device at all as any attempt to send data to it only results on silence from the device.

I am using a FTDI 5V cable to communicate with the port. I have verified the pins on the device are 5V Vcc, Tx, Rx, and Ground through tracing them with an oscilloscope and multi-meter.

As for software I am currently running Ubuntu 20.04 LTS using Python 3.8.10. I have tried using pyserial, qmodbus, and pymodbus to communicate but everything times out with no response from the device.

The serial configuration parameters are:

  • Baudrate: 9600
  • Start Bit: 1 bit
  • Stop Bits: 2 bits
  • data size: 8 bits
  • parity: None

So for example, using python:

import serial
serial = serial.Serial ("/dev/ttyUSB0", bytesize=8, baudrate=9600, parity=serial.PARITY_NONE, stopbits=2, timeout=1)

It should be possible to communicate with this port as there are two products that use this port. One is discontinued, the TS485 which allows for the controller to be used over RS485, and the other, the TS2-K which is still used as a programming key to read and write configuration data to and from various TS2/TS3 controllers.

I've tried debugging serial communication using the code suggested by the pymodbus documentation but I get the same communication timed out or no response from the device.

I will happily supply more details if needed. Any help would be much appreciated.

user1415699
  • 1
  • If the device does not comply with the [modbus spec](https://modbus.org/docs/Modbus_Application_Protocol_V1_1b3.pdf) then it would be unsurprising that there is no response (and you seem unsure whether its a proprietary protocol or not?). Does the documentation you have include sample packets (i.e. send these bytes and you will get these bytes back)? (if so please add the detail to your question). Note that you might find a command line tool like [mbpoll](https://github.com/epsilonrt/mbpoll)/[modpoll](https://www.modbusdriver.com/modpoll.html) for initial testing. – Brits Jun 28 '22 at 22:36
  • Good description of your situation, but this seems to be a setup or connection problem, rather than a programming question. IOW off topic for this site. Rather than try out different code packages, use a proven product such as a terminal emulation program, e.g. **minicom** on Linux. Compose a message using a binary/hex editor, then send as a file (which should then meet any Modbus timing requirements). Use hex display mode to see if there's any response. – sawdust Jun 28 '22 at 22:39
  • I was informed by the application engineer that sent me the documentation that it is a proprietary protocol but in the documentation that he sent me it says that "The communication protocol of TST is Modbus protocol" so you are correct it sayying that I am unsure if it is true modbus or proprietary. Unfortunately the documentation doesn't have any sample packets. I wish I could get my hands on a programming device so I could sniff some packet data but I don't have such a device. I have tried using minicom and screen to connect to the device but I still received not response from the device. – user1415699 Jun 29 '22 at 17:10
  • Hello, looking at that [configuration key port](https://www.dwyer-inst.com/PDF_files/TS_485_i.pdf) it looks like the port is half-duplex, with one connection for RX and another one for TX, are you connecting +IN to your port's TX, +OUT to your RX and -IN/-OUT to GND? You should also make sure the port works on 5V, the [config key](https://www.dwyer-inst.com/PDF_files/2017/INTL/TS2-K.i.pdf) has a 12V battery, other than the port itself I don't see any reason for that voltage. – Marcos G. Jun 29 '22 at 17:23
  • A [video](https://youtu.be/dPallPa-q3E?t=66) on youtube shows the inside of the key with a microcontroller, a transceiver, and probably a level shifter... – Marcos G. Jun 29 '22 at 17:28
  • I have a 5V FTDI cable and the digital circuitry of the controller is behind a 5V regulator. I've identified the GND pin with is connected to the ground plane connected the the 5V regulator. Next to the GND pin is what I have identified the Rx pin and Tx pin by tracing the wire from the port to the Rx and Tx pins on the ATMEGA32A microprocessor which the controllers uses. The last pin is 5V power (Vcc) which can be used to power the board from the key port. I assume it's 5V logic because the Tx pin always outputs a constant 5V and Rx sits at ~0V so logic HIGH and LOW respectively. – user1415699 Jun 29 '22 at 21:08
  • OK, I see... It might help if you try to see what's running through, other than use a scope I would advise to try and sniff with something like PCAP, take a look at my answer [here](https://stackoverflow.com/questions/58093350/how-can-i-sniff-modbus-rtu-packet-with-vb-code-or-there-are-any-library-for-it), maybe it helps... – Marcos G. Jun 30 '22 at 07:49
  • I would love to try and sniff a packet or two. I have a cheap logic analyser and an oscilloscope that I have been using to try get that data but alas there is zero response from the device. No matter what I throw at it's Rx pin the Tx stays a steady HIGH so there doesn't seem to be anything to sniff at. One option would be to get my hands on the [TS2-K](https://www.dwyer-inst.com/Product/Temperature/Switches/DigitalPanelMount/ModelTS2-K) and then hopefully I could sniff some packets like you suggest. Sadly I don't know if I can get access to one. – user1415699 Jun 30 '22 at 15:48
  • This is a tricky one indeed... I cannot offer much more advice. The only thing that comes to mind is to try different baudrates, stop bits and whatnot but I'm imagining you've already done that. If you have an old computer (or otherwise using a virtual machine) you might want to try to [LoveLink](https://www.dwyer-inst.com/Product/DataLoggers-Recorders/Software/ModelLoveLink-III#software). Page 33 on its [manual](https://www.dwyer-inst.com/PDF_files/lovelink3.pdf) mentions sending an `AT` command, maybe you need to issue some other commands to put the device into uploading/downloading? – Marcos G. Jun 30 '22 at 16:35
  • This really itched my curiosity, I've just install LoveLink on a Windows 7 PC and it seems to work well, there is even a `Find Instrument` screen. I think your device is not included but the ones you can select are `9600/N/8/1` and `9600/E/7/1`... When you come to think of it 2 stop bits is quite uncommon... If you have the time I'd take a look at this LoveLink tool, there might be something useful in it. – Marcos G. Jun 30 '22 at 16:46
  • Thanks I'll see about getting LoveLink working although I will need to setup a VM for it as I am on linux. Before I got some documentation from Dwyer I tried various baud rates/data sizes etc. but still the same problem. Even a slave address would be great to have but I can't find that anywhere. The documentation uses `0XDD` at one point for function `0x03` **Reading n Words Function** so I've been using that hoping it's correct. My other long shot hope it to find the firmware for the device and reverse engineer the comm code or find a way to dump the internal memory of the device. – user1415699 Jun 30 '22 at 18:35
  • Well, you have a lot of work ahead of you, a bit of patience seems to be called for. I can confirm LoveLink works well on Windows 7 32 bit running on a VM with Ubuntu 20.X as host. – Marcos G. Jul 01 '22 at 09:37
  • Obtained a TS2-K. The controller has to be off. Using 9600 8 data bits no parity 1 stop bits. Communication seems modbus-like. Key starts `[ff,ff,70,1a,9d]` and controller responds `[ff,ff,70,00,00,70,02,43,01,00,00,43,5d,b0]`. After key `[00,00,03,00,13,00,13,f7,d9]` response from TS3 `[00,00,03, 26,00,00,00,0f,00, 00, 00, 50, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, ff, 9c, 00, 32, 00, 0a, 00, 00, 00, 00, 00, 00, 00, 00, ff, e8, 00, 00, cf, ad']`. It does this three more times before completing. I can send packets I've sniffed but I cannot calculate the CRC code to send my own. – user1415699 Sep 15 '22 at 18:44
  • Without some documentation it's likely to be pretty difficult to reverse engineer the protocol (it's not modbus) and, even if you can, it sounds like this may only work when the unit is not powered (so may not be much use to you). While it would definitely be *possible* to get this working I'd guess that the cost vs benefit will not stack up... – Brits Sep 16 '22 at 00:14

0 Answers0