Setup:
I’m using B&R Automation Studio with standard FRM function blocks to read sensor data via RS232 (Module: CS1020). The setup follows the usual steps:
FRM_open → FRM_gbuf → FRM_write → FRM_read.
Working:
- Interface opens (
FRM_open.status = 0)
- Telegram is sent correctly (
FRM_write.status = 0)
- Format:
:06800421402140<CR><LF> (confirmed correct per protocol)
Problem:
FRM_read.status = 60 (timeout)- No data received (
buffer = 0, buflng = 0)
- Tried all combinations of
delimc := 0 and 2, CR/LF set, and idle := 1000
- Frame content variations do not help
Verified:
- I can successfully connect and receive responses using the sensor manufacturer’s
RS232 software
- So, the sensor is responding, but the B&R FRM_read block never sees the data
Question:
Why is FRM_read not receiving data, even though:
- The telegram is valid and confirmed
- The sensor replies (verified externally)
- Communication settings match on both sides
The image is from the sensor manufacturer’s documentation. Is my approach correct? I send the request using FRM_write and expect the response using FRM_read.
Any ideas or tips would be appreciated!
Hello Rene,
I suggest using the example from Automation Studio for the DVFrame library. Since the frame end identifier is known, I would use the delimiter.
Gruß
Stephan
Hallo Stephan
As shown in the picture, I’m already following this procedure. Unfortunately, I’m not receiving any response at all. Interestingly, when I send a reply from the Docklight terminal, data is always received—regardless of whether the content is valid or not.
I am sending this completely made-up message as an example. But it is displayed to me.
am happy to receive further tips
Kind regards
Rene
Hi,
as I understood, the sensor only sends response after having received a valid request, right?
And if you’re sending the request to the terminal software instead of to the sensor, the request is received by the software and you can send manually a response which is received by the PLC?
If this is the case, in my opinion the’re only 2 causes possibe:
- even if it looks good in your screenshots, maybe something is wrong with the request data, and the sensor does not respond
- there’s a physical issue in between the 2 serial interfaces (I’ve seen such issues in past for example when the serial chip of the sensor uses very low voltage signals)
About your example sending a message from the terminal software:
it looks like, that the data in the terminal software is sent as hex byte values (so sent as binary value, not as string-coded value), and your receive buffer is decoded as string (for example the 2.nd byte you send is ‘52’, which is the hex value of the ascii character ‘R’) - so the data you receive is the same data you sent, but with different ‘interpretation’ because of the datatype used.
Maybe the coding / interpretation of the request packet has to be something different than a string? Probably a byte array containing the binary values interpreted as hex numbers … at least it looks a bit like that?
Here’s a example what I mean:
I’m not sure if the colon is part of the protocol or not, but if yes and the data has to be sent binary, the request packet could for example look like:
// senddata is array of USINT[0..9]
senddata[0] := 16#3A; // colon
senddata[1] := 16#06;
senddata[2] := 16#80;
senddata[3] := 16#04;
senddata[4] := 16#21;
senddata[5] := 16#40;
senddata[6] := 16#21;
senddata[7] := 16#40;
senddata[8] := 16#0D; // CR
senddata[9] := 16#0A; // LF
Best regards.
1 Like
Some general remarks.
Did you define cyclic streaming as function model for the X20CS1020?
What cycle time is defined for the X2X cycle time and is the CPU Timer linked to the X2X-interface ?
1 Like
