Assignment help !!!!

[kamenges]

I agree with Okie PC. Personally I would do this as a state machine.

However, if you don't want to go as far as a state machine I would strongly encourage you to separate the logic deciding which pump needs to run from the actual pump outputs. You have at least one case where a pump needs to run outside of the normal sequence of swapping which pump runs when the pressure is low. It can me very difficult to keep your swapping logic working as intended when the extra pump run case is added if you use the pump outputs as part of your logic.

Keith

 

[blackhenry]

can anyone give me a clearly clue for the Stage 2 : A low pressure switch has been added to the tank. When the air stays too lo for 5 minutes, the plc starts both compressors and runs them for 10 minutes and then return to normal duty. This emergency start does not count toward the bell cycle
Thank you so much more

 

[Mickey]

can anyone give me a clearly clue for the Stage 2 : A low pressure switch has been added to the tank. When the air stays too lo for 5 minutes, the plc starts both compressors and runs them for 10 minutes and then return to normal duty. This emergency start does not count toward the bell cycle
Thank you so much more

What the others are talking about is Rung #3 XIC address O:3.0/0 Pump 1 . output. You need this instruction to be true for pump 2 to start. What if Pump 1 did not start Rung 000 is false?

Also rung 000 XIO address O:3.0/1 Pump 2' output. Once pump 2 starts pump 1 will turn off.

 

[OZEE]

can anyone give me a clearly clue for the Stage 2 : A low pressure switch has been added to the tank. When the air stays too lo for 5 minutes, the plc starts both compressors and runs them for 10 minutes and then return to normal duty. This emergency start does not count toward the bell cycle
Thank you so much more

Several others here have hinted at this, even going so far as to suggest a state machine. I'll come right out and say what they haven't:

The most important part of any automation project is to DEFINE your system. NEVER start writing code until you have a clear definition of your system. Your system can easily be represented as a state logic machine, which is easily represented by a flow chart. The first thing you need to do before you do any more is to set down and write out a flow chart. Break your system into states or steps. What happens first? How do I know when the first step is done and it's ready to move to the second step? What happens in the second step, how do I know it's done and ready to move on? Third? Fourth? etc. Are there places where it might loop back (a cycle) or loop out (e.g. your new requirement for the low-pressure recovery). MAKE A FLOW CHART!

Typically after you have a good flow chart showing all the states and transition conditions, you will find that writing the code is merely a formality.

I've been in this business for almost 25 years and this is still the process that I use. On smaller projects, I might not formally write out a state diagram, but I go through the process in my mind. On larger projects, I still do the drawing. As a matter of fact, at the company I now work at, our sequence/state drawings are standard drawings in our design process.

So, if your instructor has not taught this, please accept this advice from those of us who do this professionally:

1) Define your process.
2) Define your i/o requirements based on how your process functions.
3) Document your system.
4) THEN you have enough information to start programming.

Though I can't guarantee that following this order will prevent all problems, I can almost guarantee that you will have problems (I'm not saying how serious or expen$ive the problems will be) if you don't.

 

[Lancie1]

Can you tell me what is the mistake i got on my program?

Yes, first you insist on calling a compressor a pump. A compressor is close to being a type of pump, but "close" only counts when playing horseshoes. That will inform your instructor that your program is bound to be full of crapola, and he will probably look no further before adding the big red "F". If you can't get the basics correct, then sign up for basket weaving next semester. In your own words:

This workshop has two very large compressors which feed air into a holding tank.

 

[leitmotif]

Several others here have hinted at this, even going so far as to suggest a state machine. I'll come right out and say what they haven't:

The most important part of any automation project is to DEFINE your system. NEVER start writing code until you have a clear definition of your system. Your system can easily be represented as a state logic machine, which is easily represented by a flow chart. The first thing you need to do before you do any more is to set down and write out a flow chart. Break your system into states or steps. What happens first? How do I know when the first step is done and it's ready to move to the second step? What happens in the second step, how do I know it's done and ready to move on? Third? Fourth? etc. Are there places where it might loop back (a cycle) or loop out (e.g. your new requirement for the low-pressure recovery). MAKE A FLOW CHART!

Typically after you have a good flow chart showing all the states and transition conditions, you will find that writing the code is merely a formality.

I've been in this business for almost 25 years and this is still the process that I use. On smaller projects, I might not formally write out a state diagram, but I go through the process in my mind. On larger projects, I still do the drawing. As a matter of fact, at the company I now work at, our sequence/state drawings are standard drawings in our design process.

So, if your instructor has not taught this, please accept this advice from those of us who do this professionally:

1) Define your process.
2) Define your i/o requirements based on how your process functions.
3) Document your system.
4) THEN you have enough information to start programming.

Though I can't guarantee that following this order will prevent all problems, I can almost guarantee that you will have problems (I'm not saying how serious or expen$ive the problems will be) if you don't.

This was stated so well I can only add
1. Read what he said
2. Read it again
3. Do it - it will save lots of headaches.

Dan Bentler

 

[Lancie1]

Can you tell me what is the mistake i got on my program?

Yes, compressors are normally controlled with pressure switches, but almost never by level switches. Change your program level switches to pressure switches. There is a difference. Also please stop calling these compressors "pumps" In a loose generic sense they could be called pumps in that they move air from one place to another, but "compressor" is the more preferred specific English description.

 

[blackhenry]

Sorry guy, i'm an oversea student, English is not my main language, that's a reason why . Sorry for disturb anyone to help me

 

[Lancie1]

Henry, no problem. I am sure that your instructor will be lenient due to your language difficulty. Still, you want your work to be as error-free as possible.

Your assignment (which you posted the very first thing) clearlly spells out the compressors (not pumps) and the pressure switches (not level switches), so you want to at least get those parts correct. Using any other words would show a complete lack of understanding about what you are doing.

 

[yasirkhi]

I tried to make this program using sequencer in logixpro. I will copy it again for rslogix500, and post here.

Yasir

 

[OkiePC]

Sorry guy, i'm an oversea student, English is not my main language, that's a reason why . Sorry for disturb anyone to help me

Don't pout, just continue to work at being more specific and expand your list on information in your questions.

A good exercise in learning to program ladder logic is to start with hard wired relay logic building somewhat complex forward and reverse interlocked motor start circuits with timers.

Next, take abstraction straight to the HMI and to the machine and to pencil and paper and DESIGN and SPECIFY a program on paper in theory, KISS and use a system or structure that is proven. Flowcharts are easy to convert to exclusive bit state engines with perfection in predictability.

Complex machines with dozens of I/O moving at high speed with multiple options which need to modify the ordered and length and complex sequencer of ordered steps call for a drum stepper with SQI for input optimization and diagnostics in cases where each step often requires a different pattern or required end conditions.

If you apply yourself and have the knack for abstraction from relay logic to structures of arrays of control objects and their parameters, when you get past borrowing ideas and re-using them and move on to creating projects that work as intended with minimal problem later on, then you can do this.

If you don't like to make a plan, and a good one, it can be tough.

 

[OkiePC]

A simple Steno Pad is the ideal PLC code writer's beginners draft paper.

Write the name of the step in the left column, describe the action in the right column.

Always start with what happens when power is first applied including any homing and reset steps, and don't be afraid to leave spares and spaces. If you sequence is ten steps, use all twenty lines on the sheet 1st draft.

Tear out that page and sit down with OpenOfficeCalc or mS. excel and recreate it. Then insert 16 columns in the center. Make them narrow and assume they're a bit pattern that will end up in your SQO_Data File Area.

Next translate your description of the actions into output bit patterns. For each device you describe, pick a column to "poke a peg in" and then at teh top of the list insert a really tall row with the text properties alignment angle or orientation set to vertical, and put the name of the device above each action. So your bits are now labelled to represent distinct actions which often map directly to I/O but the imagination is the only limit.

You could decide that the operator should be able to choose one of 8 preset speeds for a drive from a drop down list in the Scada, all you do is "repeg" (with a oneshot or rising edge transition) the sequencer using 3 bits to send binary select signal right out to a bit word which is mapped to 3 DC outputs wired to the VFD speed biniary multi-speed preset wiring mode.

The thing that helps the most is if you can watch live running ladder logic with a moving machine or quality graphic representation of one to follow along.

Mickey posted a link to he BSL instruction write up with animation created at MRPLC.com which I think is a wonderful example of clean imaginitive, heck, nearly a flawless example. You need one of those for the state engine with live ladder.http://www.mrplc.com/kb/index.php?article=71

IN the coming weeks, i plan to figure out a way to tie the Crimson 3 emulator to the free version of RSLogix 500 and Emulate 500...

 

[yasirkhi]

Programmed in logixpro

Hi there,
i tried to program in logixpro with sequencer.

 

[iant]

Sorry guy, i'm an oversea student, English is not my main language, that's a reason why . Sorry for disturb anyone to help me

At this stage I would ask your instructor to assist you in your understanding of english - they will always help you - it is their job.
where are you from?

 

[blackhenry]

Well , if he can helps me, i won't ask you guys for help, he just seat on the chair, playing with computer and see youtube , how great life is that , huh?
Thank you so much with yasirkhi about helping me, i'm so grateful about that
Thank you