Sign in to follow this  
Followers 0
Famous_Fella

NX1P2 - Convert REAL to DWORD

19 posts in this topic

Hi,

I am trying to convert a variable of REAL data type to DWORD. I 've tried using Real_To_Dword function which works fine if the real number is integer but when the real is decimal the function rounds the decimal number to INT first (I ve also read it in the instruction manual so no surprise here). I 've also tried experimenting with the function CopyRealToDWORD but again the outcome was not what I expected. Is there another way to convert decimal real numbers to DWORD without losing the decimal portion?

Share this post


Link to post
Share on other sites

Could you post an example of the input ant output your expecting?

A DWORD is only a double bit string will only store a value from 16#00000000 to FFFFFFFF. The fractional part of the decimal will be rounded and only the integer will be converted.

Share this post


Link to post
Share on other sites

DWORD values do not have a decimal portion.  Real numbers are the way that you can express this type of number.....  You could multiply it first as a REAL and then convert.

so, 

100.342 x 1000 = 100342.0  Then convert:

100342 would be the DINT version and if you do DWORD (DWORD is a somewhat generic format displayed as a hex number), its value would be:  187F6.

I am not really sure why you would want to do this though.  What is it you are trying to do?

Share this post


Link to post
Share on other sites
22 minutes ago, Michael Walsh said:

DWORD values do not have a decimal portion.  Real numbers are the way that you can express this type of number.....  You could multiply it first as a REAL and then convert.

so, 

100.342 x 1000 = 100342.0  Then convert:

100342 would be the DINT version and if you do DWORD (DWORD is a somewhat generic format displayed as a hex number), its value would be:  187F6.

I am not really sure why you would want to do this though.  What is it you are trying to do?

Hi,

Thanks for the replies. I am extracting real values from FANUC Robot Registers using the explicit messaging. Then, through the HMI I manipulate those values and use explicit messaging again to send them back to the robot controller using CIPUCMMSend function but unfortonately the ServiceDat containing the value to be transfered to the robot may only be a DWORD.

Share this post


Link to post
Share on other sites

If I try to send the number 2 as real data type the robot register reports the value 1.07584e+09.

Reading and saving REAL numbers from robot to PLC REAL data types works just fine. Sending a real number though produces this.

 

Share this post


Link to post
Share on other sites

What is the protocol between the PLC and the Fanuc controller.  I ask be cause I doubt you are exchanging reals or floating point.  Rather it's probably all DINT and it's imbuement on each side to multiple and divide to move the decimal place and number of digits.

Share this post


Link to post
Share on other sites
6 minutes ago, pcmccartney1 said:

What is the protocol between the PLC and the Fanuc controller.  I ask be cause I doubt you are exchanging reals or floating point.  Rather it's probably all DINT and it's imbuement on each side to multiple and divide to move the decimal place and number of digits.

It is Ethernet IP

Share this post


Link to post
Share on other sites

Is it possible to read the value out of the Fanuk controller as a dword rather than a real, to see what the format should be?

Share this post


Link to post
Share on other sites
7 hours ago, chelton said:

Is it possible to read the value out of the Fanuk controller as a dword rather than a real, to see what the format should be?

Hi,

If I change the PLC data type of the array to DWORD,

reading a register from the FANUC controller with the value -150 is translated as "C316 0000" in my PLC DWORD variable. Setting my variables to any kind of INTEGER does't extract anything from the robot.

Share this post


Link to post
Share on other sites

This is odd.  C316 0000 is the proper format (mantissa and exponent) in hex for real -150.0.  It appears as if your robot is simply not interpreting it as a real number.  Is there some setting in the Fanuc to tell it to interpret the variable as a real?  

Share this post


Link to post
Share on other sites

Ok, with E/IP, I've never seen a input, output or comms instance with REAL as datatype.  You'll need to check the configuration of the (Rockwell terminology) configuration of the Generic EtherNet Device template and match those datatypes in your code.  You'll also need to verify the configuration on the Fanuc side as well.

Edited by pcmccartney1

Share this post


Link to post
Share on other sites

Here's a typical configuration of an E/IP interface to Fanuc.

Maybe Mr. Walsh has better insight into the E/IP configuration (Network) and can speak to any possibility of there being an ability to read or write REAL or Floating Point data types.

 

FanucEIP.JPG

Edited by pcmccartney1

Share this post


Link to post
Share on other sites

Ultimately, the data is being sent as a hexadecimal value.  It is all in how it is interpreted.  If you look at what the Fanuc is sending the NX1P2 using Wireshark or something, it is sending a value of C316 0000 (hex).  If you then tell the NX1P2 to interpret that double word of data as a real number (by making the variable that receives it a REAL), then it will use it as -150.0.   Likewise, going the other direction, the NX1P2 is sending out a double word of C316 0000 in hex and the Fanuc needs to interpret that as a real number.  This number could just as easily be interpreted as a signed double integer and would have a value of -1021968384.  This would obviously produce a non-desirable result.  In my opinion, there needs to be something done in the Fanuc controller to make it interpret this data as a REAL number.  

Share this post


Link to post
Share on other sites

Not being an Omron expert, I'll say this in Rockwell terms.  The data types are fixed.  So I work with my robot programmer to coordinate the data exchange.  If he wants three decimal places I multiply the REAl by 1000 to a DINT and send it to the Fanuc.  He then immediately divides the DINT by 1000 and stores it in a REAL variable for use in the his program.  The same is true for reading values from the Fanuc to the PLC.

Share this post


Link to post
Share on other sites
1 hour ago, pcmccartney1 said:

Not being an Omron expert, I'll say this in Rockwell terms.  The data types are fixed.  So I work with my robot programmer to coordinate the data exchange.  If he wants three decimal places I multiply the REAl by 1000 to a DINT and send it to the Fanuc.  He then immediately divides the DINT by 1000 and stores it in a REAL variable for use in the his program.  The same is true for reading values from the Fanuc to the PLC.

Well, that could certainly be done on the Omron side as well.  If the Fanuc needs an integer, we can do as I stated very early in this thread.  However, it seems the Fanuc has no problem sending a real to the Omron controller.  You would think it could handle a real being sent to it.

 

Share this post


Link to post
Share on other sites

I'm not sure what Fanuc controller the OP is using, but i found this in the R30iA ethernet IP manual. It seems there is a different class for reading/writing numeric objects as an INT or Real and also a note that Reals (Ox6c) are only supported from version 7.40

5ec6f5db5eb8f_FanucR30iA.thumb.png.65600

Share this post


Link to post
Share on other sites

It appears that when sending a set_attribute command to the FANUC controller via explicit messaging you must also inform it of the data type you send. 0x6C was the answer for me. Thanks a lot Chelton.

Share this post


Link to post
Share on other sites

Dear All.

I have the issued with NX1P2 when read data from Modbus RTU. the Slave data using 2 INT for Real data. but in the Sysmac Studio I get the data is OK, 2 INT but can not convert to Real data.

Can you pls help me to solve this issued. also I want to convert from Real to 2 INT to send the setting to salve.

Many thanks.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0