RS232 communication through PLC

Asrtarte228

Member
Join Date
Nov 2018
Location
Marsaskala
Posts
4
Hi,

I require some help regarding RS232 communication using TIA portal v15, CPU 1511-1 PN and a CM PtP RS232 BA module. I am relatively new to PLC programming. Kindly refer to the links to SCL program block, Trace, Ladder and defined operands jpegs.

I am sending GPIB commands (like those defined in the txbuffer) to a Chroma LCR meter (shown in SCL block jpg) to acquire serial capacitance and resistance.
Both Rx and Tx LEDs on the PtP module flash on switching ON the Start memory bit through LAD.

The chroma accepts all the commands and shows the serial capacitance and serial resistance with every positive trigger of the START memory bit. However the ones read through the receive block are different than the ones portrayed on the meter's display.

The trace shows the following:
- there is a sending command done (bSend), which is the trigger for the send block, and transmission done (txdone), which is the one bit from the send block, with every START positive edge - which is GOOD
- NDR is high on start up and remains TRUE except when there is data being transmitted - this is supposed to be the other way round. (!)

I am not sure what is happening with respect to data transmission. Error is false at receive block but status is 16#0096 (frame end identified based on expiration of the "Character delay time") which I do not know what it means.
What is 'dumped' in the buffer from the receive block (receivebuffer and tempbuffer) is shown in Cs and Rs (conversion in the block is being done) however the quantities are really different from the LCR meter display..

Thanks in advance for your help.

Trace link: https://files.engineering.com/getfi...9-2805-4dcb-b33c-695ac640fc6d&file=Trace2.jpg

LAD Network link: https://files.engineering.com/getfi...d-40b2-8d8d-8defa4128b80&file=LAD_network.jpg

SCL Program code block link: https://files.engineering.com/getfi...-b744-a0df9d123b02&file=SCL_program_block.jpg

Defined Operands: https://files.engineering.com/getfi...8-b183-cca2ec1e0c4e&file=defined_operands.jpg
 
Hello,
When I saw the Maltese flag, I knew I had to try to help you out. It's not every day I see a fellow Maltese person.


This isn't really in my area of expertise, but to me it looks like the data you're receiving is valid, but it is probably getting scrambled somehow. I would check that the baud rate, delimiter and Framing types all match up.


It's also useful to know that Siemens typically stores data in little endian format, so if you're working with Words instead of Bytes, the bytes may be swapped.


Double check the manual for the Chroma Meter and the hardware config of the RS232 module and make sure things all match up.


KD
 
Thank you Kduff appreciate your help :)

Baud rate is at 9600, Parity None, Data bits 8, Stop bits 1, data flow control None.

This is the format in which the Chroma sends back the values:
0,9.517396e-10,4.050937e+03

There is a delimeter ',' between Cs and Rs which i am using to do the byte to float conversion in the 'CR Values' FB.

When using Hercules to communicate directly with Chroma with the above port parameters, the values are correct and when doing a closed loop RS232 communication from PC through the PLC, using Hercules, what I send to the CM PtP block I get back..

When there isn't any capacitance to read there is still a value at the receive buffer as per below, that is why it is sooo confusing...

tempbuffer[0] Byte 16#0 16#30 0
tempbuffer[1] Byte 16#0 16#2C ,
tempbuffer[2] Byte 16#0 16#39 9
tempbuffer[3] Byte 16#0 16#2E .
tempbuffer[4] Byte 16#0 16#34 4
tempbuffer[5] Byte 16#0 16#33 3
tempbuffer[6] Byte 16#0 16#38 8
tempbuffer[7] Byte 16#0 16#35 5
tempbuffer[8] Byte 16#0 16#38 8
tempbuffer[9] Byte 16#0 16#36 6
tempbuffer[10] Byte 16#0 16#65 e
tempbuffer[11] Byte 16#0 16#2D -
tempbuffer[12] Byte 16#0 16#31 1
tempbuffer[13] Byte 16#0 16#30 0
 
I've never used it, but I'm assuming Hercules is a debugging tool that speaks RS232? And Hercules can talk to the device and get the correct values, but the PLC doesn't get the right values from it?


Can you send a command from hercules directly to the PLC, without the device?


I'm also curious if your FB2 block ever enters step 400, which I assume would happen if it detects a line feed character...
 
Hercules is a setup utility to list all send and receive communication by choosing the system like Ethernet or RS232.
I sent a command with Hercules through the PLC and the whole command was sent back so all blocks are working... I sent the command with Hercules directly to the LCR meter and the values sent back were the same as those on display..

Yes it goes into step 400 every time start is switched ON. Even if the values are not good there is always a new line at the end of the buffer received.
 
I always find it interesting doing RS232 with PLC's.

One thing that may be cause for concern is how your receive function works. If it returns immediately with whatever is in the buffer, you may enter your for loop with data missing since you are only looking for a received length different than zero.
If you know the length, or the minimum length of all the replies, I would use that value instead as it would reduce the possibility of starting to process incomplete data.

As kduff mentioned it's worth looking at the byte order, although with ASCII communication this shouldn't be an issue as you're receiving bytes and storing them as such, not words.

(frame end identified based on expiration of the "Character delay time")

I would have to go back on my RS232 notes, but in RS232 without handshaking, if nothing is transmitted for a determined length of time (character and a half, for example), the system notifies that it received a frame. Potentially, my first point can be solved by using this feature. When this value comes up, you know you received the entire reply from the sensor.
 
Thanks all for your help.

While I was out of office the PLC was changed to an older version (V1.8 instead of V2.5). Changed it in TIA and Whilst compiling I had errors as the PtP blocks were of a 'newer' version than those specified.

I did everything in a new project, copy and paste without changing anything and finally I had goooood readings!!! Whatever the LCR meter showed, I had them in the buffer and in the Cs & Rs conversions. Guess it was just the version of the PLC used..
 

Similar Topics

I have wasted a week trying to figure out how to connect an SLC5/03 with my laptop. I do not have and can not Buy the 1747 UIC and PC3 cables. I...
Replies
14
Views
2,477
Hi friends, I have a problem. I want to read ASCII data over rs232 standard port. How can I do the reading process? FATEK FBs-CB25 -> port1...
Replies
0
Views
708
MELSEC A RS422 (25pin) <> iQR C24 Serial RS232 (9pin) - Simple PLC Communication Communication from a MELSEC-A Series CPU (RS-422 – DB 25 Pin)...
Replies
4
Views
1,005
Good morning everyone, This is my first post here. I am beginning my journey on PLC programming and still a really newbie, I want to write a...
Replies
0
Views
1,209
Hi, I want to communicate slc5/03 cpu with Delta tp04 hmi through rs232 port. I tried through 1747cp3 cable directly but can not communicate...
Replies
0
Views
915
Back
Top Bottom