CTAXLIMT: need limit to be a true or false (not edge triggerred).

[CMDRMOORE]

I have an application that requires that I turn one direction until limit, then continue a set number of counts. Sometimes the limit is already reached, so I only need to run the set number of counts. Simple light on/off detection.
Application:
I move a belt until the object on the belt blocks the sensor, then continue to move a few counts more. Sometimes the object is already blocking the sensor and I just want to move the set number of counts from there.
Edge trigger for the first limit, does not work since the sensor has already detected the part, so the belt keeps moving. If there was a choice for just on or off, the first limit condition would be met and then the second limit (set counts) would be activated.

Any suggestions, other than multiple CTAXLIMT boxes?

[BobO]

I guess I would just check the limit state first, and then do a CTAXTRAP or CTAXLIMT as appropriate.

[CMDRMOORE]

That is what I am currently doing. This takes the use of a coil bit, since the sensor input is on CH1C and will just cause a toggle between the two boxes.
 This is a TASK in my DO-more code and it is a bit large with these two boxes, plus there is one more box I did not mention.

(Visualize an inch worm.)
If his back is already hunched, push his head back to hunch it a little more.(Trap.)
If it is not hunched, then push its head back until it is AND then hunch it a little more.(LIMT)
The part I did not mention is that now that he is hunched, pull his head forward until he is straight. (Second, opposite direction LIMT)

If I set up a profile within the H2-CTRIO2, I can get the state trigger. I was just hoping that I could do it in the CTAXLIMT box as well. This would cut it to just 2 LMT boxes.

[BobO]

...This is a TASK in my DO-more code...

Have you considered using a Program block and Stages? You can do it in a Task...with care, but the Stage code makes it clean, sequential, and well organized.

[plcnut]

You can do it in a Task...with care, but the Stage code makes it clean, sequential, and well organized.

^^Agreed.^^
A program with Stages would make a lot more sense. Set up a monitoring stage that checks whether your Limit has been made, and then JMP into the correct sequencing stage.

[CMDRMOORE]

Yes, OI considered it.
The "machine" advances a belt. Several stations along the belt do tasks that they just repeat every time the belt stops. Station 1 puts a block on the belt at a precise location (spacing controlled by belt advance).
Station 2 puts a sticker on the block. Station 3 flips the block over. Station 4 does the task that we discussed, to make sure that the belt is fully tensioned making the block perfectly horizontal for another task (stenciling the surface).
I treat all of the stations as tasks.
I use the program $Main to select different programs that have different belt advance distances, stickers, and the correct stencil plates and sometimes not use a task or two.
(I will probably use a recipe sheet in the HMI for this, although I can just use a button to select the program I wish to run.)
The programs control when and if each task should run.

Am I doing this incorrectly? I thought "tasks" were repeated again and again within a "program".

[BobO]

Correctly? There's no right or wrong, but some things lend themselves to certain programming approaches better than others.


We may be fighting terminology...

A Task is a code block that is enabled to execute through the ENTASK instruction.

A Program is a code block that is enabled to execute through the RUN instruction.

You could do this with either, but Program blocks give you the advantage of using Stages to create sequences. High level async instructions like the CTRIO instructions have the ability to automatically jump to a specified stage upon completion of the operation. For any operation that is a "do this until done, then do that until done, then do the other", stages are the cleanest and most straightforward way of doing the logic.

If you think in terms of enabling a concurrent piece of logic that doesn't require sequencing, a Task is preferred. You might have a Task that controls a temperature and associated alarming, that would be enabled from some other piece of logic.

If you think in terms of running an asynchronously executing standalone operation with multiple states, like running a comm protocol or a complex motion sequence, a Program with Stage is preferred. It steps through the sequence, and when complete, it EXITs. The supervisor RUNs it and then monitors the completion status through the Program block's .Done bit.

Again, no right or wrong...just ideas to make it cleaner. I was mostly just responding to your desire to simplify the code.

[CMDRMOORE]

OK. Thanks.
Any chance of the CTAXLIMT being updated to include states as well as the triggers?

[BobO]

OK. Thanks.
Any chance of the CTAXLIMT being updated to include states as well as the triggers?

It would be a firmware change to the CTRIO2. I can look what it would take, but changing the behavior always makes me nervous.