Too much scanning going on. Programming question.

[ERokc]

My previous non-PLC programming experience had me polling for inputs and using hardware interrupts to the processor trying not to miss an input.

Now I find myself trying to not process every line (rung) continuously.  It's making my head spin. I keep looking at the code to see if actions are going to happen every scan and yes they are.  Don't want that all the time!

Programs and tasks are going to help control that but within a program or task can I use a GOTO LABEL (LABEL above the GOTO) to keep other rungs from being scanned?

I'm thinking as long as the loop is active everything outside the loop is NOT scanned except in $Main.  Is that correct?

As soon as I get more comfortable I'm revisiting STAGE programming.  I get a feeling it will be a bit simpler than RLL.

[BobO]

Your undertanding is good. It'll take time, but eventually concurrency will start to make better sense and you'll manage it fine.

As you suspect, while staying in a loop, code in that module that is outside the loop doesn't solve. Code in other modules is not affected. Don't try what you are suggesting in $Main.

Just a few things to remember as you do this:
1. PLCs are fundamentally concurrent in their execution. This is because they were originally invented to approximate electric flow. Over time, they crossed over into more of an embedded controller, but they are still inherently concurrent.
2. Use Tasks and Programs to modularize your code, starting and stopping those modules as they should or shoudn't run.
3. Use Stage to manage sequence. Since PLCs are concurrent, they don't do seqeunce very easily. Stage was created expressly to manage sequences.

On the subject of Stage, I personally wouldn't wait. Much of what you are struggling with is due to concurrence...you are looking at ways to circumvent that. Don't. Use Stage, that's what it's for.

[ERokc]

In $Main I put INIT for first scan only to intitalize variables.
I thought I would put operator buttons (non HMI) in $Main so they are always read.  At least STOP and E STOP.  E STOP is hard wired to motor control also.

Then I need a main menu on the HMI to select product to make and other settings and start the machine.

So from an HMI menu a selection would set a bit that is being scanned in $Main that would RUN a program?
If that bit is not reset would $Main RUN another occurrence of the program or does the program need to reset the bit on execution?  What keeps it from running and rerunning?  The button will be closed for many scans before the operator releases it.  I'm not understanding the sequence.

Sequence ....... Stage ...... I'm going to study Stage now.

[BobO]

Program blocks are RUN by the *rising edge* of the input to a RUN box, and will continue to do so every scan until they terminate by calling EXIT. Think of a program as executing some kind of self-terminating operation. The operator tells it to do something, and it runs until complete.

Task blocks are ENABLED to run either one time by the rising edge of the input leg of the ENTASK box, or to run continuously (optionally at an interval) as long as the enable is held on. If I needed to run some kind of computation every time a switch was flipped, I might use the edge version. If I wanted a temperature control block to run all the time as long as the switch was on, I might use the latter.

Within the context of a program block, the self-terminating operation I spoke of might require a sequence of operations: Do step 1 until condition 1 is met, then do step 2 until condition 2 is met, then EXIT. That is what Stage programming does very well.

Your code needs will dictate which of these you need to use, and how they are enabled to run. If these concepts are causing you some grief, I'd really suggest getting some training. PLCs are not particularly hard, but it is definitely a different way of thinking about the problem.

[Stephen]

Sequence ....... Stage ...... I'm going to study Stage now.

ERokc, AutomationDirect put together a series of videos to help people get started with Do-more. Here's one on stage that may help a bit. http://www.aboutplcs.com/do-more/support/VidStage.html

[ERokc]

Absolutely, STAGE helps segment to code, I like it.  Got questions on when an instruction executes and how to return to $Main.

In an active stage a CTREGRD instruction which is edge triggered needs what in the power rail to execute once?

I'm guessing a differential contact addressed to $On. Does $On go from OFF to ON when the stage goes active? Probably not because it always ON.
Would a direct connect to power rail (no contact) to the instruction do it or would it trigger it every scan or never trigger?

I don't see how to create only one low to high edge.  I know the answer is simple, just don't know what it is!

How about MOVE which is not edge triggered, how to do one move only? Or should I have those in their own stages and no pending condition that would create a loop?

The examples for stage programming are simple and don't address anything but OUT & SET type instructions.

Examples don't return to the calling program either.  Do you EXIT when the last stage is done to turn off the stage and return to the calling program?

[BobO]

Absolutely, STAGE helps segment to code, I like it.  Got questions on when an instruction executes and how to return to $Main.

'Return' implies a call. Blocks are not called they are enabled. Logically speaking, the entire program is evaluated every scan. We start at the top, and as we come to a program or task block, we check to see if it is scheduled to run this scan. If so, we then check to see if it was suspended from a previous execution (like might happen with a loop) and we resume at the yielded instruction or start at the top as appropriate. We then execute that block to the end, or if looping, until the time slice is expired. If a task or program block is not scheduled, we skip over its code.

Within program blocks, you can have stages. Stages are like mini-tasks, such that when we come to a stage, we determine whether it is enabled, and execute it or skip over it. When you jump from a stage to another stage, that isn't a call, it just disables the stage you are on, and enables the stage you are jumping to.

In an active stage a CTREGRD instruction which is edge triggered needs what in the power rail to execute once?

Just connect it to the power rail. When the stage is energized, the edge instruction will run one time. It is not necessary to put any additional logic.

I assume you are using CTREGRD as an example only. As I mentioned, I seriously doubt that you should be using it.

I don't see how to create only one low to high edge.  I know the answer is simple, just don't know what it is!

For any instruction that shows the clock edge, it is already internally edge triggered, so you don't need to do anything. Clocked edges are indicated with the triangle on the input.

Where you need to create an edge, you can use a rising or falling edge contact...try pressing Shift+F2 or Shift+F3, or you can insert an edge conversion into the result of a non-edge rung...from the instruction pallet they are at the top under 'Contact Power Flow' and are ovals with rising and falling clocks, or you can use PD or ND boxes.

How about MOVE which is not edge triggered, how to do one move only? Or should I have those in their own stages and no pending condition that would create a loop?

It will perform the move every scan it is run and enabled. If you want to do it just one time, either one-shot the input, or put it in some code element that is run and then disabled.

The examples for stage programming are simple and don't address anything but OUT & SET type instructions.

Stage is all about sequencing. It doesn't take complicated instructions to understand how it works.

Examples don't return to the calling program either.  Do you EXIT when the last stage is done to turn off the stage and return to the calling program?

Nothing is ever called, hence never needs to return. It is enabled or disabled to run. When you run a Program block, it continues to run every scan until EXIT is called. If you want to stop it, just call EXIT.

[ERokc]

BobO, thank you very much for the explanations. NOW I understand the "enable/disable" of program blocks and the concurrent execution of one or more blocks. Stages definitely make it easier to write and read. Concurrent execution gives me much needed functionality not previously available to me.

I got a couple more questions. If I start a program block with the first rung not in a stage then follow with the rest of the block in stages will the first rung be enabled on every scan or just the stage that is enabled? Is this bad practice?

You say don't use CTREGRD. Why? I need to read the quad counter, store it, delay (about 3sec.), read again, compare to see if the conveyor is moving. I do loop for "On Success" before reading again as described in the module structure.

Memory allocation; I have been taking successive addresses (C0, C1, etc.) for assigning bits.  I seem to remember that retentive memory needs to be in contiguous blocks.  At this point I don't know what I want retentive so should I reserve a block of each type for that purpose?  Any suggestions on assigning addresses is welcome.

While on memory I find it difficult to change an address for a defined location, ie. Keep nickname, desc. etc. and change say C5 to C20.  Is there a way to change the address without deleting all of one and entering it again?  This might not be important as the nicknames are listed in alpha order so who cares if the addresses are successive, except for retentive blocks.

Next is using the simulator, can't wait to see if it executes like I intend.  That brings up another question, will the simulator simulate asynchronous modules like CTRIO2?

[BobO]

BobO, thank you very much for the explanations. NOW I understand the "enable/disable" of program blocks and the concurrent execution of one or more blocks. Stages definitely make it easier to write and read. Concurrent execution gives me much needed functionality not previously available to me.

Glad to hear that it is starting to make sense.

I got a couple more questions. If I start a program block with the first rung not in a stage then follow with the rest of the block in stages will the first rung be enabled on every scan or just the stage that is enabled? Is this bad practice?

Rungs prior to the first stage are always enabled. That is actually a very useful and effective thing. Not bad programming at all.

You say don't use CTREGRD. Why? I need to read the quad counter, store it, delay (about 3sec.), read again, compare to see if the conveyor is moving. I do loop for "On Success" before reading again as described in the module structure.

Because it is already in the structure associated with the quad counter. The module driver is already reading it from the module every scan...it's already in the CPU. Please go back and review my post about iReg1...that's where the quad count value will be stored.

Memory allocation; I have been taking successive addresses (C0, C1, etc.) for assigning bits.  I seem to remember that retentive memory needs to be in contiguous blocks.  At this point I don't know what I want retentive so should I reserve a block of each type for that purpose?  Any suggestions on assigning addresses is welcome.

Unless you specially don't want something to be retentive, I'd just set the whole block to retentive. As for address assignment...I usually don't. If you plan on giving your variables good names, which you should, you can just type a name in a field. Designer will prompt to create a nickname, and one of the options is for it to automatically allocate the first unused location of a specified type. Very handy.

While on memory I find it difficult to change an address for a defined location, ie. Keep nickname, desc. etc. and change say C5 to C20.  Is there a way to change the address without deleting all of one and entering it again?  This might not be important as the nicknames are listed in alpha order so who cares if the addresses are successive, except for retentive blocks.

Again, I don't generally worry about the actual address. If you do want to separate retentive and non-retentive I would probably just allocate a different block for each, as you mentioned before.

Next is using the simulator, can't wait to see if it executes like I intend.  That brings up another question, will the simulator simulate asynchronous modules like CTRIO2?

Sorry, no. It's something that we have talked about, but it's a pretty big effort. It is still a pretty useful tool for testing logic behavior. It implements the same engine as hardware, so it's not so much a simulator as a virtual PLC.

[ERokc]

BobO, I can't believe it, I don't have any questions today.  My conveyor HOME program went from 19 rungs, (7 stages) to 10 rungs, (3 stages).  I went back to the previous topic you wrote on CTRIO and it makes sense now. Thanks again for your help. I'm off the ground and climbing on the learning curve.

I'm going to connect up enough devices to run it and see if it does what I intended it to do.

You guys at Host have done an excellent job on Do-more.