Add Array Elements gives wrong answer

[dkl234]

Back again. I'm performing VISA serial read/writes using strings. I need to include a checksum each time I write a command.

After searching around I thought I could input a string into a byte array and this does do the ascii to number conversion.

The problem I'm having is when I pass the byte array to the Add Array Elements function the result is wrong. For example if I

were to take a command, #0%PVR,1^ I would expect 555 as the result but instead I'm seeing 43. Likewise if I form a command

#0%XXX,1^ I would expect 571 as the checksum but instead I get 59. However many times I loop at least the wrong numbers

are incrementing by one.

Attaching the byte array to an Index Array and watching every index, the ascii conversion in each element of the byte array is correct.

As is the byte array length.

Q1: Does anyone know what I'm doing wrong (seems like a straight forward function?

Q2: I haven't been able to get For Loop to work to do the summation (curse of being a newbie), any ideas on what that would look like?

Pardon the vi, it is pretty crude.

Thanks,

Dave  

[kbbersch]

You're problem is your byte array is a U8, which won't hold a number larger than 255.

[altenbach]

Insert a "To I32" before taking the sum if that's what you actually want.

Could it be you need to calculate a checksum instead? That would be something different entirely. 😉

(... and make sure all indicators match the datatype of the wire. You have a lot of red coercion dots. You also don't need to wire the indices of index array if they are in order starting with zero. Why not use an array indicator instead?)

[dkl234]

Thanks for the help.

altenbach, the To I32 did the trick as you suggested. As for using an array indicator vs index array, I've never seen labview until this

week so I'm to green to know what to use, when to use and where to use. Well, slowly finding my way around (putting the puzzle together).

And yes I meant I need to compute a checksum and add that to the end of the string, which is working now.

kbbersch, I'm aware an unsigned byte only gives me up to 255 but in the examples I came across strings fed into a byte array seemed

like the way to go. I don't expect to encounter any characters that translate beyond 255 (we own the device that I'm interfacing

to through VISA serial, and therefore the character strings). But really this is not a good answer. Add or change something in the future

and we could have a comms failure. I've seen some examples of type casting characters but in trying to expand to a string I

was hitting to many failures and stopped.

Thanks again for help (and if you or others know of ways to handle strings w/o the U8 limits?).

Dave

[altenbach]

---

dkl234 wrote: 

Thanks again for help (and if you or others know of ways to handle strings w/o the U8 limits?).

---

Each character of a string is 8 bits (and can thus have a value from 0..255). If you need more bits, you need more characters.

[kbbersch]

Sorry, I should have elaborated on my answer.  At least altenbach explained.

U8 is the correct conversion for string characters.  You can always convert to a U16 or U32 (or any other data type) before doing any manipulation on the U8 data.  The problem you were having was that as you totaled all the values LabVIEW just truncated the result so it fit in a U8.

[dkl234]

Thanks to you both.

Now I'm starting to get a little insight into labview. Completely missed the summation to a U8.