Adding variables into send_strings

vegastech

I am trying to send out a variable-type string that uses a devchan to populate one of the otherwise-fixed number string portions:

SEND_STRING dvDVD, "'CMD,[1:',get_last(dcDvdBtns),']'" 

When the get_last is not in the string, it would look like this:

SEND_STRING dvDVD, "'CMD,[1:1]'" 

I am trying to be able to change the 2nd numeric based on the dcDVDBtns array, which has 10 items in it. The get_last code above compiles fine, but in the diagnostics screen, I see the following:

Line     21 (23:51:49)::  CMD,[1:$01]

I tried adding an ATOI in front of the get_last, but then the $01 disappeared completely! Anyone take pity on me?

Dries Kaspers

try adding ITOA....

kbeattyAMX

It's probably best to understand what's happening here. Processors do not understand the ASCII Letters that we use. So when you surround ASCII letters by quotes it converts the letters to the HEX representation.
'HELLO'
"$48,$46,$4C,$4C,$4F"
When you watch feedback in Netlinx you can have it displayed as ASCII,Hex,or Decimal.
So if you have..
'HELLO1' it's "$48,$46,$4C,$4C,$4F,$31" in Hex
'HELLO',1 it's "$48,$46,$4C,$4C,$4F,$01" in Hex
The processor is not going to display decimal 1 as 1. It's going to try to interpret the value in ASCII and $01 is not a printable character. It's actually SOH (start of heading).

So everything depends on the receiving device, whether it wants to see ASCII (interpreted Hex) or straight up Hex (the receiving won't try to convert it to ASCII). In your example it seems as if the receiving end wants to see ASCII. So...

SEND_STRING dvDVD, "'CMD,[1:',get_last(dcDvdBtns),']'" becomes
SEND_STRING dvDVD, "'CMD,[1:',get_last(dcDvdBtns)+$30,']'" if dcDvdBtns is 0-9 or
SEND_STRING dvDVD, "'CMD,[1:',ITOA(get_last(dcDvdBtns)),']'"

which would change the integer to an ASCII string so 11 becomes "$31.$31"

It's also good to remember RS232 communications always transfers packets of information in bytes. The bytes are normally 8 data bits + 1 start and 1 stop bit for communication purposes. Because you have 8 data bits, a byte is used (8 bits to a byte). And a byte is represented as Hex because it neatly handles 1 bytes which is 8 bits. Hex is 0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F and that is 16 possible values. Neat isn't it. So 2 value places in HEX (1's and 16's) will handle 256 values $00 to $FF. That all of the possible combinations of 8 bits and that's all is needed to describe ASCII protocol. That is why ASCII '11' has to become "$31.$31" which in binary is first byte 00110001 second byte 00110001.

vegastech

So does that mean that the string I am sending would therefore work, and it's just the way the processor is displaying things that makes it seem like it is sending the wrong string?
Or would I perhaps be better off simply converting the string I want to send into a CHAR, and sending the CHAR?

kbeattyAMX

vegastech wrote: »

So does that mean that the string I am sending would therefore work, and it's just the way the processor is displaying things that makes it seem like it is sending the wrong string?
Or would I perhaps be better off simply converting the string I want to send into a CHAR, and sending the CHAR?

CHAR is a typing for a variable defining that the variable will only take up 8 bits of memory (0-255). It does not change the value in the variable. As I mentioned before, the solution depends on when the receiving device wants to see. If it wants to see 'CMD,[1:1]' then you will need to change the decimal to ASCII. So the number 1 should be $31 to represent ASCII '1'. the easiest way is to use ITOA(variable) So it looks like this "'CMD,[1:',ITOA(variable),']'"

vegastech

Working!

I don't know how or why, but for some reason (probably a typo) the string would not send correctly no matter what I did. I created a CHAR variable, pasted the same data inside it, and my debugger is now showing the correct string. I must have done something different, but who knows with all this typing! When I look in netlinx diagnostics, it looks correct. I thought I had already added an ITOA, but I suppose that shows my level of expertise..Thanks!