Read from Siemens PLC through profinet protocol

[ethushara]

Hi,

I need to communicate with Siemens PLC (S7-1500) with profinet protocol to from Daqfactory. But profibus is not in Daqconnect inbuilt. Please let me know if any possibility of doing this. This is a critical requirement for me. 

Best Regards,

 

Thushara 

[AzeoTech]

Siemens doesn't release their protocol specs without a large payment, so we don't support it natively.  In order to talk to this device, you will need to get the appropriate OPC server.  I recommend the ones from Software Toolbox.  Be warned, OPC servers are pretty pricey, at least compared to DAQFactory licensing costs.

[ethushara]

Hi,

I got your point. But the problem is the other related items in my hydro power plant is connected with Daqfactory system. So if I use a RTU (such as ABB RTU570) in between the PLC and the PC in which the Daqfactory is, I can achieve the communication, right?

 

Best Regards 

 

Thushara 

[AzeoTech]

Or just use an OPC server as I said.  DAQFactory is an OPC-DA client so can communicate with OPC-DA servers, of which there are a large variety, including ones for Siemens S7.

[SteveMyres]

S7-1500s (and S7-1200s) will do Modbus/TCP natively (300s and 400s required additional hardware and/or software modules that you had to pay to license) using the MB_SERVER and MB_CLIENT blocks from the libraries supplied with TIA Portal.  DAQ Factory has a Modbus/TCP driver built in at no additional cost so you don't have the expense (or the added moving parts) of an OPC server.  I've used DAQ Factory with S7-1500s may times and it works fine.  One caveat -- since it runs in ladder, it only works if the PLC is running, so not quite native (to the degree that a PLC that supports it in hardware and so will still work even in Stop mode).

None of the 1500s come with a serial port to my knowledge, so if you have to have RTU, you'll either need to do some sort of gateway, or buy a serial port expansion for the 1500.  Probably cheaper to buy a generic external gateway than the official Siemens solution.

I fact, I advocate that it's best practice to use widely supported protocols, and Modbus in particular, because it black-boxes your PLC and HMI one from the other.  HMIs almost universally support Modbus, as do most PLCs, so if you use it, then the PLC and HMI aren't bound together in some sort of unholy union, and if at some point you want to change one or the other, it doesn't break the one you didn't change.  I've even used Modbus when I DO use a PLC and HMI from the same manufacturer, based on that same principle.

[ethushara]

Hi,

Thanks a lot for your instructions and i managed to add MB_Server block in S7-1500s and connect it with Modbus TCP in DAqfactory. That is working nicely and also i can get it through wireless adding more benefits. 

Best regards,

Thushara. 

 

[ethushara]

Hi,

I had to face a abnormal issue with when reading the Modbus TCP data with Daqfactory. I have attached related details in pictures here. When i read by Modscanner32 it shows the the correct values in correct addresses as per in the PLC. But when i read same from Daqfactory it shows different values and addresses. Please go through the below points with the pictures and the PDF attached. 

1)  in address 40005 in Modscanner32 (in PLC address 5) the value is 1487.65 but in Address 5 in DAQ the value is same BUT,

2) in address 40007 in Modscanner32 (in PLC address 7) the value is 1486.8671 but in Address 5 in DAQ the value is 1228.0

3) in address 40009 in Modscanner32 (in PLC address 9) the value is 1228.0 but in Address 5 in DAQ the value is 0.0

4) in address 40003 in Modscanner32 (in PLC address 3) the value is 0.0 but in Address 5 in DAQ the value is 1480.0

5) I tried with changing the i/o type with near addresses. But anywhere i cannot find the value 1486.86 in DAQ

This is confusing me a lot. Please help me to find out the issue.

Best regards,

thushara

LUB_CO_Remote_Prozesswerte (DB128).pdf

[AzeoTech]

A couple points here:

1) it is possible with floating point values to get a number that is close if you are one off and reversed from how the PLC has it.   So it is possible you just missed one of the combinations.  If the registers in ModScan show 40001, 40003, 40005, etc, and you want to use 0 indexed channel #'s, you have to subtract one.  So, 40017 for example should be 16 in DAQFactory if you want to 0 index in DAQFactory.

2) remember also that except for integers (in the 32 bit floating range with no exponent), no non-integer number can be represented exactly using floating point values.  For this reason you will see rounding which can cause differences between programs in the least sig fig due to how they round.

Personally I'd say your problem is probably #1.  You probably want register 16, without the R words.

[ethushara]

hi

Thanks a lot.

Actually what i was required is to read the actual values which are in the PLC. But by selecting only this input output type (Read holding float R words) i could get the exact values of those channels at the beginning. But suddenly yesterday i found those errors. My worry is while the address 5 shows the same correct number in both DAQ and Modscanner, the address 9 in modscanner has come to 7 in DAq and address 7 in modscanner has gone to 3 in daq with some rounding up (i suppose). This doesn't show any pattern.

i tried by changing values like trying to read the addresses 2, 4,6,8, even by changing the i/o types as well. But those are giving very wrong figures. 

So could please let me know how can i overcome. i just need to read exact values in the PLC.  

Thanks again,

Best Regards,

 

Thushara

[AzeoTech]

As I said, you should subtract one.

One thing though: DAQFactory tries to automatically figure out whether you are using 0 indexed addressing, or 40001 addressing.  Both 40,001 and 0 refer to the same PLC address.  They are just two different ways of describing that address.  Technically 0 is the one actually used in the Modbus query, so I prefer it over 40,001 as it is actually used in the frame.  40,001 is much more arbitrary and has no real meaning other than the spec and just gets converted to 0 by the software on both ends.

Now as I said, DAQFactory tries to figure out which you are using.  It does this by assuming you are using 0 indexed addressing until you try and read an address in the 30,000 to 49,999 range.  Once you do that, it will assume all addresses are in 40,001 type notation and will strip the 10,000's place and subtract 1.  So if it was working for a while then stopped, it's likely that during your testing you tried a register in the 40,001 range which told DAQFactory to start subtracting one, and then when you went back to 0 indexed, everything was off.  This would get reset on restart as long as you didn't leave any channels or other reads in that 30,001-49,999 range.

BTW: you can force it into 0 indexed notation by reading a register in the 50,000+ range, even if that register doesn't exist.  The simple act of trying tells DAQFactory to stay in 0 indexed mode.