S7 - CPU still trying to access DP-Slaves although theyve been deactivated with SFC12

[RMA]

Out of 21 (near identical) Modules in this system, I have only one available to test on. On start-up I check to see which Modules are not available and then prevent these being selected. I also disable them using SFC12.

Most of the time I check whether a Module is selected before accessing it, so there is no problem. However, because the outputs of the Modules (Electrical pulses of up to 43 kA at 24 kV) are connected in parallel to one of four so-called Collectors by motor-driven switches which can also be switched by hand, it is always necessary to check that the switches of non-selected Modules are open before triggering a pulse. Since during the commissioning phase it is more than likely that a Module will be physically present but not switched on, the auto-detection of available Modules is not a sufficient safety precaution, so I must always check the state of all Modules.

Unfortunately, when I enable the S/W to do this despite having disabled the Modules I get flooded with I/O faults which pushes the cycle time up over 1 second and the CPU goes into STOP. I don't know what the maximum cycle time is, but I've set it at 500 ms at present (to try and avoid the problem) and I don't really want to increase it any further.

I've checked the state of the Modules using SFC12 Mode 0 and they all report that they are disabled. The Help file for SFC12 states quite explicitly that after being disabled, the DP-Master no longer accesses the Slaves and that the Process Image is updated with "0"s.

One thing that is a bit strange is that as long as I don't call the monitoring Block, there is no problem which implies that the Process Image update is not normally attempting to access the DP-Slaves that are disabled. The second peculiar fact is that I get exactly the same problem if I enable my general error checking S/W, even though in this case, the Modules are only accessed if they are selected.

All suggestions of how to solve the problem or locate its source would be very welcome.

[SimonGoldsworthy]

Could you do all the module detection/disabling from OB100 ? There is no cycle time monitoring in this block so you can loop and take as long as you like to get your system "smart" before running OB1.

[RMA]

Unfortunately either the FC125 or the SFC12 explicitly cannot run in OB100, but that's not the problem anyway, the indentifying and disabling of the non-existant modules works fine and as I said, after the system was up and running I enabled a patch to check the state of the modules and all the missing ones reported back that they were disabled. The one that was present also reported back, correctly, that it was enabled.

The problem is that under some circumstances and at present I'm not sure exactly what these circumstances are, they are not behaving as they should, or to be more precise, the CPU is not behaving as it should.

[RMA]

this might have something to do with it.

It occurred to me at 4:00 this morning that while I was having problems deactivating the missing DP-Slaves, I commented out the calls to the three supervision and fault-checking blocks. To enable these blocks I just edited out the comment signs and downloaded OB1 to the PLC again, but I did this online, while the PLC was running.

In the help file, I'm pretty sure it says explicitly that on a restart the deactivated DP-Slaves will be reactivated. I wonder if on restarting OB1 after downloading it, an implicit restart is occurring. I could certainly imagine that OB1 might well be handled a little differently than ordinary FBs and FCs.

It'll be Monday before I can check this out, but maybe somebody knows the answer already.

Cheers

Roy

[RMA]

Well, I've checked it out and the answer is "NO"!

I modified the 3 supervision blocks to put a BEA at the start, so that they wouldn't do anything. Then I modified OB1 to call all three, instead of leaving them commented out and downloaded OB1 and the three supervision Blocks to the running CPU. Result, the CPU kept on running and checking the state of the DP_Slaves showed that they were still reported as being disabled - so that isn't being changed.

Then I went back into one of the supervision Blocks and commented out the BEA and downloaded it to the CPU. Result - cycle time = 1000ms, CPU -> STOP!

The only thing that occurs to me at the moment is that after start-up most of the I/O is not being accessed, because I have the program divided into Phases and the I/O is only accessed when it is needed and immediately after start-up, it is not being accessed.

What it looks like (and I'm not saying that this is definitely the case!) is that regardless of whether or not the DP-Slave is deactivated, the first time the program tries to access some I/O, the CPU tries to access it regardless of the activation state of the DP-Slave.

[RMA]

This Thread can now be laid to rest!

In the diagnostic buffer I noticed that one of the DBs that was open at the time of the CPU timing out was the Status DB for the last of the modules to be checked. Thinking that this might explain why occasionally the FB would run OK and on other occasions cause a CPU time out with a cycle time of 1000 ms, I upped the allowable cycle time to 1 second and tried again. Now if the timing had been touch and go before, twice the amount of time must surely be enough, but no, once again the CPU went into STOP after a cycle time of 2000ms.

OK, I know I'm sometimes a bit slow on the uptake, but I'm not totally daft. Following the checks on the last module, there is a network with a little bit of code which checks to see whether there has been a fault and if so causes a jump to the appropriate fault screen. So I put a BEA at the start of this network and sure enough, no more crashes.

So there we have it - end of one Thread, start of next one!