How to copying bits from a float to bit file using AB.

Re: Ken take a break

Peter Nachtwey said:

To the RSLogix programmers:

RSLogix register file data windows should remember the size, columns and number format when the window is closed so that it will be restored to exactly the state as when the window is reopenned. Better yet would be to allow each word to be formated individually so that some can be in hex, others in decimal and others in binary. These suggestions would save much time of the users of RSLogix.

Click to expand...

I'll second that request!... :nodi:

And along the same topic...

Is there some setting or "trick" to make RSLogix automatically open full screen without having to click "Maximize" each time it's started?... zzzzz

beerchug

-Eric

window formatting - play around under "File" - "Load/Save Workspace"

also set up a Custom Data Monitor - you can right-click and set the radix, etc.

for open up with max screen: open rslogix500 - use restore button to make it NOT maximized - then stretch and resize the window manually to make it as big as possible - then do "window" - "arrange" to fix the toolbars and the project to fill screen - then maximize the rslogix500 window - then do "window" - "arrange" again - now shut down rslogix - make sure your icon is set to run maximized -

now it should open up full screen from now on - unless i left something out

gotta go

Smuggling bits inside a Float

I couldn't stay away... I went to the office and got out a 1764-LSP Series C FRN 6.

I can't say precisely why the COP instruction in the enhanced MicroLogix controllers doesn't function exactly like the one in the SLC, but then another instruction was needed anyway to handle the un-SLC-like Function Files in the MicroLogix.

The Copy Words instruction (CPW) will move data around in 16-bit Words without interpreting it as values.

If you perform the following:

Copy Word (CPW)
Source: #F8:0
Dest: #B9:0
Length: 2

Then B9:0 and B9:1 will contain all the individual bits that make up an IEEE 754 floating point number; Sign Bit, 8-bit Exponent, and 23-bit Mantissa.

If your motion controller packs bits into a "floating point" register in a DF1 packet such that, for example, bits 07, 11, 20, and 24 are =1 and the rest are =0, the Floating Point register will contain the value 2.645472 e-38.

You won't use that floating point value as a value in your program, but you can unpack it with the CPW instruction to get to the bits inside.

Sign = 0
Exponent = 0000 0010
Mantissa = 001 0000 0000 1000 1000 0000

Floating Point Value = 2^(2 - 127) X (1 + 1/8 + 1/4096 + 1/65536 )

= 2^-125 x 1 + 0.125 + 0.00024414 + 0.00001525902)
= 2.350988e-38 x 1.12525937
= 2.645472e-38

The CPW instruction works the opposite way, too, I just don't know if the MicroLogix can correctly send a Floating Point value via DF1 if it's an invalid number (which you could do, just packing bits into it).


Of course, the numbers that made my morning were just good old decimals.... 34 - 24 , and 8 - 0. Take that, Bobby Bowden !

Ron Beaufort said:

make sure your icon is set to run maximized

Click to expand...

Duh, how stupid am I? Yup, that was the trick Ron... Thanks!

beerchug

-Eric

Thanks guys

Ken, you shouldn't have gone to the office unless you were also trying to escape some honey dos. The weather was too nice to stay in an office.

Ron, I will trying your RSLogix tricks too, but on Monday.

I let all know how it works on Monday.

Peter,

After reading the AB Manual, here's my take on this command...

COP #F8:41 #b3:2 64


Your expectation is...

• 
  Copy from Float File to Bit File...
  
  Source starts at Element 41 of the Floating Point File,
  
  Destination starts at Element 2 of the Bit File

ASSUMING that the Basic Element of the Bit File is a BIT,

• 
  Copy 64 Bits from the Float File to the Bit File

The AB Manual seems to be somewhat inconsistent in its description of what an Element Move is and what the basic Element in a file is.



This shows that the instruction moves data in word-chunks and that the number of words moved is determined by the destination file-type.

It certainly seems reasonable to think that the basic element of the Bit File is a bit.

However...


This shows that the Bit File consists of 256 1-Word Elements (4096 bits).

You can refer to a specific...

• 
  Bit-Location B3/BIT
  
  Element/Bit Location B3:ELEMENT/BIT
  
  Element Location B3:ELEMENT

In the table above, something seems to be wrong with the B3:9 reference.
Seems to me that B3:9 should be referring to Element-9 (16-bits).

Now, as to the length (size of the moved data)...


This is where some confusion might come in...
This shows that "Length" is the Number of ELEMENTS you want to copy.
The maximum length is based on the destination file-type. The description above indicates that the operation uses word-chunks. Referring back to the second figure, the Bit File consists of 256 1-Word Elements.

So, here's how I read your command...

COP #F8:41 #b3:2 64

Copy from Float File to Bit File...

• 
  Source starts at Element 41 of the Floating Point File,
  
  Destination starts at Element 2 of the Bit File
  
  Copy 64 ELEMENTS from the Float File to the Bit File

Since the Bit File appears to be defined as 256 1-Word Elements, I expect that your command will try to copy 64 Elements (WORDS) or 32 Floating Point Numbers to the Bit File.

B3:2 and B3:3 will contain FP number-1
B3:4 and B3:5 will contain FP number-2
B3:6 and B3:7 will contain FP number-3, etc....

Doing it the way you were doing it should not have produced the data size errors.
UNLESS... S:24 was not set to ZERO! S:24 is an OFFSET Value. This value is applied to the base address and might very well cause your data to try to write beyond the File Boundary... thus causing Data Size Errors.

Since it appears you are trying to move only 2 Floating Point numbers, I suggest...

COP #F8:41 #b3:2 4 <<--- use length equal 4 instead of 64

Peter,

I’ve come up with a much simpler way to skin the cat than my first attempt.
[attachment]
This routine simply makes use of our ability to access the individual bits within a Long data location. You’re still going to be limited to only 24 usable bits within your floating point “status” word – and I’ve come to accept that as a “functional” limit. I’ve got some ideas on how to use all 32 bits but we’re talking about some major hoop-jumping.

Sorry I didn’t come up with this “bit-to-bit” method earlier. I HAD experimented with the Long data type – but didn’t realize that the “scrambling” of the bit pattern was due to using more than 24 bits – NOT due to any inherent fault of the “float-to-long” move. The “sign-exponent-mantissa” format I mentioned in my earlier post threw me off the scent. My earlier “looping” attempt might be fun and educational for our beginner readers – but I’m sure that your customer is going to like this dirt simple “bit-to-bit” approach much better. Thanks for an interesting challenge.

Ron,

You and Peter seem to be moving onto other methods for accomplishing something other than Peter's original question.

You must have read my post. In terms of the original command that Peter tried to use,

COP #F8:41 #b3:2 64

am I all wet in my understanding of what I read and what I posted?

Yo, Terry,

My understanding (certainly subject to error) is that Peter has a floating point word arriving in a MicroLogix1500 via a MSG command. That word contains "status" bits which were set off-or-on in the sending device. Once the floating point word has been received, he wants to extract the off/on status of those “status” bits and then use this status to control alarms, etc.

The major problem (as I understand it) is that Peter has found it “challenging” to extract the on/off status of the bits. That’s because the bits within a floating point word are NOT directly accessible. In other words, F8:0/3 is not a valid address - in any AB controller that I know of. Contrast this with B13:0/3 which IS a valid address - of a particular bit (/3) within a word. (Just try to change the radix of a floating point monitor window - it can’t be done because the individual bits within a floating point location wouldn’t make sense in any other radix). So since Peter can’t DIRECTLY extract the on/off status of the bits in the floating point word, I’ve been trying to come up with other ways to squeeze the data out. I came up with one method - based on a looping technique which has served me well in past conversion problems. For example: I’ve used it to convert ASCII strings into decimal values, etc. After I put that program in post #15, I got some sleep and then realized the next morning that there was a much easier way to accomplish the same thing. Which is the program I showed in post #22.

As long as Peter can live with using only 24 bits (of the 32 total) in the floating point word, I think my last post will work just fine. I’ve tested it enough to bet dinner on it - but maybe not the rent.

The reason for the 24 bit limitation lies in the format of the floating point words in an AB controller. I gave a link to the official specification of that format in post #2 of this thread. If Peter needs the rest of the 32 bits too - then I think I can come up with something which will work, but it will take some bit-by-bit analysis of the “sign-exponent-mantissa” format which is shown in that link I gave. I’ll eventually do it whether he needs it or not - just for the personal experience. Like they say, “No pain - no brain”.

In closing, it’s entirely possible that I’ve misunderstood just what Peter needs. Even so, I’ve enjoyed the exercise - and learned quite a few things about the MicroLogix1500 that I didn’t know before. One thing’s for certain: it ain’t the same thing as an SLC - I won’t make that mistake again.

I don’t do Internet at home - and I just dropped by the office to post my latest “answer” to the puzzle. I look forward to taking a closer look at what you’ve posted above when I get to work on Monday morning. I should have a chance to run your suggestion through a MicroLogix and I’ll be glad to post what comes out. As we’re all aware - there can be some major variances between what the books SAY and what the hardware actual DOES. See you around.

I assumed wrong twice!

Terry, you put way to much into what should be a simple answer.

First I assumed that the Micrologic would execute the COP command the same as the the SLC does. The Micrologix will not let one use a COP command with different source and destination types. Second, I assumed the element type in a bit field is a bit, silly me. Instead it is a word or 16 bits. I assumed wrong on both accounts so COP #F8:41 #B3:2 64 will not work. I am hoping Ken's suggestion of using CPW command allows one to copy floats to bits. This would be easy for the users. I haven't used the CPW command before because it isn't in the SLC500 documentation that I have or in the .PDF file that Ron posted a link to. I don't like Ron's suggestion, of using a MOV and picking bits out of a long, is not very clean. I think I would rather reference bits out of a long than add all those rungs. As I said above, I will let all know how the CPW command works tomorrow after I try it.

Yo, Peter,

You said:

I don't like Ron's suggestion, of using a MOV and picking bits out of a long, is not very clean. I think I would rather reference bits out of a long than add all those rungs.

Click to expand...

PLEASE do NOT think I'm offended - I'm not. But I just wanted to let you know that the only reason I added all of those rungs was so that any interested readers could (hopefully) see what was going on - by looking at the resulting bit pattern in B13:1 and B13:0. If I were going to use these "status" bits myself, it would be something along these lines:
[attachment]
I'm 90% convinced that this is as clean as it's ever going to get. We can't (I'm quite sure) access the bits in a floating point directly - we can (I'm absolutely sure) MOV a floating point into a long - we can (I'm absolutely sure) access the bits in a long directly. Seems like this is going to be as good as it gets - but I'm eagerly awaiting an opportunity to learn something new. Again, thanks for an interesting challenge. No reply necessary.

Ron:

The instrtuction that Ken Roach had, using the CPW function, is exactly what Peter needs. It gets access to all 32 bits in the float, without changing the order of any bits.

What Peter has is a 16-word data packet that the PLC is reciveing.
The first 14 words are 7 2-word element floats, and the last 2 words are some status bits.

Due to the limitations on the MSG instuction, he has to put the data packet into a continuous block of registres, and so the bit pattern winds up in a float register.

The value of that eighth float will be meaninless., as it is possilbe for the bit pattern in there to produce an invalid number (in IEEE terms, at least).

The MOV command will not work, because the PLC will try to intrerpet the number in the float, and move THE VALUE to an equivalent value into the Long.

For example, if the ezponent sign bit is set, then the PLC will move 1.2345678 e-7 into the long. 0.00000012345678 is zero as an integer, and the entire bit pattern is lost. You found that out when you determined that 16777215 was the upper limit of the transfer.

That's why it had to be the COP (or in the Micrologix case, the CPW). When mixing data types, the COP doesn't try to interpret the value of the float, it just copies the bit pattern, just as it copies the bit pattern of the lower bits of the T4:0 address when doing a COP T4:0 N7:0 3.


Terry:

Your interpretation of COP #F8:41 #b3:2 64 is correct - this instruction is supposed to copy the bit pattern found in 32 floating point elements to 64 binary word elements. That was the essence of my first post on the subject - that Peter had the length wrong, and so was trying to access data tables that didn't exist.

But that wasn't the problem. The problem was that, in the last two years when AB came up with a Micrologix that had floating point registers, the firmware programmer of the COP command said "Why would anyone want to try to convert the bit pattern of a float into anything? " and so changed what I had thought of as an "undocumented feature" (a fancy way of saying 'bug' - although you show where it exists in the documentation). Then someone pointed out why such a trick might be needed, and the programmer said "Fine, but let's make sure that the user intends to do that - we'll add the CPW instructon for just that purpose."

The COP works, as Peter was expecting it to, in the PLC-5 and SLC series. For Micrologix, you need CPW.

My findings

The CPW command does exactly what I want. It just copies bits and does not try to interpret them. I was worried when Ken said the bits got scrambled. I did a test. I did the following test:

CPW #B3:6 #F12:42 2
CPW #F12:42 #B3:8 2

This copies the bits in B3:6 and B3:7 to F12:32 and back to B3:8 and B3:9. I then changed the bit pattern and made sure that the 32 bits starting at B3:6 were exactly the same as B3:8. I could put bit patterns in B3:6 that are illegal or NaN IEEE floating point vales and the MicroLogix did care. This means I can a float to transfer a 32 bit image without worrying about the PLC faulting on any combination. I still need to check this out transfering data using the message block.

Ron, the first thing I did is look for the data monitor, setup the workspace the way I wanted it and saved it. Thanks.

I am not done yet. Now we have an internal debate as to how we are going to transfer data bits.

1. Ron's method that uses a floating point value to represent and 24 bit out of a long. To use Ron's method on a SLC would limit the number of status bits to 16.

2. Ken's method that uses the CPW command. The bit image in a floating point register would not make sense but the user would be easily able to make use the bits in the bit file.

I like Ken's method because a CPW command is clean and I can transfer 32 bits and I am not limited to 16 or 24 depending on the PLC the user is using. However, this means we will have to make a program change. Surpisingly the motion controller is now set up to work with Ron's method. It will take a lot of convincing to change the specifications.

Do the user's ( potential ) have an opinion?

So, Peter,

Have you tried my "COP #F8:41 #b3:2 4" ?

Or is it the case that the PLC you're using simply won't let it happen? As in, STRONG TYPE CHECKING during the compile.

Real CPU's (using languages that are lower - more powerful- than a PLC Interface) let you make this kind of copy or move any time you want.

The CPU is told to....

COPY BYTE
Grab all the bits you see at Byte-X and copy them to Y

-or-

COPY WORD
Grab all the bits you see at Word-X (X & X+1) and copy them to Y & Y+1.

-or-
COPY LONG/DOUBLE/FLOAT
Grab all the bits you see at Long/Double/Float-X (X & X+1 & X+2 & X+3) and copy them to Y & Y+1 & Y+2 & Y+3

(I know you know this Peter... this is for the benefit of those that don't)

These operations are done WITHOUT CONSTRAINTS!!!

This can certainly be done quite easily in Assembly Language & "C" and a few other lower level languages.

In C++ the source data is "Strongly Typed" and all moves and copies of "Typed-Data" are subject to STRONG TYPE CHECKING. If the "Type" of the Source and Destination don't match, then the compiler chokes and pukes all over you!

There are "CASTING" methods available that convert data types on the fly.

At any rate (after a lot of hot wind), In TI, I can simply grab a byte from somewhere and copy it to location Y. I can then grab a byte from anywhere else and copy it to Y+1. I can then read/use the data at Y & Y+1 as a Word for any function. Or I can read any of those bits as I wish. I can "construct" my Word, Long, Double, or Float (Real) as I need to.

I just need to know the boundaries (location and type-which I define by usage) of my newly constructed "number" and how I need to use it!

The TI method is very much like "C" (better than C++). You have a lot of power, albeit dangerous, but, none the less, incredibly powerful. And if you know what you are doing, life becomes much easier!

So, I look at this problem you brought to the forum.

If the command I suggested, "COP #F8:41 #b3:2 4" (which seems to be legitimate in terms of what you are looking for and in terms of what I read in the A-B Manual), does NOT provide what you need, then I have to wonder if AB uses STRONG TYPE CHECKING like C++, without a way around, as in "C" and TI. Is this so?

Seems to me there must be (or should be) a way to do a native-type-move without File-Type constraints. Could this be what CPW does?

We have worked it out.

Our solution is to use the CPW command to copy status bits to a bit file when using a Micrologix and a COP command as Terry and others indicated above when using a SLC. This will be easy for the user and efficient.

Thanks