FORUM QUESTION: Trends in types of threads

[Ken M]

Hi

I've been registered here for about two-and-a-half years and, with no objective evidence at all, I would say I've noticed some changes in the types, subjects, or origins of threads over that time. Does anyone agree/disagree or have they spotted other issues I've missed?

PLC MANUFACTURERS : I feel that when I started looking here it was mainly AB/Rockwell that appeared most. AD gets a lot of mentions, but not many questions are asked about it. My impression is that we see a lot more Siemens these days than we used to. Is it getting more widespread, or is it just more difficult to use so we see more questions?

TOPICS : Not much change overall. I think I've seen more questions on things like networking, SCADA and comms, but there's always a fresh influx of standard coding and application queries to balance things.

NEWBIES/STUDENTS : Definitely no change. Same old questions. Same old inability to use 'search' button before 'post' button. Same old expectation to get a full and complex answer to an inadequate question.

ORIGINS : A rising trend of members from Asia and Eastern Europe. Some excellent contributors, but also some very innocent naive questions (problems with language?) like "how do I program a petrochemical refinery?". It can be very difficult to engage satisfactorily without a great deal of question and answer work to establish the true problem.

Any other ideas?

Ken

 

[PeterW]

The PLC type depends on time of day.

For me in the morning Siemens questions are quite predominant, yet after lunch, when our learned friends across the pond awaken, it changes to predominantly AB.
Sprinklings of other flavours at all times..

 

[Doug-P]

Lots more off-topic threads. Lots of threads only peripherally related to PLCs, IMO.

Due to the breadth of knowledge represented on this board, it seems everyone thinks that someone here will have the answer to any question, even if it's not PLC related. Surprisingly, they're often right.

.02

 

[Tom Jenkins]

Definitely more Siemens. Partly because they are makin a marketing push, partly because they are harder to deal with.

We are seeing more process related questions, and more flow analog device questions. Also a lot more VFD related inquiries.

Students never change.

Also a lot more inquiries from outside the US. I think it is a good thing, as it is a world economy after all. However, the questions we get from some areas indicate to me a lot less "hands on" experience in their backgrounds.

 

[PLucas]

Ken

When I first joined this forum, some 5 years ago now, there were hardly any threads on Siemens, they have grown in numbers over the years.

Like the threads on Siemens, the number of members who use Siemens has also grown over the years.

It does sometimes go quiet on the Siemens front, then we have a rush on them again.

I have to assume that the more times a question is asked about Siemens PLC's the more likely this forum is going to turn up on a google search, the more times that happens, more new members join and ask more questions about Siemens...

The circle of life???

Paul

 

[geniusintraining]

I’m still a newbie (by some standards), but to me I like the vast array of questions, also the majority of us are getting deeper into more types of controls, having to explore and learn new types.

We are not expected to just fix a program anymore…you have to do it all, not that i'm complaining I like that part.

PS, I read my Siemens in the morning then my AB in the afternoon…then its time for OT in the evening

 

[shaarawi1984]

Hello;

I think that siemens PLC's spread in the last few years for many reasons (this is from my point of view); the first one that the services of the dealer are good and faster than other brands dealer (actually there is no dealers for some brands in my country). The prices also govern you, that when you deal with a brand that is spread in your market,it will be easy to find good service with cheaper prices than using other brand.

Another reason may be the machines manufactures themselves; when you find that siemens PLC's are used frequently in machines you dealt with more than other brands, then you will concentrate on it, specially people usually prefer dealing with the same brand than changing from one to another.

I am student, and I agree with what (Ken M) belived that they want every thing in easy way, my first project using PLC is in this summer during my summer trainig, I was asked to make SCADA project. They illustrated the desired results, and give me three programs for AB (RSView32, RSLogix5000,RSLinx), during this summer I read as much as I can, and this site helps me many times to return to the correct way to understand the overall preocess, especially that I have to find the solution for any problem may face me lonely. So thanks for any person helps me in this wonderfull site.

 

[BobB]

Ken, I think the increase in questions on Siemens is due partly to the popularity of this site expanding world wide and partly due to the fact that there is a lot more nachinery coming out of the EU these days to all parts of the world.

Further to the second thought, Siemens are very different in there approach to a lot of things PLC related. For someone used to ladder in particular. as many of us are, the STL etc approach is a bit of a pain and takes a bit of getting used to. I do not think I will ever be completely comfortable with STL. Even the way the Siemens S7 processor works is quite different and almost pure micro processor at times. Many PLCs have built in error checking and bits turn on that can be read and used for resets etc. Siemens head in a different direction from what I can see and OBs need to be inserted in the program to reset/allow the processor to keep running and not going into fault.

 

[PeterW]

and OBs need to be inserted in the program to reset/allow the processor to keep running and not going into fault.

And those OB's contain information and status on the fault, which can be read and a decision made whether or not to terminate the program.

Open an OB and look at the TEMP area, data is set up with the information, even OB1 holds data, such as scan time etc.

EDIT: Did I mention I love STL

 

[Clay B.]

And those OB's contain information and status on the fault, which can be read and a decision made whether or not to terminate the program.

Open an OB and look at the TEMP area, data is set up with the information, even OB1 holds data, such as scan time etc.

EDIT: Did I mention I love STL

Doing a search on information on STL lead me to this sight. I have learned more about STL from reading your posts than I have anywhere else.


EDIT: Did I mention that I think STL was spawned by Satan

 

[BobB]

Open an OB and look at the TEMP area, data is set up with the information, even OB1 holds data, such as scan time etc.

I am starting to understand this a bit now but it is quite different.

EDIT: Did I mention that I think STL was spawned by Satan

I fully agree.

 

[geniusintraining]

I like STL

I find STL is much easier to program, that’s the way that I talk it threw...

And this, And Not that, Or this = this

Try that with (AB) ladder…examine if closed this, examine if open that, branch examine if open end branch etc

STL is more natural…Don’t get me wrong, I still scratch my head from time to time, but I like STL and when it comes to speed….there is no comparison

I have worked with some old timers (they have taught me a lot), they are/were fast at ladder, I can only imagine if I get to there caliper using STL

 

[S7Guy]

I have found that all that most people need is a one hour tutorial in how to read and write STL, and once they understand it, they like it. Like anything else, it is a tool, and should be used.

To a novice, I use the analogy that STL is like a telephone conversation, meaning that you would write the code like you were explaining it over the telephone. It works every time.

 

[Clay B.]

I find STL is much easier to program, that’s the way that I talk it threw...

And this, And Not that, Or this = this

Try that with (AB) ladder…examine if closed this, examine if open that, branch examine if open end branch etc

STL is more natural…Don’t get me wrong, I still scratch my head from time to time, but I like STL and when it comes to speed….there is no comparison

I have worked with some old timers (they have taught me a lot), they are/were fast at ladder, I can only imagine if I get to there caliper using STL

I think it is my electrical background. I automaticaly know that AND is series and OR is parallel. NOT is an inverterted function. So when I say it in my mind (feeble as it is) I visulize it as ladder.

Heck with my luck, by the time I can get STL down they will have some other form of code to torcher me with.

 

[Peter Nachtwey]

I have found that all that most people need is a one hour tutorial in how to read and write STL, and once they understand it, they like it. Like anything else, it is a tool, and should be used.

Then why are there so many questions about how do such basic things.

To a novice, I use the analogy that STL is like a telephone conversation, meaning that you would write the code like you were explaining it over the telephone. It works every time.

I haven't seen evidence of it on this forum. I have seen veterans fight problems for days here.

I must admit that I would prefer to use STL over ladder in many of the applications that I get involved with but frankly I cringe when I hear another customer is going to use our motion controller with a S7. On a S7 these projects would be almost impossible in ladder. In STL too many don't understand indirect or indexed addressing, they find it to be a struggle to handshake data through the Profibus, let alone keeping track of state if the message is longer than what can be sent in one Profibus DP packet.

I must write an FB that interfaces with our controllers and write example programs that show how to use it.

I agree with those that said there are more S7 users and S7s are harder to program.

There are also too many BS threads full of opinions and few facts. I do like the threads where PLC features are discussed.