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
Hello everyone,
I finally managed to read data from the sensor!
I’m now sending the request as a string and simply appending CR LF at the end.
The issue was actually a combination of multiple problems:
- The telegram termination was incorrect
- The response needed to be read very quickly – I had to adjust the cycle time
- Otherwise, the reply would already be gone before being processed
- And in the end… it turned out RX and TX were swapped
Now I’m facing a different challenge.
The response from the sensor is returned as an ASCII String.
How can I convert this ASCII string into a REAL (float) value?
According to the manufacturer:
Float numbers are represented in 32-bit IEEE-754 single-precision format,
e.g., 3F800000 = decimal 1
Strings contain ASCII characters, e.g., hex 41 = ‘A’, hex 4D = ‘M’, hex 6D = ‘m’, etc.
How can I convert my fMeasure string (BDFEF4A0) into a REAL value like `r_flow = -0.12449002
The value is received as an ASCII string and should be interpreted as a 32-bit IEEE-754 float.
Is there any guide or working example for this?
Any help would be greatly appreciated!
My module is configured to use the functional model ‘Stream’.
You must first convert hex string to long and then cast it to float for instance in a c-program.
#include <bur/plctypes.h>
#ifdef _DEFAULT_INCLUDES
#include <AsDefault.h>
#endif
#include <stdio.h>
#include <stdlib.h>
void _CYCLIC ProgramCyclic(void)
{
const char *hex_string = “1A3F”;
long int_value = strtol(hex_string, NULL, 16);
float float_value = (float)int_value;
}
and in Structured Text ?
I don’t have strtol.
just pack the C code into a library.
#include <bur/plctypes.h>
#include <stdio.h>
#include <stdlib.h>
#ifdef __cplusplus
extern "C"
{
#endif
#include "hexlib.h"
#ifdef __cplusplus
};
#endif
float hex2real(plcstring* hex_string)
{
UDINT hex_value = strtoul(hex_string, NULL, 16);
return *(float*)&hex_value;
}
VAR
hex_number : STRING[8];
r : REAL;
END_VAR
PROGRAM _INIT
hex_number := 'bdfef4a0';
END_PROGRAM
PROGRAM _CYCLIC
r := hex2real(hex_number);
END_PROGRAM
hexlib.zip (1.9 KB)
1 Like
