b_carlton

I am curious what you mean by changing your question to 'soft'

Search the manual for your CPU for the GTS and SBR instructions. The subroutine is inserted after the main program END instruction. The subroutine is started with the SBR instruction and ended with an RT (return)  instruction. You may use a RTC (return conditional) if your subroutine requires it) Unlike many other programming languages there is no structure for passing or returning values, The subroutine is identified by a constant provided as an argument to the SBR instruction. You invoke the subroutine from within the main program using the GTS instruction with the same numeric argument as the target subroutine. I don't remember if you can use the GTS from inside another subroutine. Otherwise the operation is similar to other language subroutines. On invocation the main code stops, the code within the subroutine is executed, then the processing of the main program continues from the instruction immediately after the GTS.

The actual program will be fairly easy using comparison contacts. A catch will be that when an output is turned off to halt the flow of one of the components there will be some still falling. You'll have to experiment and find the amount to anticipate, probably different for each component.  

I think the description of the system implies that the supply method will soon be inadequate for the processing speeds. I don't think that just program modifications will make up for that.

The way I implement a ramp is with a timer whose preset is the total ramp time. At any point the output is FinalOutput * (Timer accumulator/Timer preset)

Try using Modbus if available.

Edit: - for a much larger number of items to work with Alaric's method is much less wasteful of system resources. But for only 10 then this is probably ok. 1. Prepare an array of DINT 10 long (example Average_Array - set dimension to 10 - you get Average_Array[0] through Average_Arrya[9]) 2. Once you have a new inter-case timing use COP to move Average_Array[1] through Average_Array[9] to Average_Array[0] through Average_Array[8]). We have to do the COP this way or they will overwrite themselves. 3. Move your just acquired timing to Average_Array[9] 4. Now use the AVE command to average the ten entries into a DINT called Timing_Average. Create a 'control' variable called Average_Control. Your rung should look something like the attachment

It may have been lost on the site during the changeover. That far back it was probably on my work computer. I'm retired now (2016). I only have RSLogix 500 micro lite now. Sorry.

There's a bit more flexibility in the Do-more line. That software is free like the Click and includes a simulator so you can check it out for no cost.

  I think you meant Local:7:I.Data.4.  (Swapped 4 and 7)

Yes, timers and counters in the SLC500 and Micrologix worlds consist of 3 16 bit words One contains the preset time/count. Another contains the current time/count. The third is used as individual bits and, at least in the timer, a small numeric section to compare with the system real-time clock. Refer to chapter 8 in this manual for more info.   https://literature.rockwellautomation.com/idc/groups/literature/documents/rm/1766-rm001_-en-p.pdf  

The SLC500 and Micrologic do not have the ability to set up user defined structures. They have some items (counters, timers, strings and others) which are structures. In the Compactlogix User-defined types (UDT) can be set up. Google for UDT and RSLogix.

First a link to the air pressure manual would be helpful.

Whatever works in your application is right.

I found it easiest in a similar application to just do the ADD and SUB blocks and not use a counter at all. Actually mine was 4 separate Up counts and one Down count input. With the complexity it was more understandable to group the 5 rungs together with 4 up counts followed by the one down count.

If using ADD or SUB make sure to one-shot the conditions to do the ADD/SUB only once for each.

If multiple down counts occur simultaneously what do you expect as behavior? Will just one down count be appropriate?

I could see this for a discreet AC input or output module but I see no reason for an analog module. Do you have an example or a link to such cards?

This area is for PLCs from Automation Direct. Please re-post in the 'Modicon' area

I'm sorry that I can't help further. The only applications I worked on were much slower. I don't know if there is a module with PLS (Programmable Limit Switch) capabilities such that processing of counts is done in the counter card itself and directly controls it's own high speed outputs. Good luck.

It will count and keep track of each pulse but the rpi will control how often the total is reported to the CPU. Your scan time will control how often your program can act on the total as reported.

You didn't mention your program's scan time. You would still have to deal with that. The number of pulses between actions on them will depend on the greater of the rpi or the scan time. You may have to do more research on high speed processing.

60Khz is a 16.66 microsecond per pulse period. What is your scan time? At an rpi of 2 ms you get about 120 pulses per update. Is that ok?

Since 'dispersion' is a general concept you might use standard deviation (STD)

You have the second output - O:5.1 - set to current output. That doesn't fit your description. O:5.0 is the first output on that card.