S7 318 DINT to Real problems

I have to interface to a program that is using DINT data in DBlocks. The DINT is data coming into the PLC and I have to do calculations on these numbers as Real types. My problem is that when I use the DI to R Converter the numbers do not match. At the input the number in DINT is 7 million and something and the Real is 12 billion or so.

Maybe I should convert the datatypes to DINT if this is going to get ugly.

Any suggestions?

Lance

The DTR instruction is pretty straight forward, so I don't think the input and output can possibly be different. Can you post an example of what you are doing?

I do dint and real math all the time, and it works as advertised.

Hi Snydl0ga,

Always trust S7Guy - if he says it works, it works.
So I did a bit of testing (sorry that should read "a little testing" - DI_R testing using bits is tricky!) and I think I can see the same symptom as you reported.

I took the the DI_R instruction and applied MD0 and MD4 as the input and output respectively. Both addresses were deliberately left undeclared in the symbol table - in other words I did not impose a datatype on them.

I then monitored these two addresses in a Variable Table while the instruction executed. If I monitored MD0 in 'decimal' format and MD4 as 'floating-point' format everything works as expected. However if I monitor MD4 as 'decimal' then you can be sure that the display is different. This would happen if I monitored it as hex or some other format as well. I even tried sticking in 7 million to MD0 (7,000,000) and what I get displayed for MD4 is 1,255,513,984 when displayed as decimal.

You can check what is happening by also displaying MD4 in binary format at the same time as displaying it in f-p or decimal. You'll find that the binary pattern remains the same, it's just a matter of how the representation you've chosen interprets the bit pattern. For a DINT or decimal, every bit is just a successive power of two until you reach the MSB which is used to indicate sign. For an f-p representation of the same bits, the display has to split the 32-bits in to the sign, mantissa and exponent, and then calculate the resulting real number to display.

So, how do you know if the number in MD4 really is a DINT or a REAL or a TIME or any other 32-bit variable? Well, it all depends on what you do with it next. If you feed it to an instruction which expects a REAL input parameter it will be treated as REAL. If you feed it to a DINT instruction, that will try to interpret it as a DINT, and so on. The other option is to declare the datatype in the Symbol Table. Providing you leave 'Type Check of Addresses' switched on in the Ladder Editor Options\Customize tab then that should prevent you misapplying REALs to DINTS etc.

Regards

Ken.

This looks like a simple "viewing" problem.

If you load 7000000 (decimal) into the accumulator and then perform DTR, the number in the accumulator afterwards is 1255513984 (decimal). If you view 1255513984 (decimal) in floating point format, it is in fact 7.000e+006.

(I was creating this post as Ken M was posting, hence duplication)

Thanks all....I will look further today. To clarify: I have a DB13 that the vendor of a machine populates with Machine Data and I pull numbers from that and calculate production counts and so on. I place my results in Arrays in DB310 which is my DB to work with.


The DB data given to me in DB13 is DINT and my DB310 is mostly Real types. I think the original thinking on this design, which was designed for other PLCs, was to use Real numbers internally to account for LARGE numbers of counted product. Our numbers can go into the Millions but not Billions. In the other PLCs we use the Real numbers internally and then convert them to High/Low Byte Integers and store them in another DB as INT. The software pulls the data from the DB that is using INT types. So I have to do a lot of converting on this project.

I will take a closer look today.

Lance

Lance, it looks like you can skip the REAL number format altogether, and work only with DINTs. I don't understand why they thought real numbers would be better than dints in the first place, especially since you are just counting discrete parts and aren't doing real math. Even if I had a processor that supported only INTs, I would have used back-to-back INTs to simulate DINTs rather than go with REALs.

Yep. Agreed. The reason for the reals is probably carried over from other PLCs. This software has to interface with several different types and sizes of PLCs and I think the last programmer just thought the Math on the real numbers would save accuracy in the decimals.

Turns out, the advice here and discovering more about the functions available helped a lot.

I learned yesterday how to create a FB from a FC I wrote and it does all of my Real to Integer High/Low byte placements. That is a nice feature most PLCs do not have. I saved a lot of recoding.

I also discovered I was search the Step7 help files for Statements and other info when I should have been going to the DOCUMENTATION PDF files. That info was a lot better! I just thought the Help menu in Step7 would have had all that but I was way wrong!!!!!

Thanks a lot. I have made a lot of progress on this project and with only one week of training. I have converted 200 pages of Control Logix code in the past week and about ready to test the program.


Lance