Help with COM Port

[Subquantum]

I am having a problem with the com port module. I am sending data via RS232 with no trouble, but when receiving data I am getting extra digits.
I am sending a two byte string, carriage return, four byte string, carriage return, running in a 500ms loop to flowstone via rs232. the first string is an identifier, the second string is a changing a/d value from a microcontroller. MY idea is to eventually send multiple A/D values to flowstone and have them identified by a ruby case statement then routed to the appropriate numerical front panel display, but i have not been able to get a single A/D value read.
with both a hyperterminal and with the microcontroller debug window I am receiving:
VB
1010
VB
1009
VB
1011
......ect, Great, this is what I am expecting.
However in flowstone I am receiving:
VB
1010
VB1
1009
VB0
1011
.......ect, I am getting an extra one or zero tacked on to the VB I'm sending to flowstone. Any help would be much appreciated.

[Tronic]

Tried with "RxTerminator" setting with value "0"(zero)?

[Subquantum]

I did not try setting the RX terminator to zero, but wouldn't that just cause the drop any value after a zero and not prevent an extra digit if its a one?

[tulamide]

Let me start by saying that I have no experience with external modules, either via RS nor USB.

However, when looking at your log-screenshot, it appears to me that the last digit of the 4 byte string gets appended as a 8-bit number after the 2 byte string. That looks a bit as if the cache or queue isn't set up correctly, something like that. As if it replaces a sent 4 byte string with the incoming 2 byte string, but leaving the rest of the previous 4 byte string in there.

I hope you can follow this thought, because I see that I have difficulties to describe in english what I see.

Here's a try to visualize it:

(r means carriage return)
incoming: VBr
incoming 1010r, overwriting VBr => 1010r
incoming VBr, overwriting 1010r => VBr0r

etc.

Maybe that's the issue?

[Subquantum]

Tulamide,
Yes, I noticed that also. I have been trying to resolve this in the queue, but this is the closest I have got so far. Since this would be an issue for anyone reading more than one sensor via the comport, I know someone has a better method of doing this than I. I am using the carriage return as an RX-terminator to deal with the two different string sizes.

[tulamide]

I think it is the issue. If I understand it correctly, you've set up a CR as 8-bit ASCII on your module (ASCII 13)? Then in Flowstone you are using a conversion from the Newline prim. The Newline returns a 2-byte-character (CR + LF, ASCII 13 + ASCII 10). Although the ASCII prim should only interpret the first char of a string, I am not sure if it works reliably. So, here are three things to try:

1) Send an integer 13 directly instead of the NL/ASCII construct, just to be sure.
2) You could try to set NoNULL to true.
3) You could try what Tronic asked for.

Regarding 2) and 3), the data is sent as a series of ASCII chars. There's a difference between 0 and NULL. The first one is represented by ASCII 48 while NULL is ASCII 0.

[Subquantum]

tulamide,

Those are some great ideas! I will give them a try.
Thanks for the help.

[Subquantum]

Ok, I finally resolved the issue.

for some reason, it seems the Com port module does not like using a carriage return(acsii 13) for an RX-terminator.
instead of sending a carriage return after each data set, I picked an arbitrary character that I knew I was not going to use. In this case I picked "T" for the Rx-terminator.
for example I sent via a micro controller:
VAT
1010T
VBT
1009T
and in the flow stone receive queue I get:
VA
1010
VB
1009

It seems that the Com port uses a received carriage return as an actual carriage return and places each received data set on a new line instead of appended next to each other horizontally.

Also, using zero or any other ascii line instruction did not work as a proper Rx-terminator.