One for the Siemens PLC programmers...

[Wedg1e]

S7-1200 so newish kit. Need to output an RS232 data stream (up to 6 Bytes) to control a bit of equipment. I've got the right RS232 module and the data format of the port is set up at both ends (Baud rate, 8 bits, no parity blah blah).
I think the idea is to create a buffer with the Bytes in it, then send that to the output, and I can get the Tx LED flashing on the RS232 module but the remote kit fails to respond. It only uses Tx, Rx and 0v lines of the 232 cable and the Tx and Rx have been tried both ways in case the socket's wrong on the remote unit.
I suspect something in the construction of the buffer is wrong; have tried saving the values as Hex and Binary but made no difference.
Any ideas...?

 

[MCKDAVID]

@daleyd ....

 

[rikrobson]

if you want to test the data is being sent, you can connect a pc with a serial port and connect that as the receiver. you will need a terminal program, like putty set up for the correct com port and speeds. this will then display the data received

 

[daleyd]

As rik says above, get something to verify the right data is actually being sent. Do you have anything else to connect up to verify it’s sending/receiving something? Does it need an initialisation command to get it to wake, is there any handshaking expected?

I tried to connect a hmi to an s7 300 a while back and it decided to fry the comms port on the hmi, I’ve never had that before with a-b or Mitsubishi - may not be relevant if you are using an add on 232 module ...

Are you using the new TIA portal programming tool - I’ve only used the older simatic manager and seem to remember serial comms was a bit hit and miss.

 

[minimutly]

Surely you can't just send, and send and send without any handshaking? Or can you? As long as the transmit signal is within the (receive, buffer,decode) time of the receiver it might work, but you'd have to set that up both ends, and it might be slower than using handshaking.
Ditto the comments about using a pc to read the codes transmitted - I used to use one that came with windows 95...

 

[Wedg1e]

Bloody hell, I had to scroll so far down I thought the thread had been deleted

DaleyD - it is the TIA portal we're using.

I can see that I'll have to lash up some sort of terminal to see if the data actually is being sent. I have however hung a 'scope on the RS232 module output and there is a good data stream when we tell it to send. Changing the sent data gives a different data stream.

Doesn't help that the makers of the kit we're trying to control appear to have no experience themselves of controlling their own gear over an RS232 link.
They do provide lots of info on the format of data to control and/or interrogate the equipment, but with only Rx, Tx and Gnd there's not a lot of scope for full-duplex handshaking so I guess it's just done by the set 'listening' for a valid data stream. Essentially it wants min. 3 bytes: one to tell the Rx how many bytes follow; one is the command and one a Stop byte. Couldn't get much simpler. Longest command is 6 bytes but until it works with the simplest one we'll leave that alone.

We figured that the way to do it would be to set up a buffer as 'Array of Bytes'; store the command bytes and then set the port to send that buffer - the Tx LED flashes on the RS232 module to suggest it is doing something. We've tried setting up a loop so the PLC sends the buffer until we tell it otherwise, still no response from the remote kit (remote as in, on the end of 5 feet of cable).

To complicate matters we've already pointed out to the equipment manufacturers that the pinout of the RS232 port that they show in their manual is wrong - they show pins 1, 2 and 5 when it should be 2, 3 and 5 as that's how their socket is wired (i.e. correct for standard RS232!). On that basis I thought they might also have Tx and Rx mixed up on the PCB so I've even tried linking them both together at the PLC end and sending to both pins - no difference.

Bloody computers - give me things I can measure, put a spanner on or hit with a hammer

 

[eddie49]

Don't forget that if both ends are set up to be DTE ( terminals ) rather than DCE ( modems ), then you will need a "cross-over" or "null-modem" connection - i.e. send data on Pin 2 wired to Receive data on pin 3 at the other end.

 

[Wedg1e]

Don't forget that if both ends are set up to be DTE ( terminals ) rather than DCE ( modems ), then you will need a "cross-over" or "null-modem" connection - i.e. send data on Pin 2 wired to Receive data on pin 3 at the other end.

Yep, that's how it's wired, although we tried it Rx to Rx/Tx to Tx in case the remote socket was wrong, as I said.