S7 - Fault during program download

RMA

Member
Join Date
Sep 2004
Location
North of Hamburg, Germany
Posts
2,052
I've got a couple of FBs which are virtually identical, in fact one is a copy of the other with only a single parameter changed when calling the FC sub-routine.

These programs both compile and save OK Offline, but when I try to download them I get a message saying that it was not possible to copy the file. According to the error message Help file the most likely causes are:

1) The files already exist, but cannot be deleted, for some reason. - No, online neither file exists (I've had this problem since day one, so no version has ever made it to the CPU)

2) I'm using an instruction which is not allowed on the CPU concerned. Well the only thing slightly exotic, which I'm using is SFC108 - Alarm_D and commenting it out made no difference.

3) I'm trying to access Periphery at an address higher than exists on the CPU concerned.

Well this last one might be a possibility, but I'm using indirect addressing here. I would have expected the fault to be generated at Run-Time, or is this sort of thing checked at Download time?

What makes life a bit harder is that simply jumping round bits of the program doesn't solve the problem. i.e. putting

SPA sorry, JU exit

on the first line doesn't clear the fault, it looks as though I need to go through and comment out everything, which is a major pain in the neck!

Any thoughts on what the problem might be and any more convenient way to track it down, other than working my way though the whole program and commenting out line by line.
 
You could comment out half of your code to determine what half causes this fault, then comment out half of the remaining half or uncomment half of the other.
 
Yes, I know about Binary divides, it's still an awful lot of slashes though! Still if nobody comes up with any bright ideas, I guess I'll just have to bite the bullet! :(
 
I actually had one of those faults yesterday.
The cause, using bit M260.0 when the maximum allowed for that PLC was M255.7.

I would check what is allowed for your PLC.

Also, in some they limit the range of FCs and FBs, often to 128 but I think some earlier ones only allowed you to go to FC64.

Timers could also cause this problem.

My 2c.

Doug
 
Found it, or to be more precise, them.

Problem number one was a Timer No. I've grouped my Module related Timers by Module Nr., i.e. the Timers for Module 1 have numbers between 10 and 19, Module 2 has Timers T20 - T29 etc. (don#t what I'll do if I need more than 10 Timers, fortunately I don't, yet!). For other general purpose Timers I started at the other end and did exactly the same T512! There are 512 Timers available numbered, of course, T0 - T511! :oops:

Problem Number two was a classic case of believing Siemens' Help Files. In the Help file for ALARM_S (and _SQ) the first two lines tell you that for new projects you should in future use SFC107 and 108 - ALARM_D and _DQ, apart from anything else, because they handle system resources better.

What they unfortunately don't say, is that they don't work with 300 Series CPUs - or at least, they don't work with my 317-2 DP!
 

Similar Topics

I have a cell with a compact guardlogix as the plc and I have three hmi's and two vfd's on this cell. I been experiencing momentary comms faults...
Replies
10
Views
154
Any one give solution for this fault. We are using AB Gaurd logix controller(5573s), resent days we are facing major fault in controller...
Replies
1
Views
95
I migrated to a WSP2023 application. Now when I open a HMI object (for example a valve or motor) the popup is first correctly show as defined ...
Replies
0
Views
58
We had a site where a rat gnawed through some fiber optic cables which (obviously) prevented communication to a remote rack entirely. We, and the...
Replies
3
Views
134
Good morning everyone I’m currently working on a omron device net and have a nord drive that fell off the network. I have limit knowledge in...
Replies
3
Views
159
Back
Top Bottom