From 12:00 AM CDT Sunday, October 17 - 11:30 AM CDT Sunday, October 17, ni.com will be undergoing system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

[Ethernet TCP/IP] Recover data from sensor - KIMO C310

Solved!
Go to solution

Hi, 

 

Yes to both questions : 

adress set to the KIMO : 

IP : 192.168.002.003

Mask : 255.255.255.000

Gateway : 127.000.000.001

Port : 502

 

Ethernet RJ45 connexion : OK : 

Windows recognize that there is a "non identified network". but if I unplug, this network disappear.

 

Best regards.

Download All
0 Kudos
Message 11 of 22
(419 Views)

Can you ping the device?

 

(I usually don't set any gateways…)

Best regards,
GerdW


using LV2020 on Win8.1+cRIO
Message 12 of 22
(418 Views)

Yes sorry I was eating ^^

 

Here is the result, 

 

it seems that the device answered the ping.

 

 

0 Kudos
Message 13 of 22
(411 Views)

Hi Benny,

 

so the port settings are correct.

Now you "just" need to implement the protocol as described in the manual of your device...

Best regards,
GerdW


using LV2020 on Win8.1+cRIO
0 Kudos
Message 14 of 22
(397 Views)

Hey, 

 

Thank you for the reply, 

it seems I should give up then ^^' 

 

The datasheet literally said

"

CONFIGURATION
Class 310 transmitters allow you to set all the parameters managed by the transmitter : units, measuring ranges, alarms, outputs, channels... via the different
methods are shown below :
➢ Via keypad, only on models with the display. A code-locking system for keypad guarantees the security of the installation. See configuration manual.
➢ Via software (optional) : simple and user-friendly. See LCC-S user manual.
➢ Via Modbus (optional) : configuration of all parameters from your PC, via the supervision or data acquisition software.
➢ Via Ethernet (optional) : configuration of all parameters from your PC, via the supervision or data acquisition software.

"

I guess the device is just locked and we are not supposed to use LabVIEW to recover data... it really feels wrong but well.

 

I'm going to exploit the ModBus option since it is also available, I'll struggle the same way but at least I would've tried.

 

If you have any idea, I'll be more then thankful, 

 

Best regards.

0 Kudos
Message 15 of 22
(392 Views)

Hello everyone,

 

so, after hours of learning and testing around, 

 

We finally got something out of the situation: we tried using "'Doctor Modbus", a software. 

 

We can read both values using Modbus AND TCP/IP via RJ45 cable. This means that it is possible to do so without manufacturer software.

 

So, I learned that the client is supposed to send a request to the server so the server can send the response, that's why nothing was working and the code kept timing out.

 

See attached the new code, it's mostly the same, but I just add a request (TCP write). 

So, now, I need to find out the "formula" of the request, after some test, I saw that the IP of the device + the Modbus register name does give weird result, but results indeed.

 

I'm gonna keep digging, I'll post if I find a way to retrieve the correct data.

 

Also and finally, there are multiple datasheets for the same device, I don't know why but oh well, in this third datasheet there are all the parameters to program a Modbus communication (register's ID, baud rate, etc).

 

It seems that the reply is in HEX, which won't help but will still be manageable.

 

Best regards !

 

0 Kudos
Message 16 of 22
(355 Views)

Why aren't you using the Modbus TCP/IP libraries?

 

One such set is here.  https://www.ni.com/example/29756/en/

 

 

 

0 Kudos
Message 17 of 22
(344 Views)

Hey Raven, 

 

Well mostly because I did not know it existed. I though TCP was only for ethernet communications

 

Well, I did this (see attached), I changed the computer so I modified the address.

 

I now get a different issue. See attached too.

 

I feel it's the input that led to this

 

All I know is: 7010 is the registry number for the data I need. 3 is the slave number.

0 Kudos
Message 18 of 22
(332 Views)
Solution
Accepted by topic author Benny360

If 3 is  your slave number, you should note that Modbus TCP/IP will refer to that as a Unit ID.  The term slave address tends to apply to serial based Modbus such as Modbus RTU or ASCII.  When you go into the palette for the purple Modbus library, you'll see a subVI called Set Unit ID.  You'll want to use that to set it to 3.

 

If you are only trying to read registers, then you should be using Read Holding Registers.  Not Write/Read Multiple Registers like you are now.  (I've only ever need to read registers or write registers.  I've never need to write and read them in the same function!)

 

If you only want to read 1 register, then your Read Starting Address should be 7010 and the Read Count should be 1.

 

 

 

Message 19 of 22
(300 Views)

Hello Raven

 

So, Thank you for your explanation !

 

The result actually varies when the pressure varies.

Now I have to decode the message, I believe. Because the data is widely different from what I can read.

 

In the datasheet, it said the value is coded this way :

7010 : real on 4 bytes

7020 : U8 on 1 byte

(the unit I don't need)

 

I guess my work now is to convert the register value back to decimal ! but that's a big job done and the communication works !

 

Thank you a lot Raven.

Download All
0 Kudos
Message 20 of 22
(292 Views)