hi,

Kicken

Hmmm.. This F-monitoring time is default 2500ms in step 7, and I have not changed this?

looks like someone else on your site had the same failure before, because default is 150ms.

When the F-monitoring time is this high, I guess the CRC-error has an other reason. Check the reasons that are mentioned before.

regards,

mopS04

 hi,

Kicken

Hmmm.. This F-monitoring time is default 2500ms in step 7, and I have not changed this?

looks like someone else on your site had the same failure before, because default is 150ms.

When the F-monitoring time is this high, I guess the CRC-error has an other reason. Check the reasons that are mentioned before.

regards,

 It's a new project I'm working on, and default was 2500.

I even tried to create an other configuration from scratch with only a 315F-2 PN/DP CPU and a single FAI6x15bit HART card and F-monitoring time is 2500ms.

Can the default time be different on different step7 installations/computers?

Installed versions:

Step7 V5.5.4.8

S7 F Confifuration pack V5.5 SP12

S7 Distributed safety Programming V5.4 SP5

Kicken

 It's a new project I'm working on, and default was 2500.

I even tried to create an other configuration from scratch with only a 315F-2 PN/DP CPU and a single FAI6x15bit HART card and F-monitoring time is 2500ms.

Can the default time be different on different step7 installations/computers?

Installed versions:

Step7 V5.5.4.8

S7 F Confifuration pack V5.5 SP12

S7 Distributed safety Programming V5.4 SP5

 hi Kicken,

no, the default-settings are not depending on the Step7 versions and should be always the same.

The most of the modules have a default time of 150ms.

I had a look on the default parameters of the FAI6x15bit HART in the manual. It has a default time of 2500ms. so everything is ok.

Have a try and set it to the maximum of 10000ms. If the error still occurs, you have to search for other reasons.

hope this helps,

regards,

Dear All,

I am also facing similar problem in one of our project. We are using Step7 v5.5 with Safety.

One of DI module is giving CRC error. All the settings of this module is same as other module which are error free. The monitoring time has been changed to 3500ms from 2500 ms.

The issue is with one of the F-DI.

Please suggest to solve the issue.

Regards,

Udaybhaskar

 hi Desi-Boy,

what about the other possible errors, that are mentioned in this thread?

mopS04

 

Pittiplatsch

Hello,

CRC signature error during communication between the CPU and the module has occurred, for example,

1. due to electromagnetic interference in excess,
2. faults during sign-of-life monitoring error,
3. in case of voltage drop
4. standard program accesses F-SM.

Does any point applies to your problem?

 hi,

I know some more reasons of the CRC signatur error:

5. security-relevant parameter in HW-Config were changed and the changed F-program was not compiled and loaded.

6. DIL-Switches adjustment is not rigth

7. F-Call is not called in an Interrupt-OB(e.g. OB35)

I guess No. 5 could be the reason of your problem.

hope this helps,

regards, 

Also tell us, which module you have exactly.

regards,

Did anyone find a solution to the problem described? I see a lot of suggestions but no confirmation on a solution.

I am facing the same here on 2 installations. Previouslly both had a 317F-2PN/DP CPU installed with F-modules next to itof one or more of the following types:

FDI24xDC24V: 6ES7 326-1BK02-0AB0

FDO10xDC24V/2A: 6ES7 3262BF10-0AB0

FA6x15Bit Hart: 6ES7 336-4GE00-0AB0

All was fine. Due to plant expantion we moved the CPU's and place IM153-4 (6ES7 153-4BA00-0XB0-V4.0) modules infront of the F-modules. No IO-wiring of the F-modules is changed, but since then we are facing the CRC error on each of the modules in both systems.

A 3rd system is running on the same network with IM153-4 and only F-AI modules without any problems.

I have checked all 7-points mentioned within this post, but without any result. Additionally I changed:

- OB35 cycle (100ms) to OB34 (200ms) --> No result

- Modified some PROFINET timing settings --> No result

- Repositioned the CPU into the same cabinet as the remote IO so that all network cabling and switches throughout the plant are eliminated, with the exception of one 2m ethernet cable bewteen CPU and RIO. --> No result.

Could anyone advise on below items or give any other suggestion to look at:

A) Use an F-separator (6ES7- 195-7KF00-0XA0)? This is not required according the IM153-4 manual, but maybe ...... it is....?

B) Is the order of IO modules within the RIO of any relevance? Now we always have F-DI/F-DQ/F-AI. In the CPU that runs without errors, we only have F-AI's installed and no digital modules. Might it be a solution to first install F-AI’s and then the digital ones?

Please advise since major commissioning activities are currently on hold by this since e-stops remain active.

Kind regards,

Joost

For those who are also looking for answers like I did, I finally found the problem in my application which caused the CRC errors.

In the end it was a programming error were I was writing to address 0 (zero), which was the address of the F-DIO module within my remote IO.

The point was that I had added some typical functions for valves, pumps and scales etc. but which were not fully functionally configured since I was missing required information from other parties.

One of the functions is used to read data from a scale that communicates via PROFIBUS. Since I did not yet have an address for this device, I left it address input empty on the function block that I use to read the required data.  In this case the function used the default value of the function Input signal, which is .... 0 (zero), just like the address of my safety IO.  So when the function was called, it tried to read/write data for my scale on address 0.

I found this by disabling all calls of my standard program (not safety) by adding an unconditional jump in OB1 from beginning to end. When not calling any of the standard program the problem was solved. Then step-by-step I add some calls until the error reoccurred, and I found the function that was causing this.

Hope that this might help some of you and bring on the right track in solving your problem. It cost me 4 days.

Thanks to Siemens Support who advised me to check on this, since I was quit confined that programming could not be the cause.

Regards,

Joost

For me the same problem after changing the sensor supply from internal to external. After the change all 3 safety DI are not functioning with the Cyclic Redundancy Check as error on all modules.

After checking all options from this thread I have finally found my weird solution:

I use the Edit safety program menu option in Step7. 

Then from this editor I compile and download. 

This results in the CRC error.

Now if I compile in the Edit safety program menu and do not download from this screen, but I go back to all blocks and the copy all the blocks to the PLC from the blocks overview in Simatic manager then all my problems are gone.

A very very strange solution and it costed me over a week of trouble. Looks like a bug maybe, but I am happy that the machine runs again......

This is a real solution. I had the same problem. When I changed CPU to STOP, problem disappeared, when I changed to RUN it appeared again. So I put BEU at the beginning of OB1  and moved it to the end of the block while I found the function which caused the error.

Siemens should do something about it!!!

Dear All,

I have the some problem. I using Et200S modules. After download the hardware configuration, all modules work. If I enable the safety input/output or use QBAD bit in the safety program, all safety modules come down with CRC fault.