Pump control from 4-20ma level
- Thread starter Dakotap92
- Start date
OkiePC
Lifetime Supporting Member
The ML1400 is what we use for exactly the same application. Our customers all seem to use the 120vac powered, DC input relay output model. All analog signals are brought in with expansion cards. The analog signals may be subject to more problems and the cards may suffer damage and are easier to replace than the PLC with built in analog I/O.
My opinion of the ML1400 has increased greatly over the past 6 months. Many of our customers have no backup programs, poor grounding, no memory modules and the little controllers have been running for years without any hiccups. They support online (run time) editing with the exception of MSG instructions.
I think your choice of controller is a good one. Personally, I would specify DC outputs for the discrete signals and interposing relays, but I often need to match what is already onsite for the sake of reducing the number of spare parts a customer might need to keep on hand.
For your tower level, have a look at some snippets of logic I just wrote. This tower level signal in my case comes from another ML1400 about a mile away via a radio and is scaled and filtered there. My logic is not yet installed and there are a couple of alterations I intend to make like scaling the levels to tenths of feet and changing my 2nd compare to a LES instead of LEQ:
My opinion of the ML1400 has increased greatly over the past 6 months. Many of our customers have no backup programs, poor grounding, no memory modules and the little controllers have been running for years without any hiccups. They support online (run time) editing with the exception of MSG instructions.
I think your choice of controller is a good one. Personally, I would specify DC outputs for the discrete signals and interposing relays, but I often need to match what is already onsite for the sake of reducing the number of spare parts a customer might need to keep on hand.
For your tower level, have a look at some snippets of logic I just wrote. This tower level signal in my case comes from another ML1400 about a mile away via a radio and is scaled and filtered there. My logic is not yet installed and there are a couple of alterations I intend to make like scaling the levels to tenths of feet and changing my 2nd compare to a LES instead of LEQ:
OkiePC
Lifetime Supporting Member
Also, I recommend mapping your inputs and outputs to internal bits (B3 addresses for example). And, you will want to make sure to add timers so that when you bring on a pump, it runs for a minimum amount of time and when you shut it off, you make it stay off for a minimum amount of time. Pumps (most motors) don't like being short cycled. This can and will happen when (not if) your transmitter goes whacky someday without these minimum on and off delays.
we have radio coming into plan from tank with the signals for the tank levels. So very similar! Thanks so much I didn't know if posting on this forum I would get a lot of flak for having no schooling . You guys are great . I can't wait to start this project. A lot to learn but it's so interesting. I just wanted to get a start on learning for myapplication so when I get hardware il already have a head start on knowing where to begin .
One stupid question when doing this .. We have like I said 8 maybe more analog inputs for tanks, level and water quality measuremt devices . When I start the ladder logic say for one set (2 pumps lead lag) for one tank , and another set of pumps for the second tank do I just write all this in the same file ? Rung after rung until everything in the plant is on the same file or do you separate things ?
OkiePC
Lifetime Supporting Member
I typically separate my logic:
LAD 2: MAIN. file number two always runs. All other LAD files must be called in order to run. This allows you to pick and chose which ones you want to call. I almost never have conditional subroutines, So in LAD 2 there will be unconditional JSR (call subroutine) instructions for all the other ladder files.
LAD 3: INMAP. This is where I take the real world inputs and copy them into internal bit addresses. This file is often written last. I might want to get all the actual controlling logic. For a small system, I may also put any HMI mapping here too. For a larger system, I may have a whole separate routine for mapping the HMI or SCADA addresses and handling any necessary logic that needs to be there to manipulate values, etc.
LAD 4: Logic: This is where the meat and potatoes of the control logic goes. I may have just one main logic file or twenty. It sort of depends on how big is the project. If you have two or three more or less isolated tank/pump systems, put each in its own file.
LAD 9: OUTMAP. This is where I take the results of the other files which end up in internal addresses and copy them to the real world outputs.
There may be other files dedicated to things like RADIO MSGs or what not.
Data Files:
Expand your data files. Make them bigger than you need. Add extra ones. You have to do this offline, and if you get to a running system and need to add stuff without shutting down, it is always nice to have room to do it orderly.
I have some habits here:
Always add a spare of each main type like Floats, Longs, Ints, Bits, Counters, etc. I rarely use string files, but I always have one in there . . . just in case...
N10: This is my favorite file number for Output Mapping bits
N11: This is the file number I seem to always choose for Input Mapping bits.
N20: Output values from the PLC to the HMI/SCADA
N21: Inputs from the HMI
N30: Message Data to another controller
N31: Message Data from another controller
These are just examples, you can do what ever you want, but it is good to have some sort of a system and consistency.
Each time you add a file, be sure to make it plenty big enough for future expansion. If you are worried about memory use, you can Verify the Program (right click on the "Program Files" folder icon) and then double click on the Controller Properties to see how much memory is used and still free.
By using internal addresses for your ladder logic, you can write your code and even test it to a large degree without having to worry about how the real world inputs and outputs are going to end up being wired. You can fill in the input and output map last and make changes to said "maps" without greatly affecting your actual control algorithms.
The only references to the real world inputs and outputs will always be located in my "INMAP" and "OUTMAP" ladder files. Throughout the rest of the program, I work with the mapped addresses. By mapping, I simply mean:
LAD 2: MAIN. file number two always runs. All other LAD files must be called in order to run. This allows you to pick and chose which ones you want to call. I almost never have conditional subroutines, So in LAD 2 there will be unconditional JSR (call subroutine) instructions for all the other ladder files.
LAD 3: INMAP. This is where I take the real world inputs and copy them into internal bit addresses. This file is often written last. I might want to get all the actual controlling logic. For a small system, I may also put any HMI mapping here too. For a larger system, I may have a whole separate routine for mapping the HMI or SCADA addresses and handling any necessary logic that needs to be there to manipulate values, etc.
LAD 4: Logic: This is where the meat and potatoes of the control logic goes. I may have just one main logic file or twenty. It sort of depends on how big is the project. If you have two or three more or less isolated tank/pump systems, put each in its own file.
LAD 9: OUTMAP. This is where I take the results of the other files which end up in internal addresses and copy them to the real world outputs.
There may be other files dedicated to things like RADIO MSGs or what not.
Data Files:
Expand your data files. Make them bigger than you need. Add extra ones. You have to do this offline, and if you get to a running system and need to add stuff without shutting down, it is always nice to have room to do it orderly.
I have some habits here:
Always add a spare of each main type like Floats, Longs, Ints, Bits, Counters, etc. I rarely use string files, but I always have one in there . . . just in case...
N10: This is my favorite file number for Output Mapping bits
N11: This is the file number I seem to always choose for Input Mapping bits.
N20: Output values from the PLC to the HMI/SCADA
N21: Inputs from the HMI
N30: Message Data to another controller
N31: Message Data from another controller
These are just examples, you can do what ever you want, but it is good to have some sort of a system and consistency.
Each time you add a file, be sure to make it plenty big enough for future expansion. If you are worried about memory use, you can Verify the Program (right click on the "Program Files" folder icon) and then double click on the Controller Properties to see how much memory is used and still free.
By using internal addresses for your ladder logic, you can write your code and even test it to a large degree without having to worry about how the real world inputs and outputs are going to end up being wired. You can fill in the input and output map last and make changes to said "maps" without greatly affecting your actual control algorithms.
The only references to the real world inputs and outputs will always be located in my "INMAP" and "OUTMAP" ladder files. Throughout the rest of the program, I work with the mapped addresses. By mapping, I simply mean:
Last edited:
OkiePC
Lifetime Supporting Member
If you temporarily block or delete the JSR to your INMAP and OUTMAP routines, you can toggle bits and see what happens to simulate the real I/O when testing with RSLogix500 Emulate or with a real controller. If you use a real controller and do not have the actual I/O addresses installed, you will have to disable the fault for missing modules or delete all references to them in order to allow a download. This is my main reason for advocating "mapping".
Similar Topics
Hi everyone, I am a newbie and I have trouble in the control sequence. I have a system with 4 pumps. The required:
Ex: Push a button to start in...
Hi there,
We have a system at a water treatment plant where large raw water tanks feed into the plant that's all on the same level. At high tank...
I am at a loss...
I have a pasteurizing system that i need to control product temperature with the speed of the product pump. I currently have a...
I am controlling a very tight window in a 8 foot sump. My low level to keep from cavitating the pump is 44” and my high level is 55”. The problem...
Hey everyone,
I was on a customer's site on friday where they have a large bioreactor that they bought secondhand from a previous user. System is...