Subroutines in DMD.

[Todd Dice]

I have been tasked with designing a product that the BRX is perfect for.

In broad terms, this product will need to ability to operate multiple recipes simultaneously, but those recipe steps are exactly alike except for the variables associated for each step of the process.

Looking over the videos on YouTube, it seems a subroutine would make sense to use, since each recipes code is exactly alike. But what I can't wrap my head around is that a recipe's process can't be performed in just one scan. Some recipes may take 3-seconds to complete, others 5, and then others 7 or more.

Is use of a subroutine the best method for my application?

[BobO]

Simultaneously? That complicates it.

How many do you need to do at once?

[Todd Dice]

Up to 24.

[BobO]

Up to 24.

Yuk.

I understand that they take a while to complete, but what is involved in the control problem itself...comms and/or other async stuff, or just math and logic?

[Todd Dice]

Math and logic.

[BobO]

Timers? Counters?

[Todd Dice]

Good question, tell me what you think would work best.

I'm going to have a pulse train which is artificially generated by the PLC, or one coming from an encoder input. The pulse train, plus some math, will be used to interpret distances that operators will enter as their ON and OFF values.

I'll have for example, one output that will ON in a stage, then OFF in the next stage, then ON again in the next, repeating this for up to 24 stages. The time in each stage will be based on the preset values entered by the user. There will be a input used to start the stage's logic. So my guess is, I use a counter in each stage?

EDIT:

I just realized, I'll have to store 24 recipes, but only one will run at one time, BUT I could have up to 8 outputs operating based on the settings of each recipe. So, worst case is 8 outputs, or the subroutine being called 8-times per scan. I guess.

Got to think about this more.

[franji1]

If you can write the code generically for just 1 of the 24 "machines", but that code can handle every possible recipe, without any stages, but go ahead and use Timers and Counters (and anything else, for now).

Based on that exercise, it could be you could do it in a subroutine emulating the timers/counters through "basic" ladder logic (allowed in subroutines).

Or another possibility is a TASK with an data block of a UDT that is 24 long (one for each machine), where the UDT contains the input/output/internal state values of 1 machine , and the TASK would just have a FOR/NEXT loop iterating through the 24 "machines", and all the logic in the task would be array references of THAT UDT.  If there are no edges, and some other caveats, it could work but even edge behavior can be emulated in traditional ladder logic/data.  You could even use some simple Timers and Counters, creating a corresponding block of 24 of each of those (or 48 or 72 if you needed 2 or 3 timers per machine).

It's possible, but we would have to see the required logic for 1 machine.

[Todd Dice]

I can write the logic in regular code (timers, counters, bits). I just thought writing it in stage would be helpful for coding (plus I haven't written a stage program since 1990, so I was kind of looking forward to it ).

And just for reference, does DMD have an OR Out? An OR Out is an output available in P Suite where the addressed output can be in multiple rungs, and they all are operative, instead of just the last instance of that output/address in a scan.

Thanks for all your help.

- Todd

[franji1]

If you do the logic in stage, you cannot do any kind of re-use.  You can go down the bunny trail of doing traditional with re-use, and if that doesn't work, go ahead and do it in stage (24 program code blocks, all identical, except for the actual parameters, but a UDT block of 24 would be helpful there also).

Yeah, there is no OROUT in Do-more.  OROUT can be implemented by doing a RST at the top of $tTopOfScan, then using SET wherever you would want to do an OROUT.  That would give you the identical behavior.  That costs you a RST at top of scan.

[BobO]

There were 24 recipes, but only 8 outputs working at a time, so it sounds like it would only need to be 8 program blocks worst case.

[franji1]

There were 24 recipes, but only 8 outputs working at a time, so it sounds like it would only need to be 8 program blocks worst case.

I misunderstood - I thought that there were 24 recipe instances running at one time.

[Controls Guy]

And just for reference, does DMD have an OR Out?

OROUT was an abomination! 

[ATU]

The Japanese seem to love OROUTS. Every Koyo based machine I worked on used OROUTS everywhere.

 I am still very confused on what Ridgeline wants. Statements seem to contradict and not be very clear. Might be good to describe a layout of the process and write a list of what you want the program to do.

[Garyhlucas]

Hook a C-More HMI to the Do-More and use the built in recipe function in the C-More to enter the recipe values for the BRX to process.