Perhaps someone already faced with similar problem.
I have PLC and decentral periferie module IO, where is installed Serial Interface module. To interface of this Serial Module is connected an usual transducer which is capable to communicate by RS-485 bus.
I have a list of commands and adequate answers for this device.
- I transmit a query :ADR?; an adequate answer should be: 31CRLF;
I see that in buffer exactly 4 characters. However they are looking differently (there's so called character's distortion).
However, after quite long shutdown (allegedly, I'm not sure that was a reason), I made a query and I had got adequate answer. After that I made second query (to be sure if it's became working), and I had got four distorted characters as I wrote at the beginning.
Communication settings: both are identical;
Cable length: less than 1 meter.
Cable type: twisted pair, copper multistrand wire;
So, any comments on this matter, please
1. You expect the reply to be ASCII four characters 3 1 CR LF, correct?
What four characters do you actually get?
2. ASCII is usually 7 bit. Is your serial setup configured for 7 bit words?
1. I get C6 24 24 C1. Normally I should get 33 31 0D 0A and it sometimes happens.
2. No, it isn't. This transducer doesn't work with 7 bit at all, it works with 8 bits only. The standard communication setting is: 9600 Baud, 8 bits, even parity, 1 stop bit.
>1. You expect the reply to be ASCII four characters 3 1 CR
> What four characters do you actually get?
>2. ASCII is usually 7 bit. Is your serial setup configured
>for 7 bit words?
- check cable termination resistor (120 ohm)
- add an equipotential wire between the serial card and the sensor
- try swapping A and B wires at one end of the RS485 cable
- reduce baud rate
- check the way a string is accepted as "complete" in your plc serial card: may be upon "termination characters" (CR+LF in your case) or by character delay (e.g. 4 milliseconds without activity on the serial line). In the latter case, character delay must be adapted upon actual baud rate.
1.The SI module itself has integrated termination and biasing facilities.
I've already tried both on/off variants.It had no effect. Moreover, the cable has so ridiculous length, that I don't think it's a reason.
2. Yes, it was done. GND wire was connected between devices.
3. Yes, it was done, just in case. The slave went to error state.
4. 9600 Baud it's not high and default baud rate, to increase/decrease rate I have to establish normal communication first.
>- check cable termination resistor (120 ohm)
>- add an equipotential wire between the serial card and the
>- try swapping A and B wires at one end of the RS485 cable
>- reduce baud rate
>- check the way a string is accepted as "complete" in your
>plc serial card: may be upon "termination characters" (CR+LF
>in your case) or by character delay (e.g. 4 milliseconds
>without activity on the serial line). In the latter case,
>character delay must be adapted upon actual baud rate.
The 33 31 13 10 is the decimal representation of the ASCII characters. The same characters in hex are 51 49 0D 0A
The 'wrong' reply characters that you sometimes get, C6 24 24 C1, must be hexadecimal representations of the received characters because C6 and C1 are not decimal.
Sorry, I can't help; I do not know why it would work sometimes, not others.
Not my best day reading an ASCII table . . .
33 31 0D 0A is indeed Hex representation of ASCII for 3 1 CR LF; my bad.
The SI card should detect framing errors. I don't remember if such error is shown in the status word or in the card diagnostics (go online with "hardware configuration").
Definitive tool is an oscilloscope, you can then check the waveform and count the bits in the serial frame.
Further (and maybe naive) questions:
1. is your connection a straight RS485 from the SI module to the instrument or is there an interface converter (RS232/RS485) in between?
2. Have you already tested the SCPI commands using a terminal app on notebook and a serial line to the instrument?