Help with RS-232 message from scale

You could just remove that delay all together and go directly back to the receive string - default timeout on that is to wait 1 second if no data is received. Since your scale sends data every 100ms, you don’t want to delay longer than that. Also, since the Receive String is blocking, you don’t really need a delay in that loop for chart performance as it will give up the time-slice at the call to Receive String.

Currently you are delaying 300ms every time the length is wrong causing the buffer to fill up.

So your current logic should work by just eliminating that delay all together, and you won’t need the Clear Buffer either. You will just be throwing away all the 19 character strings. Though you could improve the parsing logic to adjust for that.

Untested, AI generated Optoscript below to remove anything before the first ampersand:

// Variables:
// sMyString (String) - The input string
// nPos (Integer)      - The index of the ampersand
// nLen (Integer)      - Total length of the string

// 1. Locate the ampersand (ASCII 38)
nPos = FindCharacterInString(38, 0, sMyString);

// 2. If the ampersand is found (result is not -58)
if (nPos >= 0) then
    // 3. Get total string length
    nLen = GetStringLength(sMyString);
    
    // 4. Extract starting FROM the ampersand position
    // We start at nPos and take the remaining length (nLen - nPos)
    GetSubstring(sMyString, nPos, nLen - nPos, sMyString);
endif

I ended up using the script suggested by @tjcrusher back in Feb 2025 and then put in an extra check to discard the occaionally short (garbled) RS232 message from the scale.

// Check if the message contains the ‘N’ character before processing
PosIdx = FindCharacterInString(78, 0, RS232_Receive_Message);

// Only process if ‘N’ was found (PosIdx will be -1 if not found)
if (PosIdx >= 0) then
  Incrementvariable(PosIdx);
  GetSubstring(RS232_Receive_Message, PosIdx, 6, Six_Digit_String_of_Weight);
  scale_weight = StringToFloat(Six_Digit_String_of_Weight);
endif

I then incorporated the suggestions from @philip to eliminate of the 0.3 sec delay (cannot remember why I had that there in the first place).

Much simpler now and very robust handling of the stream of data.

Recording 2026-01-11 160904

1 Like