0

I am trying to receive and send data from a vacuum gauge (previous Model of https://www.pfeiffer-vacuum.com/en/products/measurement/digiline/gauges/?detailPdoId=13238&request_locale=en_US) with a computer (Linux 16.04) via an USB-to-RS485-Interface (the half-duplex USB485-STISO from http://www.hjelmslund.dk/). When I send a request to the gauge using a specific protocol it is supposed to answer to the request and I should be able to receive it with the interface. I managed to send data but whenever I send data, it seems that nothing comes back. I'm trying to do this with Node.js. The Code that I used so far is:

function pack(address, action, parameter, data) {
    var length = String('00' + data.length.toString()).slice(-2);
    var bufferAsString = address + action + parameter + length + data;
    var check = 0;
    for (var i = 0; i < bufferAsString.length; ++i) {
        check += bufferAsString.charCodeAt(i)
    }
    var checkSum = String('000' + String(check % 256)).slice(-3);
    var buffer = Buffer.from(bufferAsString + checkSum),
        carriageReturn = Buffer.from('\r');
    return Buffer.concat([buffer, carriageReturn]);
}

var serialPort = require('serialport');
var SerialPort = serialPort.SerialPort;

var port = new SerialPort('/dev/ttyUSB0', {
    baudrate: 9600,
    dataBits: 8,
    stopBits: 1,
    parity: 'none'
}, false);
port.open(function(err) {
   if (err) {
       return console.log('Error opening port: ', err.message);
   }
    console.log(port.isOpen());
    port.on('data', function (data) {
        console.log('Data: ' + data);
    });
    port.on('close', function() {
        console.log('port closed')
    });
    var sendBuffer = pack('001', '00', '740', '=?');
    setInterval(function() {
        port.write(sendBuffer, function(err, bytes) {
            console.log('send' + bytes)
        });
        port.drain();
    }, 1000)
});

That is supposed to send a request every second to the gauge to measure the pressure. I know that the request is being send since the TxD-Led blinks shortly every second. But I receive no answer to that request. I also tried other methods of sending data (mostly via python and the terminal) but with similar success. The green lamp for sending always flashes up but then nothing happens and no answer is received. I am at a loss as to what to try next and would really appreciate any help that you could give me.

UPDATE: Ok so I seem to have found one possible error in the whole thing. I was working with an oszilloscope to capture the signal that is going out of the interface when I send something. I started with single ascii-characters to see if the most basic signals are cominng out right. For ascii '0' the signal that is being sent is 10000011001, for ascii '1' it is 10100011001. So those are almost what I would expect, except that there seem to be 2 startbits. Normally I would expect there to be only 1 startbit. Is there a way to change the amount of startbits sent? Here are the outputs of the Oszilloscope:

Signal of ASCII '0' Signal of ASCII '1'

Christoph Pohl
  • 325
  • 5
  • 19
  • As RS485 uses both D+ and D- as a differential pair half-duplex, i.e. both ends transmit on the same two wires, the fact that D- is changing is absolutely no indication that the sensor is transmitting, because when either end transmits both D+ and D- will vary. Yes RS485 is half-duplex but the protocol between PC and sensor will probably involve PC requesting data and sensor responding then shutting up. Both ends know the protocol and cooperate to ensure no collisions. Most likely your request is not correctly formatted or the checksum is wrong. Can you validate the checksum calculation? – DisappointedByUnaccountableMod Jul 07 '16 at 08:43
  • To reduce possible sources of errors I would first try connecting using a serial terminal program. Manually send the command string, see if there is a response. Looks like a command is all in ascii, terminated by \r (so no worries about endianness, ralf) e.g. "0010074002=?ccc\r" where ccc is the checksum in decimal, zero-padded on LHS to three characters. The checksum is the simple decimal addition of all the value of the characters before it, modulo 256, i.e. 000-255. For 0010074002=? I make the checksum 106, so the complete command should be "0010074002=?106\r". Yes? – DisappointedByUnaccountableMod Jul 07 '16 at 09:01
  • The checksum should be correct, as I am using an example request from the documentation of the gauge. And even if the checksum would be incorrect, I believe the gauge should at least send an error back. I used a similar example as you which would be '0010074002=?106\r' (you forgot the length of the data in the request). So if I would use screen in linux to connect to the serial port what would I have to exactly do to send this string? Sorry I have never really worked with this kind of thing before – Christoph Pohl Jul 07 '16 at 09:01
  • "should be" implies you haven't checked it yourself. Print the message you are *actually* sending, and verify the checksum is correct. It's a very simple checksum to check. – DisappointedByUnaccountableMod Jul 07 '16 at 09:05
  • I checked the buffer I was sending to the port and the checksum was the same as in the example from the documentation – Christoph Pohl Jul 07 '16 at 09:07
  • yes I forgot the length, added it. Was decoding your code. – DisappointedByUnaccountableMod Jul 07 '16 at 09:08
  • you make sure the serial port settings are correct, then type those characters 0010074002=?106 and press return. – DisappointedByUnaccountableMod Jul 07 '16 at 09:09
  • If multiple sensors should be addressable on the same RS485, I'd be surprised if they would respond to a bad checksum message - all the attached sensors would try to respond at same time. – DisappointedByUnaccountableMod Jul 07 '16 at 09:13
  • 001 is the address of your gauge, isn't it? This doc about the Pfeiffer protocol http://mmrc.caltech.edu/Vacuum/Pfeiffer%20Turbo/Pfeiffer%20Interface%20RS@32.pdf says "The slave component (for example, Pfeiffer drive unit) cannot independently begin a communication and only answers when it is addressed with a valid individual address." so it won't respond if checksum is bad. – DisappointedByUnaccountableMod Jul 07 '16 at 09:36
  • Yes I have the address of the gauge as 001. As I'm using the exact same bits as in the example request I'm sure my checksum is correct. When I type screen /dev/ttyUSB0 in the terminal it just opens an empty window and I can't type anything. But it seems to be sending data everytime I press a button. Is that how it's supposed to be? – Christoph Pohl Jul 07 '16 at 10:32
  • So the Buffer object that I'm sending through Node is , which should be the bits in hexadecimal. Translated that seems right to me. – Christoph Pohl Jul 07 '16 at 10:36
  • Yes that looks OK. Not used screen, but I guess it isn't doing a local echo of what you type, this is probably a setting you can change. Make sure to set the comms rate/format (speed, 7/8 bits, odd/evenparity, etc.) correctly, they are specified on the command line I think. If you have another RS485 adapter and another PC you should be able to connect them to each other (should also work on the same PC with screen running in two windows each one connected to a different USB adapter) - this is a good way of checking that data is being sent/received. – DisappointedByUnaccountableMod Jul 07 '16 at 10:51
  • If you have a controller that works with your gauge, you should be able to hook onto the RS485 and screen will show the messages going to and fro. – DisappointedByUnaccountableMod Jul 07 '16 at 10:53

2 Answers2

0

this is a communication problem:

1 check the protocol-based communications parameters like baud rate, parity, start-/stop-bits they have to be consistent (if you use UART protocol on RS-485 other protocols like MODBUS, Profibus,... are also possible, this is a difference to normal RS-232)

If the gauge uses 9600 baud for communication you can not use 115200 baud in your command. In the nodejs code you do not set any parameter (i assume you use the UART protocol because of your nodejs). If the gauge uses any other protocol the nodejs code will also not work, despite that there are not set any parameters like baud rate, parity,... in the code https://en.wikipedia.org/wiki/RS-485

for other protocols node js serial module can not be used

http://libmodbus.org/

http://www.pbmaster.org/

2 check the proprietary commands you send to the gauge. When i want to read out the data of my multimeter i have to send an ASCII 'D' = 0100 0100 (bin) to get an answer (endianness ?) If i send any other value the multimeter stays silent.

http://electronicdesign.com/what-s-difference-between/what-s-difference-between-rs-232-and-rs-485-serial-interfaces

ralf htp
  • 9,149
  • 4
  • 22
  • 34
  • So for 1) When I define the new Port, I leave the options for communications parameters free, since the standard parameters are already what I need ( baudrate 9600, no parity, 8 databits, 1 stopbit 2) the commands that I send are defined by the Pfeiffer protocol, where the first 3 bits are the address of the gauge, followed by an action indicator (2bits), the parameter (3bits), the length of the data, the data and a checksum followed by a carriage return – Christoph Pohl Jul 06 '16 at 10:59
  • ah okay, the protocol really is UART. For clarity insert the UART parameters in the nodejs. There are other UART parameters like *flow control*. Check these also and insert them. Else, if this is all correct maybe it is because of endianness in the commands ? – ralf htp Jul 06 '16 at 11:21
  • *flow control* is specific to RS-232 and is not in RS-485 according to http://www.electronicspoint.com/threads/flow-control-in-rs485.25678/ – ralf htp Jul 06 '16 at 11:34
  • Yeah I tried that already and that didn't change anything. Also the gauge reads the ascii bytes that are send from the buffer, does this depend on endianness? – Christoph Pohl Jul 06 '16 at 11:53
  • no, endianness means the byte-ordering.if the gauge expects `0100 0100` and it is send `0010 0010` (endianness problem, LSB first) it will not answer. The node js serial library has a parser (newline,...) maybe use this https://itp.nyu.edu/physcomp/labs/labs-serial-communication/lab-serial-communication-with-node-js/ i have to go now... – ralf htp Jul 06 '16 at 12:07
  • Maybe see this else i don't know http://www.barryvandam.com/node-js-communicating-with-arduino/ – ralf htp Jul 06 '16 at 15:59
  • I agree with Ralf, you should assert the serial protocol settings - if they are wrong then the communication will not work, and that is definitely a symptom you have. May be more than one problem causing that symptom, of course. – DisappointedByUnaccountableMod Jul 07 '16 at 08:45
  • Sorry if this is a silly question, but do you have the correct address for _your_ gauge, or is it 001? – DisappointedByUnaccountableMod Jul 07 '16 at 09:21
0

Unless you have DE pulled high and R︦E︦ tied to ground, your conversation will be rather one-sided.

And if you do wire as above, you need to be able to deal with your own echo in the received data.

Bhargav Rao
  • 50,140
  • 28
  • 121
  • 140