Micrologix 1400 hsc

I am trying to program a Micrologix 1400 to control a beer keg filler using an IFM SM6001 flow meter. The meter will be set up for a pulse output. I have a little bit of programing experience just from trying to automate some other brewery equipment.

I attached my program file and the high speed counter function file. I am assuming that I need to use HSC (program will eventually include keg washing/I need to make it as accurate as possible). I need help setting up the HSC parameters and help figuring out how to load 2 different High Preset values into counter depending on the size of kegs. I do not know if my programming so far is practical-it is really short in case I need to start over. Thanks a bunch, Kevin

Move the HSC value to an N file. Compare the N file value using the EQU instruction for different filling values.

Not used the MLX HSC, but used many others, you shouldn't need to load pre-set values, just zero the count on the start of filling, in normal scan just move the value into an integer register, assuming the flow meter is x pulses per litre/gallon etc. then convert the count from the HSC to a real, divide it by the expected pulses i.e. 56.45 then you have your true litres/galls or what ever.
Then you compare that with the set point i.e. the amount required & ?I also suggest you have an in-flight value to allow the time it takes the valve to close.
I have done many of these, however, I also include a calibration procedure where we dose a quantity of liquid into a vessel, weigh it (using calibrated scales) then enter the number of litres or what ever is your preferred measurement & it calculates the pulses per litre etc. this what they call the "K" factor is stored in retentive memory and used in the calculation.
Attached, is one I gave my apprentice many years ago to have a go at, it only shows the code for the flow meter & calibration code in Mitsubishi GX Developer.

Still thinking about it, and don't understand what the OP question is, if any, but welcome to the forum (as a poster), and well done!

With the caveat that I do not know the process, here are some initial thoughts:

• I think the HSL instructions are basically correct, although
  • I would use negative values for the low preset, to ensure [LAD 4] is never called on an LPR trigger, even if [LAD 4] does nothing.
  • I would think about using different trigger logic for the HSLs; read on.
• Rungs 0002 and 0003
  • There is no need to load the HSC presets every scan
    • Also note that the current logic here could change the presets while a fill is active
    • Put an [XIO* <SIXTEL IS FILLING>] on Rung 002
    • Put an [XIO <HALF BBL IS FILLING>] on Rung 003
    • The <HMI START ...> bits are only read, and not re-assigned to 0, in the PLC program,
      • so I am assuming the HMI does the clearing,
      • but it's generally a bad idea to trust the HMI to perform process-critical work
    • An alternate approach would be to only assign a 1 to those bits via the HMI, and then, when those 1s are detected in the PLC, unlatch them to 0 in the PLC on these rungs
      • This is called "Set-and-Forget," and eliminates problems caused by the well-known issue where an HMI momentary control assigns a 1 to a bit in the PLC, and then fails to assign a followup 0.
      • Set-and-Forget enforces the momentary behavior in the PLC
  • Also, consider whether the two <HMI START ...> bits could both be 1 at the same time; that would be bad.
    • E.g. combine them into a single bit
    • Or do the Set-and-Forget mentioned above
  • With logic like the above, the reset of the HSC could be done on the output side Rungs 0002 and 0003
    • Although there should be logic to ensure that another press of an <HMI START ...> cannot re-start a fill if one is already in progress.
    • I.e. so only <HMI STOP> or <HIGH PRESET REACHED> can re-arm the logic on Rungs 0002 and 0003.
• I don't see where <FILL HOSE TIL CLEAR PB> is assigned a 1
  • So with that, plus the PB (PushButton?), I assume that is another bit driven by the HMI
  • Use Set-and-Forget again
• For style/clarity, I would shift current Rung 0001 to be after current Rungs 0002 and 0003, to keep the Latches/Unlatches of the <... IS FILLING> bits rungs logic together.
  • The <First Pass> bit should protect against any problems here, but only using OTEs for bits is sometimes a better approach
• The <FILLING HOSE> bit can only be turned off by <HMI STOP> in that start-stop circuit on current Rung 0001. That will re-activate the output rung (current Rung 0004) and the re-open <KEG FILL VALVE>, even after an <HSC PRESET REACHED> event resets everything else; consider the following sequence of events at the end of a fill:
  • <HIGH PRESET REACHED> becomes 1
    • Rung 0004 goes false on [XIO <HIGH PRESET REACHED>]
      • <KEG FILL VALVE> becomes 0, presumably closing the valve
    • Rung 0000 resets the HSC [RAC HSC0 0]
  • The HSC reset will ensure <HIGH PRESET REACHED> is 0 no later than the next scan
    • I think Rung 0000's RAC, activated when <HIGH PRESET REACHED> becomes 1, will not clear <HIGH PRESET REACHED> for the rest of the scan when the RAC executes, but it will definitely be 0 on the the next scan.
  • <FILLING HOSE> is still 1
    • Assuming there has been no <HMI STOP> to break current Rung 0001
  • Rung 0004 goes true again on [XIC <FILLING HOSE>] => [XIO <HIGH PRESET REACHED>]
    • So <KEG FILL VALVE> becomes 1 again, presumably opening the valve immediately after the preset was reached, indicating the keg was already full.

* XIO is --]/[--

Again, I do not know the process, but from the comments on current Rung 0001, I assume the <FILLING HOSE> bit relates to an activity distinct from filling a keg, i.e. seeing clear beer at the end of the filling hose (instead of foam?). So the general programming principle "separation of concerns" suggests to me that <FILLING HOSE> should be decoupled as much as possible from filling a keg. One way to do that would be to wrap the [XIC <FILLING HOSE>] branch around all the XIC/XIO instructions above it on Rung 0004, and add an [XIO <FILLING HOSE>] instruction to those upper instructions.

• The bypass of [XIO <HMI STOP>] on Rung 0004 is justified because the [XIO <HMI STOP>] on current Rung 0001 would still deactivate Rung 0004, when Rung 0004 had been activated by <FILLING HOSE>.
• The bypass of [XIO <HIGH PRESET REACHED>] is justified because looking for clear beer coming out of the hose is a separate activity from filling a keg.

Finally, I noticed there is nothing in [LAD 4], which is executed when the <HIGH PRESET REACHED>, and I think it is executed as an interrupt i.e. it can happen at any time, either between program scans or even during a program scan. For the current program, an unlatch of the valve and filling signal bits could be put here, along with the other reset actions currently in Rung 0000. Such a [LAD 4] could also be called on [XIC <First Pass>] or [XIC <HMI STOP>]. That said, it would also require some very careful logic in the main [LAD 2] to latch the valve outputs to start a fill or clear the hose, because an HSC-triggered interrupt that executes [LAD 4] could potentially interrupt between the main program logic that triggers the latch and the latch itself. That may not be a problem here, but it should be considered.



Note that [LAD 4] is also executed then the low preset is reached, so if it was used for something, those low presets should be set to something other than 1 e.g. a negative value that will never occur.

Thanks everyone for your time. It will take me a while to work thru your great suggestions. Set and Forget HMI Issue: I now understand why but not sure of most practical way to do it. Can I just add a rung with a MOV instruction (without any conditions) to move a 0 into the bit that HMI just assigned a 1?

Project Background Info: I am putting together a Micrologix1400 with Cmore HMI trainer with misc sensors in order to start figuring out how to gradually automate three different processes in my existing brewery- Keg Filler/Keg Washer, a small bottling line, and brewhouse operation. Each process will have its own Micrologix 1400 based control panel. Inputs are a combination of RTDs, Level sensors, flow meters, pressure sensors, prox sensors. Most of the Outputs are to control VFDs and a bunch of air-actuated valves. My first project is to modify a two station keg washer/filler. https://www.iddeas.com/products/keg/mini-king-plus-2 (I think that the model that I have was an early prototype) Currently with 2 stations, it takes 3 minutes to wash and sanitize a 5.16g keg and then 1 minute to fill it. I want to change to 3 stations- wash 1.5min, sanitize 1.5min, fill 1 min. Our batch size equals ninety 5.16g kegs, so it will save 2-3hrs of work. The Future Keg filler station starts with a clean keg (5.16g or 15.5g) that is already pressurized to 15PSI with CO2. A tank of beer is also pressurized at 15 PSI. The keg is tapped and beer flows thru a flow meter to fill keg from the bottom as gas escapes thru a mechanical pressure relief valve set at 14PSI. The PLC just opens and closes a fill valve based on # of pulses.

Hunter-Gatherer Brewery is in Columbia, SC. Sooner or later, I am going to have to pay someone to do most of this work. Please Let me know if interested. Thanks again, Kevin

kvarner said:

Thanks everyone for your time. It will take me a while to work thru your great suggestions. Set and Forget HMI Issue: I now understand why but not sure of most practical way to do it. Can I just add a rung with a MOV instruction (without any conditions) to move a 0 into the bit that HMI just assigned a 1?

Click to expand...

It should be a bit, so, instead of a MOV, an OTU (unlatch) should do the job to assign the bit to 0, triggered when it detects the bit is a 1 and after it does or starts the work requested.

And yes, if the rung to unlatch that bit is after the rung(s) that act on the bit get to see that bit as a 1, then the unlatch rung could be unconditional, at least for the MicroLogix. Note that for some other PLCs (e.g. ControlLogix?), I/O, and perhaps transfers from an HMI, could be asynchronous with the program scan, in which case the bit could be assigned a 1 between the rung that checks, and does not find, a 1, and the rung that assigns the 0. So ideally there should be only one test for a 1, and that test should robustly trigger the unlatch to a 0, even if it happens on a later rung. There is a section in Ron Beaufort's YouTube series where he talks about this issue, about three-quarters of the way through video #4, I think. Actually that is about asynchronous I/O, not transfers from an HMI, so I do not know if it would make a difference here, and almost certainly not in a MicroLogix.