Auto Mains Failure PLC Program Using Omron PLC

Auto start up of the DG when the Mains Supply fails . This is a very common system and is the first step in DG synchronization.
Here we will see that what is the basic concept in AMF? What hardware is required to set up AMF and how PLC Programming is done.

First of all let us understand what is AMF?
Generally all the major industries/companies/institution have the DG for power back up , but when when main power is cut off , someone has to go to start the DG and this takes time and also a man has to be kept for this purpose. So to eliminate this process PLC panel is installed to Auto start the DG when main power fails.

Working is as follows:- when main power goes , a signal is received to PLC and after 2 minutes DG starts . When the Main supply fail signal is received by PLC then after a delay time (can be from 1 to 2 minute) , output for ACB/Contactor of DG is ON and DG starts automatically. Also the ACB/Contractor of main transformer if sent OFF Command. When main power comes then the signal is again sent to PLC and PLC off the ACB/Contactor of DG and after 2 seconds it on the ACB/Contactor of main transformer and after 30 seconds it off the DG. DG is sent OFF command a little late so that the load beared by DG for a long time can be compensated by running at no load for some time.

NOTE :- In no Condition the ACB/Contactor of both DG and Main transformer should be ON.

So this is the main concept in DG AMF system.
In a simple system there are generally 4 inputs and 4 outputs.

Inputs :- 1. DG ACB/Contactor close feedback.
2. Transformer ACB/Contactor close feedback.
3. Transformer Voltage Available.
4. DG Voltage Availaible.

Outputs :- 1. DG start.
2. DG Stop
3. DG ACB/Contactor close.
4. Transformer ACB/Contactor close.

How to Make Start Stop Logic in PLC using Different NO-NC Combination

This Tutorial Will teach you how to use NO and NC for making Start stop logic. For this we understand that you have basic knowledge of No and NC . You can also learn Basic of PLC here.

To make start-stop logic you just have to write a simple program in PLC. In Electrical it is possible to make start – stop logic with a NO start push button and NC stop push button BUT in PLC you can make start-stop logic with any combination of start and stop push button.

Let us understand ……..

**PB- Push Button, NO – Normally Open, NC – Normally Closed**

1> Start PB – NO , Stop PB – NC



2> Start PB – NO , Stop PB – NO



3> Start PB – NC , Stop PB – NO




4> Start PB – NC , Stop PB – NC




Source:-http://www.automation-talk.info/2010/07/how-to-make-start-stop-logic-in-plc.html

Different Type of List AC/DC Electrical Motors

Motors are the heart of any plant or industry. The origin of Motor was to convert electrical energy to mechanical energy. DC motor was the first one to be invented and was result of concepts of electromagnetism by Michael Faraday. Today DC Motors , AC Motors - Induction , Squirrel Cage , Servo and Stepper Motor are used widely. We will see in brief about all these different types of Motors used in Automation Industry.


Electrical Motors In Industries :-

1) AC Motor :- We have already discussed the history of AC Motor in our earlier post. There is two broad classification of AC motors first Induction Motor and second as Synchronous Motors.
AC Induction Motor can viewed as Transformer for easy understanding. When voltage is applied to primary of Transformer a current flows and as a result current is induced in secondary winding of transformer.

The primary can be considered as Stator and Secondary as Rotor of AC Induction Motor. The magnetic field set up in the Stator results in Induced Magnetic Field in Rotor and results in Motion. Working of AC Induction Motor discussed already.

Synchronous Motor is same as Induction motor but with different Rotor configuration. The rotor is constructed in such a way that the Rotor is able to rotate with exactly same speed as of stator field. There are two variants of Synchronous Motor - self excited and Directly excited.

2) DC Motors :- DC Motors have been used in Past over the AC motors for applications demanding Speed and Position Control . Until the Introduction of Power electronics the speed variation of DC Motor was easier. In DC Motors the field in stationary in stator and rotor field, is set up by passing current through a commutator and into the rotor assembly. There are different types of DC motors as Shunt Wound Motor, Series Wound Motor and Compound Wound Motor.Subscribe to Automation-Talk by Email

3) Stepper Motor :- As the name indicates Step Motors are used for Converting the Digital Inputs commands in to Analog motion with the help of motor controller electronics.
Stepper Motor Rotates in angular positions according to the digital pulses Inputs. There are different types of Stepper Motors namely as solenoid activated, variable reluctance,permanent magnet and synchronous inductor stepper Motor.

4) PMDC Motor :- PMDC stands for permanent magnet DC , and is mostly used in closed loop system with effective feedback system. In these Motors there is linear speed-torque curve due to permanent magnet which provide provide constant field flux at all speeds. This Motor generates high starting or acceleration torque with light weight and thus used for rapid positioning applications.

5) Servo Motor :- Servo Motor works on servo-mechanism , best for closed loop applications . A controller issue commands for position/speed/torque control of motor shaft. "Servo" is a very big word to understand and we will be discussing more about servo drives, controllers and closed loop system in details in our further posts.



Source:-http://www.automation-talk.info/2011/02/different-type-of-electrical-motors.html

Embedded Software Risk Areas -- An Industry Study

I've had the opportunity to do many design reviews of real embedded software projects over the past decade or so.  About 95 reviews since 1996. For each review I usually had access to the project's source code and design documentation.  And in most cases I got to spend a day with the designers in person. The point of the reviews was usually identifying risk areas that they should address before the product went into production. Sometimes the reviews were post mortems -- trying to find out what caused a project failure so it could be fixed. And sometimes the reviews were more narrow (for example, just look at security or safety issues for a project). But in most cases I (sometimes with a co-reviewer) found one or more "red flag" issues that really needed to be addressed.

In other postings I'll summarize the red flag issues I found from all those reviews. Perhaps surprisingly, even engineers with no formal training in embedded systems tend to get the basics right. The books that are out there are good enough for a well trained non-computer engineer to pick up what they need to get basic functionality right most of the time. Where they have problems are in the areas of complex system integration (for example, real time scheduling) and  software process. I'm a hard-core lone cowboy techie at heart, and process is something I've learned gradually over the years as that sort of thing proved to be a problem for projects I observed. Well, based on a decade of design reviews I'm here to tell you that process and a solid design methodology matters. A lot. Even for small projects and small teams. Even for individuals. Details to follow in upcoming posts.

I'm giving a keynote talk at an embedded system education workshop at the end of October. But for non-academics, you'd probably just like me to summarize what I found:

(The green bar means it is things most embedded system experts think are the usual problems -- they were still red flags!) In other words, of all the red flag issues identified in these reviews, only about 1/3 were technical issues. The rest were either pieces missing from the software process or things that weren't being written down well enough.

Before you dismiss me as just another process guy who wants you to generate lots of useless paper, consider these points:

• I absolutely hate useless paper. Seriously!  I'm a techie, not a process guy. So I got dragged kicking and screaming to the conclusion that more process and more paper help (sometimes).

• These were not audits or best practice reviews. What I mean by that is we did NOT say "the rule book says you have to have paper of type X, and it is missing, so you get a red flag." What we DID say, probably most of the time, was "this paper is missing, but it's not going to kill you -- so not a red flag."  Only once in a while was a process or paperwork problem such high risk that it got a red flag.

• Most reviews had only a handful of red flags, and every one was a time bomb waiting to explode. Most of the time bombs were in process and paperwork, not technology.

Source:-http://betterembsw.blogspot.in/2010/10/embedded-software-risk-areas-industry.html

Embedded System | Embedded Software Programming

Really good code usually consists of a large number of relatively small subroutines (or methods) that can be composed as building blocks in many different ways. But when I review production embedded software I often see the use of fewer, bigger, and less composable subroutines.This makes the code more bug-prone and often makes it more difficult to test as well.

The reason often given for not using small subroutines is runtime execution cost. Doing a subroutine call to perform a small function can slow down a program significantly if it is done all the time. One of my soapboxes is that you should almost always buy a bigger CPU rather than make software more complex -- but for now I'm going to assume that it is really important that you minimize execution time.

Here's a toy example to illustrate the point. Consider a saturating increment, that will add one to a value, but will make sure that the value doesn't exceed the maximum positive value for an unsigned integer:

  int SaturatingIncrement(int x)

  { if (x != MAXINT)

    { x++;

    }

    return(x);

  }

So you might have some code that looks like this:

  ...

  x = SaturatingIncrement(x);

  ...

  z = SaturatingIncrement(z);

You might find that if you do a lot of saturating increments your code runs slowly. Usually when this happens I see one of two solutions.  Some folks just paste the actual code in like this:

  ...

  if (x != MAXINT)  { x++; }

  ...

  if (z != MAXINT)  { z++; }

A big problem with this is that if you find a bug, you get to to track down all the places where the code shows up and fix the bug. Also, code reviews are harder because at each point you have to ask whether or not it is the same as the other places or if there has been some slight change. Finally, testing can be difficult because now you have to test MAXINT for every variable to get complete coverage of all the branch paths.

A slightly better solution is to use a macro:

#define SaturatingIncrement(w)  { if ((w) != MAXINT)  { (w)++; } }

which lets you go back to more or less the original code. This macro works by pasting the text in place of the macro. So the source you write is:

  ...

  SaturatingIncrement(x);

  ...

  SaturatingIncrement(z);

but the preprocessor uses the macro to feed into the compiler this code:

  ...

  if (x != MAXINT)  { x++; }

  ...

  if (z != MAXINT)  { z++; }

 thus eliminating the subroutine call overhead.

The nice things about a macro are that if there is a bug you only have to fix it one place, and it is much more clear what you are trying to do when there is code review. However, complex macros can be cumbersome and there can be arcane bugs with macros.  (For example, do you know why I put "(w)" in the macro definition instead of just "w"?) Arguably you can unit test a macro by invoking it, but that test may well miss strange macro expansion bugs.

The good news is that in most newer C compilers there is a better way. Instead of using a macro, just use a subroutine definition with the "inline" keyword.

  inline int SaturatingIncrement(int x)

  { if (x != MAXINT)

    { x++; }

    return(x);

  }

The inline keyword tells the compiler to expand the code definition in-line with the calling function as a macro would do. But instead of doing textual substitution with a preprocessor, the in-lining is done by the compiler itself. So you can write your code using as many inline subroutines as you like without paying any run-time speed penalty. Additionally, the compiler can do type checking and other analysis to help you find bugs that can't be done with macros.

There can be a few quirks to inline. Some compilers will only inline up to a certain number of lines of code (there may be a compiler switch to set this). Some compilers will only inline functions defined in the same .c file (so you may have to #include that .c file to be able to inline it). Some compilers may have a flag to force inlining rather than just making that keyword a suggestion to the compiler. To be sure inline is really working you'll need to check the assembly language output of your compiler. But, overall, you should use inline instead of macros whenever you can, which should be most of the time.



Source:-http://betterembsw.blogspot.in/search/label/optimization

Embedded Systems Training | Sofcon Embedded Training Institute

Critical embedded software should use static checking tools with a defined and appropriate set of rules, and should have zero warnings from those tools.

Consequences:
While rigorous peer reviews can catch many defects, some misuses of language are easy for humans to miss but straightforward for a static checking tool to find. Failing to use a static checking tool exposes software to a needless risk of defects. Ignoring or accepting the presence of large numbers of warnings similarly exposes software to needless risk of defects.

Accepted Practices:

• Using a static checking tool that has been configured to automatically check as many coding guideline violations as practicable. For automotive applications, following all or almost all (with defined and justified exceptions) of the MISRA C coding standard rules is an accepted practice.
• Ensuring that code checks “clean,” meaning that there are no static checking violations.
• In rare instances in which a coding rule violation has been formally approved, use pragmas to formally document the deviation and direct the static checking tool not to issue a warning.

Discussion:
Static checking tools look for suspicious coding structures and data use within a piece of software. Traditionally, they look for things that are “warnings” instead of errors. The distinction is that an error prevents the compiler from being able to generate code that will run. In contrast, a warning is an instance in which code can be compiled, but in which there is a substantial likelihood that the code the compiler generates will not actually do what the designer wants it to do. Reasons for a warning might include ambiguities in the language standard (the code does something, but it’s unclear whether what it does is what the language standard meant), gaps in the language standard (the code does something arbitrary because the language standard does not standardize behavior for this case), and dangerous coding practices (the code does something that is probably a bad idea to attempt). In other words, warnings point out potential code defects. Static analysis capabilities vary depending upon the tool, but in general are all designed to help find instances of poor use of a programming language and violations of coding rules.

An analogous example to a static checking tool is the Microsoft Word grammar assistant. It tells you when it thinks a phrase is incorrect or awkward, even if all the words are spelled correctly. This is a loose analogy because creativity in expression is important for some writing. But safety critical computer code (and English-language writing describing the details of how such systems work) is better off being methodical, regular, and precise, rather than creatively expressed but ambiguous.

Static checking tools are an important way of checking for coding style violations. They are particularly effective at finding language use that is ambiguous or dangerous. While not every instance of a static checking tool warning means that there is an actual software defect, each warning given means that there is the potential for a defect. Accepted practice for high quality software (especially safety critical software) is to eliminate all warnings so that the code checks “clean.” The reasons for this include the following. A warning may seem to be OK when examined, but might become a bug in the context of other changes made to the code later. A multitude of warnings that have been investigated and deemed acceptable may obscure the appearance of a new warning that indicates an actual bug. The reviewer may not understand some subtle language-dependent aspect of a warning, and thus think things are OK when they are actually not.

Selected Sources:
MISRA Guidelines require the use of “automatic static analysis” for SIL 3 automotive systems and above, which tend to be systems that can kill or severely injure at least one person if they fail (MISRA Guidelines, pg. 29). The guidelines also give this guidance: “3.5.2.6 Static analysis is effective in demonstrating that a program is well structured with respect to its control, data, and information flow. It can also assist in assessing its functional consistency with its specification.”

McConnell says: “Heed your compiler's warnings. Many modern compilers tell you when you have different numeric types in the same expression. Pay attention! Every programmer has been asked at one time or another to help someone track down a pesky error, only to find that the compiler had warned about the error all along. Top programmers fix their code to eliminate all compiler warnings. It's easier to let the compiler do the work than to do it yourself.” (McConnell, pg. 237, emphasis added).

References:

• McConnell, Code Complete, Microsoft Press, 1993.
• MISRA, (MISRA C), Guideline for the use of the C Language in Vehicle Based Software, April 1998.
• MISRA, Development Guidelines for Vehicle Based Software, November 1994 (PDF version 1.1, January 2001).
• (See also posting on Coding Style Guidelines and MISRA C)

NIEC College Training With Sofcon

Dear all

as you know that we have been conducting in-campus training in NIEC Delhi for the past 4 years. This year they gave us additional assignment of training their final year students of ECE & EE students on Industry readiness program, even though, it was slightly a different line for Sofcon. But Sofcon Noida team with the help of an outsourced agency, managed this well, which was a great success (Well done). Infosy has given 253 job offer letters in a single drive to NIEC students, its a great milestone for the college. Previous highest placement from college has been only 68. College authorities are very happy with Team Sofcon. The letter (attached) is the endorsement of this happiness.