Subroutines in DMD.

[BobO]

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.

[Todd Dice]

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?

[BobO]

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.