S7-200 PLCs and MicroWin32, was COMM Profibus to Modbus

  • Thread starter Robert D. Wagner, P.E."
  • Start date
R

Thread Starter

Robert D. Wagner, P.E."

To all List Members:

Would anyone on the list care to share their experiences with the new S7-200 PLCs and the MicroWin32 programming software. I'm considering using these on a project, but Roger's comments make me a bit wary.

Thanks,
Robert D. Wagner, P.E.
 
M

Michael Griffin

At 15:58 27/04/00 -0400, Robert D. Wagner, P.E. wrote:
<clip>>
>Would anyone on the list care to share their experiences with the new
>S7-200 PLCs and the MicroWin32 programming software. I'm considering
>using these on a project, but Roger's comments make me a bit wary.
<clip>
To comment directly on roger Irwin's statements :
>> For about $500 you might just about be able to get the S7-200 'DP' PLC.

This (the S7-215) is an obsolete product. You can probably still get some out of stock. I understand it wasn't a good seller. There is a Profibus DP slave expansion module available for the new S7-22x series though.

>> developed using the pretty, yet hopelessy incompetent, MicroWin 7.0 package.

The latest version of MicroWin that I am aware of is version 4.0, and this only came out (around here anyway) a few months ago. It is a
completely new replacement for the previous versions, not just a the old version with more features.

The older S7-21x series has been replaced by the S7-22x series. This is new hardware, new firmware, and new I/O. It is not physically
interchangable with the previous series (i.e. the new I/O won't plug into the old CPU). They provide:
- Removable terminal blocks (except on the lowest end CPU).
- I/O connects with ribbon cable instead of edge connectors.
- CPUs and I/O are physically smaller.
- Fewer CPU models (e.g. no S7-225).
- Subroutines can have parameters and local variables (this is the feature I like the most).
- A high speed MPI network slave mode is possible.
- PPI Networking of OPs plus programming computer on the same port works much better than with the S7-21x.
- Old S7-21x programs can be imported into the new software to run on S7-22x CPUs (however, symbol names are shorter). The new software can be used with the older CPUs.
- The programming cable has been changed.
- Most of the new CPUs have more memory than the corresponding versions in the older series (except the S7-226 still has the same memory as the S7-216).

There is no point in describing what is different about the new programming software; very little is the same as the old version. For
example, you move between subroutines by clicking on tabs instead of by scrolling down the screen.

I have recently completed a retrofit project involving an S7-224 with 4 8-in/8-out I/O expansion modules. This was an old machine equipped with a palletised conveyor system, RF tag system (parallel I/O interface), pick and place with a 14 step sequence, indexing system (new), a welder, and an OP-7 operator interface (new). I found the new software easy to use with
very few problems (much better than most other software I have used in this regards). I would have no hesitation at using this PLC in other similar projects. I estimate my program was about half the size (in bytes) I would have required to perform the same functions with an S5-95U.

I only wish the S7-300 series software and hardware was as simple and inexpensive to use. Siemens offers training for the software and
hardware, but I didn't need any of it. I found it easy enough to sit down and start programming once I was familiar with the instruction set and
addressing. This was my first large project involving an S7-200 (I had only previously worked on some simpler applications with them, using MicroWin version 2.0). I also found the S7-200 manuals to be better than other Siemens manuals at explaining what I wanted to know.

Its not too often that I feel like saying something nice about Siemens, but I will say that this is the first software from them that I have seen that looks like a really professional job. It has the right combination of features and ease of use to suit my applications. I can concentrate on what I want to do rather than on how to make the software work. Most Siemens software that I have seen before looks like it was designed by students working on their first project (i.e. Step-5 or Comtext).

There is a bit of history behind the Microwin software. Originally, the hardware was designed by the old TI team in the States, but the software
was supposed to come from Germany from the same team that was writing Step-7. The software was late..... (the Step-7 project itself was
disastrously late). Eventually the hardware team gave up on ever seeing any software, so they quickly cobbled together first the MicroDos, and then the original MicroWin software as an interim solution. This new software is probably what should have been originally available (I don't know which team it was written by).

>> wonder that it is the only dev package that Siemens give away for free!

I'm not aware that this new software is free. However, you should contact your local Siemens rep for any questions in that regards. Policy may
vary in different countries.


**********************
Michael Griffin
London, Ont. Canada
[email protected]
**********************
 
G

Goodwin Paul

Maybe Rodger was using an early release of MicroWin? I am not aware of a ver 7.0. The latest rel is Ver 3.1 I think. I have been using 3.02, It has a similar appearence to Microsoft Outlook and I find it quite good to use. It is a full 32 bit application which runs on 9x/NT whereas some of the earlier packages only ran under dos or win 3.11. One of the advantages of the new version over 2.1 is the ablity to pass parameters to subroutines that you can define. This functionality was only available on the higher end processors in the S7 family originaly but it is now possible with the new 22x series.

Regards,
Paul Goodwin
Siemens Technical Support Sydney
 
P

Pierre Desrochers

We have had two systems with quadrature encoder and analog I/O and when we would monitor the counts we would almost always get a communication failure.

There was a lot of maths functions in it (quantity not quality...)

Tried with 2 diff. Laptops ... Acer P350 and Toshiba P... nothing solved the problem...

We went to the Siemens distributor and after 2 hours... they could not have better results... They insinuated that ... "Well You got it for free didn't you ..."

After that we never again use Siemens for "Shoe-box" PLC ...

Maybe we were just not lucky that time.

Pierre Desrochers
Integral Instrumentation Inc
[email protected]
 
M

Mattias Wallinius

Have you programmed any Texas PLCs? Then the way you program the S7-200 should be somewhat familiar. The MicroWin environment isn't the best but for programming PLC it isn't that bad, there are worse packages on the market. The S7-215 or the new S7-220 series are one of our favorites for small cheap solutions since it's very powerful and also has the DP port. I can see no
reason for not using the PLC because of MicroWin. Actaully I think the PLC command set is worse than the environment, but it shouldn't pose any problem to a skllled PLC programmer.
Hopes this helps.
/Mattias Wallinius
 
B
I find the S7-200 to be a lot of bang for the $ particularly the high-speed counters and PWM generators. It is a good data manipulating platform with many data types including single precision floating point. They are fast, solid
performers.

Step 7-micro/Win32 is definitely not RSLogix but should not be passed off. It reflects its IEC1131-3 underpinnings and Siemens predilection to statement list (STL). I find the ladder editor to be klunky and difficult to document but it is easy to move from LAD to STL and STL permits instruction comments. There is also function block programming but I am not particularly comfortable with blocks so I avoid FBD.

I have not used the S7-200 with Profibus but it would certainly be worth considering.

Bill Marsh
Integrated Controls
 
R
On Mon, 01 May 2000, you wrote:

> Maybe Rodger was using an early release of MicroWin? I am not aware of a ver
> 7.0. The latest rel is Ver 3.1 I think.

I am using 3.0.2, I cannot find this mysterious version 4. I think the 7 is confusion with Step7, the name of the package for the 300's.

>It is a full 32 bit application which runs on > 9x/NT whereas some

Caveat: PPI does not accept multiple masters with NT, that excludes its use under NT with the TD200 display panel, and other complex configurations.
 
R
Michael Griffin wrote:

> This (the S7-215) is an obsolete product.

Oh dear, we are still using it!

> There is a Profibus
> DP slave expansion module available for the new S7-22x series though.

So a 222 with DP module should check in for $500?

> The older S7-21x series has been replaced by the S7-22x series. This
> is new hardware, new firmware, and new I/O. It is not physically
> interchangable with the previous series (i.e. the new I/O won't plug into
> the old CPU). They provide:

Actually when I said the S7-2xx was great hardware I was refering to the new series, my mistake in citing the old model DP PLC.

> - Removable terminal blocks (except on the lowest end CPU).

221 is the lowest, but also the 222 (small but expandable with modules) and some modules do not have this facility.

> - PPI Networking of OPs plus programming computer on the same port

But not under NT, and does not work all that efficiently for my likes, but hey, at least they included it for free and it does actually work! Pity they charge $3000 for the PPI protocol document, especially as if you do buy it you must sign an agreement which will limit what you can do with PPP for evermore.

> There is no point in describing what is different about the new
> programming software; very little is the same as the old version. For
> example, you move between subroutines by clicking on tabs instead of by
> scrolling down the screen.

This is what I meant by pretty! I would point out that I am using 3.0.2, not 4, but I do not believe 4 has that many differences (but maybe some if the bugs have been fixed).

Things about this software that make it a burden for serious development are:

- Subs and Ints may not be given symbolic names, you must always call 'n' not call <name>

- Code blocks go in seperate tabbed windows, so you cannot e.g. group handlers that work on the same interupt in different phases. Tabbed by default is pretty (and easy for new users), but a great thing about these little PLC is that they can handle 64 interupt routines, which is very usefull for fast handling of complex interupt handlers, but you can also imagine the mess of having (as I have), 37 tabbed inteupt handler windows, each with a few lines of code. It should not be obligatory. Note also that in my state machine design I must attach and detach these routines by number rather than symbolic name!

- You cannot do generic 'defines' or 'equates' (symbolic constants), and thus by inference there is no symbolic constant math facility.

- Symbolic variable names do not work with indirect addressing (perhaps this is a bug that has now been fixed).

- There are no code macros, nor source editing macros for that matter.

- The code export/import facility only works with the contents of the window, you cannot get a global copy of the whole caboodle (otherwise I would be using a programmers editor and homespun pre-processor to overcome these difficulties).

- There is no provision for automatic allocation of variable space, so name tables end up being sequential rather than in logical groups.

These are examples which only require changes to the development software, not the actual PLC or it's firmware. I would like to mention a couple of shortcomings that MAY be due to hardware limitations (but nonethless implementable at a firmware level in the form of macrocode):

- Indirect bit addressing

- Fast interrupt calls that let the programmer decide what (if anything) must be pushed and pulled from the stack. It is annoying to suffer all that overhead when you only e.g. clear a flag.

I would point out that the facilities I have discussed here (which is by no means an exhaustive list of my gripes) are facilties that I would expect to find on a little microntroller cross ambler designed to run on a commondore 64, i.e. they require little code to implement. The MicroWin environment is a wonderful collection of GUI objects, and I apprecite that the graphical implemetations of IEC and ladder logic programming require some work. BUT we appear to be lacking a simple capable underlying assembler.

These simple ommisions (particularly the symbolic ones) make it difficult to manage large/complex projects (for which the hardware is suitable), and also very difficult to re-use code, as it ends being full of direct references.

Another grudge is that it is the only programming solution, and it only works with windows. Sure windows is a great platform for writing stand alone PLC projects, but I am connecting my S7-200's to a centralized PC, which must be a remotely administered 24x7 job. Needless to say I am using Linux for this, but that means
programming the PLC requires or a re-boot or the use of a second machine.

Just a decent command line cross-assembler would suit me! In fact I would write my own where it not for the fact that I would not have a way to dowload the code or access the hardware for de-bugging (no published monitor).

>I only wish the S7-300 series software and hardware was as simple and inexpensive to use.

I wish they would drop it. Most of the hardware seems to be full of air. A few nice touches to the 200's along with an expanded range of I/O modules would allow it to do most jobs the 300 is used for. For the rest there is the 400.

>
> Its not too often that I feel like saying something nice about
> Siemens, but I will say that this is the first software from them that I
> have seen that looks like a really professional job.

It is a collection of pretty ready made GUI modules, but that does not mean they are suitable for the task.

> >> wonder that it is the only dev package that Siemens give away for free!
> I'm not aware that this new software is free. However, you should
> contact your local Siemens rep for any questions in that regards. Policy may
> vary in different countries.

Check out this page:

http://www.aut.sea.siemens.com/microwin/index.htm

This seems to think the V3.0.2 is THE new product (you may also download it).

Now, who can tell me more about the mysterious version 4?
 
M

Michael Griffin

At 11:07 01/05/00 -0400, Pierre Desrochers wrote:
<clip>
>We have had two systems with quadrature encoder and analog I/O and when we
>would monitor the counts we would almost always get a communication failure.
<clip>
>Tried with 2 diff. Laptops ... Acer P350 and Toshiba P... nothing solved the problem...
<clip>

Which version of S7-200 and which version of MicroWin were you using? The original S7-21x series PPI to programming laptop communications
does not seem to be as reliable as with the newer versions.

I also had a problem with on line monitoring with the new software due to the serial port configuration of my laptop. In the read-me file (or some such place) which came with the software, it specifies to increase your UART buffer to the *maximum* size (if you have a buffered UART).

However, I had problems with this if I had my laptop and an OP connected to the same port on the PLC. I complained about this to my rep,
and he made inquiries with the technical fellows in Brampton. The answer came back to *decrease* the UART buffer size to the *minimum* size possible (no buffer if possible). Apparently, the UART buffer causes problems with maintaining the correct timing, and this cannot be corrected in the PC due to the limitations of Windows.

I made the necessary adjustments to my laptop's serial port configuration, and the problem went away. I'm using 9600 baud, but all the other PPI settings are the normal recommended ones.

**********************
Michael Griffin
London, Ont. Canada
[email protected]
**********************
 
M

Michael Griffin

At 02:37 29/04/00 +0200, roger Irwin wrote:
<clip>
>> - Removable terminal blocks (except on the lowest end CPU).
>
>221 is the lowest, but also the 222 (small but expandable with modules)
>and some modules do not have this facility.
<clip>
Actually, they have added removable terminal blocks on the CPU and I/O I have used, but they are not very good ones. They are very hard to remove. I was able to pull out the terminal blocks from the I/O modules, but I gave up trying with a 224 CPU because I was afraid I would damage it. I think Siemens needs to try this again.

>> There is no point in describing what is different about the new
>> programming software; very little is the same as the old version. For
>> example, you move between subroutines by clicking on tabs instead of by
>> scrolling down the screen.
>
>This is what I meant by pretty! I would point out that I am using 3.0.2, not
>4, but I do not believe 4 has that many differences (but maybe some if the
>bugs have been fixed).

Sorry, the '4' was my mistake from poor typing. I'm using version 3, which is the latest. I understand there is a version 3.2 coming out soon.

>
>Things about this software that make it a burden for serious development are:
>
>- Subs and Ints may not be given symbolic names, you must always call 'n'
>not call <name>

I believe I'm using the same version that you are, and I can give subroutines symbolic names and call them by that name (I haven't had any need yet for interupt routines, but they may be the same). If I recall correctly, you select the subroutine from the tree diagram on the left, and then do something like right click on it and a menu pops up that lets you rename it (I can't remember just how I do it, but its one of these Windowy things that you find by poking around). You can also add comments to document the subroutine. Make sure you have symbolic addressing turned on as well.

>- Code blocks go in seperate tabbed windows, so you cannot e.g. group
>handlers that work on the same interupt in different phases. Tabbed by
>default is pretty (and easy for new users), but a great thing about
>these little PLC is that they can handle 64 interupt routines, which
>is very usefull for fast handling of complex interupt handlers, but
>you can also imagine the mess of having (as I have), 37
>tabbed inteupt handler windows, each with a few lines of code.
<clip>
It sounds like your application is a little out of the ordinary. Most people I have asked like the new format better, but then they are writing pretty conventional PLC programs. The main advantage of this format over the one used in version 2 is that you don't have to scroll all over the place to find what goes on in a subroutine.


>- You cannot do generic 'defines' or 'equates' (symbolic constants), and
>thus by inference there is no symbolic constant math facility.
<clip>
>- There are no code macros, nor source editing macros for that matter.
>- The code export/import facility only works with the contents of the
>window, you cannot get a global copy of the whole caboodle (otherwise
>I would be using a programmers editor and homespun pre-processor to
>overcome these difficulties).
<clip>
>I would point out that the facilities I have discussed here (which is by
>no means an exhaustive list of my gripes) are facilties that I would
>expect to find on a little microntroller cross ambler designed to run on
>a commondore 64, i.e. they require little code to implement.
<clip>
Maybe a shoebox PLC isn't what you really want then. There are lots of single board computers out there that will let you use any assembler you like.
In my own applications, I put a lot of effort into making my programs simple. I would like to think that someone with only some basic
programming knowledge could pick up one of my programs and understand most of it. It doesn't sound though as if you need to write programs in your applications which other people may have to read later.


>large/complex projects (for which the hardware is suitable), and also very
>difficult to re-use code, as it ends being full of direct references.
<clip>
I re-use code in the form of parameterised subroutines and an overall program skeleton. I haven't found the remaining direct references to be a problem, since I manually mapped out the memory usage with this in mind. I/O references constitute most of the direct references which need to change, and they are application dependant anyway.

>> Its not too often that I feel like saying something nice about
>> Siemens, but I will say that this is the first software from them that I
>> have seen that looks like a really professional job.
>
>It is a collection of pretty ready made GUI modules, but that does not
>mean they are suitable for the task.
<clip>
OK, maybe I got a bit carried away. In comparison with Step-5 or Comtext though, just about anything would start to look pretty good. I will say that I hadn't expected much, so I what I ended up with was rather a pleasant surprise.
It sounds though like your requirements are rather unusual. Most people working with shoebox PLCs are looking to do something rather simple and straight forward.
The simplicity of the software is particularly welcome in comparison with Step-7 for the S7-300 and 400. If I ask someone to build a machine for me which uses an S7-22x and I give them a working sample program and a written implementation guide, then I know that they should have no problems even if they have never seen an S7-200 before.

I'll give you a list of some features that I would like to see in the S7-22x series:
Programming software:
- The ability to re-order the subroutines. You can give them symbolic names, but the tab order can't be changed. (Right now to get around this I export the subroutine as text, renumber it manually, and then import it back in).
- Fix the situation where symbol names and large constants can appear OK on the screen, but they get cut off in the print-out.
- Let me compare two off-line copies of a program, instead of just on-line to off-line.
- Change the cross-reference print-out so it doesn't waste so much paper. This just needs a different format. There are some other paper
wasting features which need to be fixed as well.

Processor Architecture and Instruction Set:
- The latch and unlatch instructions (set and reset) allow you to apply this instruction to a range of bits. I hate this feature as it makes
programs unreadable if someone uses it (fortunately few people do). They also take 7 bytes each rather than the 2 bytes of a normal coil instruction. This is a memory waster if you use the SCR feature a lot (which I do) since
you tend to need a lot of set & reset instructions with the SCR. Set and reset bit ranges is a feature which I could have done without. It would be nice to add a new pair of instructions which don't have the range subscript.
- I would like to be able to re-define the time base for some of the 100 msec. timers to give me more 10 msec. timers if I need them. I think this feature could be added by allowing you to define the timer time bases in the system configuration.

Hardware:
- An ASCII module would be nice for bar code readers and other similar devices. Right now you have to hope the spare port on the S7-226 is
all you need. If you need more ports, you're in trouble unless you want to try using a serial port multiplexer (this is messy). This is unfortunate, as I have found that it's the simpler machines that seem to need ASCII ports the most.
- A Profibus DP master module would be useful for RF controllers, drives, etc. I suspect though that internal Siemens politics will prevent
this since the S7-300 team may feel threatened by something like this.
- The next logical step is an S7-22x (S7-228?) with more memory, I/O capacity etc. Maybe an integrated ASI master would be a good idea for this one.


**********************
Michael Griffin
London, Ont. Canada
[email protected]
**********************
 
R
On Wed, 03 May 2000, you wrote:
>
> Sorry, the '4' was my mistake from poor typing. I'm using version 3,
> which is the latest. I understand there is a version 3.2 coming out soon.

Real soon now.......where have I heard this before?!

> I believe I'm using the same version that you are, and I can give
> subroutines symbolic names and call them by that name (I haven't had any
> need yet for interupt routines, but they may be the same).

Does my software have a bug?! I know I can right click on the tree to give a name to a sub (or an int, or a data table), but that name does not then appear on the tab, and I cannot call them by name. Just to add insult to injury, they must be added sequentially, which can make things very messy indeed. Please tell me how you call things by name. I am using symbols, I use them for
variables, but often they are not accepted even there (eg. indirect adressing).

> It sounds like your application is a little out of the ordinary.
> Most people I have asked like the new format better, but then they are
> writing pretty conventional PLC programs. The main advantage of this format
> over the one used in version 2 is that you don't have to scroll all over the
> place to find what goes on in a subroutine.

My applications, I have done a few. I agree that programmers not familiar with using programmers editors probably find it easier, and I like it as well. What I said is that it should not be exclusive. Look at a normal GUI IDE (VC++ C++
Builder etc.) They all have tabbed windows for each module, but not necessarily for each routine. If users want a tab for each block of code then they use it just like that. But supposing you want to have a subroutine that is only used from OB1. For me the logical place is to put it in OB1 using something like:

SUB FOO

and then be able to

CALL FOO

it is a simple feature whose use is optional.

> Maybe a shoebox PLC isn't what you really want then. There are lots
> of single board computers out there that will let you use any assembler you
> like.

I agree MicroWin is suitable for little applications. My point was that the S7-200 are getting quite powerful, and in applications were there is a small I/O but a complex problem, the 200's could be used were one might of gone for
a 300, but the MicroWin software limits these possibilities.

Everything I suggested is easy to implement, and does not make it more difficult to use as they are optional facilities, for the most part however I simply interested in having an environment that is fully symbolic rather than
partially.

> In my own applications, I put a lot of effort into making my
> programs simple. I would like to think that someone with only some basic
> programming knowledge could pick up one of my programs and understand most
> of it.

You are flying in the face of conventional programming wisdom, which dictates that the use of symbols and modularity makes the program more easily readable to all. Which is easier,

CALL 13 or CALL VALIDITY_CHECK
ATCH 24,8 or ATCH ModiconHandler,RxSerialChar

where RxSerialChar would have been a 'define'

You can add comments, but beware, even if you meticoulously add them to every line, they do not get de-bugged, which can cause great confusion.

> I re-use code in the form of parameterised subroutines and an
> overall program skeleton. I haven't found the remaining direct references to
> be a problem, since I manually mapped out the memory usage with this in
> mind. I/O references constitute most of the direct references which need to
> change, and they are application dependant anyway.

Mapping out memory has severe limitaions, allthougth if I/O is your biggest problem we seem to be back to the point that that (at least my MicroWin) is only PARTLY symbolic.

> It sounds though like your requirements are rather unusual. Most
> people working with shoebox PLCs are looking to do something rather simple
> and straight forward.
> The simplicity of the software is particularly welcome in comparison
> with Step-7 for the S7-300 and 400. If I ask someone to build a machine for
> me which uses an S7-22x and I give them a working sample program and a
> written implementation guide, then I know that they should have no problems
> even if they have never seen an S7-200 before.

My requirements are that of someone who has been programming for 25 years, and until recently had programming just about anything programmable
(microcontrollers and hand held terminals through to COBOL on mainframes) but never PLC's. I find the MicroWin lacking some very basic features that may be completly ignored by somebody doing a simple task, but be very useful for people doing complex tasks for which the 200 is capable in hardware terms.


> - The ability to re-order the subroutines.
Not necessary if they were truly symbolic. People who want to insist on
primitiveness can name then 1,2,3........!

As for changing the name, there is no global editing, so you cannot find and replace. The find and replace in C++ builder, lets you choose if you want to work across all modules (each module has its own tab window).

> - Fix the situation where symbol names and large constants can
> appear OK on the screen, but they get cut off in the print-out.
> - Let me compare two off-line copies of a program, instead of just
> on-line to off-line.

Better still, why not pickle the project file to ASCII, which opens up whole new horizons for user tools (non sophisticated users need not know the
difference).

> - Change the cross-reference print-out so it doesn't waste so much
> paper. This just needs a different format. There are some other paper
> wasting features which need to be fixed as well.

Save more paper, don't do print outs. It has been many years scince I have printed a program, what does one actually do with the hardcopy?

> Processor Architecture and Instruction Set:
> - The latch and unlatch instructions (set and reset) allow you to
> apply this instruction to a range of bits. I hate this feature as it makes
> programs unreadable if someone uses it (fortunately few people do). They
> also take 7 bytes each rather than the 2 bytes of a normal coil instruction.

If you could define macros you could do your own with OR and AND


> - I would like to be able to re-define the time base for some of the
> 100 msec. timers to give me more 10 msec. timers if I need them. I think
> this feature could be added by allowing you to define the timer time bases
> in the system configuration.

This is likely a hardware/formware related issue, I am generally at odds with the MicroWin package. I do not deny that one could improve hardware, nut then there is the cost issue that must be added to every PLC. Improving MicroWin is a one off cost that has no influence on compatibility, spares etc.


> - An ASCII module would be nice for bar code readers and other
> similar devices. Right now you have to hope the spare port on the S7-226 is
> all you need. If you need more ports, you're in trouble unless you want to
> try using a serial port multiplexer (this is messy). This is unfortunate, as
> I have found that it's the simpler machines that seem to need ASCII ports
> the most.

I would like a USART module, jumperable for RS232,485 or TTL.

> - A Profibus DP master module would be useful for RF controllers,
> drives, etc. I suspect though that internal Siemens politics will prevent
> this since the S7-300 team may feel threatened by something like this.

I believe this may also be the reason that the 200's symbolism is 'knobbled'

> - The next logical step is an S7-22x (S7-228?) with more memory, I/O
> capacity etc. Maybe an integrated ASI master would be a good idea for this one.

I would like a 200 series I could program in C.
 
M

Michael Griffin

At 00:21 08/05/00 +0200, 'root' wrote:
<clip>
>Does my software have a bug?! I kown I can right click on the tree to give a
>name to a sub (or an int, or a data table), but that name does not then appear
>on the tab, and I cannot call them by name.

I don't think the name appears on the tab, just on the tree at the side, and also in the instruction when you call it. I am using ladder
exclusively. Just on the off chance that this is a problem in statement list though, I tested it in this mode, and I found that with STL, subroutine symbols don't appear. However, I haven't found anything yet which I can't do in ladder mode, so I've never tested this before.

This is rather interesting - I would call this a 'bug'. It works OK in ladder or function block diagram modes but not in statement list. I assume from this that you are writing in statement list.

I find the way symbol names are assigned to subroutines to be rather peculiar anyway. I would have expected to simply add them to the symbol
table (this was actually the first way I tried to do it) and for them to be treated the same way as addresses.

<clip>
>Just to add insult to injury, they
>must be added sequentially, which can make things very messy indeed.
<clip>

I think I mentioned last time that I have to do a little trick to renumber subroutines. I export the subroutine, edit the subroutine number
manually, and then import it back in. There is a good reason to renumber subroutines. If you are importing subroutines from another program (via the ASCII import facility), then you have the potential to have subroutine number clashes unless you re-assign one or the other. I also like to keep related subroutines near one another, and also to separate reusable subroutines from ones which are application specific (generic ones to the higher numbers, application specific ones to the lower numbers). Yes I agree that this problem is due to lack of symbolism, but there it is none-the-less.


>You are flying in the face of conventional programming wisdom, which dictates
>that the use of symbols and modularity makes the program more easily readable
>to all.

I won't argue about whether symbol addressing is a good idea or not. I found that after I started using it I made less mistakes entering
addresses (a typing mistake was less likely to be a valid address). However, it is still a fairly novel idea to many people in the PLC world even though it has been around for a while.


>My requirements are that of someone who has been programming for 25 years, and
>until recently had programming just about anything programmable
>(microcontrollers and hand held terminals througth to COBOL on mainframes) but
>never PLC's. I find the MicroWin lacking some very basic features that may be
>completly ignored by somebody doing a simple task, but be very usefull for
>people doing complex tasks for which the 200 is capable in hardware terms.

I've written programs using Pascal, Modula-2, C, Basic, etc. on PCs (10,000+ line programs), and even Fortran on mainframes (simple stuff there
though) and have seen how good even fairly low end development systems can be there.

I've also used some pretty horrible PLC programming software. I've come to have fairly low expectations when dealing with PLC programming
software (especially the stuff from the original hardware manufacturers) so I'm pleasantly surprised when the software isn't positively painful to use.

I've also programmed PLC/2 with T3 terminals, and even SLC-100 and Omron S6 with hand-helds and hand made sketches of programs while sitting on
a concrete floor in the plant and working under a dead line. Maybe compared to *that* this software isn't so bad.

>> - The ability to re-order the subroutines.
>Not necessary if they were truly symbolic. People who want to insist on
>primitiveness can name then 1,2,3........!

Except making the system completely symbolic isn't just a matter of a change to the PLC programming software. The symbolic names aren't stored in the PLC, so if you upload a program you'll find the numbers are really still there after all. The S5 PLCs stored the actual function block names and parameter names inside the PLC. I think that was actually rather a good idea.

>As for changing the name, there is no global editing, so you cannot find and
>replace. The find and replace in C++ builder, lets you choose if you want to
>work across all modules (each module has it's own tab window).
<clip>

If all you want to do is to change the way a symbol is spelt, there is a little trick which can be used here. Turn symbolic addressing off,
change the symbol name, then turn symbolic addressing back on. If you want to change which physical address the symbol relates to, then just change it in the symbol table (when symbolic addressing is ON). These are the only global edit changes I've ever needed to do (I have done these in ladder mode only though). I've never needed to do a global search and replace on instructions.

For simple text style search and replace, my version does have this in statement list mode. This only really works in statement list mode
though, and I think only one subroutine at a time.

>Better still, why not pickle the project file to ASCII, which opens up whole
>new horizons for user tools (non sophisticated users need not know the
>difference).

Do you use the ASCII import/export features? Unfortunately, this doesn't take the symbols with it, so I suppose its not really what you want.

>> - Change the cross-reference print-out so it doesn't waste so much
>> paper. This just needs a different format. There are some other paper
>> wasting features which need to be fixed as well.
>
>Save more paper, don't do print outs. It has been many years scince I have
>printed a program, what does one actually do with the hardcopy?
<clip>

What one does with a hard copy, is on smaller machines you put a print out in the control panel for the electrician to read. Pretty often you can troubleshoot most smaller machine problems with a print out without bothering with a computer. Its less useful on large programs and machines
though.

>> - An ASCII module would be nice for bar code readers and other
>> similar devices. Right now you have to hope the spare port on the S7-226 is
>> all you need. If you need more ports, you're in trouble unless you want to
>> try using a serial port multiplexer (this is messy). This is unfortunate, as
>> I have found that it's the simpler machines that seem to need ASCII ports
>> the most.
>
>I would like a USART module, jumperable for RS232,485 or TTL.
<clip>

Sounds good to me. I'm familiar with the term "ASCII module" as a generic term for a simple serial port expansion, as opposed to a "Basic
module" or some other such more advanced device.


>I would like a 200 series I could program in C.
<clip>

There was an earlier S7-200 (S7-210?) which was intended as an OEM device. It used a special development system (not 'C' though - still S7-200
language), and the final target hardware could not have its program altered with normal programming software. I think it didn't sell very well and was dropped from the next generation.

If you were really ambitious, you could write a 'C' to statement list (ASCII text) compiler, and then use the ASCII import feature in the
MicroWin software to pull it in for final target compile and download.


**********************
Michael Griffin
London, Ont. Canada
[email protected]
**********************
 
M

Michael Griffin

> At 15:58 27/04/00 -0400, Robert D. Wagner, P.E. wrote:
<clip>>
>Would anyone on the list care to share their experiences with the new
>S7-200 PLCs and the MicroWin32 programming software. I'm considering
>using these on a project, but Roger's comments make me a bit wary.
<clip>
To comment directly on roger Irwin's statements :
>> For about $500 you might just about be able to get the S7-200 'DP' PLC.

This (the S7-215) is an obsolete product. You can probably still get some out of stock. I understand it wasn't a good seller. There is a Profibus DP slave expansion module available for the new S7-22x series though.

>> developed using the pretty, yet hopelessy incompetent, MicroWin 7.0 package.

The latest version of MicroWin that I am aware of is version 4.0, and this only came out (around here anyway) a few months ago. It is a
completely new replacement for the previous versions, not just a the old version with more features.

The older S7-21x series has been replaced by the S7-22x series. This is new hardware, new firmware, and new I/O. It is not physically
interchangable with the previous series (i.e. the new I/O won't plug into the old CPU). They provide:
- Removable terminal blocks (except on the lowest end CPU).
- I/O connects with ribbon cable instead of edge connectors.
- CPUs and I/O are physically smaller.
- Fewer CPU models (e.g. no S7-225).
- Subroutines can have parameters and local variables (this is the feature I like the most).
- A high speed MPI network slave mode is possible.
- PPI Networking of OPs plus programming computer on the same port works much better than with the S7-21x.
- Old S7-21x programs can be imported into the new software to run on S7-22x CPUs (however, symbol names are shorter). The new software can be used with the older CPUs.
- The programming cable has been changed.
- Most of the new CPUs have more memory than the corresponding versions in the older series (except the S7-226 still has the same memory as the S7-216).

There is no point in describing what is different about the new programming software; very little is the same as the old version. For
example, you move between subroutines by clicking on tabs instead of by scrolling down the screen.

I have recently completed a retrofit project involving an S7-224 with 4 8-in/8-out I/O expansion modules. This was an old machine equipped with a palletised conveyor system, RF tag system (parallel I/O interface), pick and place with a 14 step sequence, indexing system (new), a welder, and an OP-7 operator interface (new). I found the new software easy to use with
very few problems (much better than most other software I have used in this regards). I would have no hesitation at using this PLC in other similar projects. I estimate my program was about half the size (in bytes) I would have required to perform the same functions with an S5-95U.

I only wish the S7-300 series software and hardware was as simple and inexpensive to use. Siemens offers training for the software and
hardware, but I didn't need any of it. I found it easy enough to sit down and start programming once I was familiar with the instruction set and
addressing. This was my first large project involving an S7-200 (I had only previously worked on some simpler applications with them, using MicroWin version 2.0). I also found the S7-200 manuals to be better than other Siemens manuals at explaining what I wanted to know.

Its not too often that I feel like saying something nice about Siemens, but I will say that this is the first software from them that I have seen that looks like a really professional job. It has the right combination of features and ease of use to suit my applications. I can concentrate on what I want to do rather than on how to make the software work. Most Siemens software that I have seen before looks like it was designed by students working on their first project (i.e. Step-5 or Comtext).

There is a bit of history behind the Microwin software. Originally, the hardware was designed by the old TI team in the States, but the software
was supposed to come from Germany from the same team that was writing Step-7. The software was late..... (the Step-7 project itself was
disastrously late). Eventually the hardware team gave up on ever seeing any software, so they quickly cobbled together first the MicroDos, and then the original MicroWin software as an interim solution. This new software is probably what should have been originally available (I don't know which team it was written by).

>> wonder that it is the only dev package that Siemens give away for free!

I'm not aware that this new software is free. However, you should contact your local Siemens rep for any questions in that regards. Policy may
vary in different countries.


**********************
Michael Griffin
London, Ont. Canada
[email protected]
**********************
 
Top