From 11:00 PM CDT Friday, Nov 8 - 2:30 PM CDT Saturday, Nov 9, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From 11:00 PM CDT Friday, Nov 8 - 2:30 PM CDT Saturday, Nov 9, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
05-23-2023 08:09 AM
Hi all
It looks like my little VI works OK with word HEX as input but it fails when it has to deal with double word HEX numbers.
E9B2 --> -5710 OK
ADD22 --> 32767 NO! --> I want 711970
Can anyone explain to me why and how can I solve this problem?
Thanks
Solved! Go to Solution.
05-23-2023 08:21 AM
The representation is not ok but even so it will depends of your need.
If representation is i16 (as you have it now) you have a good value (up to your words) for E9B2 but ADD22 iw wrong as going to overflow.
If representation is i32, E9B2 will give 59826 (wrong if I follow well) but ADD22 will give 711970 as you expect.
It is confusing. What are the expected limits values of your input ?
05-23-2023 08:47 AM
You are right: I have skipped a part of the story...
I receive ASCII string from COM port of my PC and I have to interpret it.
In some cases it's OK for me to use word HEX.
In others I have to use double words HEX. How can I do in this last case? Do I just have to change the representation?
Thanks
05-23-2023 09:33 AM
You must have the communications protocol somewhere. The general steps would be:
If you are trying to adapt common code to each data type on the fly, that's making it a lot more difficult than it needs to be.
05-23-2023 09:51 AM
@Lucky-Luka wrote:I receive ASCII string from COM port of my PC and I have to interpret it.
In some cases it's OK for me to use word HEX.
In others I have to use double words HEX. How can I do in this last case? Do I just have to change the representation?
The word "HEX" alone is very ambiguous, often misused, and really does not tell us anything.
When attaching code, it would be best to have a few default values for the inputs, exactly as received from the com port. Or at least diagram constant for your typical scenarios.
(Create an indicator where you receive the string. Run your communication code so the indicator shows the received string. Stop the VI, right-click the terminal, and "create constant". repeat a few times until you have a few typical strings of various length. Save the VI under a new name an attach it here. You might add a label for each constant to tell us what value you expect from it, if known)
For troubleshooting, you should also create an indicator for "remaining string".
Do you have a link to the manual of the device?
05-23-2023 09:58 AM
Thanks for the suggestion.
Let's say that I just have to deal with double word HEX...how can I adapt my VI?
Thanks
05-23-2023 03:05 PM
@Lucky-Luka wrote:
Let's say that I just have to deal with double word HEX...how can I adapt my VI?
Thanks
While there are many definitions of the term word, you probably mean two bytes and thus four bytes per double word. Formatted in hex, each character (0..F) represents a nibble (4 bits), so it seems you want to parse 8 characters into a 4 byte integer. Do you want signed or unsigned? Where (left or right) do you want to pad with zeroes if there are fewer than 8 characters?
The first adaptation would be to change the representation of the type constant to either I32 or U32, depending on your needs and change the indicator accordingly.
so. many. question! It would help if you could do some of my suggestions above.
05-24-2023 09:43 PM
You can do it like this