Continue to Site

Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

  • Congratulations KootK on being selected by the Eng-Tips community for having the most helpful posts in the forums last week. Way to Go!

RS232 communication through PLC

Status
Not open for further replies.

Asrtarte228

Automotive
Nov 22, 2018
5
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 accordingly. 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 - GOOD
- NDR is high on start up and remains True except when there is data running - 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 really different from the LCR meter display..

Thanks in advance for your help

Trace link:
LAD Network link:
 
Replies continue below

Recommended for you

I don't know anything about your particular hardware, but I've been tripped up on this sort of thing before because the bytes were reversed, big-endian, little-endian and all that.
John
 
Thank you John for your help.

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

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, again 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... below is an example of what I get at the receive buffer. Regarding little/big endian could you explain further please? Thanks.

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


 
Endian just refers to what order the bits and bytes come in as. MSB first or LSB first, that sort of thing. not all hardware is the same. I don't really understand what format your meter is sending, floating point, ascii, etc. What does the documentation say? I don't get your buffer printout either. Maybe I'm just reading it wrong, but I would expect to see an 8-bit byte at each array member.
 
Thanks once again John for your reply. I do not think that it is using MSB or LSB format. For RS232 communication there is Receive_P2P block which receives the length of the sent info as UInt and the data as an Array of Bytes.

The above list is the first bytes in the tempbuffer where it reads as follows: 0,9.438536e-10 which is different from what is displayed in the LCR meter.

tempbuffer[0] Byte 16#30
tempbuffer[1] Byte 16#2C
tempbuffer[2] Byte 16#39
tempbuffer[3] Byte 16#2E
tempbuffer[4] Byte 16#34
tempbuffer[5] Byte 16#33
tempbuffer[6] Byte 16#38
tempbuffer[7] Byte 16#35
tempbuffer[8] Byte 16#38
tempbuffer[9] Byte 16#36
tempbuffer[10] Byte 16#65
tempbuffer[11] Byte 16#2D
tempbuffer[12] Byte 16#31
tempbuffer[13] Byte 16#30
 
I see. What does the meter read? Are you sure you're requesting the same thing that's on the screen? You seem very close, it may be time for a quick call to their tech support to see if there's something quirky that you'll have a hard time figuring out but they already know.
 
Thanks all for your help.

Answering IRstuff, whenever I didn't have any resistance to be measured, there was still a value in the buffer and consequently shown in the Rs value. Also the capacitance read through the block didn't match those physically and read by the LCR meter...

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 good 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..
 
Asrtarte228 said:
Guess it was just the version of the PLC used.

Welcome to the world of industrial controls.

Brad Waybright

It's all okay as long as it's okay.
 
Still didn't answer my question. What was the actual numerical value on the meter display when you got the PLC output listed above? You can't troubleshoot something like this with only one piece of information.

TTFN (ta ta for now)
I can do absolutely anything. I'm an expert! faq731-376 forum1529 Entire Forum list
 
Np IRstuff!
So if the display showed 9.234pF and 1.5Kohms, I had 9.4385e-10 and 3450 respectively.
If there wasn't any resistance to measure, I'd still have an average of 3kOhms and a 9.285e-10 instead of the 2.85pf shown on display. With every trigger, only the digits after the decimal point change.

I do not know what is there to troubleshoot when the problem was 'solved' just by changing the PLC to an older version without changing anything from the program, it is more of a Siemens problem, which unfortunately they didn't understand my query at all.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor