Question sending HEX to device

undrtkr

I'm going to be controlling a couple of Samsung displays. Their protocol is HEX with a checksum and I'm trying to calculate the checksum through code. Basically to get the checksum you add bytes 5-2. Here is what I have so far

DEFINE_VARIABLE
integer byte[6]

DEFINE_CALL 'Checksum'
{
byte[1] = byte[5] + byte[4] + byte[3] + byte[2]
byte[1] = byte[1] BAND $FF
SEND_STRING dvDISPAY, "byte[6],byte[5],byte[4],byte[3],byte[2],byte[1],"
}

DEFINE_START
byte[6] = $AA //Header Byte
byte[5] = $00 //Command Byte
byte[4] = $FF //Display ID
byte[3] = $01 //Data Length
byte[2] = $00 //Data Byte
byte[1] = $00 //Checksum

DEFINE_EVENT
BUTTON_EVENT[dvTP,1]//Power On
BUTTON_EVENT[dvTP,2]//Power Off
{
PUSH:
{
SELECT
{
ACTIVE(BUTTON.INPUT.CHANNEL = 1):
{
byte[5] = $11
byte[2] = $01
}
ACTIVE(BUTTON.INPUT.CHANNEL = 2):
{
byte[5] = $11
byte[2] = $00
}
}
CALL 'Checksum'
}
}


Now, this code calculates all bytes correctly as I watch the byte variable in debug. However looking in netlinx diagnostics it only sends the full string on power on which is "$AA$11$FF$01$01$12". Power off sends only this "$AA$11$FF$01". The only thing I can think of is byte 2 is $00 in the power off command but am not understanding why it's behaving this way. If someone could shed some light and offer some changes to make it work correctly I'd appreciate it.

.

DHawthorne

Your code works, the problem is in whatever you are using to monitor your serial port output. $00 is a null character, and programs like hyperterminal just don't display it, they skip right over it. Using a COMM monitor that shows the output in hex, it looks fine.

Oh, and I htink you really want byte to be a char array, not integer. If the checksum adds up to over FF, it may not give you what you think you are getting.

Chip Moody

That's acutally not a horrible way of doing it - by using an integer array instead of a char - easier to do math on... (Not how I'd do it, but still not horrible!)

And you can loose the BAND $FF statement - when you put an integer variable in as part of a string like that, the upper byte is automatically ignored - the OS understands that only the lower 8 bits can be used in string construction that way.

- Chip

Chip Moody

Netlinx diagnostics is doing you a disservice here - one that I've hated for a really long time. If you have a string going out that contains a null character in it, you will see all the bytes up to it, and everything from the first null and beyond is simply skipped.

Other <cough> vendors' diagnostic software deals with these much more nicely...

If you had a PC running the right terminal software (like the one provided by that other vendor, in fact) connected on the receive end of that cable, you would have a few options for viewing strings like this. You could, for instance, enable a mode that takes ANY byte outside of the printable ascii set and show its hex value instead. Extremely handy.

- Chip

undrtkr wrote:

Power off sends only this "$AA$11$FF$01". The only thing I can think of is byte 2 is $00 in the power off command but am not understanding why it's behaving this way.

undrtkr

Ugh, I completely forgot that it won't show that. That's what I like about the other vendor's diagnostic software. You just check "Show as Hex" and prestro. So if I were to do a char array I would need to designate each byte like byte[6] = "AA" correct? Then HEXTOI each byte to add them for the checksum?. So my DEFINE_CALL would change to this:

LOCAL_VAR nByte

nByte = HEXTOI(Byte[5]) + HEXTOI(Byte[4]) + HEXTOI(Byte[3]) + HEXTOI(Byte[2])

SEND_STRING dvSERIAL1, "BYTE[6],BYTE[5],BYTE[4],BYTE[3],BYTE[2],nByte"

So even if nByte ends up being over FF the SEND_STRING won't show the upper byte? Is there a reason why I should do a char array or is it just a preference thing?

Joe Hebert

Use Notifications

If you monitor the strings going out the RS-232 port in the Notifications window you?ll see the data properly. The Notify window doesn?t discriminate against NULLs like the Diag window does. I hope this bug gets fixed in the next release.

undrtkr

Joe Hebert wrote:

If you monitor the strings going out the RS-232 port in the Notifications window you?ll see the data properly. The Notify window doesn?t discriminate against NULLs like the Diag window does. I hope this bug gets fixed in the next release.

Well I'll be..your right it works in notifications but not in diagnostics. Didn't even think to try that. Thanks Joe!

DHawthorne

undrtkr wrote:

Ugh, I completely forgot that it won't show that. That's what I like about the other vendor's diagnostic software. You just check "Show as Hex" and prestro. So if I were to do a char array I would need to designate each byte like byte[6] = "AA" correct? Then HEXTOI each byte to add them for the checksum?. So my DEFINE_CALL would change to this:

LOCAL_VAR nByte

nByte = HEXTOI(Byte[5]) + HEXTOI(Byte[4]) + HEXTOI(Byte[3]) + HEXTOI(Byte[2])

SEND_STRING dvSERIAL1, "BYTE[6],BYTE[5],BYTE[4],BYTE[3],BYTE[2],nByte"

So even if nByte ends up being over FF the SEND_STRING won't show the upper byte? Is there a reason why I should do a char array or is it just a preference thing?

You don't need to change a thing except the type declaration, just change it from integer to char. I ran a copy of your code that way on my test NetLinx, it works fine. The double quotes are only needed if you are assigning a string, not a single character to an array.