Siemens S7-1200 to Vacon VFD Modbus RTU errors help

I have 3 control panels made by an OEM, they are all identical and have a Siemens S7-1200 PLC with a Siemens CB-1241 Modbus card talking to 2 Vacon 20 VFD's.
The PLC program in the working panels is password protected so no help there.

We have to make changes to the process and the OEM is gone, so I purchased the exact plc and modbus card and wrote a new program.

All I have done is pop off the terminal strips from the OEM PLC and installed my new PLC so there have been no wiring changes at all.

I can control both VFD's over Modbus and everything looks fine, but after a couple minutes the MB Master instruction starts getting
16#80C8 error (timeout error) and
16#80E2 error (frame error)

After a couple of hours of running, the Vacon VFD's will fault out.

I can pop the old OEM plc back in and there are no errors (I can get online with the OEM PLC and see their MB Master tag values)

So that means there are no wiring or noise issues (I believe)

This is my first Siemen's PLC program, I have been programming AB for almost 20 years, so there is something wrong with my Siemens program but I can't figure it out.

I have rewritten the program three times, once using multiple instances of the same MB Master block and a hz counter to fire messages in sequence.

Rewrote that one to use the MB Master done bit to move to the next step..

Rewrote again to use a single instance of the MB Master instruction and used the step function to move in the different values.

All programs are getting the same errors

I have triple checked the Modbus settings in drive and PLC and they are:

9.6 kbps
no parity
8 bits per character
1 stop bit

I have attached a pic of Modbus settings from both PLC and VFD

Also attached a link to PLC program on OneDrive:

https://1drv.ms/u/s!AmzzeJcgGAJomAThZRSm3va8I9r3?e=dCTAYj

Thanks in advance for any advice...

Sounds like that is collisions on RTU data side.



I have done it that way, that if MB_master blocks is not busy & delay timer then enabling next query.


Looked your code and I'm not sure if you error handling works at all. Done and error bits are one scan bits and there is 1s delay for them.


MB com load have timeout 1s and MB_loads parameter retries is at default value (2 at static variables). This means that actually on error same modbus querys is sended 3 times and whit 1s delays. Actual timeout is 3s.


I think that now when your error handling makes next querys afte 1 or 2 seconds it makes collisions on data side with growing speed.

This leads to that VFD wont see any data coing from master and after VFD timeout drives are faulted to fieldbus errors.

Thank you Lare,
Are you saying I should put a 1 second delay between messages?

Thanks

Start whit 1s, then make it smaller if needed faster coms.



Change code that if master have error then change to next state. (done and errors on pareller)



Timeout on hardware can be 1s, it should be only hundres of milliseconds for one query on RTU and direct cables.



Change replies to 0 on modbus load block.


Then for error handling make init for block is busy signal is stuck on "1" state 5-20s or state is not changing. There is no need to have error and done bits on error handling I think.


It is also possible that CPU forget MB_load paramters if PtP-card is removed. (This can happen on ET200S and SP on remote IO racks. On that case state starts to change on rapid speed as modbus querys are not sended at all and busy signal is allways false. But on 1200 with CB-1241 you probably don't need to take care of that. MB load needs call again on that case so that MB_master can send data again.)


I have done working coms with several modbus master blocks (one master block for one MB query).
As on RTU and one RS-port this anyway leads that you need enable correct MB_master block at time as instance block needs to be same for MB_load block, which means that you need same instance also for MB_master. But that way you don't need take care that MB_master querys data is pointed to right VFD data area.


On TCP side there can be several MB_master and instance blocks for querys same time.




Good thing is that it isn't old 300 with CP or ET200S PtP. They were much more awful to code as you also need to listen MB reply with different block and Modbus query was sended with other block.

Lare said:

Start whit 1s, then make it smaller if needed faster coms.



Change code that if master have error then change to next state. (done and errors on pareller)



Timeout on hardware can be 1s, it should be only hundres of milliseconds for one query on RTU and direct cables.



Change replies to 0 on modbus load block.

I do not know where to change replies?

Then for error handling make init for block is busy signal is stuck on "1" state 5-20s or state is not changing. There is no need to have error and done bits on error handling I think.

I do not know what you mean by init for block is stuck on 1

It is also possible that CPU forget MB_load paramters if PtP-card is removed. (This can happen on ET200S and SP on remote IO racks. On that case state starts to change on rapid speed as modbus querys are not sended at all and busy signal is allways false. But on 1200 with CB-1241 you probably don't need to take care of that. MB load needs call again on that case so that MB_master can send data again.)


I have done working coms with several modbus master blocks (one master block for one MB query).
As on RTU and one RS-port this anyway leads that you need enable correct MB_master block at time as instance block needs to be same for MB_load block, which means that you need same instance also for MB_master. But that way you don't need take care that MB_master querys data is pointed to right VFD data area.


On TCP side there can be several MB_master and instance blocks for querys same time.




Good thing is that it isn't old 300 with CP or ET200S PtP. They were much more awful to code as you also need to listen MB reply with different block and Modbus query was sended with other block.

Click to expand...

thank you

Replies is static parameters at instance db of MB_load. You could chnage its start value to 0. but it is better to move value 0 with move block to there. (On your case it is located on IDB DB3 block).


Note that if you have retries, then actual timout for MB_coms is timout value * retries. By default it is 1s * 3 = 3s.


That is why your 2s error timer behaves wrongly if any of VFD communication have error.


With stuck I meaned that if stepper number is not changing, if done or error bits are not changing to "1".
It is possible on some circumstances that busy signal is staying on "1" state and there is never error or done. I think that on that case your error block won't reset communication at all.




Look attachments.

last 2 attachments

Thank you very much for the help Lare...

Comms are working great!

lunenburger said:

Thank you very much for the help Lare...

Comms are working great!

Click to expand...

good to know that it worked .


I have programmed it little bit differently but principle was same than yours. Instead of moving addresses to one MB_master block, I enable different MB_master blocks whit same instance data block. So eventually it works same way.


I also like to see directly from MB_master block inputs what addresses is asked on that network / MB_master. That way I don't need to go online or don't need to look stepper numbers for which addresses are valid at which time. (Of course at online you can see addresses allways. on both ways.)


I have also added ok, error and all message counters. From counters it is more easy to see if only one slave have communication problems and others are working 100%.