MicroLogix 1400 - programming question

[drbitboy]

May i suggest the following.
1. write your logic for only 1 pump and get it working. that will help you set up
your data table requirements.
2. set up your data table requirements for all the pumps.
3. create a subroutine for all the pumps.
4. save the logic for the first pump to a library.
5. import the logic into each subroutine and use edit index to change the i/o, bits, and other control bits/words.
6. go to each subroutine and do a LOCAL search / replace for the pump numbers.
you will save a ton of time by doing this. i use it a lot.
james

Sure, but with the data structured, and the pump number and the hour of day both abstracted into indices to access those data, as @parky and @MikeyN suggest, one rung handles all pumps for all hours. The rest is bookkeeping.

It will be ugly to debug to be sure, but your get-it-working-for-one-pump-during-one-hour-first approach will certainly help there.

What is going to be a mess is the HMI for this. A slider/selector box for hour of day, and a button to send the selected hour's enables and schedule times for all pumps? A slider/selector for pump number, and a button to send the selected pump's enables and schedule times for all hours? A slider each, for hour of day and for pump number, ...?

 

[drbitboy]

Here is an implementation on a MicroLogix 1100, which should be similar to OP's 1400, of the approach suggested by @parky and @MikeyN; less than a dozen lines for the key functionality.

It uses one N (integer) data file both for the setpoint minute-of-hour schedule values and for the setpoint duration values. It also implements the enable bits in a B (binary) data file.

One looping rung sets all five pump outputs for any time of day.

The additional attachments show it works.

​

It's fuzzed because the problem definition plays like a class assignment to my eyes. It would be straightforward to make a Jupyter interface that assigns the setpoints via Modbus.

I would think a bigger problem would be clock drive and keeping track of daylight savings time within the PLC.

 

[parky]

@DR , Nice.
There is a fundamental problem with the times on all so far, although effectively I have eliminated the hours the problem exists if the minute start time is say 50 & the run time is 10 or greater, this steps over to the next hour, not a real problem except the motor will not run for the length of time as it has stepped on to the next hour, it will be a problem regardless how the OP puts it into practice as any wrong times put in could cause problems From the OP's post it is assumed that each of the 24 steps have the hours 0-23 in order or the steps go out of sequence also if a start time of say 11:50 but a run time of 12:10 was put in then the pump will stay on for the next step, also the OP has not actually said how the step is changed I have assumed it is every hour i.e. 24 hours 24 steps.
In my code have not used enable bits as if the setpoint for the minutes run is 0 then the pump will not run.
It would be interesting to know why there are 4 pumps and what dictates which run i.e. is there more than one pump running at any given time what is the reason for multiple or even just one to run is there some other factor that governs how many pumps run i.e. flow or pressure ?.
without knowing why & how these pumps are controlled it is difficult to decipher what is the real control strategy.

 

[drbitboy]

@DR , Nice.
There is a fundamental problem with the times on all so far, although effectively I have eliminated the hours the problem exists if the minute start time is say 50 & the run time is 10 or greater, this steps over to the next hour, ...

Yes, that was one of my first D.M.D. questions, i.e. whether the sum [minute-of-hour + duration] could exceed 60 (i.e. could the setpoint period cross an hour boundary). My implementation allows any integers as the start and duration minutes-of-hour, even negative values, but the period that the pump will actually run in each hour will be bounded by the limits of that hour even if the calculated period is not.

The simplest solution would be to convert to both run time parameters to start and stop minutes-of-day, but then what happens if the hour 23 period crosses midnight?

It would be interesting to know why there are 4 pumps and what dictates which run ...

This is what makes me think it is a homework assignment, and for that it is not bad, as the student has to explore various parts of the 1400 (RTC function file, data files, indirect addressing of data files, of elements in data files, and of bits in words, ensuring the minute-of-hour value MOVed from the RTC function file is consistent with the hour-of-day value).

It's basically a sequencer, as noted in the OP, but a set of pumps seems like an odd system to drive with that.

 

[parky]

Yep, Agree, crossing boundaries as I noticed not a problem except that the pump that was running depending on how it is programmed will or will not stop but in the case of the code I produced it does stop, however, then there was the problem of the accumulated run time did not reset.
The hours does not make sense "IF" it is meant to run only during that hour, again getting the times correct is a major problem unless you put code in to either show an error if run minutes is greater than current start time plus required time. The only thing you can do is on the time field limit them to the respective H:M:S i.e. 0-23 0-59, 0-59.
If this is a genuine request for an existing plant I think the OP needs to discuss with them exactly what is required, mention the pitfalls above so that everybody understands what is the requirement, that way a reasonable job does not turn out to be an epic battle between the management & the programmer.