MB_Client TIA Issue

bb76 · Oct 20, 2021

I'm trying to set up some comms for a new bit of kit we're getting. The OEM has supplied a simulator software in order to do this.

I need to read 20 registers from the simulator over Modbus TCP from their Modbus server so I've created a MB_Client block and it's happily doing it's thing. The issue I have is that the values it is reading are jumping from the actual values to zeroes.

After trying different block versions, TIA versions, timers for the read request I noticed that in the MB_Client DB there are some temp data registers and the values are constant in there but the values being output from the block to my DB seem to jump to zero in line with the block active signal going false.

Has anyone got any idea what is happening here? We have a few of these blocks in other bits of kit and I can't see any differences in the config.

Edit: Also tried S7 1200 & 1500 but same issue.

L D[AR2P#0.0] · Oct 20, 2021

Disable the modbus block and verify that nothing else is writing to your DB by modifying some values in the online view.

bb76 · Oct 20, 2021

L D[AR2 said:
Disable the modbus block and verify that nothing else is writing to your DB by modifying some values in the online view.

There is nothing else in the code at the minute, only the client block and my DB.

Lare · Oct 21, 2021

Any screenshots of blocks or code?

RVaughan · Oct 22, 2021

First thought is, of course, post the code.
Second thought is, are any of the values stored in Temp variables? Inside optimized blocks the Temps are initialized each block call.

bb76 · Oct 22, 2021

Apologies, other work got in the way!

So a few pics for you.

Image 2 shows the client block.
Image 3 shows my DB containing the TCON IP v4 addressing tag and the array the data is being moved to. (note the data values are all zero)
Image 0 shows the same DB with actual values. Pics are a couple of seconds apart.
Image 4 shows the status code I've recorded as it operates. Mostly 7005/7006 (data being sent/received) but near the bottom of the pic there is 0000.

So the block is executing and receiving data but it seems like it drops connection for some reason.

Since the first post I've also used a red lion data station with the same addressing which works perfectly, so it's an option to use if I need to but if I can understand why the client block isn't happy it is much cleaner.

bb76 · Oct 22, 2021

Forgot the pics!

m_turk · Oct 22, 2021

- That "busy" bit on REQ.. I don't think you need it, and it might even cause problems. Try it with "always on".
- maybe the device can't reply so fast as you are calling it.. You'd then need an edge every second or two on REQ.
- I usually have a buffer, that would be your "MB_Data_Pointer". And another array and then If "done" move "MB_Data_Pointer" to Data_Array. That doesn't overwrite your data if there is an error.. Try that.

Lare · Oct 22, 2021

m_turk said:
- That "busy" bit on REQ.. I don't think you need it, and it might even cause problems. Try it with "always on".
- maybe the device can't reply so fast as you are calling it.. You'd then need an edge every second or two on REQ.
- I usually have a buffer, that would be your "MB_Data_Pointer". And another array and then If "done" move "MB_Data_Pointer" to Data_Array. That doesn't overwrite your data if there is an error.. Try that.

MB_client needs rising edge on request input.

What I think is that MB_client is sending next request too soon as there is no delay after busy signal of same block is back to false.

MB_client takes several PLC cycles to operate so it can be timing error. Modbus query answer isn't processed before you send another message.

MB Serial coms makes CPU to fault if new request are sended faster than CPU can handle.

(At least on 300 series with same blocks)

Try clock bit to request (0,5s or 1second), will it work then?
Then make coms faster and look when it start to go wrong.

m_turk · Oct 23, 2021

Lare said:
MB_client needs rising edge on request input.

What I think is that MB_client is sending next request too soon as there is no delay after busy signal of same block is back to false.

MB_client takes several PLC cycles to operate so it can be timing error. Modbus query answer isn't processed before you send another message.

MB Serial coms makes CPU to fault if new request are sended faster than CPU can handle.

(At least on 300 series with same blocks)

Try clock bit to request (0,5s or 1second), will it work then?
Then make coms faster and look when it start to go wrong.

Are you sure? I'm not sure for the MB TCP, but 100% sure for MB Serial in TIA that they changed the way REQ is handled (V14 or V15) and that you don't need the edge. It generates its own edge when not busy. I know because it was giving me problems with my routines where I was using 1s clock like you suggested, but the block went on and got more reads instead of one.

I agree that no delay on only one device might be giving him problems, but just putting the clock bit will make it read for half a second and then not read for half a second. That is why clock bit with edge is what I suggest..

Lare · Oct 23, 2021

m_turk said:
Are you sure? I'm not sure for the MB TCP, but 100% sure for MB Serial in TIA that they changed the way REQ is handled (V14 or V15) and that you don't need the edge. It generates its own edge when not busy. I know because it was giving me problems with my routines where I was using 1s clock like you suggested, but the block went on and got more reads instead of one.

I agree that no delay on only one device might be giving him problems, but just putting the clock bit will make it read for half a second and then not read for half a second. That is why clock bit with edge is what I suggest..

Haven't tested it lately. Over one year when last time played with modbus and MB_client block.

Pretty sure that block needed square wave on reguest pin earlier. Then it maked rising edge inside of block.

If reguest pin was setted only to allways on state, then it only sended one reguest, not multiple ones.

I should test with V16 to be 100% sure, but no time for that.

Rising edge outside of block at least don't make multiple requests.

p.s

On old communication manual there was example that request pin is controlled by anothers MB_cliet block's done and error bits.

First block is started with first_scan bit and if another block is done or error.

Done and error bits are true only one scan so maybe r_trig is need outside. (or use done and error bits)

m_turk · Oct 23, 2021

Lare said:
Haven't tested it lately. Over one year when last time played with modbus and MB_client block.

Pretty sure that block needed square wave on reguest pin earlier. Then it maked rising edge inside of block.

If reguest pin was setted only to allways on state, then it only sended one reguest, not multiple ones.

I should test with V16 to be 100% sure, but no time for that.

Rising edge outside of block at least don't make multiple requests.

Yeah, it worked like that, I know. But it doesn't for MB_Master anymore so I guess it is the same with MB_Client. And don't want to use the weekend for testing either, lol..

He can't go wrong with the rising edge outside the block, then it will do just one no matter how it works internally..

Lare · Oct 23, 2021

m_turk said:
Yeah, it worked like that, I know. But it doesn't for MB_Master anymore so I guess it is the same with MB_Client. And don't want to use the weekend for testing either, lol..

He can't go wrong with the rising edge outside the block, then it will do just one no matter how it works internally..

Quick googling gived this manual for 2019.

https://cache.industry.siemens.com/...8119/v6/net_modbus_tcp_s7-1500_s7-1200_en.pdf

Chapter 4 on page 19.

MB_scleint and server

request:

Modbus request to the Modbus server, for example:
•Write holding register
•Read holding register
The "request" parameter is level controlled. This
means that the instruction sends communication
requests for as long as the input is set.

I undestand it that way that rising edge is needed outside of block.

Lare · Oct 23, 2021

m_turk said:
But it doesn't for MB_Master anymore so I guess it is the same with MB_Client.

You probably meaned to write
"But it doesn't for MB_server anymore so I guess it is the same with MB_Client."

As MB_Master is same than MB_client and MB_Server is same than slave.

m_turk · Oct 23, 2021

Lare said:
Quick googling gived this manual for 2019.

https://cache.industry.siemens.com/...8119/v6/net_modbus_tcp_s7-1500_s7-1200_en.pdf

Chapter 4 on page 19.

MB_scleint and server

request:

Modbus request to the Modbus server, for example:
•Write holding register
•Read holding register
The "request" parameter is level controlled. This
means that the instruction sends communication
requests for as long as the input is set.

I undestand it that way that rising edge is needed outside of block.

Yup. That is how I thought it works now..

Edge outside to achieve the delay we both think he needs.

MB_Client TIA Issue

bb76

Member

L D[AR2P#0.0]

Lifetime Supporting Member

bb76

Member

Lare

Member

RVaughan

Member

bb76

Member

bb76

Member

m_turk

Member

Lare

Member

m_turk

Member

Lare

Member

m_turk

Member

Lare

Member

Lare

Member

m_turk

Member

Similar Topics