RS-232 16Bit Word ? (Serial bit composition question)

[Amper]

Hi,
im working on a Turbopump i scored for pretty low money off ebay. Its a Leybold TW290 that is a cartridge for mass spectrometers. The motor controller is included and i only need to interface it. It supports RS232 and RS485. With the manufacturers software and a direct usb- 232 converter i can read and write parameters as its supposed to work.  Though i want to be able to build a stand alone device for control without a computer.

The Problem im having is that even though there is a detailed manual for the communications protocol i cant get it to respond to anything by sending things over serial terminal.
I suspect that the reason is that the control words are supposed to be 16Bit and something is wrong with the other bits in the stream.

Can anyone with some more experience tell me what else i could try? Will i even get a binary "0000100 00000001" by sending Hex "0401" ? or do i need to bitbang something in the microcontroller to achieve what the pump is expecting?

There is a detailed communications manual on the website for more Information:
https://www.leybold.com/en/downloads/download-software/pc-software-for-turbomolecular-pumps/
-> "Interfaces TURBO.DRIVE S/L/300/400/700"

Also i attached something as a screenshot, that might be enough for understanding my problem.

I hope someone can help me out here...

cheers

[Kleinstein]

The second picture seems to indicate that the RS232 is using 7 Bit + even parity. Thus they can only send 7 Bits at a time, so that 16 Bit in binary form would take 3 "Bytes". This makes me think the Data may be send in an ASCII form, like decimal or Hex.

If the instructions are so unclear, one could use a parallel receiver as a way to decode the signals from the supplies software.

The UART inside an µC should be able to provide the signal without bit-banging. IT usually needs a level converter. As data are send in words it would take usually several call the the UART to send on word at a time.

[george4657]

I don't know the product but a quick glance of the manual I found this:
"In the case of word data (16 or 32 bits long) the high byte is transferred first (Motorola standard)"

This would mean 16bit word is sent a two 8 bit words which is the normal method for RS232 transmitting 16 bit instructions.

[cv007]

Section 2.2 Structure of a Complete Data Telegram...

Looks like it lays it all out- 24 bytes go out to make a 'Data Telegram'. Assemble the packet as described, some take 2 bytes, some take 1 (all packets will start with 2,22,0,...)
Once assembled, send out the packet using the underlying 8E1 rs232 (pointed out below, 19.2K looks like the fastest common/normal baud rate)

edit- corrected 7E1-> 8E1

[hexreader]

send out the packet using the underlying 7E1 rs232.

8E1 19200 baud

[cv007]

my bad, 0-7=8

[Amper]

Thank you guys a lot so far, i didnt expect anyone to actually look into it that nicely ^^

I dont get how the output really has to look like, they show how a single  bit byte is transmitted, does that mean that for a 16bit one i will just do it twice with high and low part? Or do i extend it by inserting 16 bits inbetween start and stopbit? im sorry for these nooby questions, but luckily i never had to deal with anything but standard uart until now...

Also i have just connected a uart - usb bridge to the rs232 working its thing, there is a much longr string beeing sent thatn just two characters. For every message i think it was more than 16 characters. I could not find this in the manual though. Also, when i transmit the string i captured before, i still dont get any response from the hardware...

EDIT: I only realized now that rs232 is inverted from uart, so probably what i captured was the opposite of whats actually sent. Ill post again when i have a MAX232...

[hexreader]

does that mean that for a 16bit one i will just do it twice with high and low part?

Yes, that is exactly it.

[Amper]

But how does it know then which bytes belong together as a 16b word? In my understanding after the stop bit is sent i can have it take a brake as long as i want to and then continue later, since the stop bit tells the controller that the transmission has ended.

[hexreader]

Look at diagram 3.1 in the Operating Instructions.

See how bytes 3 and 4 are together, presumably to form a 16 bit value. Byte 3 will be a high byte and byte 4 will be the low byte. Note that bytes count from byte 0.

It is all about how a telegram is constructed.

[cv007]

Forget the rs232 stuff like stop bits, bytes, etc.- that is done later after you create a packet

Data Telegram- 24bytes - this is what you need to focus on
//======
const uint8_t STX = 2; //start byte, always 2
const uint8_t LGE = 22; //length, always 22
const uint8_t ADR = 0; //RS232 = 0
uint16_t PKE; //AK<15:12>, PNU<10:0>
const uint8_t reserved = 0; //0
uint8_t IND;
uint32_t PWE;
uint16_t StatCtrl;
uint16_t val1;
uint16_t val2;
uint16_t val3;
uint16_t val4;
uint16_t val5;
uint8_t BCC; //xor checksum
//======

you need to first assemble a complete packet (data telegram)
then send the whole packet one byte at a time via rs232-

STX|LGE|ADR|PKE.HIGH|PKE.LOW|0|IND|PWE.HH|PWE.HL|PWE.LH|PWE.LL|StatCtrl|... |BCC

the packet entries that are more than one byte- looks like they need to be sent high byte(s) first
like when you get to PKE, send the high byte (PKE >> 8 ) then the low byte
(all data goes out a byte at a time- the receiver receives a byte at a time, reassembles the packet and verifies)

if you can capture the packets, you could probably get a better idea how its done

[newbrain]

But how does it know then which bytes belong together as a 16b word? In my understanding after the stop bit is sent i can have it take a brake as long as i want to and then continue later, since the stop bit tells the controller that the transmission has ended.

All communication happens in "telegram" units.

Framing is controlled by the STX and checksum byte in a complete "telegram", the most important picture is the one on page 6 of the manual you pointed out.

Inside a frame, fields are in a fixed position, so, as long as the sender and receiver state machines do not get confused, it's possible to know what you're looking at.

Ah well...ninjaed by cv007

[Amper]

Ok, i will do a bit o reading again i guess.  Though one thing i think you didnt see, the 2 word telegram is, what the pump sends back, there is no purpose in sending there read only parameters to it. Maybe i got something wrong though.

[cv007]

there is no purpose in sending there read only parameters to it.

Look at table 2.2- it looks like you send 0's for read/write, and the packet you receive has those values filled. So the purpose in sending those parameters (although 0), is that all packets are the same. Its not going to like you deciding that since they are not used, no need to send.

[Amper]

You were right, i just hacked together a signal inverter to read the full transmission with a uart-USB bridge. It needs to see the entire 24 words to respond even though most are just blanks. In my previous understanding i thought id have to just transmit the number of the parameter im interested in and would get the number + value as a response. Now since i can communicate and actually start the pump with my own program i can begin to have a look into the actual data transmitted.

Strings are
"02 16 00 00 00 00 00 00 00 00 00 04 00 03 e8 00 00 00 00 00 00 00 00 fb" for wakeup and arm
and
"02 16 00 00 00 00 00 00 00 00 00 04 01 03 e8 00 00 00 00 00 00 00 00 fa" for starting the rotation

Thanks for the help!