Bringing Freewave Wave Contact registers into CompactLogix PLC

TheCanboy

Member
T
Join Date
Jun 2021
Location
North Dakota
Posts
7
Hi all, I have picked up a job where the previous automation guy selected some Freewave Radios (WC20i-485 into WC45i stick gateway) to transmit from a Cameron NuFlo Scanner 2000 Micro EFM. I have downloaded the Modbus Client AOI from Rockwell’s website, and set up everything as best I could according to the documentation. I’m going to the site to download the project today, but just looking at the code I don’t see where my values will come in, or how I select which value will be coming in. There are 2 modbus radios collecting Y-Total from Scanners, 1 flare meter and 1 sales meter. I hope someone has experience polling data from these radios and can advise on writing their values into a tag on the PLC. Thanks for reading, I will be able to reply with additional information if needed while on site today.

Edit: Modbus CLIENT, not server
 
Last edited:
I am not familiar with radios but had some exposure to Modbus TCP AOIs.
My recommendation is to get AOIs working on hard wired connection first, without radios, then setup radios.

In AOI data will be coming into the tag assigned to the Ref_ModbusData parameter.
What to read will be defined under one of five transaction tags. Transaction will also define where exactly data will arrive in Ref_ModbusData tag.

Good luck.
 
I have the two communicating now. Does anyone who’s worked with this AOI know how I can change the data type to a REAL without breaking the code? I’m pulling in a 32 bit floating point.
 
TheCanboy said:
Nope, it’s just coming in as 32640 on one of the holding register data points
Click to expand...

  1. I am going to assume that is a 16-bit integer.
  2. Is it possible the floating-point value you are expecting is positive infinity?
    1. Can you make it some value other than infinity?
  3. Is there a 16-bit zero on one side or the other of the 32640?
 
drbitboy said:
  1. I am going to assume that is a 16-bit integer.
  2. Is it possible the floating-point value you are expecting is positive infinity?
    1. Can you make it some value other than infinity?
  3. Is there a 16-bit zero on one side or the other of the 32640?
Click to expand...
Sorry, I got pulled off of that at the beginning of this week. I re-set up the AOI from scratch and now it’s coming in as 12 INTs. When I try to COP those with a length of 11 into a REAL it returns 22222.0
 
The COP instruction looks at the data type of the Destination to determine how to utilize the Length parameter. I think you would want to choose 6 since your destination is REAL (32 bits) and your source is 16 bit (INT) words, all twelve INTs will be copied bit-for-bit into 6 consecutive REALs. That is me making the assumption that all 12 INTs actually represent 6 REALS. Earlier in the thread, you mentioned 1 floating point (REAL) number.
 
1) Do you know what the floating-point values should be? If there is noise, Knowing to +/-10% or better is good enough.


2) Post the decimal (or hexadecimal) values of the 12 holding registers you are seeing.


The rest of the solution is basically bookkeeping the bits.
 
TheCanboy said:
Sorry, I got pulled off of that at the beginning of this week. I re-set up the AOI from scratch and now it’s coming in as 12 INTs. When I try to COP those with a length of 11 into a REAL it returns 22222.0
Click to expand...

Take a look at the documentation for the byte order.
 
drbitboy said:
1) Do you know what the floating-point values should be? If there is noise, Knowing to +/-10% or better is good enough.


2) Post the decimal (or hexadecimal) values of the 12 holding registers you are seeing.


The rest of the solution is basically bookkeeping the bits.
Click to expand...

The value for the register I was pulling was 890.68 (it’s the y-total for a sales meter so should be exact)
Once the PLC pulled it in, my HoldRegister_4xxx[0] through [11] had these values:
896
18521
768
18183
-3904
18653
-8192
17930
15360
17948
896
18521

I noticed the last 2 repeated so I just tried COPing those into the REAL to see if that worked. I got 2.3 or so. After that I rebooted the Freewave gateway and cleared the data from the registers in the PLC side, then the Modbus TCP client transactions wouldn’t complete and the overload bit was set to 1 in transaction diagnostics.
Edit: even though my overload bit was 1, the Freewave gateway’s log was registering successful transactions
 
Summary


Try some nearby Modbus addresses until you find a 17502.


TL;DR

Code: 
$ python
>>> import struct

>>> struct.unpack('f',struct.pack('hh',896,18521))[0]
222222.0
>>> struct.unpack('f',struct.pack('hh',896,18521))[0]-222222
0.0

>>> struct.unpack('f',struct.pack('hh',768,18183))[0]
34563.0
>>> struct.unpack('f',struct.pack('hh',768,18183))[0]-34563
0.0

>>> struct.unpack('f',struct.pack('hh',-3904,18653))[0]
454534.0
>>> struct.unpack('f',struct.pack('hh',-3904,18653))[0]-454534
0.0

>>> struct.unpack('f',struct.pack('hh',-8192,17930))[0]
8888.0
>>> struct.unpack('f',struct.pack('hh',-8192,17930))[0]-8888
0.0

>>> struct.unpack('f',struct.pack('hh',15360,17948))[0]
9999.0
>>> struct.unpack('f',struct.pack('hh',1536[COLOR=red][I][B]0[/B][/I][/COLOR],17948))[0]-9999
0.0
>>> struct.unpack('f',struct.pack('hh',1536[COLOR=Red][I][B]1[/B][/I][/COLOR],17948))[0]-9999
0.0009765625
So there are five floats: three values (222222.0, 8888.0, and 9999.0) that are floating point representations of whole numbers (integers) of repeating decimal digits, plus two other floating point values that are either odd or odd multiples of two; those are unlikely to be random occurrences.

Also this:
Code: 
>>> struct.unpack('hh',struct.pack('f',890.68))
(-21627, 17502)
>>> struct.unpack('f',struct.pack('hh',-2162[COLOR=blue][I][B]7[/B][/I][/COLOR],17502))[0]
890.6799926757812

>>> struct.unpack('f',struct.pack('hh',-2162[COLOR=Blue][I][B]9[/B][/I][/COLOR],17502))[0]
890.6798706054688
>>> struct.unpack('f',struct.pack('hh',-2162[COLOR=blue][I][B]5[/B][/I][/COLOR],17502))[0]
890.6801147460938

>>> struct.unpack('f',struct.pack('hh',0,17502))[0]
888.0
>>> struct.unpack('f',struct.pack('hh',-1,17502))[0]
891.9999389648438
The -21627 might vary depending on the next digit of 890.68, but the 17502 covers all values in the range [888.0:892.0).


Cf. https://en.wikipedia.org/wiki/Singl...cision_binary_floating-point_format:_binary32
 
drbitboy said:
Summary


Try some nearby Modbus addresses until you find a 17502.


TL;DR

Code: 
$ python
>>> import struct

>>> struct.unpack('f',struct.pack('hh',896,18521))[0]
222222.0
>>> struct.unpack('f',struct.pack('hh',896,18521))[0]-222222
0.0

>>> struct.unpack('f',struct.pack('hh',768,18183))[0]
34563.0
>>> struct.unpack('f',struct.pack('hh',768,18183))[0]-34563
0.0

>>> struct.unpack('f',struct.pack('hh',-3904,18653))[0]
454534.0
>>> struct.unpack('f',struct.pack('hh',-3904,18653))[0]-454534
0.0

>>> struct.unpack('f',struct.pack('hh',-8192,17930))[0]
8888.0
>>> struct.unpack('f',struct.pack('hh',-8192,17930))[0]-8888
0.0

>>> struct.unpack('f',struct.pack('hh',15360,17948))[0]
9999.0
>>> struct.unpack('f',struct.pack('hh',1536[COLOR=red][I][B]0[/B][/I][/COLOR],17948))[0]-9999
0.0
>>> struct.unpack('f',struct.pack('hh',1536[COLOR=Red][I][B]1[/B][/I][/COLOR],17948))[0]-9999
0.0009765625
So there are five floats: three values (222222.0, 8888.0, and 9999.0) that are floating point representations of whole numbers (integers) of repeating decimal digits, plus two other floating point values that are either odd or odd multiples of two; those are unlikely to be random occurrences.

Also this:
Code: 
>>> struct.unpack('hh',struct.pack('f',890.68))
(-21627, 17502)
>>> struct.unpack('f',struct.pack('hh',-2162[COLOR=blue][I][B]7[/B][/I][/COLOR],17502))[0]
890.6799926757812

>>> struct.unpack('f',struct.pack('hh',-2162[COLOR=Blue][I][B]9[/B][/I][/COLOR],17502))[0]
890.6798706054688
>>> struct.unpack('f',struct.pack('hh',-2162[COLOR=blue][I][B]5[/B][/I][/COLOR],17502))[0]
890.6801147460938

>>> struct.unpack('f',struct.pack('hh',0,17502))[0]
888.0
>>> struct.unpack('f',struct.pack('hh',-1,17502))[0]
891.9999389648438
The -21627 might vary depending on the next digit of 890.68, but the 17502 covers all values in the range [888.0:892.0).


Cf. https://en.wikipedia.org/wiki/Singl...cision_binary_floating-point_format:_binary32
Click to expand...

I think there was some problem with my TCP communication, after toying with it I've got the 32 bit float coming in as 2 INTs.

The Y-Total value is:
1016.702

The values of the 2 INTs are:
17534
11504

When I COP them into a real I get:
6.82881442e-012

It's worth noting that my overload bit is still getting set to 1 even when I mess with the PollInterval, but it seems like data is coming through anyway. Not sure what's going on with that
 
Your words are swapped. I used this tool: https://www.h-schmidt.net/FloatConverter/IEEE754.html

Plugged in your correct result ( 1016.702 ) on the top field and hit enter. I then took the HEX results from the bottom field:
0x447e2cee
I swapped the words (not bytes):
0x2cee447e

Hit enter and I get:
6.77197100479e-12

Not exactly the same as what you had, but close enough to make me think the difference is based on rounding or some small change that occurred to your Y-Total when you recorded it versus the data arriving in the PLC,

So I think you need to reverse the order of the INTs before you COPy them.
 
Last edited:
OkiePC said:
Your words are swapped. I used this tool: https://www.h-schmidt.net/FloatConverter/IEEE754.html

Plugged in your correct result ( 1016.702 ) on the top field and hit enter. I then took the HEX results from the bottom field:
0x447e2cee
I swapped the words (not bytes):
0x2cee447e

Hit enter and I get:
6.77197100479e-12

Not exactly the same as what you had, but close enough to make me think the difference is based on rounding or some small change that occurred to your Y-Total when you recorded it versus the data arriving in the PLC,

So I think you need to reverse the order of the INTs before you COPy them.
Click to expand...

Legend! Swapping them has my Y-Total coming in properly. I'll bookmark that page for the future in case something like this happens again.
 

Similar Topics

S
Bringing Wonderware SMC to foreground
If have a need (trust me its a need) to bring the System Management Console to the foreground while the HMI is running. I am trying to to this...
2 3
Replies
40
Views
11,324
SouthernStang
S
N
Bringing Data Science to Automation
I am not very experienced (2 yr) so this question is for people who know both what is going on with data science currently and have experience...
Replies
0
Views
1,099
NO_ERR
N
rootboy
Bringing a Siemens MP370 back from the dead
Hi guys, While trying to upgrade a Siemens MP370, it hung somewhere in the process and gets about halfway through the creation of its disk...
Replies
4
Views
2,756
rootboy
rootboy
R
Bringing Projects into Proficy Machine Edition
I'm fairly well-versed in programming GE 90-30 PLCs with Proficy ME, but I can't figure out how to open a project that was created on a different...
Replies
4
Views
9,834
Steve Bailey
Steve Bailey
I
Bringing New Code online with Step 7 over OPC on Industrial Ethernet
Can you use an existing OPC over Industrial Ethernet connection to update code on a S7-300 PLC using Siemens Step 7? I found something somewhere...
Replies
1
Views
3,109
JesperMP
JesperMP
Back
Top Bottom