Turbo Pump Pfeiffer

Hallo

i am working on a control Interface for serveral Components including turbo Pumps from the company Pfeiffer.

The communication will be done according to the The Pfieffer Vacuum Protocol for RS485.

Does any one have experience with this Protokoll or is there a library that can be used for this art of communication.

I will use a MAXCHIPRS485 for the communication between Arduino (SerialPorts) and the Pumps RS485 Port.

the Wiring is clear .
I want to ask if someone already has done a similar Code that sends and reads from the Pump continuously.

Thanks in advance

Hi F-edi,

no I haven't worked with this protocol yet. But I'm quiet experienced in reading datasheets and manuals of very different kinds of devices. So if you can provide datasheets and documentation as PDF-documents (attachment or download-links) of the used protocol this task wil become intriguing for more users to take a look inside.

best regards Stefan
any newbee can apply the most professional habit from the first line of code they write on their own:
add only ONE thing at a time. Test/debug that ONE thing until that ONE thing works reliable - repeat.
The sad thing is: only the REAL professionals write code this way.

RS485 simply provides level shifting and differential signaling on top of regular logic-level serial comms. The Maxim chip will take care of that for you assuming you connect the logic side to the appropriate pins on your (unnamed) Arduino board.

You can implement the (known only to you) protocol using any serial object whose class inherits from Stream. I'd recommend using an Arduino with an available Hardware Serial port (Mega, 32u4, Teensy, etc) so you can avoid Software Serial.

Assuming the protocol is all-ASCII, you can send data to your pump using the standard print() and println() methods of the Print class (from which Stream inherits).

For reading the data back, study @Robin2's Serial Basics Tutorial.

EDIT:
Of course, you also have to set up the correct Serial parameters. If you're lucky, it will be something like 9600/8N1.

hallo
thanks for the response.
the Datasheet i attached here, where you can find the protokoll that is used from Pfeiffer.
I already thought about sending the Data and read it Throught Serial.

I have decided to use an arduino Due since i Have one and it has many Hardware Serials.

The problem is that i want to write a code that enables me to communicate with 3 Pumps without having trouble with the Data to get mixed.

The main challenges are:
-sending the message and changing quick enought to read so we recieve the answer correctly from the pump and then turn the RS485 back to read mode.

  • If i send one message to each pump, I want to make sure that i get an answer from both pumps correctly

I wil be glad to have any tipps that will help
thanks

Pfeiffer Interface RS@32.pdf (181 KB)

Unfortunately, I could not find any information in that document regarding the timing of the message exchange. For example, how long does a slave (pump) wait after receiving a request before starting to transmit the answer?

Many times with RS485, the slaves have control inputs that tell them when they're allowed to switch into bus driver mode and start sending their data. The master is then able to drive these inputs so that only one slave is enabled and sending data at a time. I don't see a provision for that in this document.

In general, you'll want to send a command to one slave at a time and then wait for it to respond (or time out) before moving on to the next slave.

I also don't see any information in this document about serial transmission parameters (baud, parity, stop bits, etc).

Hallo

I couldnt upload the whole DataSheet
so i took a picture of the RS485 available Infos

F-edi:
The main challenges are:
-sending the message and changing quick enought to read so we recieve the answer correctly from the pump and then turn the RS485 back to read mode.

  • If i send one message to each pump, I want to make sure that i get an answer from both pumps correctly

I wil be glad to have any tipps that will help
thanks

The module that you mentioned has automatic TX/RX switching. When you transmit anything, it sets an RC timer that puts the bus driver in TX mode. When you stop sending characters, the timer expires and reverts to RX mode.

It is easy to select devices in the Pfeiffer protocol. There is an address field in the "telegram" for that. If you send a valid telegram with the address of a device, it will receive and decode it, respond if it has an answer. That part of the bus control is not available to you, but it doesn't matter because you should be waiting for a response from the device, so you remain in RX bus mode (by virtue of the simple fact that you are not transmitting).

gfvalvo:
Unfortunately, I could not find any information in that document regarding the timing of the message exchange. For example, how long does a slave (pump) wait after receiving a request before starting to transmit the answer?

This part is quite important, because of the automatic bus timer on the MAX module. It will not transition from TX to RX mode until an on board RC timer expires. The slave device has no idea when this timer expires. So it has to have a guaranteed wait time before sending a reply, that always exceeds the MAX bus timer. If not there will be a bus collision.

Thanks for the Response

I have done a Qt Gui where i have buttons to control each pump
So if i click one button to turn on pump1
and then directly click one button to activate pump2

the first message will be sent and as you known and then the pump 1 will answer
on this time the message for the pump 2 wont be send correctly since the bussystem is on readmode

thats the exemple where i am afraid of prolems in the communication
Since the Pumps are expensiive i would like to avoid such problems before testinf my code on the Pump directly

aarg:
This part is quite important, because of the automatic bus timer on the MAX module. It will not transition from TX to RX mode until an on board RC timer expires. The slave device has no idea when this timer expires. So it has to have a guaranteed wait time before sending a reply, that always exceeds the MAX bus timer. If not there will be a bus collision.

OP could also switch to a RS485 transceiver with manual TX / RX switching and drive the control with a processor GPIO. Surely then the switch could be made before the slave starts transmitting.

F-edi:
Thanks for the Response

I have done a Qt Gui where i have buttons to control each pump
So if i click one button to turn on pump1
and then directly click one button to activate pump2

the first message will be sent and as you known and then the pump 1 will answer
on this time the message for the pump 2 wont be send correctly since the bussystem is on readmode

thats the exemple where i am afraid of prolems in the communication
Since the Pumps are expensiive i would like to avoid such problems before testinf my code on the Pump directly

Your code will have to handle that situation by properly controlling the command message timing.

F-edi:
the first message will be sent and as you known and then the pump 1 will answer
on this time the message for the pump 2 wont be send correctly since the bussystem is on readmode

Can you arrange it so that each button press queues a request for the pumps and you have a comms subsystem that takes care of transmitting once the last communication is complete?

wildbill:
Can you arrange it so that each button press queues a request for the pumps and you have a comms subsystem that takes care of transmitting once the last communication is complete?

Thats actually the idea that I was considering
but since i am not sure when the slave(pump) changes to writing and how it takes t to read the whole message.
those are the Parampeters that i need to understand soi can choose whether i have to use a delay (a non blocking delay) each time(how long? ) to make sure slave and master have enough time to recieve or to send

Don't use any "delay". Simply wait until the complete message from the current slave is complete (or times out) before sending any commands to the second slave.

The length of the "time out" period is the only thing you need to determine. That can be done through experimentation.

Do you have a link to the RS-485 device? The automatic feature I mentioned controls the "turn around delay" which is optimally one bit period long. That depends on the baud rate. Since the cheap ones I have don't have an adjustable delay, they must be optimized for some assumed baud rate. I haven't measured them yet to find out exactly what it is... of course it's not documented because they are anonymous clones. But if the turn around delay is less than one bit period at the baud rate you're using, it becomes transparent and you don't need to worry about it. However this does require that the transmitter software is in control of the TX buffer.

I'm new to these modules and to RS-485, but it seems to me that a simple RC timer can't produce that, since as many as 8 consecutive one's might be in a transmitted byte, and the TX buffer would have to remain enabled during that time. There is no way it could distinguish that from an end of transmission (with this simple method, the EOT is just some interval after the last zero is sent...). In that case, it would be necessary for any slave to implement a "hold off" period before responding.

If you depend solely on the processing delay of the slave, you could have a system that works but without any guarantees.

aarg:
Do you have a link to the RS-485 device?

If you depend solely on the processing delay of the slave, you could have a system that works but without any guarantees.

The Problem is that i Have no Information about the delay of the Slave.

I can try it to find it throught exeperimentation as mentionned above. Its still not the most reliable method I guess

I’d just try it with a single pump to find out how they behave. I think that you may be overthinking this.