Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: plcnut on December 26, 2012, 05:14:40 PM
-
I have a STRFIND inside of a task that is called multiple times from different stages in another program block. The STRFIND only works when it is called from the first stage, and each subsequent call it doesn't set either of the delimiter found/not found flags. It appears this problem also exists with other edge triggered instructions as well. In the attached example I tried to get a simple STRPRINT to work.
Please help me with how to make an edge triggered instruction work properly on each call in the top of a task. I am probably just missing something simple, but right now I just can't see it.
Thank you
-
Interesting. I had to study this one for a few minutes to figure it out, but I think I may know what is going on.
Programs, Tasks, and Stages all execute special logic on the scan following their completion. We call this 'termination'. Stage 1 gets the .Done indication and immediately jumps to Stage 2, which then re-arms the task to run. It appears that the termination logic is not running for the task prior to running the task a second time. One of the things that termination logic takes care of is edge states for edge triggered instructions. I reversed the order of stage execution, to execute the bottom stage first and then jump to the prior stage...which gives the termination a chance to run by inserting an extra scan between Stage 2 running the task and Stage 1 running it the second time...and it worked fine.
Truthfully? It sounds like a bug. I gotta scratch my head to see what it will take to fix it, but it may be pretty simple.
-
Yep...a brief study of the code agrees with my prior guess. Termination isn't running. Now just gotta figure out what to do about it... :-\
-
Thanks Bob!
Anxiously awaiting a fix ;D
-
Anxiously awaiting a fix ;D
Sounds like the short-term workaround is to have consecutive tasks (if they're always consecutive in the same order) in reverse order in the list. That way an extra one-scan delay is imposed when switching which fixes the problem. At least, if I was interpreting BobO's post correctly.
If the order isn't consistent, put a timer between each task pair (or just preceding each task) to enforce a short wait, 10ms or something. That should do the same thing, as long as the task isn't nominally running while it waits for the timer expiration.
-
Another work-around is to add an intermediate stage after the task is .Done that looks to see when .DoneThisScan is FALSE (i.e. NC CONTACT) along with a JMP to the next stage that has an ENTASK in it.
See attached screen shot.
-
It works perfectly with the .Done and NOT .DoneThisScan both on the rung with the JMP.
Thank you!
-
It works perfectly with the .Done and NOT .DoneThisScan both on the rung with the JMP.
Cool! Even better!!
-
I have a fix...but...we weren't planning on releasing new bits until DmD 1.1. Made worse by the fact that some stuff is in flux right now. I could probably cobble together something without too much pain, but it would need to go through some testing before we could release it. I completely understand the problem...it isn't scary...it just means that if you re-arm an edge-triggered task to run prior to running termination, termination doesn't happen. Verifying both .Done and !.DoneThisScan means that termination ran...and should be a very clean workaround. If you are happy with that for now, I won't push immediate release.
-
I would run into the same type of problem in the DL Stage logic with timers. If the finish of a timer triggered the JMP out of a stage but the stage was re-enabled on the next scan the timer hadn't reset. Because I needed the stage structure as I had it I just added resets of the timer in the calling routines alng with the JMP.
-
If you are happy with that for now, I won't push immediate release.
I'm happy, The workaround is quick, easy, and reliable. :)
BTW, I'm amazed at how FAST this thing(H2-DM1E) is!
-
I would run into the same type of problem in the DL Stage logic with timers. If the finish of a timer triggered the JMP out of a stage but the stage was re-enabled on the next scan the timer hadn't reset. Because I needed the stage structure as I had it I just added resets of the timer in the calling routines alng with the JMP.
I believe that. The resets occur as part of termination, which doesn't happen until the next scan, but the next stage (if it follows the first) happens immediately. I could probably run the termination at the time the stage is jumped out of. Not sure if there are any side effects, but it probably wouldn't be hard to do.
-
I believe that. The resets occur as part of termination, which doesn't happen until the next scan, but the next stage (if it follows the first) happens immediately. I could probably run the termination at the time the stage is jumped out of. Not sure if there are any side effects, but it probably wouldn't be hard to do.
It's best to leave it how it is. You can reset stages, not just JMP out of them. This is also consistent with Task and Program termination (termination is done on the next scan).
-
Yeah...stages would be hard. Tasks and programs would actually be the easier case, the termination could be performed in the TEND and PEND instructions. I would only consider doing it if I could do it everywhere, and without side-effects. I would also only consider doing it because it could potentially fix some of the possible confusion...make it work like I think it should without caveats. That said...I find this kind of change scary. So many possible gotchas...
The initial problem was easy to fix though. It just involved moving the termination test to the top...which is how it already was in Program.
-
How do I make an edge triggered instruction work properly inside a For/Next loop?
I am trying to assemble a response back to a web server by using the STRPRINT instruction, and appending all the data into a string, it is simple to do in a for/next by using the loop index to increment through the data as I pack it in. The loops lose a lot of their attractiveness when I cannot perform these type of tasks inside of them...I know I can use a loop toggle bit, but then I have to do math on the index outside and inside the loop, which makes a mess quick.
Any advice for me on this?
-
I came up with this, and it seems to be working ok:
-
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? ;)
-
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?
-
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.
-
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.
-
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... :)
-
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.
-
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.
-
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.
-
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! :)
-
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??? ;D).
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").
-
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??? ;D).
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.
-
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.
-
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.
-
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! ;D)
-
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.
-
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.
-
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.
-
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'. ;)
-
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.
-
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 (http://support.automationdirect.com/docs/strpd.pdf)
-
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.
-
Thank you. The 'feature' in some of the DL CPUs had bitten some.
-
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!
-
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.
-
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?
-
Yes. The ball is not in my court right now, but if all goes well this system should be running early next week.
-
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.
-
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.
-
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.
-
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
-
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.
-
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).
-
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???
-
Here is one of my offending loops:
Try C0 and then try C1 and see the difference.
-
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???
-
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.
-
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...
-
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...
-
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.
-
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.
-
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) :D