STRFIND in a Task

[plcnut]

The simplest answer is to get the beta 1.1 where we have made the edge optional on all the string functions. Can you wait for a few more days?

Bob,
It looks like we have gained a couple of more weeks on start-up. If you're willing, I'd love to do some beating on the beta, I have local I/O only and no human safety or machine safety issues with this system.
Thanks

[plcnut]

I would imagine that the changes to the task termination code you're working on will have fixed this, But I wanted to let you know that the STRPRINT instruction acts different when the task is enabled to run on a time interval versus being edge triggered. My fix was to use a timer on the rung to edge trigger the ENTASK and it works just fine (1 second interval).

Let me know if this has not been covered and I can give more info on my findings.

[franji1]

I would imagine that the changes to the task termination code you're working on will have fixed this, But I wanted to let you know that the STRPRINT instruction acts different when the task is enabled to run on a time interval versus being edge triggered. My fix was to use a timer on the rung to edge trigger the ENTASK and it works just fine (1 second interval).

Let me know if this has not been covered and I can give more info on my findings.

Not sure if this is what you are seeing, but...

When edge triggered, the TASK terminates once it reaches the bottom of the TASK code-block, so on the next scan, it runs termination logic.  When power-flow enabled, the TASK terminates when the "enabling code-block" removes power flow from the ENTASK instruction.  The behaviors are different by design.  Edge-triggered means run once and done.  Power-flow enabled means the "enabling code-block" directly controls the execution (and termination) of the task (even with a non-zero Interval).

[plcnut]

When edge triggered, the TASK terminates once it reaches the bottom of the TASK code-block, so on the next scan, it runs termination logic.  When power-flow enabled, the TASK terminates when the "enabling code-block" removes power flow from the ENTASK instruction.  The behaviors are different by design.  Edge-triggered means run once and done.  Power-flow enabled means the "enabling code-block" directly controls the execution (and termination) of the task (even with a non-zero Interval).

The STRPRINT in a for/next loop will not print an index of zero when power flow enabled. It will print any other index. I have tried resetting the loop toggle bit inside and outside the task but I cannot get it to recognize a leading edge without scanning the STRPRINT twice, unless the task is edge triggered and then I can do it with a workaround.

I guess my other option would be to use a different instruction that is not edge triggered for moving a block of strings from user defined 8 character strings, to SS strings so that a CMore can display them.

I'm open to suggestions...

EDIT: As I look over your post, I still don't understand why the termination would not have run when it is powerflow based, The time was set for 1 second. But still no termination???

[plcnut]

Here is one of my offending loops:

Try C0 and then try C1 and see the difference.

[franji1]

Here is one of my offending loops:

Try C0 and then try C1 and see the difference.

I got it to fail with C0.  I got it to work by modifying the logic.  I think the reason it is failing is because in your implementation, the first time through the FOR loop when power-flow enabled, when the V86 value is 0 and C48 is OFF, and it DECREMENTS V86 (the NOT part of the work in the FOR loop).  Guess what V86 - 1 equals when V86 is 0?  Not -1, but 65535 (V is unsigned).  I'm not sure what the FOR loop does in THAT situation.  I know that it's not good, and I'm not sure why the other worked???

I changed it to use a NESTED FOR loop, where the INNER loop just counts from 0 to 1, and I check for the value of 1 to do the "real" work.  It worked fine (see attached screen shot).  You can probably clean it up and NOT use the second V89 index at all, and just utilize the main V86 loop iterator???

[franji1]

Nope - I was wrong (why it failed).  You are setting C48 before the loop, hence the STRPRINT is NOT seeing an OFF to ON transition (first time through, C48 is ON, so the first time through never executes.

[plcnut]

Nope - I was wrong (why it failed).  You are setting C48 before the loop, hence the STRPRINT is NOT seeing an OFF to ON transition (first time through, C48 is ON, so the first time through never executes.

I realize that trying to subtract from the loop index when it is zero is a bad thing, and so I have set up the logic always make sure that the loop toggle is on when it passes through the loop for the first time. But I can reset the toggle after the NEXT to make sure it is off when the loop completes, or I can reset it in my other logic, it really doesn't matter, the loop does not recognize it as a leading edge if the task is not edge triggered...

[plcnut]

You can probably clean it up and NOT use the second V89 index at all, and just utilize the main V86 loop iterator???

V86 and V89 are two separate indexes, V86 can start out anywhere in a list 3000 indexes long, but V89 always starts at zero in an index that is only 10 long.
This task is for populating a CMore screen from a "Virtual database" in the DoMore

I am running out of memory in the DoMore and so instead of having a separate tag for each item on my HMI, I reuse the same tags on different HMI screens, and then by controlling the screens from my PLC I can place the matching data into the memory locations that the operator wants to see. It would be MUCH simpler if I could do a MOVER or MEMCOPY to get the string data moved around, but I am stuck with STRPRINT because of the differing string lengths...

[franji1]

I would stick with the nested FOR loop.  It works.  I would not try to make your inter-TASK state behavior "work" (i.e. making sure on the LAST time through the loop on the LAST time the TASK executed, the STRPRINT power flow was OFF).  Hacking the FOR loop index from within the loop is usually NOT a good thing.

Similarly, if you try to use C48 initially be OFF, then you run into the 65535 FOR loop problem due to the FOR loop index hacking from within the loop.

Hence, just use the nested FOR loop.  It works, is straight forward, and there's no loop index manipulation going on.

[franji1]

V86 and V89 are two separate indexes, V86 can start out anywhere in a list 3000 indexes long, but V89 always starts at zero in an index that is only 10 long.
This task is for populating a CMore screen from a "Virtual database" in the DoMore

I am running out of memory in the DoMore and so instead of having a separate tag for each item on my HMI, I reuse the same tags on different HMI screens, and then by controlling the screens from my PLC I can place the matching data into the memory locations that the operator wants to see. It would be MUCH simpler if I could do a MOVER or MEMCOPY to get the string data moved around, but I am stuck with STRPRINT because of the differing string lengths...

I see that now (V89 usage).  That's what I used anyway, so it definitely makes sense to NOT eliminate V89.

[plcnut]

Thanks Mark,
The nested loop is a much cleaner workaround for the edge triggered instructions. I'll go back over my other loops and see if I can use it to smooth them out as well. (wish I could think like you guys)