Home› AMX User Forum› AMX Technical Discussion
Options

interpreting serial data

w_hariw_hari Posts: 15
in AMX Technical Discussion

Hi.

I am trying to read data from a Digital Power Meter which I transfer via RS422 to a NI-3100.
I expect 123 HEX-values each second, starting with 7ea079cf

With

DATA_EVENT[dvSmartMeterRS422]
{
STRING:
send_string 0, "itoa(length_string(DATA.TEXT)),'@RS422: ', DATA.TEXT"
}
I receive strings between 40 and 60 characters, where send_string returns ie.:
Line 109 2020-08-19 (17:50:54):: 52@RS422: $F6$FEr$B2$1E$06$91$F2$A4$AE$F3$FA

Device Notification returns:
Line 91 2020-08-19 (17:50:54):: String From [5001:5:1]-[ $F6$FEr$B2$1E$06$91$F2$A4$AE$F3$FA$00$0B$1A$97$072$E7"!$FCR$8At,$B2r$8C$88;$14$88$A1$C0$8A$15$1E'd)$BA:$9C&Ys$89; ]

So, everytime a '$00' occurs, the DATA.TEXT is cut with send_string and those are no HEX-values either.
Tried it with RS232 - same results. Any suggestions?

thanks,
Harry

Comments

  • Options
    richardhermanrichardherman Posts: 389

    Netlinx diagnostics is not displaying the string correctly. If you have a string that contains a 'null' in it, you will see all the bytes up to it, and everything after that isn't displayed. As you found, this works correctly in 'notifications', but not in 'diagnostics', that you are using with 'send_string 0'. So, the string IS there, it's just not displayed correctly.

    For the controller there is no such thing as a HEX, ASCII, or binary character. That's just the way we humans interpret them. Notification is trying to help you here by displaying the hex as an ascii character when it can.
    In your case you can disable this behaviour in: 'settings' > 'preferences' > 'diagnostics' > 'display as...'

  • Options
    w_hariw_hari Posts: 15

    Found my hardware problem and finally I receive my HEX-values as expected in 'notifications' like this example:
    String From [5001:5:1]-[$7E$A0$79$CF$00$02$00$23$13$D9$86$E6$E7$00$7E]
    Now I have the problem, how to handle them, since I cant interpret the corresponding CHAR-values but only the HEX-values. There is a HEXTOI() but no CHARTOHEX() for example...
    I created a buffer and use GET_BUFFER_CHAR(RS422_buff). But what data type do I have to put the buffer into, so I finally have a variable data = '$7E$A0$79$CF$00$02$00$23$13$D9$86$E6$E7$00$7E' ?
    Tried it that way, but i dont get what I expect.

    stack_var char frame[15]
    stack_var char buffer
    stack_var integer x

    for (x = 1; x <= 15; x++)
    {
    buffer = GET_BUFFER_CHAR(RS422_buff)

    IF (x=1)
{       
IF (buffer = $7E) // found start package
     frame[x] = buffer
ELSE x=0
}
ELSE IF (buffer = $7E) // found end package
{
frame[x] = buffer
break
}
ELSE 
{   
frame[x] = buffer
}

    }

  • Options
    richardhermanrichardherman Posts: 389

    Not sure again what you mean with "what data type do I have to put the buffer into". Most likely there is no conversion needed: 'A' = $41 = 65 = 100 0001, they are all the same to the program, it's just presented that way for us puny humans... B)
    A char array is fine, the value of each won't exceed 255 ($FF). Of course, no idea what the protocol asks for, so no idea howto interprete the data.

    It seems like the array length is not defined after you filled it. You set a max length of 15 at define time, but if you fill an array one value at a time, the effective length of the array stays at 0, although it will contain the right values. If you add 'set_length_array(frame,15) after the 'for' loop, the array will probably be fine.

Sign In or Register to comment.