hex send problem
vladimirk
Posts: 4
anybody can help me with hex send issue
if i send from netlinx or telnet : send_string 1:1:1,"$81,$73,$01,$05"
actually i send this string : [$81s$01$05]
if i send from netlinx or telnet : send_string 1:1:1,"$81,$73,$01,$05"
actually i send this string : [$81s$01$05]
0
Comments
They are both the same thing, it?s just the way they are displayed.
its correct that $73=s, but the divice that i send to should recive a string at hex.
when i send under than $20 and over than $80
for example: send_string 1:1:1,"$73" the controller send to port 1
send_string 1:1:1,"$05" the controller send to port 1 [5]
i cant understand why a week ago it worked properly, without making any change.
for example: send_string 1:1:1,"$81,$73,$01,$05" the controller send to port 1 [$81$73$01$05]
and the divice worked fine.
For now when i send: send_string 1:1:1,"$81,$73,$01,$05" the controller send to port 1 [$81s$01$05]
the divice doesnt work.
What Joe is trying to say is that four bytes are always four bytes. There's no such thing as an ASCII byte or a hex byte. Each byte has a value between 0-255 (decimal), $00-$FF (hex). Some of those values happen to be printable ASCII characters, and AMX defaults to showing those as characters.
"$74,$65,$73,$74" is the same four bytes as "'test'", and both result in sending the same thing out the serial port.
I have ran into one device (which escapes me at the moment) that actually wanted an ascii string spelling out a hex string. It was creepy.
the ascii string was something akin to '0h00,0h25,0h5F' and then followed by a real <CR> That one threw me for a loop for quite a while. The engineer at the manufacturer said it was more secure. I still ponder that statemt... I've been blown off before, but never so blatantly...
It was the equivalent of me telling our designers, "Ah, well, I can't tell you. It's highly electrical and dangerous."
"Send zero, h, and then two zeros. It's a lowercase h."
Ha!
There's always that lonely feeling when you throw out something like that and get nothing but increadulous stares back...
Unfortunately, you can't easily run this baud rate at distances over 40-50ft with out having all sorts of issues.
By the way, the longest control command consisted of about 12 characters as I recall. Data coming back from the unit was about the same 12-15 chars. Lastly, they indicated that some control systems might send data to quickly and they recommended putting in a delay between commands being sent.
Jeff