Please help !!!

I need Help !!!!
Hello Everyone...i got my final year project titled as
"Problems and remidies of the industries using PLCs"
Basically we have to chek all those problems which an industry can face related to PLCs. e.g Power failure in PLCs, Memory lost in Plcs, slow scnning of inputs etc etc ... soo i want help from u guys that plz if u know any industrial problems using PLCs or the solutions of the problem i discussed above.. plz plz let me know about that .. any website or any personal that u guys have surely be welcome ... Bye

My biggest problem with PLCs can be summed up as follows:

I really hate this damned machine,
I wish that they would sell it.
It never does quite what I want,
But only what I tell it!

You have posted the same question three times in the last 24 hours. The fact that there have been no responses should indicate to you that there may be something in your question that makes people reluctant to get involved. I think if you do a little research on your own and ask something more specific, you'll get more help.

Steve Bailey said:

My biggest problem with PLCs can be summed up as follows:

I really hate this damned machine,
...

Click to expand...

Power failure -- that's not a plc problem. That's a utility problem. And it doesn't matter if the machine is plc-controlled or not, when the power goes off, it's done...

The other issues you listed are primarily design issues. You need to select the right PLC for the job. If you're concerned about program loss, there are ways to fix that. If you're concerned about slow i/o scan, there are faster PLCs on the market. The PLC will do exactly what it's designed to do -- if you design your system beyond it's capabilities, it will fail -- and that's not the PLC's fault, it's the system designer's fault. Get the one to do the job correctly.

This is your final-year project. What have you already learned? What have you studied? What problems have your instructors taught you about?

One of the biggest problems may be communicating clearly! Learn to document your systems. One REMEDY is to learn to spell correctly and to CHECK your work -- nuna dis txting shortcut **** dat u b usin...

OZEE said:

One of the biggest problems may be communicating clearly! Learn to document your systems.

Click to expand...

Real programmers don't document thier code.

-jeff

Hakutsuru said:

Real programmers don't document thier code.

-jeff

Click to expand...

It's swan hunting season!

Hakutsuru said:

Real programmers don't document thier code.

-jeff

Click to expand...

Oh yeah, they do! And they do it extensively. They even use spell checkers to get it right.

Only beginners who think they're real programmers don't.

Regards,

Real programmers don't document thier code.

-jeff

Click to expand...

Jeff, some programmers may not document their code, and I would also describe them as "real" --real buttholes, real arrogant S.O.B's, and real unconcerned for those who have to pick up their mess afterwards. Usually I find that undocumented code was done by the inexperienced programmer who is afraid somebody will be able to figure how how little he really knows.

Sliver said:

It's swan hunting season!

Click to expand...

Thats a white crane. And BTW, your sig ... I still fear electricity. Nothing wrong with that.



-jeff

this thread is officially hijacked...do you document code?

Lancie1 said:

...Usually I find that undocumented code was done by the inexperienced programmer who is afraid somebody will be able to figure how how little he really knows...

Click to expand...

I have seen some of the most experienced programmers obscure and/or omit documentation to give themselves job security...sad thing is sometimes it works...

Hakutsuru said:

Real programmers don't document thier code.

Click to expand...

"If it's hard to write, it should be hard to read...."


.
.
.

Don’t forget to password protect your little work of art.

krk said:

"If it's hard to write, it should be hard to read...."


.
.
.

Click to expand...

I like that. You say job security, I say it keeps idiots out of my code. Potatoe Potahto.

All kidding aside, I actually enjoy going into an undocumented program and figuring out whats going on. And, of course, as I'm doing that, I have to fill in the documentation as I figure it out. If i were going to really be the type that was anti-documentation ... I'd probably just make the undocumented versions of my programs easy to find, and keep the documented ones under lock and key. Not that I do that. Not as far as any of you know.


-jeff

I've rewritten 4 projects this year from scratch purely because the existing code was undocumented.

I prefer to do this than waste time trying to understand what someone else was trying to do.

I would rather write something that I have little of no chance of getting that 3:00 a.m. phone call over.

I want my code to be readable by the operator if necessary. Not everyone has to understand how it works, just what it is intended to do. Often this is enough to diagnose a problem/solution.

I do not want to fly half way across the world to explain my code to someone when just spending and extra few keystrokes in the initial writing of the code can avoid it (Yes I did have to do that once).

My policy is document EVERTHING, and then go back and document the parts you documented again for clarity.

MartB said:

I've rewritten 4 projects this year from scratch purely because the existing code was undocumented.

I prefer to do this than waste time trying to understand what someone else was trying to do.

I would rather write something that I have little of no chance of getting that 3:00 a.m. phone call over.

I want my code to be readable by the operator if necessary. Not everyone has to understand how it works, just what it is intended to do. Often this is enough to diagnose a problem/solution.

I do not want to fly half way across the world to explain my code to someone when just spending and extra few keystrokes in the initial writing of the code can avoid it (Yes I did have to do that once).

My policy is document EVERTHING, and then go back and document the parts you documented again for clarity.

Click to expand...

DITTO

When a customer calls you to service a piece of machinery, the last thing he wants is to pay you to try and document someone elses code when it should have been done in the first place.