Have I told you guys how much I hate programming using Step7 today?

[Nick B]

Stretching Image

Any CPU 315 and bigger (V2.5+) can have it's process image stretched. I prefer this method. It's also the way PCS7 does it. They stretch the image and drop everything into a huge IW/QW area.

Nick

 

[JesperMP]

It wasn't luck because they knew the 128 limit when they started. There is an old saying here, "I would rather be lucky than good" I tend to think that Peter's company is both.

Sure, but in this case I think it is luck.

 

[JesperMP]

Any CPU 315 and bigger (V2.5+) can have it's process image stretched.

Good tidbit of info there ! Didnt know that.

I did a test, and found out a little bit more:

315-2PNDP - firmware 2.5+: Yes, can resize the proces image.
315-2DP - firmware 2.5+: No, cannot resize the proces image.

This confirms a suspicion that I have had for some time, and members on other forums are also hinting at:
The 315-2PNDP is really a derated 317-2PNDP, not an enhanced 315-2DP.
Appearantly, the 315-2PNDP should have much better instruction cycle times than a 315-2DP, and better than it says in the latest documentation for "315" CPUs.

 

[bkottaras]

Any CPU 315 and bigger (V2.5+) can have it's process image stretched. I prefer this method. It's also the way PCS7 does it. They stretch the image and drop everything into a huge IW/QW area.

Nick

Good stuff on here.
Never worked with PCS7 but this Process Image thing is awesome.

 

[S7Guy]

One thing to consider when stretching the process image (I've done it in the past on the 400s) is that it does take longer to update the image. That said, the time increase may be inconsequential, but I can't say for sure. I seem to remember an application note from years ago that if the PI was shrunken and all IO was made as contiguous as possible, then the image update time would be quicker.

Some day I am going to have to sit down with a processor and scope and run some tests of my own.

 

[bkottaras]

One thing to consider when stretching the process image (I've done it in the past on the 400s) is that it does take longer to update the image. That said, the time increase may be inconsequential, but I can't say for sure. I seem to remember an application note from years ago that if the PI was shrunken and all IO was made as contiguous as possible, then the image update time would be quicker.

Some day I am going to have to sit down with a processor and scope and run some tests of my own.

Isn't this the case with pretty much all CPUs?
ControlLogix will do the same. They recommend using the same technique to keep scan times down and have better update and consistancy. I believe this is true for all image tables regardless of manufacturer.

 

[S7Guy]

Isn't this the case with pretty much all CPUs?
ControlLogix will do the same. They recommend using the same technique to keep scan times down and have better update and consistancy. I believe this is true for all image tables regardless of manufacturer.

Yes, it probably is. I just don't know what the real implications are.

For instance, let's say that "out of the box", my CPU use 0-511 for the process image and 512+ for the peripheral image. If I am only using bytes 0-19 of the process image, do I gain anything by shrinking it to 20 bytes and have my peripheral area start at byte 20? I'm not sure.

 

[bkottaras]

Yes, it probably is. I just don't know what the real implications are.

For instance, let's say that "out of the box", my CPU use 0-511 for the process image and 512+ for the peripheral image. If I am only using bytes 0-19 of the process image, do I gain anything by shrinking it to 20 bytes and have my peripheral area start at byte 20? I'm not sure.

Thinking about it. Data is data and fills locations.It must be read somehow which will take time.
By shrinking the image table you shoud be able to gain some "Wasted" time.

Unless, the image table is updated on a "fixed" time regardless of its actual number of elements, which I doubt.
Just speculating here!!

 

[Peter Nachtwey]

Real engineer don't depend on luck

I remember using Protool a while ago, and I was supposed to know to <ctrl>+rightmouse click on a certain screen 'repaired' unused tags.

This thread has made me think about our interface. I know we have magic click points but we also have entries in the main menu so one can find what they need from the main menu or by right clicking on the project tree.

I found the secret to the Step7 programming. I finally right clicked on the blocks and then on check consistency. Here I found a dependency tree that like like and automated make file. I found this magic click point by accident. I was looking for something that said update. That is what the help said. I guess it really meant update the project by compiling everything. I don't think I should have taken all these instructions so literally.

C14/SFC15.
edit: The 128 bytes mentioned is the maximum consistent data for Profibus. The 32 bytes I mention is a limitation with S7-300:

The old S7 had that problem, not the new ones. Our RMC100 was one of the first Profibus DP slaves to be ceritified in north america. We were the first to pass certification the first time. The Profibus test center made us limit the number of I/O registers initially to 16 words in and 16 words out. That meant that we had only two registers in and two registers out per axis. ( we support 8 axes ). The interface was easy but it required that parameter be hand shaked through the Profibus I/O on register per axis at a time. This would take about 700 milliseconds. In most cases this was not a problem. Then Siemens came out with the CP342-5. This allow use to have 3 data areas. One 32 register are for status and two 64 word areas for sending messages back an forth. The CP 342-5 had data consistency up to the Profibus DP limits of 128 bytes or 64 words. Our customers liked the new mode but not the extra price and performance of the CP 342-5. The CP-342-5 required yet another two functions DP-SEND and DP-RECV. TThe Siemens plastic group in the US used our motion controller until Siemens came out with their own product. They liked to use our Message Mode on the RMC100 which is a 16 bit integer controller. At first they used the CP-342-5 but it raised the cost. Transferring data across the back plane isn't fast with a S7 either. Then Siemens came out with a new version of the S7 that allowed message mode from the DP ports on the S7 itself. This happened about three years ago. The DP ports on the S7 allow faster transfers between the Profibus and the CPU.

JesperMP, the data you are looking at is old. It was true once.

My interest in SFC26 and SFC27 is not for the immediate problem.

You are lucky because the 128 bytes in each direction exactly matches your requirement for 32 doublewords (REALs).

As CharlesM said, luck has nothing to do with this. We made our Profibus DP interface work the best we could within the Profibus DP limitations. If I could I would allow more registers in and out. We can actually. The problem is that if you had a project with 5 RMCs the Profibus DP I/O map gets used up fairly quickly.

This is why I am a big fan of Ethernet/IP. There is a bigger I/O space and messaging that the Profibus DP doesn't have. We treat the Ethernet/IP I/O and the Profibus DP I/O in a similar way.

If the location is outside the normal process image, you get max 32 bytes consistent data, and you have to use SFC14/SFC15.

See CharlesM's project above. His I/O is consistent and not within the normal process image. As I said above, this capability has existed for a few years now.

Sure, but in this case I think it is luck.

What will it take to convince you. We knew about the limitations. You are looking a this from a single point of view, Siemens. SST and other PC Profibus DP master had the ability to send 128 byte of consistent data long before Siemens did. Even the TI505 could send 128 bytes of consisten data before the S7 could. Stranger yet. A PLC5 with a SST card was a MUCH better master than the S7 for many years. The SST card in the PLC5 could do the 128 byte consistent transfers and the data would automagically just show up in a N file or be read from a N file. No SFC14 or SFC15 required!!!! Siemens has just caught up.

I have mentioned our electronic zoo. We have all sort of PLCs, HMIs and communications cards here. It cost too much to develop a product to depend on luck.

Some day I am going to have to sit down with a processor and scope and run some tests of my own.

See this thread
http://www.plctalk.net/qanda/showthread.php?t=38454&highlight=Profibus
We bought one so we can analyze Profibus DP traffic and timing. We don't depend on luck. We have scopes but for this the specialized adapeter are better.

I don't think that keeping the PLC image table compacted will any difference. Each slave must be updated with a separate call or data transfer. The number of transfers or packets will have the most affect on the I/O update time.

 

[S7Guy]

I don't think that keeping the PLC image table compacted will any difference. Each slave must be updated with a separate call or data transfer. The number of transfers or packets will have the most affect on the I/O update time.

These are two different issues though. Ignoring PB for a moment, I wonder if there is any difference in the real scan time if I am only using local IO (or for that matter, no IO at all) and I make the image very small. I know that in the old S5, it was recommended to keep the IO contiguous, but then again the S7 family is much, much faster (at least with the 400s and some 300s).

When PB slaves are thrown into the mix, the process image is probably irrelevent. During your tests, did you find much difference between your results and what Siemens calculates in the hardware configuration?

 

[Nick B]

One thing to consider when stretching the process image (I've done it in the past on the 400s) is that it does take longer to update the image. That said, the time increase may be inconsequential, but I can't say for sure. I seem to remember an application note from years ago that if the PI was shrunken and all IO was made as contiguous as possible, then the image update time would be quicker.

Some day I am going to have to sit down with a processor and scope and run some tests of my own.

I did this and going from 128 to 2K took an additional 2mS. That said now if you access to Process Image you effectively get the time back (it faster to read from table).

Now you can force I/O above 128 like a 400. Note every byte you use takes 4 from work memory...small penalty.

Nick

 

[Peter Nachtwey]

These are two different issues though. Ignoring PB for a moment, I wonder if there is any difference in the real scan time if I am only using local IO (or for that matter, no IO at all) and I make the image very small. I know that in the old S5, it was recommended to keep the IO contiguous, but then again the S7 family is much, much faster (at least with the 400s and some 300s).

I can't answer for the S7. In our case the image table is small and the I/O is allocated in a contiguous manner so there are no gaps. The digital and analog I/O processing goes extremely quickly and is an insignificant part of the scan time. All the I/O can be read in less than a microsecond. The Profibus and Ethernet I/O take MUCH more time.

When PB slaves are thrown into the mix, the process image is probably irrelevant. During your tests, did you find much difference between your results and what Siemens calculates in the hardware configuration?

I would need to look. All our early tests were done with a SST Profibus DP master that was PC based. The SST Profibus DP masters are very fast because they have a CPU dedicated to just processing Profibus DP data. SST claimed they could update 6000 i/o bits per millisecond. At 12 MB/s 100% efficiency would be 12000 bits per second. That is an efficiency of 50% which is very high relative to other buses. From what I saw I believe it. The S7s scan time does not stress the Profibus DP. I saw no need to evaluate it the S7 because it is relatively slow. We tested the SST Profibus Master and one RMC. The SST card would do 3 data exchanges per millisecond. The RMC100 could only update 1024 times a second or every 976 microsecond. Obviously the data was only updated every third data exchange.

Our largest Profibus DP project was this. Three were sold.
ftp://ftp.deltacompsys.com/public/PDF/Tamglass%23101.pdf
The motion controllers could support up to 128 axes but not all were used. However, all the I/O registers were still scanned. There were were 2 16 bit registers in and 2 16 bit registers out per axis for a total of 8192 bits being transferred. This took less than 2 millisecond which was happened much faster than the Think n Do scan. Because the Profibus master board had its own processor it would process the I/o in parallel with the Pentium running the Think n Do. Most of the time the SST master was sending and receiving the same data over and over. A S7 doesn't have a co processor. The S7 Profibus DP processing would just lengthen the overhead part of the scan. In short we didn't test the S7 because it is too slow.

If someone asked today about how to coordinate 128 axes I would still lean toward Profibus DP and a PC based master.

 

[JesperMP]

My remark about luck was Obviously too snooty. Sorry about that.

I dont have the actual experience with large blocks of data having to be consistent. I just read the manuals and draw my conclusions from them. In the latest STEP7 v5.4 it it still mentions that it is max 32 Bytes for S7-300. But another place it also say that one shall check what each CPU supports. So I have attempted to locate that piece of information for the 313C-2DP. I have checked ALL the manuals for S7-300, and ALL FAQs for "data consistency" but have failed in finding it. All I found was another reference to that the limit is 32 bytes.

Peter, did you or did your customer do the S7 programming back then ?
I am asking because either they (or you) used the process image method, or the manuals are wrong.

 

[Peter Nachtwey]

My remark about luck was Obviously too snooty. Sorry about that.

No problem. I figured you forgot about what I do .... again.

I dont have the actual experience with large blocks of data having to be consistent. I just read the manuals and draw my conclusions from them. In the latest STEP7 v5.4 it it still mentions that it is max 32 Bytes for S7-300.

That still may apply to some of the smaller CPUs. I didn't think my customer's S7-313=2DP would support 32x32 in and 32x32 out but it did. I am using a S7315-2DP. I assure you that my project has 32 32 bit register in and 32 32 bit registers out. My project is similar to CharlesM's example in the previous posts.

But another place it also say that one shall check what each CPU supports. So I have attempted to locate that piece of information for the 313C-2DP. I have checked ALL the manuals for S7-300, and ALL FAQs for "data consistency" but have failed in finding it. All I found was another reference to that the limit is 32 bytes.

Peter, did you or did your customer do the S7 programming back then ? I am asking because either they (or you) used the process image method, or the manuals are wrong.

It was a joint effort between me and two engineers of the Siemens plastic group. Originally we used SFC14 and SFC15. This was back when the S7 supported the limited number of registers 16x16 in and 16x16 out. This was very limiting. The graph data could not be read from our controller fast enough because of the limited number of registers. A 'bigger pipe' was needed to get the data in and out faster. Siemens developed a CP-342-5 that allowed 2 input blocks ( 32x16 and 64x16 ) and one output block ( 64x16 ). The CP 342-5 used the DP-SEND and DP-RECV instead of the SFC14 ( DPRD-DAT ) and SFC15 (DPWR-DAT). Around 2003 or 2004 the new S7s were released that supported the message mode. Then the SFC14 and SFC15 were used again. We never used the peripheral I/O below 256. We always used the location assigned by the hardware configuration which is at 256 or higher.

We knew back in 1996 that Profibus DP could support 128 byte in and out with consistency. The Profibus Technology Center ( PTC ) strongly suggest that we limit the number of register we used to 16x16 in and 16x16. This way we could work with the S7s. This permitted only 2 registers in and 2 register out per axis. This worked but I had to write some FBs that the customers could use to handshake parameters, graphs and step tables through the limited number of I/O register. Parameter transfer and commands could not be done at the same time. The message mode allows the PLC to monitor status, write parameters or commands and get graph data all at the same time. The message mode works well but few used the capability to the fullest.

 

[JesperMP]

I have now perused the technical specifications for S7-300 CPUs (https://support.automation.siemens.com/WW/llisapi.dll/12996906?func=ll&objId=12996906&objAction=csView&nodeid0=10805161&ehbid=html_00%2Fehb%2F13008499%2Ehtm&lang=en&siteid=cseus&aktprim=0&extranet=standard&viewreg=WW&load=content&start=11&subtype=133300)
And I have found 1 statement in appendix 1.8 saying "You can transfer a maximum of 128 bytes of consistent data". So this confirms what you say.