STRFIND in a Task

[franji1]

Yeah, I was going to mention the inline-power-flow-based leading edge and trailing edge contacts (see the Contact Browser F4 or the Instruction Palette on the Ladder toolbar or Edit->Instruction Palette).  The inline-power-flow-based contacts are not on the Ladder toolbar (there are 3 of them, leading edge, trailing edge, and invert) cuz we ran out of room.

See the attached set of rungs.  Rungs #1 and #2 are equivalent to Rung #3.  So you can do power-flow based one-shots without burning a CR by doing it like #3.

[Controls Guy]

So you can do power-flow based one-shots without burning a CR by doing it like #3.

And as (more?) importantly, the intent of the rung with the in-line is instantly decodable in one single glance.

[franji1]

The only time I would consider doing it the "old way" is if I had multiple rungs throughout my program that needed this "one shot" information.  Typically, though, it is only needed in that one place.

[BobO]

The only time I would consider doing it the "old way" is if I had multiple rungs throughout my program that needed this "one shot" information.  Typically, though, it is only needed in that one place.

Yes, for creating an 'event'. Of course the inline with an OUT does the same thing...so...I guess it is really just about 'respecting the legacy'.

[Controls Guy]

The only time I would consider doing it the "old way" is if I had multiple rungs throughout my program that needed this "one shot" information.  Typically, though, it is only needed in that one place.

Me too, or almost the same.  What I'd do is

Wad-O-Logic--------OUT C0

Then give C0 a good description and use C0 one-shots throughout the ladder, rather than having C0 be a PD itself.  Never really warmed to the PD.  Using OUT in conjunction with OS contacts gets you maintained, leading edge, AND trailing edge, plus hinting at the intent in the rung where used.  PD gets you......leading edge.

[b_carlton]

Regarding the Leading Edge and Trailing Edge contacts. In the DL world this construct compares the current state of the argument with the recorded state (not an addressable piece of memory) of the argument AT THE END OF THE PREVIOUS SCAN. If the argument is a bit affected by logic, as opposed to an input, the the Differential Contact only had a valid use from the point of the affect to the end of the scan. It is not valid to use the DC for this argument on the next scan before the point of the affect.

So the question is, where is the previous state of the argument for Leading Edge and Trailing Edge contacts held? When is it stored?

Here's a link to information
http://support.automationdirect.com/docs/strpd.pdf

[BobO]

So the question is, where is the previous state of the argument for Leading Edge and Trailing Edge contacts held? When is it stored?

Nothing complicated. It is stored in special edge memory...which is essentially just control relays, but is hidden and managed by DmD. The condition is evaluated at the time of execution of the instruction...basically like this:

  if(CurCondition && !PrevCondition)
    {
    Do stuff...
    }

  PrevCondition = CurCondition

Like most of the things we do at Host, it is simple and it works.

[b_carlton]

Thank you. The 'feature' in some of the DL CPUs had bitten some.

[ATU]

Early on, I remember when I was trying out the TCP/IP client, I had a problem with the STRPRINT instruction. It took me a while before I noticed it was edge triggered. I felt stupid that I didn't see that right off, but I remember having to add several stages to work around it. I didn't say anything, because I assumed that's "just the way it is" and had to deal with it.

BTW, Happy New Year!

[plcnut]

I'm having a time with this one. I have a STRCMP in a FOR/NEXT loop that is nested 4 loops deep in a task. I am using a loop toggle inline with the STRCMP and it works fine the first time through, but then I have a problem after that; I cannot get it to compare when the index is at "0". I know it has to do with the edge trigger.
Please explain to me exactly what it is that the instruction needs to see to trigger it.
I don't know if I need to add an extra SET and then a RST on the toggle bit before the instruction or what.

I have attached a screenshot of the innermost loop. The toggle is set "On" immediately before the loop.

[BobO]

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?

[plcnut]

Yes. The ball is not in my court right now, but if all goes well this system should be running early next week.

[BobO]

Ah...well, bein as this is beta, I'd rather not see you depend on it for a deployed system in the near term. The instruction improvements are pretty simple, but we have done a bunch of work with the new expansion I/O. It really needs to be wrung out before going on a machine.

[plcnut]

Ok. The only place the loop has a problem is with comparing to index 0 of the table. I have inserted a string in index 0 that will never be used so that the dynamic portion of the table starts at index 1.

The part that really bothered me was why it was doing it, but when I went back over this thread and re-read the termination logic issue, it explains the problem I'm having so I will work around it.

[BobO]

Yes. The TASK termination code will cause issues with edges. It's fixed in the current code...but again...given the big changes for the Ethernet Expansion I/O, I don't feel great about this for anything but the lab. We'll get it proven and shipped pretty quick, but not before you commission.