Modbus - change setpoints and settings

Hi,
We have modbus tcp implemented in s7-1200. For now it has been only control and status. Now we want to change settings. I have never done it before and just need a push in the right direction.

Normally I have had all data in a datablock called modbus only for modbus, but since I now want to change settings from both modbus, hmi and plc I figure I need to write to the same variable from all places? The setting variables are in a datablock called hmisettings. Is it a good solution to write directly from modbus to the hmisettings datablock? I would prefer to have it seperated to have more control over the modbus comm.

/Tim

Hi,

A lot of this will depend on how you've configured your system - i.e. which device within the network is acting as client or server (server effectively being the 'Slave' and client the 'Master'). Then you can look at which function codes to use (e.g. Function 06 - write single word).

Rob

Kidblue said:

Hi,

A lot of this will depend on how you've configured your system - i.e. which device within the network is acting as client or server (server effectively being the 'Slave' and client the 'Master'). Then you can look at which function codes to use (e.g. Function 06 - write single word).

Rob

Click to expand...

Hi,

Sorry I forgot to add that information. We are the slave in this case.
I have no problem writing and using the modbus communication protocol but it's how I'm going to handle it in the PLC when letting the Client write to setpoints.

If I for example let the modbus client send values to a Setpoint used by the HMI and PLC then I can't change this setpoint from the HMI anylonger since the modbus client will overwrite it assuming the client is have established a cyclic communication with the server.

Or should I make the client send setpoints to its own adress and then let the client trigger the changes with a command that is moving the modbus values to the setpoint?

Or do I force the client to send setpoints directly to the setpoint but not establish a cyclic communication on the modbus write command?

/Tim

Hi,

A lot of this will come down to the overall control narrative (or FDS) and how the package/system is intended to work. When we interface with (customer/client) remote systems, we nearly always include conditional logic to determine (say) which setpoint to use. For oil and gas, it was very common to have a package that could be put into either local control or remote. The setpoints would then be selected, conditionally, based on mode selection. A lot of these decisions will be based on plant criticality.

Hope this helps.

Rob

Thanks for the suggestion, however in this setup I would like it to be able to change from both HMI and Modbus Client seemlessly. As if the modbus Client where a HMI.

I have a solution that may work but it includes more logic. That include a Modbus Setpoint variable and a Modbus Setpoint Memory variable

Modbus Setpoint <> Modbus Setpoint Memory MOVE Modbus Setpoint to Setpoint and Modbus Setpoint Memory

If the Modbus Setpoint is changed it is no longer equal to the Modbus Setpoint memory. This will change the Setpoint and also store the setpoint in a memory.
After the setpoint has been changed from modbus it can freely be changed by the HMI and PLC. The Client can have a cyclic communication because the continous write to the modbus setpoint will not affect the Setpoint until it is entered a new setpoint.

Would this be a wierd programming?

/Tim

rQx said:

Thanks for the suggestion, however in this setup I would like it to be able to change from both HMI and Modbus Client seemlessly. As if the modbus Client where a HMI.

I have a solution that may work but it includes more logic. That include a Modbus Setpoint variable and a Modbus Setpoint Memory variable

Modbus Setpoint <> Modbus Setpoint Memory MOVE Modbus Setpoint to Setpoint and Modbus Setpoint Memory

If the Modbus Setpoint is changed it is no longer equal to the Modbus Setpoint memory. This will change the Setpoint and also store the setpoint in a memory.
After the setpoint has been changed from modbus it can freely be changed by the HMI and PLC. The Client can have a cyclic communication because the continous write to the modbus setpoint will not affect the Setpoint until it is entered a new setpoint.

Would this be a wierd programming?

/Tim

Click to expand...

I would say it weird if HMI and/or Scada are TCP Clients (TCP master and your PLC is TCP Server (slave)


HMI and Scada should take care of this automatically if they are masters and all you need on PLC side is that you change same DBD.DBW address than is linked to modbus side for HMIs.
Then you don't need actually nothing else on PLC side than modbus mapping and Modbus settings with Siemens blocks.


But if you would have TCP Client (TCP master on PLC) then situations changes, then if you wan't change setpoints from another PLC Via DB-blocks
(Or HMI connected to another PLC and this PLC is TCP server to another), then you need on program comparing, moving data to different buffers and selecting which is newest setpoint. (or selecting with bit on program if settings are from setted locallly or from remote side)


This same is also to Serial MB, but only if your PLC is MB master.

Also on serial if HMI or Scada is MB master, then you don't need anything else than com setting and modbus mapping on PLC side. You can change directly setpoints on PLC side, and they are changed to different also on HMI "screens" by panel communication.



(This is because HMI master communication is allways read and write by change if needed,
but PLC side by blocks is read allways or write allways if there is no any comparing if write or read is needed before communication blocks etc.)



If you have same setpoint on 2 different DB.DBW places,
then you need also comparing and moving between, depending which variable have newest data.

(So actually you need 3 variables, as you need to buffer value which is used before last change. Then it is only comaring between buffer and those 2 setpoint variables and move newest to there where is older setpoint, otherwise you can only change from one place.)

Lare said:

I would say it weird if HMI and/or Scada are TCP Clients (TCP master and your PLC is TCP Server (slave)


HMI and Scada should take care of this automatically if they are masters and all you need on PLC side is that you change same DBD.DBW address than is linked to modbus side for HMIs.
Then you don't need actually nothing else on PLC side than modbus mapping and Modbus settings with Siemens blocks.

This same is also to Serial MB, but only if your PLC is MB master.

Also on serial if HMI or Scada is MB master, then you don't need anything else than com setting and modbus mapping on PLC side. You can change directly setpoints on PLC side, and they are changed to different also on HMI "screens" by panel communication.



(This is because HMI master communication is allways read and write by change if needed,
but PLC side by blocks is read allways or write allways if there is no any comparing if write or read is needed before communication blocks etc.)

Click to expand...

My PLC is server and I will make it available to "whatever" on Modbus TCP client side.

But if the modbus Client is cyclic writing to the Setpoint, then I can't change it from HMI? Or should I demand that the Modbus Client is only writing to the setpoint when they are changing the setpoint?

Also if the setpoints are sqattered in diffrent datablocks, then it would complicate things to write directly to the setpoints? I would have to setup several MB_Servers?

HMI and Scada on Modbus client should write only from Change, but all variables is readed

If you change setpoint from PLC via DBW address and your programming laptop, it is readed to panel automatically via modbus. Also if you have more than one panel, same MB addres is changed everywhere on MB TCP Clients.

That have been situation at least on every Schneider panel and Scada.

There should not be cyclical writes if there isn't scripts on panel, normal setpoint is writed only when changed.


Only side effect whit Siemens PLCs is that you need to configure different TCP port for every TCP MB connection, still you can have same modbus addresses and also same DBW addressing on PLC side, but panels 1,2,3 needs ports like 502,503 and 504.


Different DB areas also maybe need different ports even to one panel, as only one DB-area is mapped by one communication block. Different DB-areas can go mixed if you try to communicate them to same TCP port.
You should have all modbus addressing only at one DB-area on PLC, it can be difficult if you several areas.

This different port config is needed only because of Siemens PLC and MB addressing linking by blocks. On Schneider all connections are via 502 port.

If you have only one panel and one DB-area, then you can only need port 502. If you add second panel, then you need TCP ports 502a nd 503, but DB-area is still same for both panels.





Problem can be that not all panels are capable to change MB port to different than 502, then you need some switch between which changes port from panel 502 to Siemens TCP port used.


You should only use one variable on PLC side, which is mapped to modbus. Then it goes easy on PLC side and you don't need to worry any move/copy/compare logic.

Lare said:

HMI and Scada on Modbus client should write only from Change, but all variables is readed

There should not be cyclical writes if there isn't scripts on panel, normal setpoint is writed only when changed

Click to expand...

Thanks, this is basicly what Im looking for!

Just dropping in a question yo add to thia thread. As it is right now I have the mpdbus master to write a bot to mu slave cyclicaly that I call hearbeay. If the hearbeat isnt recieved I reset all controls from the master. Is this common way to determine that communication is working?

Hard to understand what you mean ...

Normally in an installation with a PLC and an HMI screen the data is all stored in the PLC. There are no two copies of the data.

The HMI screen reads the data cyclically and can also change some of the data, but the data is always stored in the PLC, If the HMI changes some data it will be updated on the screen in the next cyclic reading.

Also in a Modbus RTU (serial) network there can only be one master, it cannot be that both the PLC and the HMI change data

lfe said:

Hard to understand what you mean ...

Normally in an installation with a PLC and an HMI screen the data is all stored in the PLC. There are no two copies of the data.

The HMI screen reads the data cyclically and can also change some of the data, but the data is always stored in the PLC, If the HMI changes some data it will be updated on the screen in the next cyclic reading.

Also in a Modbus RTU (serial) network there can only be one master, it cannot be that both the PLC and the HMI change data

Click to expand...

You can on master side code it so that master is reading setpoints from slave and then compare this data to last values writed from master.

If slave's setpoints differs from masters lastly writed values, then data is changed on slave side after master writed values.
Now you need to copy these readed setpoints from slave to master (so ther is no 2 different masters, but you read or write to / from master depending where is newest setpoints/data)


Then if master have newer setpoints, these are writed to slave (which would be normal way)

But for these you need 2 different modbus guerys for setpoints and you need also store lastly writed data to memory so that you can make compare if slave or master setpoints are newest and which way data is actually moved.)


First, write data only if setpoints are only changed on master side, you need also to write these values to some meory area on master side that you know which data values are writes lastly from master. (save data only if writing was succesful to slave)


Now, on another modbus query you read data from slave (which should have same values than you have writed little bit before)

These readed values are moved to some temp memory on master side also.
Compare these readed values to master's lastly writed values

If both slave and master data is same -> no changes on slave or master and no new writing from master.




If you change data values on master side -> set bit
-> if bit is setted -> write new values to slave. (normal writing)


On next modbus query you again read setpoints from slave.

Then you compare again. If readed data differs from lastly writed values from master, data is changed on slave's HMI panel.

Now you need to copy these readed values to above master's data setpoints
so your master PLC actually readed values from slave and copies them to setpoints)

Now data is readed and both master and slave have same data.
It works but have lot of coding.





This is actually how your PC is writing / reading on MB RTU or TCP.

(If you have PC, you can change data on PC and PLC side, and they are updated to PC or PLC.)





So why you can't change setpoints if only difference is that you have 2 PLCs communicating and on other you have PC and PLC?


On both cases you have 1 master, but if PLC is master you need make all coding on PLC, which is allready inbuild on PC master softwares.

Maybe I should started a new thread with my new question.

My new question i posted in post10 is regarding when the slave recieves control from the master.
For instance the master is starting a motor in the slave, I then want to make sure that the master hasnt lost the comms. If they lose comms then I will stop the motor. As I have it aranged right now is that the master need to send a bit high (heartbeat) to the slave. The slave start a TOF of 5 sec and the reset the incoming heartbeat. The master need to send another hearbeat within 5sec or else the TOF expires and reset all control signals from the master.

I thought it to be convinient to add to this thread

rQx said:

Maybe I should started a new thread with my new question.

My new question i posted in post10 is regarding when the slave recieves control from the master.
For instance the master is starting a motor in the slave, I then want to make sure that the master hasnt lost the comms. If they lose comms then I will stop the motor. As I have it aranged right now is that the master need to send a bit high (heartbeat) to the slave. The slave start a TOF of 5 sec and the reset the incoming heartbeat. The master need to send another hearbeat within 5sec or else the TOF expires and reset all control signals from the master.

I thought it to be convinient to add to this thread

Click to expand...

Sending certain bit or word value and resetting on other side is one of many methods.
Then setting individual Com alarm which stops or reset directly controlling bit after timeout

I have sometimes coded heartbeat like on this post:
http://www.plctalk.net/qanda/showpost.php?p=20048&postcount=2


Advantage is that you can check commmunication time on master side and communication loss on slave whit these bits.

Bit are toggled 0,1,0,1,0,1 between writes and reads.
Then you need 2 timers on slaves side which checks if bit stays too long on 0 or 1.

Or sending value 0 from master, and incrementing same value on slave side. (so you see straight on slave side, how fast communication is working between 2 writes from master)

They all work




But toggling bit only at master side (like 100ms or 1 second pulse) isn't good as depending of communication you theoretically can send allways 0 or 1 value long time even that coms are working.

Thanks, so it's a common practise to use a heartbeat then. Thanks alot