Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: Todd Dice on August 01, 2018, 11:42:28 AM
-
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?
-
Simultaneously? That complicates it.
How many do you need to do at once?
-
Up to 24.
-
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?
-
Math and logic.
-
Timers? Counters?
-
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.
-
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.
-
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 ;D).
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
-
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.
-
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.
-
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.
-
And just for reference, does DMD have an OR Out?
OROUT was an abomination! ;)
-
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.
-
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.
-
The Japanese seem to love OROUTS. Every Koyo based machine I worked on used OROUTS everywhere.
In the context of stage, I think they used them to avoid duplicate output warnings and other side effects.
We are of the belief that a RST in $tTopOfScan and SET in the main code works well and avoids the need for special OROUT handling.
-
OK, upon further conversation with the customer, I have a better picture of what they want.
I will running one recipe at a time, based on which recipe the operator chooses. The recipes will have the same code, but an operator will be able to select for each recipe:
1. Which of the 4-inputs will trigger the start of the code.
2. Which of the 4-outputs will be controlled by the code.
3. Whether the code is dependent on a pulse train from an encoder, or time based.
This is for the application of glue to substrate.
So, what would work best for the application; a subroutine, task or program?
-
You don't really need a subroutine.
The decision as to whether to use a program or task is based on two things:
1) Do you need stage? Only supported in program blocks.
2) Who is in control of the execution lifespan? Programs are RUN by the supervisor and then the program terminates itself upon completion with EXIT. Tasks are ENABLED by the supervisor and disabled when the supervisor no long wants that function.
Even without knowing what the recipe is doing, I'd probably be thinking PROGRAM.
The input and output is easy. Just map X[InputNumber] to an internal input variable, and an internal output variable goes back to Y[OutputNumber]. In the attached picture, InputNumber is V0, and OutputNumber is V1. RecipeInput is C300, and RecipeOutput is C301.