STRFIND in a Task

[plcnut]

I came up with this, and it seems to be working ok:

[BobO]

Nice hack, but you shouldn't have had to hack it.

Truth is, there isn't really a great reason for STRPRINT to be edge triggered. It is left over from an intermediate design when the print instruction went directly to a stream output device...basically STRPRINT + STREAMOUT. We changed the design and honestly forgot to remove the edge until very late in the release cycle...and by then it was too late. It still has some merit I guess, because STRPRINTs are quite slow, and the edge makes you 'mean it'. But you are using the instructions in ways that are well within the design intent...and they should work.

We can fix it by making the edge optional, and we will look at doing that for DmD 1.1. I don't actually think it would be that hard, but I'll talk to Franj when he gets back. It won't help you for what you are doing now, but should be there for your next app...which is hoping that Do-more wins a second use in spite of these hiccups.

So where were you when we were during beta test?

[Controls Guy]

I came up with this, and it seems to be working ok:

Don't you lose every other loop that way, in effect making Step == 2?  Or is that the intent?

[BobO]

Twice as many loops are required to clock the edge of the STRPRINT. He really doesn't want STEP 2, he just wants two loops for each STEP 1.

[plcnut]

Don't you lose every other loop that way, in effect making Step == 2?  Or is that the intent?

No, that is what the MATH is for, is subtracts one from the index every other loop.

[plcnut]

So where were you when we were doing beta test?

I was right here checking your site almost every day to see when your new controller was coming out... 

[Controls Guy]

No, that is what the MATH is for, is subtracts one from the index every other loop.

Ah, OK, very slick!  

Interesting that the FOR loop doesn't mind you messing with the index.

[BobO]

Interesting that the FOR loop doesn't mind you messing with the index.

Minimal internal state, maybe none...I can't remember.

Loops need to be simple stateless branching implementations to allow time-slicing to work correctly, especially when you start throwing in nesting. Doesn't hurt that it ends up working like a C for loop, allowing index adjustments on the fly.

[BobO]

I was right here checking your site almost every day to see when your new controller was coming out... 

Yeah, well, ADC managed the beta program and we had very little input into the participants. Which is not a knock on them or anyone else anybody, it's just that hanging around here wasn't part of the criteria for inclusion. Given the way you are using the product, it would have been great to have you involved.

Your issues hit on the core of why beta programs are so necessary though. There are two major considerations when determining product fitness: 1) does the product work like it is supposed to, and 2) does the product do the job it is intended to. We made many, many design changes during development, specifically because we determined that while functional, certain things weren't as elegant as we hoped. Ironically, the STRPRINT edge issue was the result of completely refactoring strings and comm. The result was very sexy, and the absolutely correct thing to do...unfortunately one small thing got dropped.

The good news is that it is very easy to fix and 1.1 will support the dual mode STRPRINT.

[Controls Guy]

Loops need to be simple stateless branching implementations to allow time-slicing to work correctly, especially when you start throwing in nesting. Doesn't hurt that it ends up working like a C for loop, allowing index adjustments on the fly.

Yup!   

[franji1]

Should be relatively easy to do (we do it for ENTASK).  We may want to visit other "edge triggered" instructions and double check to see if we need to make them optionally be power flow based.  Alternataively, we could look at other power-flow based instructions and make them have the option to be edge triggered (e.g. MATH), although I have not heard of this from anybody (anybody out there want to provide opinions for/against???  ).

I don't want to tweak the instruction set every release, cuz it will make for lots of consistency issues between Designer versions vs. CPU firmware versions (i.e. "you cannot download this project to the PLC cuz its firmware does not support the instruction feature XYZZY", or whatever).

Oh, and then there's the opposite issue, uploading a power-flow STRFIND with an old version of Designer ("sorry, we cannot upload this project because of XYZZY").

[plcnut]

Should be relatively easy to do (we do it for ENTASK).  We may want to visit other "edge triggered" instructions and double check to see if we need to make them optionally be power flow based.  Alternataively, we could look at other power-flow based instructions and make them have the option to be edge triggered (e.g. MATH), although I have not heard of this from anybody (anybody out there want to provide opinions for/against???  ).

I don't want to tweak the instruction set every release, cuz it will make for lots of consistency issues between Designer versions vs. CPU firmware versions (i.e. "you cannot download this project to the PLC cuz its firmware does not support the instruction feature XYZZY", or whatever).

Oh, and then there's the opposite issue, uploading a power-flow STRFIND with an old version of Designer ("sorry, we cannot upload this project because of XYZZY").

Generally, If I need edge based I will use a Rising edge/falling edge contact, or a PD coil, so unless there is a reason that an instruction should ONLY be edge triggered, I would prefer to control powerflow in rll rather than have it built into the instruction.   

[BobO]

Should be relatively easy to do (we do it for ENTASK).  We may want to visit other "edge triggered" instructions and double check to see if we need to make them optionally be power flow based.  Alternataively, we could look at other power-flow based instructions and make them have the option to be edge triggered (e.g. MATH), although I have not heard of this from anybody (anybody out there want to provide opinions for/against???

It very easy for the user to create edge-based behavior with logic. I would tend to use edge-based in the instruction only when there are very good reasons to do do...ENTASK being a very good example. The only reason I would even maintain the edge behavior for STRPRINT is compatibility.

I don't want to tweak the instruction set every release, cuz it will make for lots of consistency issues between Designer versions vs. CPU firmware versions (i.e. "you cannot download this project to the PLC cuz its firmware does not support the instruction feature XYZZY", or whatever).

Oh, and then there's the opposite issue, uploading a power-flow STRFIND with an old version of Designer ("sorry, we cannot upload this project because of XYZZY").

I wouldn't even have proposed it at all, but as far as I'm concerned, STRPRINT is functionally crippled with the edge. If you will recall, we noticed this a couple of weeks prior to launch, but were so concerned with the documentation getting done and the product launched on time we chose not to rock the boat. At the time I wasn't of the mind that it was that big a deal, but this app example showed the flaw in that logic. <yes, pun intended>

I do agree that we should run through the instruction set and see if there are any other edges lurking around that should be considered. If it is already edge triggered and there are already options in the instruction, it only takes me about 10 minutes to mod the code. DmD will obviously be more work, and we will have to ask the larger question of how we want to deal with compatibility...but we already need to ask that for the PUBLISH/SUBSCRIBE options we extended.

[BobO]

Generally, If I need edge based I will use a Rising edge/falling edge contact, or a PD coil, so unless there is a reason that an instruction should ONLY be edge triggered, I would prefer to control powerflow in rll rather than have it built into the instruction.   

I agree with this. I think the only strong justification for putting it into the instruction is for functional reasons...and other than performance, STRPRINT is not a functional issue.

[Controls Guy]

Generally, If I need edge based I will use a Rising edge/falling edge contact, or a PD coil, so unless there is a reason that an instruction should ONLY be edge triggered, I would prefer to control powerflow in rll rather than have it built into the instruction.   

Agreed.  Or the new inline one-shot!  (Nice to have one of those!   )