Help with RS-232 message from scale

[grant1]

Hi all.

I have changed brands of a weigh scale with RS-232 output that is used in a PAC Control program and I need to adjust some parts of the program to adjust to the new string of characters. I can parse the string okay using my code, but I notice that the string length changes between 18 and 19 characters. My settings are:
baud=9600,parity=n,data=8,stop=1
I tried changing parity to e and o but that did not help.
Any suggestions as to why the string length changes from 18 to 19 characters and what I can adjust to correct this?

video (value on scale is 15.80 lbs)

[dp_engsberg]

Hi Grant,
I’m guessing that the new scale has a CR LF termination, where the other scale just used one of those characters. The . character at the beginning of the string is probably the CR (or LF) from the previous message.

[Beno]

A few thoughts…

Whats your Set End-Of-Message Terminator character?
I’m wondering if the string from the new scale has a different EOL character?
Is the update rate of the new scale faster?

[philip]

If you change your debug window to view in hexadecimal, it may become clearer on what is happening.

Parity and stop bits on serial are character by character, so if the rest of the string is good, your settings are probably okay.

[grant1]

Thanks guys. Here is the manual. From p. 57:

In my PAC Control program, the End-of-Message Terminator is set to 13 which seems to be correct given the table above.

[grant1]

See above output. I have studied this for quite a while and come to some conclusions:

1. The new scale’s End-Of-Message Terminator is CR (ASCII 13) and I do not believe the . character is end of the previous message
2. The message seems to alternate evenly between 18 characters and 19 characters.
3. I believe the update rate of the new scale is faster vs the previous one, but I am not sure if that comes into play here.
4. Inspecting the output in hexadecimal shows that the . character is actually 00 in hexadecimal which is the Null Character whereas the hexadecimal representation of the “.” character (period or full stop) is 2E.

So now the question becomes why is there a leading Null Character, and the manual mentions nothing of that.

The PAC Control program works in that I inspect the length and if it’s not 18 characters, it sends it back in a loop until it sees 18 characters. My feeling was that was a sloppy way of handling it and there could / should be a technical reason why I could not get a steady 18-character message repeatedly, but maybe there is some setting deep in the scale that I am not aware of and I’m hunting a ghost.

[philip]

Is the scale serial output direct wired to the 232 input? It shows that in the manual, but that would technically be out of spec since the 485 and 232 voltage levels are different. This could be being picked up as data when the bus is idle.

Are you running at the max transmission frequency for the baud rate? Have you tried reducing that?

[Indigo]

I may have found a clue in a few replies to your 2021/2022 post, Can EPIC Serial Module GRV-CSERI-4 be used with Node-RED?.

You said,

I rewrote some blocks from my existing program (where I was getting string data and converting to a float), to allow to obtain the data from the new Communication Handle. I can see the stream of RS232 data (50.27, 50.27, 50.27), but it gets chopped down to 50.2 (instead of 50.27) via the block shown. I have changed the 4 to a 5 and get no different result, so I must be doing something wrong?

Philip replied,

What is the length of Four_Digit_String_of_Weight? - maybe it needs to be Five_Digit_String_of_Weight.

And you said,

Bingo. Thank you. It has been a few years since I went thru this program block-by-block.

I’m not sure the issue in the quoted reply is the same issue in this thread, but there are similarities.

Looking at your Opto script may be helpful. If you’re comfortable posting more script context here, we could take a look.

Does anything in the linked thread jog your memory?

[grant1]

Thanks @Indigo for pointing that out. Indeed, I was switching brands of scales and that 4-digit to 5-digit code block did originally trip me up, but this time around I did change that and I do not believe it’s a problem.

I am going to play around more tomorrow (Monday) and will post back what I find.

[tjcrusher]

I think I would just do a find character in substring, look for the N then pull the next 6 characters with get substring and convert to a float. Then it wouldn’t matter if the string length changes a bit.

[tjcrusher]

Here is the simple script to do it.

[grant1]

Thanks so much @tjcrusher and indeed for all the ideas & feedback. We are moving the equipment today so it’s powered off, but will get at it tomorrow & Wed and report back on any progress we make.

[grant1]

Ok, I tried to analyze the MSG_RECEIVED a bit more closely, so set up this small loop and I am not seeing the same thing as I reported last week. Instead, in addition to the standard “expected” message length of &NxxxxxxLyyyyyy\ckckCR I see regular messages that appear to be just fragments of the last string’s message. I do not see a “pattern”, but it definitely is not perfectly outputting the same number of characters (sorry for the poorly legible video)

Not being that familiar with this, but should I include the block “Set EOM Terminator to 13” in the loop? I thought that step was needed only at the beginning and once done, I could just receive the RS-232 data.

@Philip: Yes, the Rice-Lake’s serial output is direct wired to the CSERI serial module of the EPIC (about 2 ft of shielded wire). I can try futzing with the transmission frequency and baud rates. Having looked over the other sections of the manual, I am thinking RS-485 would have been a better way to go (was only using RS-232 because the last scale had that, and did not offer RS-485).

[philip]

You’re clearing the receive buffer mid transmission, so the next receive is getting the end of the one you cut off.