Industrial Communications

cancel
Showing results for 
Search instead for 
Did you mean: 

labview dsc conerting Modicon Real number into Single Precision problem

I am just starting to learn about the DSC module in Labview. I created an IO server that is monitoring two inputs on a Modicon Quantum PLC for testing concepts. One input is a simple boolean the othe is an analog Vin that is being scaled to a real number in the Modicon. I created a small vi to monitor the values of the shared variables.

The IO server is working. I I can see the boolean value change states as I toggle a switch and I can see numbers on the analog display in the vi BUT the numbers aren't correct. Instead of displaying a 0 to 10 volt range I am getting HUGE values i.e. 5.66528000236e+31.

Having experience communicating through Labview this very same Modicon I know what the issue is.

The analog data is stored at two register addresses in the PLC 400001 and 400002. in the shared variable engine I set the address to F400001 to read the two registers which when displayed give me the wrong numbers so I then created two ne variables to read 400001 and 400002 seperatly and put them into a subVi that we have used in another application that converts two integers into a floating point number. With 400001 being the low integer and 002 being the hi integer the value on my little vi reads correctly. when I swap the inputs the display reads the same as the F400001...huge.

So my question is... does anybody know whats going on? I would like to be able to just read the data straight from the PLC without having to install my conversion vi.

 

Alan

0 Kudos
Message 1 of 6
(5,084 Views)

Hello Alan_W,

 

I am going to assume you are using a Modbus I\O server. Which version of LabVIEW are you using? Prior to LabVIEW 2010, reading registers F400001 will return the least significant word in register 400001 and the most significant word in register 400002. If you are using a version of LabVIEW prior to LabVIEW 2010, this would explain the behavior you are seeing. This behavior was incorrect and was fixed in LabVIEW 2010 and forward. The corrected behavior is: F400001 should return the most significant word in register 400001 and the least significant word in register 400002. 

 

Regards,

 

j_bou

 

0 Kudos
Message 2 of 6
(5,064 Views)

j

 

Yes you are correct, I'm using a Modbus I/O server on Labview 2014.

 

If I read your responce right I don't think Labview is doing it right. In the attached .jpg the vi diagram on the left is the one I wrote to test the behavior. When I reverse the two inputs to the ConvertINTs2Float from the way they are shown the value is the same wrong F400001 value. The vi on the right is the conversion vi.

0 Kudos
Message 3 of 6
(4,994 Views)

Hello Alan_W,

 

If you look at the shared variables in the NI Distributed System Manager do you see the same behavior? Specifically, can you confirm which shared variable contains the most and least significant word? Could it be possible for the Modbus slave to be storing the least and most significant words in reverse?

 

j_bou

 

0 Kudos
Message 4 of 6
(4,963 Views)

Yes the DSM displas the same behaviour.

 

0 Kudos
Message 5 of 6
(4,961 Views)

Hello Alen_W, 

 

I have been working on replicating your issue to determine if LabVIEW is not behaving as expected. Currently the results of my tests are indicating that LabVIEW is behaving correctly. I used a cRIO as a Modbus slave and a computer as the Modbus Master. On the slave, I split a U32 into two U16 words and wrote them to holding registers 400001 and 400002 respectively (using Modbus API). On the computer, I used a Modbus I\O server to read in the U32 using the F400001 convention and the U32 was correct (Although I did have to convert to single precision float to a U32).

 

Using Modbus I/O Servers (DSC Module or Real-Time Module):
http://zone.ni.com/reference/en-XX/help/370622M-01/lvmve/dsc_modbus_using/

 

I am not sure if Modicon Quantum PLC slave is writing to the registers like we are assuming. Since the simple conversion VI you are using is working well and providing you with workaround, I would recommend using it.

 

j_bou

0 Kudos
Message 6 of 6
(4,931 Views)