More Frustrations with Siemens.

[PeterW]

I agree with the post, get someone in that knows what they are doing.

I've read numerous posts by Peter regarding 'his' frustrations with Siemens and for the most of the time he is having problems with the very basic concepts of Siemens programming. TRUE and FALSE FFS.

I have programmed both Siemens and Allen Bradley and know that you have to approach both differently, I also believe Siemens to be the superior of the two (personal opinion).

So your customers are having problems with Siemens, I have had many customers who have no problems with Siemens, maybe its the original programmers fault that the customers have problems.

The fact that Allen Bradley can do x and y and Siemens cannot is imaterial, the fact is Siemens can do z, r and q and Allen Bradley cannot. These are very different and both very good PLC's that need to be approached from the outset correctly.

A drop down arrow?? Why not ask for a hand to hold!

REAL, Floating Point?? what's the problem, read the help files and it explains fully (ever read any?).

 

[PeterW]

This program is has OB1 written in ladder and it calls FBs written in STL. The idea is that I write the FBs that do the communications with the controller so the customers don't have to. This way we don't need to teach the customers about loading address registers and indirect address.

My approach is to program OB1 in STL, OB1 is short and consists of calls to other blocks only, mostly FC's, which are named something like 'INPUT CONDITIONING', 'COMMUNICATIONS', MACHINE CONTROL', etc. Thus making it easy to find areas of code and not overfilling OB1.

Blocks can have a mixture of Ladder and STL, program in ladder and change the view to STL whenever you want to program an STL network. Change back to ladder when you want to, therefore certain calls to FB's and FC's can be seen in STL and use the 'TRUE' and 'FALSE' constants, the cost of coiurse is you cannot write a series of conditions to a block input.

I set a bit to true and another to false in OB100 and then I used the variables and not the constants.

I program a block called from OB1 which I call System Variables, here I create the 'always_On' and 'Always_Off' flags and create timed one shots from the Clock Memory byte. If you set from OB100 and someone accesses and accidently changes those BOOL's then it would screw your program. Some people check the status of these BOOL's at the end of OB1 as well.

I also had problems adding variables to a shared DB. I added the variables and immediately downloaded the DB but for some reason the symbol table doesn't get updated so I can't use the variables. After much cursing and swearing the S7 give in and lets me use the symbols. I tried doing consistency checks too but I have know idea what really causes the S7 to add the new variables in the DB to the symbol table. This problem has plagued me since the beginning but it has been minor compared to other problems.

My shared DB variables are always UDT's, whenever I change a UDT I always do a consitancy check (my program is set to symbolic programming too). The downside to this is after a consitancy check the timestamp is different to the one in the PLC and I may not be able upload that DB and maintain the symbols (even if the change was renaming a spare to a unique name). I don't store data I would need to upload in an IDB though, so this doesn't matterif the IDB length is unchanged, I don't have to download.

Also, when I first connect to a S7 using MPI should I be able to use the 'display available nodes' to show what MPI channel I am using? What is more important, should it display the channel number that the PLC is using?

A new PLC is default address 2, if the PLC had been programmed before then it may have a different address (or if your program has a different address to 2), so checking avialble nodes (after trying to download and fail) is necessary. You have to download to the address the PLC has set, but if your program settings has another address then it will change to that. You shouldn't have to do anything afterwards as the stored address is the one now in the PLC.

I get the "adapter damaged" messenge and it ticks me off because I know there is nothing wrong with my MPI cable. The Step7 simply can't connect with the PLC after trying all the channels. After much cursing and swearing the MPI adapter finally works but I have no idea why.

My S7 hates me. I know it hates me and I hate it.

I get this sometimes, usuall when I've forgotten to plug the USB bit in.

 

[Peter Nachtwey]

I agree with the post, get someone in that knows what they are doing.

I've read numerous posts by Peter regarding 'his' frustrations with Siemens and for the most of the time he is having problems with the very basic concepts of Siemens programming. TRUE and FALSE FFS.

It doesn't change the fact that I wasted too much time trying to use Bool#false as an input to a function. Bool#false is in the documentation as a legal constant but I can't use it as the input of FB in LD. Don't you see, it is the little inconsistencies that tick me off. I program a S7 only when a customer needs help.

I have programmed both Siemens and Allen Bradley and know that you have to approach both differently, I also believe Siemens to be the superior of the two (personal opinion).

Rockwell does use klduge adaptors like the MPI adapter that is always saying it is damaged.

So your customers are having problems with Siemens, I have had many customers who have no problems with Siemens, maybe its the original programmers fault that the customers have problems.

Most use ladder only and don't do indirect addressing.

A drop down arrow?? Why not ask for a hand to hold!

Fine, so how am I supposed to guess FLOATING_POINT? It wasn't in the documentations either. I suppose the V5.3 doesn't support it.

REAL, Floating Point?? what's the problem, read the help files and it explains fully (ever read any?).

I did, so what genius decided to use FLOATING_POINT instead of the obvious REAL. It is yet another inconsistency.

 

[RMA]

I did, so what genius decided to use FLOATING_POINT instead of the obvious REAL. It is yet another inconsistency.

This may be another difference in American and British (European) language usage. I can't imagine anybody over here who had completed school to A-Level / Abitur level (not sure what the American equivalent for university entrance level is) not knowing that floating point and real are the same thing.

 

[Tharon]

This may be another difference in American and British (European) language usage. I can't imagine anybody over here who had completed school to A-Level / Abitur level (not sure what the American equivalent for university entrance level is) not knowing that floating point and real are the same thing.

It's not about knowing that they are or aren't the same thing. It's about consistency of terminology throughout the single program.

Why define something REAL, and then when you are asked what you want to display it as, not be able to use REAL? Without knowing that you can right click on the box to bring up a menu with type selections, a drop down arrow would quickly let you know that something is there! There is something to be said about a program that makes it easy to quickly navigate and understand it's options without having to read the help documentation to do simple things.

Minor details that make the program a lot easier to use and just all around more user friendly. Or, yes, as someone here put it... more like "Windows". I mean, let's face it... Windows is a 'user friendly' environment.

In the past few years I've had some pretty complicated Siemens programs dumped on me, and while I was trained in RSLogix 500/5000, and the more I deal with Step 7 the more I being to understand it... the interface in general feels a tad clunky and just not well refined when compared to RSLogix 500/5000. Purely from an interface standpoint, not judging programming methods and efficiencies in the actual PLCs.

 

[PeterW]

This may be another difference in American and British (European) language usage. I can't imagine anybody over here who had completed school to A-Level / Abitur level (not sure what the American equivalent for university entrance level is) not knowing that floating point and real are the same thing.

That explains that then, I was wondering why the confusion.

I thought about this later when I went to the supermarket on my wife's behalf armed with a shopping list she prepared, the list copntained 1* aubergene and 2 * courgettes, so i duley picked up an eggplant and a 2 zucchini's.

 

[OkiePC]

Nice...but that shopping list wasn't generated by a multi-thousand dollar software program, was it?

High end software elicits high end expectations...details like terminology should be highly polished.

 

[Peter Nachtwey]

You guys are as bad as Siemens. How can you defend the lame?

This may be another difference in American and British (European) language usage. I can't imagine anybody over here who had completed school to A-Level / Abitur level (not sure what the American equivalent for university entrance level is) not knowing that floating point and real are the same thing.

It there was a pull down list where I could see FLOAT_POINT as an option I would have, but there isn't. That isn't my fault.

So must I waste time guessing with Siemens thinks is a good alternative to REAL? You know I am right and this complaint and others gripes are just as justified.

You don't get it. I don't spend every day programming S7s. I can be two years between my journeys to the dark side. I do so when it is necessary to support a customer but I find the tools get in the way ever time. Little is intuitive.

If I used S7 every day like PeterW and LD then I probably wouldn't have these complaints because I would know all the inconsistencies but every two years or so I must rediscover them. What many of you don't seem to understand is that many system integrators are forced to use S7 and they have never or rarely used it before so they are just a confused by the inconsistencies.

One of my favorite gripes is configuring Profibus. You have to know exactly where to click to select the Profibus DP master. If you select the line it will grow bigger and make you think you have select it but actually you must click on the card in the CPU? WHY MUST I GUESS WHERE TO CLICK? Why can't I pull down menu where I can select between the buses.

Step 7 is the most poorly 'designed' ( that is being too generous ) piece of **** I have ever come across.

Match the IDEs of Microsoft, NetBeans of Java, Apples XCode, or even FreeScales Codewarrior.

I will admit I am not tolerant of p!ss poor programming. My guys know it because I b!tch at them and get on their cases and they get upset with me. Evan so there are a few guys that are more fanatical making it easy than I am. These are the tech support people.

I just want you all to know I discriminate against all software equally.

 

[JesperMP]

I'll grant you that the dialogs and terminology in Siemens software products are not consistent enough.
I have said before that Siemens has a steeper learning curve than other software vendors products. It is probably a german thing.

But apart from that, I cannot believe the energy you put into these gripes.
Yes it is a problem that you are a lone programmer without the possibility to ask a collegue that know the anomalies already.
If you encounter another "Siemens anomaly", then ask here immediately. People will help.

 

[luccass]

I'll grant you that the dialogs and terminology in Siemens software products are not consistent enough.
I have said before that Siemens has a steeper learning curve than other software vendors products. It is probably a german thing.

I don't think it's just 'German'. I think that Siemens decided to go this route when they first started taking this business. It is clearly visible when you work with programming software, when you read manuals, gather knowledge about 'new' hardware or contact tech support. All info is available but written in a really nasty way - nasty I mean difficult to fully understand if you don't have solid basic knowledge. So how to get this knowledge? - attend a training course done by Siemens - this is how they make money as well.

But apart from that, I cannot believe the energy you put into these gripes.
Yes it is a problem that you are a lone programmer without the possibility to ask a collegue that know the anomalies already.
If you encounter another "Siemens anomaly", then ask here immediately. People will help.

I think to learn any platform you have to like it. The trouble with Siemens is you either love it or hate it. Most of my colleagues who have enormous experience with AB just hate Siemens. They cannot understand basic stuff - because their mind is thinking in AB way. So they swear and curse and help others for explanation - very rarely they want to discover.
Personally I'm still on my learning curve and probably will be forever (so many different areas covered by Siemens). But the more problems I solve the more I like Siemens, the more problems are solved by my colleagues the more they hate Siemens. That way they life is never to be easy...

 

[JesperMP]

Nah, I think it is a german thing.

I have experienced the same with several german products. The products themselves are fine, well thought out, and works as intended. But when you try to read the manuals or navigate the online dialogs, you often have to try and figure out what they probably intended to say.

 

[luccass]

I don't speak German, but you think the main meaning is lost during translation or in German it's exactly the same?

I recently worked with product originated in Austria/Benelux - manuals are fine and accurate...hmm..

 

[JesperMP]

Benelux is Belgium, Holland and Luxembourg. They dont speak german natively there (maybe in Luxembourg). It means a lot that the original manual writers are used to many languages. This is typical for smaller countries.

 

[ndzied1]

I don't think it's just 'German'.

Maybe to say it is "German" is not fair but it does seem to be a cultural thing. Cultural differences are real. In some parts of the world it is totally acceptable and even expected to show up hours late for an appointment and in others it would be heresy.

I work for an American company that represents many German companies. When it comes to programmable systems, we know that if we don't support the product the first time at the customer there is very little chance of a repeat order. Every time we sell a new system from a German company that can be programmed we send an application engineer to the customer to help with startup, provide sample code and to answer questions.

Perhaps another factor is the reduced staffs that many many companies around the world have now. It used to be machine manufacturers and systems integrators had armies of programmers but more and more there are a couple people bouncing between projects like ping pong balls. They don't have the time to learn the ins and outs and little undocumented features (bugs) or hidden mouse clicks that seem to be rampant in the software.

 

[widelto]

We have a joke here in South America, when something is complicated it is called "Siemenized" (aka Siemens style).