Modbus TCP/IP Help

[Heckler511]

Well thanks to everybody and especially Ravens Fan and juliodiaz for providing workable solutions.  I must admit, setting up the I/O server and shared variables the way you suggest juliodiaz is precisely what I wanted to do.  I figured LabVIEW had a way to just make it work, but I suppose the couple of days I spent trying to figure this out, immersed in Modbus, will pay off down the road. 

So, I believe this will now work the way I intended, although, I'm not sure I entirely understand why it is working.  I thought we all decided that I would need to read two consecutive register addresses and then combine them to produce the final number, but now it appears that LabVIEW is doing the needed combination and translation without any further direction from me?  Does it have something to do with specifying that special "F" addresses when I enable aliasing?  Do those other address prefixes "D," "SD," "A," have associated functioning as well?  

Also, that "first word low in 32 bits data types" option is still a little confusing.  I had originally checked that box as I found a NI document here: http://zone.ni.com/devzone/cda/tut/p/id/7210 which states, one should check that option "because data will be coming in from your RT Target in big endian and selecting this option will take that into account when trying to read that data" - it's confusing because my data is coming in from my controller in Big Endian, which I now gather means first word high, so perhaps that article needs to be changed or I'm just not getting it? 

Finally, juliodiaz, how did you get my actual variable numbers to show up in your final screenshot?  That's cool! 

[RavensFan]

You're welcome.

I haven't worked with the I/O server before.  I have no idea what the alphabetical prefixes mean.  I hope someone can provide an explanation on that.  I think the registers that are listed with a 300001.1  or .16, are a way to get access to an individual bit of a particular register.  Since the Modbus protocol doesn't support reading or writing individual bits of holding or input registers (at least not in the function codes I'm used to seeing), I bet the server is reading the entire register using normal Modbus commands and providing a means to break it into individual bits behind the scenes without doing anything extra on the LabVIEW programming end.

As for that "first word low in 32-bit data types", I read that sentence in the exact opposite of my understanding of it.  I bet that it is an error in that document that should be corrected.  Perhaps someone else can comment.

[juliodiaz]

@Heckler511, Im glad I could help.

Almost all devices in market are 16 bits base addressing. Even modbus (I think) is 16 bits base addressing. However we need 32 bits to represent some real values. So, either devices and OPC's (IO Servers) implements a way to solve this issue.

In your case 30001 and 30002 are 16 bits, but if a Variable is configured with a 32 bits data type (I32, U32, Sgl, etc.), it will poll 2 registers that it need to complete its 32 bits, so, it polls 30001 and 30002 at once.

Regarding how the IO Server knows the data type, you tell to IO Server the data type with "F" (Single = Float = IEEE format), this prefix is within NI Modbus IO Server. In "Browse for Variable..." window, you can select the addressing and check the default data type for each one, check it out.

"S" (Signed integer) prefix indicates that is a I16 data type

"SD" (Signed doble word) prefix indicates that is a  I32 data type

"A" prefix indicates that is an array, you can indicate the data type of elements as well

 

Now, about "first word low in 32 bits data types" option. As I said, some devices implement a way to solve this, what they do is "concatenate" 2x16 bits registers and use them as one of 32 bits. Think in an up counter, with a 16 bit register you can reach up to 65535, but we need more. So 65535 which is "1111111111111111" in binary, add 1 to this (65536) and you'll get "0000000000000000" in LO (low) register, then a device can stores it in 30002 and stores "1" in 30001 as HI (high) register. If you could see 30001 & 30002, you will see "0000000000000001" & "0000000000000000", concatenate them and obtain a 32 bit register which contains "00000000000000010000000000000000". Buuuut some others devices store LO part in 30001 and HI part in 30002. So 65536 in this device will contains "0000000000000000" & "0000000000000001", can you see the difference? this is where "first word low in 32 bits data types" makes sense.

Finally, I used a Modbus TCP/RTU simulator, it's a software that runs on windows and it's free as beer you can download it:http://www.plcsimulator.org/

[esodar1981]

I all,

i've followed this discussion since the beginning, now it's time for me to apply what i've learned 😉

Just one question for you guys, how can i deploy the variables created using the Distributed System Manager??

I just can't find a way to do that, i have installed the DSC Module but actually haven't activated it, maybe it's 'cause of that....

Thanks in advice

Dario 

[Robbob]

Esodar,

When you add a process and variable to your system in DSM, it is already deployed. If it shows up in DSM = it is deployed.

Think about a project, you make a library and variable in your project, but it doesnt show up in DSM until you deploy it. By creating it in DSM, we go straight to the end result.

And software in evaluation mode has no limitations, minus a splash icon on your front panel. Functionality should be the same.

[esodar1981]

Thanks Robbob,

that's so easy.....   

[tanmoy_vec]

Hi,

I am using Labview 7.1 to fetch data from Schneider PLC using MODBUS/TCP.

I can read using TCP read with 0104 function code(hex) and able to fetch floating point data upto 62 PVs in 1 shot. i.e can read 124 registers (16 bits each).

Basically I am able to read 248+9 = 257 bytes.

When I try to read 63 PVs. i.e. 125 register (261 bytes) in one command, it is returning timeout error.

Even using it in CRLF mode I can only get response 000003 018403 timeout error.

Can anyone help ?

Thanks in advance

Tanmoy

[Andrey_Dmitriev]

It is probably because in the classic Modbus maximum register quantity per request is known to be 125 (250 bytes + 6 bytes of overhead).

You should not to try to read these in one single shot, but in multiple requests instead.

[tanmoy_vec]

OK Thanks.