Thanks Daba.
Yeah I understand that the there is no such thing as a Hex tag or decimal its just a view thing. But with that being said when something is being messaged and it originates (or needs to be written to) in hex format it is different. Let me give a couple examples to better explain myself (I hope) and I have two different applications that have me looking for a solution.
Application one:
I have both analog input (1771-IFE) and analog output (1771-OFE) cards in a rack that I am using as remote I/O (RIO)
I have MSG instructions doing the BTW and BTR's for these to configure the cards and read and write values for the input and output cards. Word 5 and 6 for the BTW to one of the Input cards set the scale for this channel. The source for the MSG is a portion of a large array of INTs, not every word in the array is being the same way so its base view is decimal.
The minimum Scale is zero (decimal style: 0, Hex style: 0) that’s pretty simple being zero.
The maximum Scale is 4095 (decimal style: 16533, Hex style: 16#4095) that’s were it causes confusion, because the value I want to display is 4095. In this large program I have a mix now of ControlNet racks and RIO racks. I want all my data to look the same to help Maintenance and operations to be able to troubleshoot more efficiently.
Application two:
I have a couple RFID readers that I am installing to track metal pallets through flash cooler. (1) The reader data coming back to the PLC is in a SINT array with each SINT being a two digit number hex (00-99) that I need to Concatenate together into one long number (dint or string I don’t really care which) to give me the pallet number (Each pallet has a unique 8 digit identifier). (2) So I need to take the 16#99, 16#99 16#00 16#00 and make it read 00009999. (2) How do I strip out 16# and the hex number only?
Does that make any sense? I've read it back and to me it makes sense but I wrote it so it should…..
Long post - bear with it....
Application 1.
I feel your pain... having worked on many "legacy" upgrades to ControlLogix where they retained the existing 1771 IO chassis, I came across the same issues. I resolved them all by creating UDTs for each BTW/BTR "flavour", naming the elements and component parts, and selecting the correct "View Style" for data that wasn't decimal. No need for the manual anymore, the UDT member descriptions can pass-thru onto your tags when viewing the logic, for your people to see numbers as they want to. You just need to be careful to "pad out" with dummy members where necessary to keep the UDT structure exactly matching the BTW/BTR INT array bits and bytes. I can't remember if I had to COP between UDT tags and plain vanilla INT arrays for the messages, or whether I just MSGd the UDT tag directly, I can't get at the code now....
Application 2.
Lets deal with a few points in your post, numbered as above....
(1)
00-99 doesn't look like a HEX number to me, it looks like the SINT is containing a 2-digit BCD code. You use the HEX View (16#) to display BCD numbers, because 0-9 is the same bit pattern in both numbering systems, confusing I know, but they didn't provide a "BCD" view, only hex (16#).
Even if they are HEX digits (which go from 0 to F, that's why there's 16 of them), the FRD in ControlLogix is flawed and incorrectly converts them to decimal, unlike the PLC5 and SLC which treats a BCD digit >9 as an overflow.
SLC :-
1001 FRD = 9
1010 FRD = 32767 and Overflow flag set
to
1111 FRD = 32767 and Overflow flag set
Logix5000 :-
1001 FRD = 9
1010 FRD = 10
to
1111 FRD = 15
This flaw might work to your advantage if the data is Hex, and not BCD.
(2)
You don't need to "strip" the 16#, it is put there by the programming software to tell you what number base you are viewing the number in. It is not contained in the data....
(3)
So the number you need to extract is stored as two digits in each of four SINTs, but it looks like they are in reverse order...
eg. for 00009999 decimal...
SINT[0] = 16#99
SINT[1] = 16#99
SINT[2] = 16#00
SINT[3] = 16#00
We can easily create a 32-bit BCD number from them using 8 BTD instructions, taking 4 bits at a time from the SINT array and putting them into 4-bit fields in a 32-bit DINT.
We won't need to be bothered if bit 31 gets turned on, since we will immediately convert the bit pattern to a decimal number with FRD.
Your BTD instructions will need to be coded to pick up the correct 4 bits from each SINT, since I can't tell (because you used example 00009999) if they are low-byte/high-byte or high-byte/low-byte orientated. You can easily see which by reading in a pallet number "12345678".
If it works out correct for your incoming data, the 8 BTD instructions can reduce to 4, moving 8 bits at a time.
Lastly, have you searched the knowledgebase for Add-On Instructions to do the conversion ? I'm sure you're not the first to need this.