Advice needed, BRX w/ Click IO

[Ssweber]

Hello,
I have a Click Plus with all io filled. It operates 2 washers. Problem is, it's not very modular. Changes to Washer 1 ladder logic need to be copied manually to Washer 2 ladder logic.

I was thinking of adding a BRX (no io) to act as controller, and make the click be i/o only.

I'm not too familiar with Do-More programming. In python, this would be the perfect fit for Classes. You would init a class object, set forward = y1, water_valve = y2, etc, and then the rest of the logic would stay the same, but reference these local attributes.

How does on accomplish this in Do-More? I see how you can use Input/Output parameters in Subroutine CALLs. I guess I could have Subroutines of all the different actions, and have Stage for each Washer that CALLs these, setting the Input/Output with the correct IO... but is there a better way?

Or should I use 2 BRX, each with a copy of the same program, with a bit set mapping its variables to the correct modbus IO?

Appreciate any pointers!

[Kristjan]

We sometimes use Click as I/O only and a BRX for logic. Using Modbus TCP for memory mapping gives a very robust solution. Most of these implementations have different Clicks, so there is limited or no reuse of the code for each Click. But we also have some cases where a more modular approach would be more efficient.

You make a good point about using a kind of a class-approach but unfortunately I am not aware of any means to achieve this in the Do-More environment. I would also love to hear suggestions on how to achieve this.

[Bolt]

I would create a structure called Washer as a User Data Type containing things like CycleState, DoorLockSol, ColdWaterSol, HotWaterSol, DetergentPump, etc. Then create a memory block with a size of 3, so you would have Washer0, Washer1, Washer2 (this way you don't use the one named 0, as that probably doesn't jive with what the operators call it). Possibly also create a UDT called Cycle, and contain things like ColdWaterSec, DetergentPumpSec, etc. Use this UDT to create Heap Items called FirstRinse, SecondRinse, etc.

Setup the Click PLC as a device in the Modbus I/O Scanner. Possibly only mapping your X and Y bits to bits you create in your UDT (this is in theory bad practice as you may want the Click PLC to have backup control over the outputs in event of a comm failure, etc).

Then you can make a FOR/NEXT loop, index V0, from 1 to 2. Then you can write rungs like: STR Washer[V0].StartButton AND Washer[V0].CycleState == Idle, COPY Start to Washer[V0].CycleState. This would allow the code to be identical, and the Washer[V0].Name bits/words would be mapped to each physical washer via the Modbus scanner tools.

A few caveats about FOR/NEXT loops is that you can't use timers nor edge bits in the rungs. You'll have to do workarounds like MATH UTC+FirstRinse.ColdWaterSec, create a block of LastScan bits, etc.

[RBPLC]

There currently isn't support for function blocks/classes. There are ways to attempt to modularize things like Bolt recommended but they all have their own drawbacks. See the post below discussing this:
https://forum.hosteng.com/index.php?topic=3401.30

[Ssweber]

Thanks for the tips. I thought I had saw discussion on classes (what you call `Instantiable programs concept`), but I couldn't remember if if it went any where.

I'll think about this, I'm sort of leaning towards two physical units. And then map the modbus addresses at the start, w/ identical logic.