S7 300 Backplane

[RMA]

Hi S7Guy,

I was just about to go home when I noticed you were back in the forum, so I stayed on just in case you needed some info that I could only give with the system in front of me.

The FMs are virgin, or at least 2 & 3 were, so they had both the SF and MMC fault LEDs on before I started. FM1 I had loaded before, with the demo program that comes with the FM S/W. I can't remember exactly but I assume the SF fault would have been on there as well, because I didn't muck about with the standard paramerization so I would assume there was a fault because I had no 24V on the IO.

I don't know how the communications were handled on the other 352s. In the 352-5 you have to create two DBs exactly 14 Bytes long, called CPU_In and CPU_Out, which then map to these addresses in the declaration table of the FM. These are NOT the same as the IDB and you can assign the Bytes and Bits any way you like. It's quite well covered in the handbook, which I put link to earlier on in this thread. The description is in Chapter 6.2.

As far as writing to the variables is concerned, I haven't tried anything there, but when you make the call to the FB, part of the info you have to pass over is the address (as shown in HW-Config) and the DB-numbers for the IDB and the CPU_In and _Out DBs, so I would think that aspect ought to be fairly well covered.

I'm off back to my digs now, because my wife will be expecting a phone call in about half an hour. I'll have a look in from there later on.

Cheers

Roy

 

[nif]

jesper

Here is the info
http://www4.ad.siemens.de/dnl/jIyNzM3MwAA_19124657_FAQ/S7KommMoeglichkeitenAllg_00_e.pdf

 

[RMA]

This has been niggling at the back of my mind for a while now, so I finally got round to working out how long the FM352-5 to CPU update needs. On the basis that for a complete transaction we need both input and output data then the pure transmission time works out at (14 + 14) * 8 /187,5 ms = 1.195 ms.

On the face of it this seems to tie in quite well with the 1.4 - 1.5 ms typical, 1.7 ms max which Siemens quote in the FAQ which rsdoran turned up on page 1 of this thread. Assuming that in their firmware update, one of the modifications was to give the FM352-5 the highest priority on the bus, this is probably fairly realistic - for 1 FM352-5. But I've got three of them on the Buss, not to mention the CP343-1 IT which presumably also likes to talk to the CPU now and again - It's a good job I'm not in the position of depending on 1.7 ms max being correct!

Now if only I could find out where the heck my internal error is coming from we could go and measure it - the scope's sitting there ready.

 

[nif]

Speeds for updateing th I/O:s

Process Image Updating
The table below shows the CPU times for process image updating (process image
transfer time). The times listed in the table are “ideal values” that may be increased
by the occurrence of interrupts and by CPU communications.
The transfer time for process image updating is calculated as follows

C + portion in central rack (from line A of the following table)
+ portion in expansion rack with local connection (from line B)
+ portion in expansion rack with remote connection (from line C)
+ portion via integrated DP interface (from line D)
+ portion of consistent data via integrated DP interface(from line
E1)
+ portion of consistent data via external DP interface (from line
E2)
-----------------------------------------------------------
= transfer time for process image updating

The following tables list the individual portions of the transfer times for updating the process
image (process image transfer time), once for standard CPUs and once for redundant CPUs.
The times listed in the table are “ideal values” that may be increased by the occurrence of
interrupts and by CPU communications.

Portions
n = number of bytes in the process image
c= number of consistency areas ****) in the
process image
CPU 412
C Base load 20 uS
A In the central rack *) **) n * 1.5 us
Read byte/word/double word
Write byte/word/double word
with n = 1, 2 or 4


Type of Access CPU
412-1
I/O Module
Read byte 3.0 us
Read word 4.7 us
Read double word 7.6 us
Write byte 3.2 us
Write word 4.7 us
Write double word 8.1 us

 

[nif]

http://www4.ad.siemens.de/dnl/jQ1NTg1MQAA_100605_FAQ/mpikom_e.pdf

check page three

A little bit old manual

 

[RMA]

Fortunately the 317, like the 318, is a sort of half-way house to the 400s. The 317 can handle up to 8 FMs/CPs and 32 connections.

In the meantime I've been back and loaded the Demo program which came with the FM352-5 and this runs just fine. Now that I've got 24 V on the I/O, there's no SF error LED and the OP LEDs are running up and down just like they ought to.

So it's defintely a fault in my oh-so-simple program. Now I just need to find out where!

 

[jacekd]

Hi Niklas,
Where have you found it ?

Type of Access CPU
412-1
I/O Module
Read byte 3.0 us
Read word 4.7 us
Read double word 7.6 us
Write byte 3.2 us
Write word 4.7 us
Write double word 8.1 us

 

[nif]

Hello!
I have this siemens Cd called manual collection. It contains all the siemens manuals in PDF -format.
I read through think it was some CPU specifications manual or maybe I found it on the siemens home pages?

 

[RMA]

I couldn't find the English versions in a hurry, but searching for "operationsliste" in the German pages of the Siemens support side brought these two up on the second page:

S7 400 operationsliste

S7 300 operationsliste

They are massive URL's so I hope they work. Those are the download pages, by the way.

Cheers

Roy

 

[RMA]

Well, I solved my problem with the internal error by the simple expedient of taking the Demo program and modifying it (extending it) to run my test program. Yes I know it's cheating, but I'll worry about why the other version didn't work when I've got more time!

That was the state of affairs at about 10:00 this morning, and it's taken me up till now to dig up a scope that actually works!

It's getting to be a habit on this project, that every step forward usually delivers another puzzle, this time's no different!

On the basis of the ~1.5 ms update times quoted by Siemens, I was expecting to see cycle times (for my output DOT, ON -OFF - ON) of about 3, 6 or 9 ms, depending on how many FMs were active. Wrong again, total cycle time is approx. 23 ms - regardless of how many FMs were doing something. Even when I commented out the calls for the Demo program, nothing changed. Since the Run light modified its blink behaviour according to whether the (common) Debug bit was set or not, it looks as though there is a baseline communications overhead as soon as you include the hardware in the project.

The second thing that was a bit odd, the cycle is asymmetrical, the time from being OFF to switching ON is 10 ms, the time till it switches OFF again is 13 ms. Having a look at the cycle times in the diagnostic panel, using the refresh button turned up cycle times of 11 and 15 ms - as I say I have no idea how accurate the scopes calibration is, but it ties in pretty well.

So there are the questions - am I wrong in my feeling that these are ridiculously long cycle times for a program that consists of just the four FM calls and about 20 lines of simple AWL code? According to the operations list the 317 executes a CALL FB/DB in 1.9µs. OK, I realise that doesn't say anything about how long the program requires to execute.

And how come the big difference between cycle times between ON and OFF cycles.

Apart from the FB calls this is the program:

UN DB5.DBX0.0 //CPU_In DB
S DB6.DBX0.0 //CPU_Out DB

U DB5.DBX0.0
R DB6.DBX0.0

In the FM the program consists of an AND gate which copies the the mapped value of DB6.DBX0.0 to DOT 7 and to the Interface to DB5.DBX0.0.

Another point, there is no timing difference (measurable) between running the program under "Normal" purely in the FM352-5 or running it under "Debug" where each step of the program is passed back to the CPU to enable obseervation of the program in its FB.

 

[rsdoran]

Is it possible the scan cycle time in module information is set high?

You can set the maximum and minimum cycle times when you configure the hardware. To do this, double­click in the offline view of the configuration table on the CPU/FM to define its properties. You can enter the appropriate values in the “Cycle/Clock Memory" tab.

 

[RMA]

As far as I can see there is no provision for affecting the cycle time of the FMs in any way.

In the CPU, the only possible adjustments are cycle supervision (i.e. max.) period, set by default at 150 ms and the % of cycle time for communications. There is a box for minimum cycle time but it's grayed out and set to zero.

The only other boxes available, also grayed out, are for size of the process image - I assume this only becomes available if you have more I/O than the allocated process image memory can cope with, at the moment the box is empty. The other box is a check box for OB1 cyclical process image update, which is checked.

 

[S7Guy]

Hey Roy,

Are you showing any hardware errors? If so, those can drive your scan time up significantly. I just want to make sure that isn't the case.

Secondly, this looks suspicious (probably because I can't see the rest of your project):

UN DB5.DBX0.0 //CPU_In DB
S DB6.DBX0.0 //CPU_Out DB

U DB5.DBX0.0
R DB6.DBX0.0

In the FM the program consists of an AND gate which copies the the mapped value of DB6.DBX0.0 to DOT 7 and to the Interface to DB5.DBX0.0.

Since the code you wrote can actually be written like this,

UN DB5.DBX0.0
= DB6.DBX0.0

and it appears that DB6 is being mapped back to DB5, is it possible that DB6.DBX0.0 is toggling on every scan? Could this cause the FM to complain or soak up scan time? Just a thought.

 

[nif]

Hello!
Have you checked these things in hardware settings:

Operation
Irrelevant for S7-400 and CPU 318-2.
In process operation the test functions such as program status or monitor/modify variables are restricted so that the set permitted scan cycle time increase is not exceeded. Testing with breakpoints and sequential program execution (single-step mode) are not possible.
In test operation all test functions via programming device/PC can be used without restriction which may cause considerable increases to the length of the scan cycle time.
Important: If the CPU is in test operation, you must ensure that the CPU or the process can "cope" with large increases in scan cycle time.

By selecting the "Process Mode" option, you can prevent the test mode and the call environment from being selected in the program editor.


Monitoring online will cause the cycle to increase, if you want the update time connect a scope to the output and check the cycle.

I made a program with 316 the cycle time was under 20 ms program code was around 86 kb.
Have you checked which standard blocks the FM calls, they have their own times.

 

[jacekd]

...

There is a box for minimum cycle time but it's grayed out and set to zero.

The only other boxes available, also grayed out, are for size of the process image ...

The boxes for minimum cycle time and size of process image are only availible on s7-400 CPUs and probably on CPU 318.