Created Date: August 08,2011

Created by: franji1

You 're getting $FA2 in ASCII

1. Is the dollar sign part of the ASCII text, or are you just using that to show these are ASCII characters (and not hex/raw). That is, is the buffer

ASCII HEX

'$ ' 0x24

'F ' 0x46

'A ' 0x41

'2 ' 0x32

or is it

'F ' 0x46

'A ' 0x41

'2 ' 0x32

without the '$ '?

2. Exactly what value are you expecting? 2FA? A20F? AF02?

Give us one or two examples each of 3 and 4 digit values of what you receive and the result you need.

3. Is it possible to get 2 (or less) digits? 5 (or more) digits?

Created Date: August 10,2011

Created by: HobieCat

I figured out a way to accomplish the task. It seems like it would be a common thing people would need to do(like get ascii data from a scale and need to do math with it) but apparently there are not ladder commands to handle this kind of thing, so the best answer is - get a co-processor card, but I have a fairly simple application so I'm doing this:

I get some ascii data like this:FA02 with the AIN box, in the AIN box I swap all bytes so it looks like this:AF20 (displayed as text in dataview)

A and F take up the first mem slot, I'm using V5001.

2 and 0 are in V5002 (still as text)

Then I use the the ATH command to put the bytes in V5010, in the ATH conversion the 32 bits of 2 mem slots are compressed to 16 bits, and reversed, so in V5010:02FA (displayed as Hex in dataview).

Then I use the SWAPB command on the 2 bytes and 'swap all ' option so it swaps "02 " with "FA " and I end up with:FA02 (displayed as hex in dataview).

So that works with 4 digits just fine, but when I have 3 digits like FA0 I end up with:FA0A (displayed as hex) because there's trailing zero in my method. I get around it by using the "Data Destination " address assigned in the AIN command to get the number of bytes sent, so If it's 4 digits I don't do anything, if 3 digits are sent I add an extra step and use the ROTR command set to K4 to remove the trailing zero.

This will work for my application but this would be a real headache if the number of digits could be 2-5, maybe 7 if we needed some decimal places. And if there is a stream of data where each piece of data might have different numbers of digits and you are trying to figure out where leading and trailing zeros will end up in relation to the separators, big problem.

Created Date: August 10,2011

Created by: Bob S BN

Not sure if this idea would help you or not, but the only time I messed with ASCII from a scale to a DL06 I dealt with only 2 digits per AEX box.

AIN box to bring the whole string in, then an AEX box to move out the two digits left of the decimal out to another VMEM, and another AEX box to move out the two digits to the right of the decimal point to a different VMEM.

Just a thought, hope it helps,

Created Date: August 07,2011

Created by: HobieCat

I'm receiving 3 or 4 digits of ascii data with the AIN box just fine and getting it into a vmemory slot(s) but I'm having trouble converting from text data to Hex data and putting it in a new vmem location as a hex value. I'm trying ATH. My problem is that it reverses the digits so the number is obviously different. I could just send the digits reversed and that works when the hex value is going to be 4 digits, but if it's only 3 then I have to put in a leading 0, then that leading 0 ends up on the end of the number making something like $FA2 become $FA20, which makes sense, but doesn't make my machine happy. I understand(I think) why the digits are reversed with the MSb and LSb between data types and all that, but it seems like there is probably an easy way to handle this, like they have the LDA instruction to load address as octal and it does the hex conversion automatically, but I can't seem to find the instruction. I tried SWAPB, that makes the $FA2 I send become $AF02, again I understand why, 16 bit words, 8 bit bytes and all that.

Does anyone know how to receive 3-4 digit Ascii data and get it converted to HEX keeping the byte order straight?