Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: Mike Nash on December 31, 2016, 11:34:33 PM
-
This works:
Math R25 IF(R25 != R20, IF(R20 > R25, IF((R25 + (((0.0001 * (D120 - D121)) / R21))) < R20, R25 + (((0.0001 * (D120 - D121)) / R21)), R20), IF((R25 - (((0.0001 * (D120 - D121)) / R22))) > R20, R25 - (((0.0001 * (D120 - D121)) / R22)), R20)), R25)
This won't "take".
Math R25 IF(R25 == R20, R25, IF(R20 > R25, IF((R25 + (((0.0001 * (D120 - D121)) / R21))) < R20, R25 + (((0.0001 * (D120 - D121)) / R21)), R20), IF((R25 - (((0.0001 * (D120 - D121)) / R22))) > R20, R25 - (((0.0001 * (D120 - D121)) / R22)), R20)))
I don't understand why though. It took me a long time to realize it didn't like the order. I prefer the == because I thought it might be faster if no ramp is happening.
Simplified
If(A!=B,If(etc.),A) is OK
If(A==B,A,If(etc.)) is No Go.
Why?
Just in case you are wondering, it's supposed to be a ramp. R20 input, R25 output, R21 Accel Time, R22 Decel Time, D120 Current TICKus, D121 Previous TICKus. I was having real timing issues trying to use a timer - 22.xx seconds to do a 20 second ramp. Real Do-more with some serial comms and VPN for me to program/monitor. I have used this concept with D2-260 and D0-06 before with the scan time, but it is actually cleaner in DL because the scan time is a single Vmem and I don't have to do the new-previous steps and math. This is quite ugly - I was hoping for a single instruction.
I think this will be going into the Dancer Simulator for the undesirable drive following lag. My most consistent trait is inconsistency as this will be the third excuse for a linear ramp in that little program.
RAMP HINT HINT HINT :D Eagerly awaiting DMD 2.0 to see what we get to play with.
Happy New Year folks!
Edited 11:18PM CST Sorry to those who have seen this already, but I have had to correct some things, namely, while TICKms was working fine, it is too crude a resolution for Do-more's fast scan times so I replaced it with TICKus and cleaned up the math to get rid of the extra multiply for clarity (I had a good reason for it!).
Secondly, it was niggling in my brain that DST4 $ElapsedTicks had been mentioned by BobO as being what I wanted, but I didn't find the post and the help file doesn't really sound like it. I did just test a SINGLE INSTRUCTION Ramp that works perfectly:
MATH R25 IF(R25 != R20, IF(R20 > R25, IF((R25 + ((0.0001 * DST4) / R21)) < R20, R25 + ((0.0001 * DST4) / R21), R20), IF((R25 - ((0.0001 * DST4) / R22)) > R20, R25 - ((0.0001 * DST4) / R22), R20)), R25)
I like it!
BTW, the reason it is so involved is to prevent the output from oscillating around the input value as can happen without the extra tests.
-
I think DM equality test operator is a single equal, not double (just from memory).
-
I think DM equality test operator is a single equal, not double (just from memory).
Never trust a squishy flesh memory is my new motto. I verified == is correct by simplifying first and then adding. I have been bitten too many times now by == != and ** that I go look it up every time now.
I edited the first post BTW with important updates for the last hour of 2016 in my time zone. Single instruction linear ramp!
-
Yeah, I know what you mean about the meat memory (as my post illustrates)! ;D
-
I need to understand this ramp concept more. On our small waste treatment plant we change flow rates based on tank levels. Proportional isn't desired because the tank level can change suddenly upward and its purpose is flow equalization. But the biological process gets upset when we step from one flow rate to another up or down. A slow ramp would really help the situation but I didn't know how to code it.
-
MATH R25 IF(R25 != R20, IF(R20 > R25, IF((R25 + ((0.0001 * DST4) / R21)) < R20, R25 + ((0.0001 * DST4) / R21), R20), IF((R25 - ((0.0001 * DST4) / R22)) > R20, R25 - ((0.0001 * DST4) / R22), R20)), R25)
R20 is your desired setpoint.
R21 is how much time in seconds you want it take to go from 0 to 100
R22 is how much time in seconds you want it take to go from 100 to 0
R25 is the ramped output.
If R21 is 180 and R20 is 50 and so is R25, if you change R20 to 100, it will take 90 seconds for R25 to reach 100 because the change of 50% will take 50% of 180 seconds.
You can scale the input and output to whatever you want (same units) either by changing the 0.0001 in the MATH instruction in 4 places or scale them externally and let the MATH be % in and out.
It's a simple concept - how much do I need to add or subtract each scan to move the output toward the input. The (scan time/ramp time)*(max value) is that value. The other comparisons are to keep it from hunting once it gets there.
Edit to fix the simple concept equation to include *(max value)
-
I basically did this by writing a subroutine that my program entered into when the current speed no longer equaled the setspeed. It determined the amount of change, broke it into small pieces for adjusting over a set period of time, then used a timer and pulses to slowly ramp the output over the desired amount of time. A function with a few input values would be wonderful for this sort of thing. I never considered using the scan time to break it into super small chunks.
-
I was finding the timer and pulses to be taking up to 10% longer than intended on a real PLC if the timer was too small a value (10-25ms). I am just guessing that is due to other routines and VPN ethernet comms from DMD.
I discovered a glitch with my instruction last night. A zero value for a ramp results in no output change. Either it needs to be non-zero or another condition needs to be added. I find myself spending a lot more time trying to get the nested excel-like IF format happy than I like (even in Excel). Probably a mental block. I will fix it when I get a chance.
I also have a conceptual issue with winder dancer PV value. I want it to be in terms of storage so 100% is max storage and therefore slack. But that is counter to everything since a high PV gives a lower PID output and the winder slows. That means my Dancer Simulator has a few mislabeled terms I need to fix. I'm not sure I want to reverse the PID action or not.
-
Isn't that the difference between a forward and reverse acting loop? If you made it a forward acting loop, it should go in the same direction as the error, reverse acting they work opposite each other?
-
Isn't that the difference between a forward and reverse acting loop? If you made it a forward acting loop, it should go in the same direction as the error, reverse acting they work opposite each other?
I do believe so and will try it. I get stubborn about stupid things at times. It works perfectly fine, but I don't care if the glass is 90% full if I see it as 10% empty.
Edit: Well you were so right. I switched to reverse acting and saw where I had actually reversed the error trim polarity previously just to see if it would work, so now that's correct and all is as I prefer it. I do recall intending to go back there when I had to switch the trim polarity but had slept in between.
-
I don't think order is the issue. I suspect it is stack depth, but the math parse guru may have a different opinion.
-
No RAMP in DmD 2.0 (other than the already existing RAMPSOAK), but it does add true subroutines. May or may not be helpful for this, but it is another tool in the box.
-
No RAMP in DmD 2.0 (other than the already existing RAMPSOAK), but it does add true subroutines. May or may not be helpful for this, but it is another tool in the box.
I really need to stay out of your 20% category. :'(
Subroutines will be good. :)
RAMPSOAK just doesn't get me there even for simple speed ramps. I tried it again and it looked promising until I tried to have a different decel rate. Then I realized it really didn't want to turn around if the setpoint was lowered to a value less than it already was. In other words, it isn't designed* for this at all. Since I don't do applications that need it, I'll put it back in the box.
As for wanting a RAMP, I just want clean and easy, what can I say? It's fun to tackle things as a challenge and just for fun, less so under the gun.
As for trying to get the zero ramp rate handled in the single MATH instruction, I did do it, but it would appear all of the expressions are evaluated whether they will be operated on/with or not, so I get Divide by Zero warnings even if everything is hunky-dory otherwise. It's just a warning and I know some warnings can be cleared programatically, but would require another instruction, which "moots the point."
* I swear you Host people must sit around and figure out all of the cool but unconventional uses of your instructions and defeat them ahead of time! :D
-
I swear you Host people must sit around and figure out all of the cool but unconventional uses of your instructions and defeat them ahead of time! :D
I assure you that our intent isn't so nefarious. ;)
The 80/20 thought process is driven by the revelation that ADC's customers generally don't benefit by going too far and their business model can't really support them if we did. That doesn't prevent us from building parts that can be assembled to create lots of complexity and power. The fact that you are able to repurpose features is awesome, and is at the center of how we think about design. Unfortunately we can't anticipate everything you might do...
-
* I swear you Host people must sit around and figure out all of the cool but unconventional uses of your instructions and defeat them ahead of time! :D
As BobO alluded to, it's actually quite the opposite.
ADC works very hard with HOST Engineering to make sure that what we do deliver to our customers is as cool, good and easy to use as we can make it.
We have no shortage of fantastically cool ideas. Now if we only had an unlimited pool of programmers and engineers to implement them. :D ;D
The only nefarious plan that I am aware of is the one to take over the world. Narf...
Was I supposed to say that out loud, Brain???
-
The only nefarious plan that I am aware of is the one to take over the world. Narf...
Was I supposed to say that out loud, Brain???
It is preferred that we stay silent, but irrelevant. They simply cannot stop us. :rubbing hands gleefully:
-
The "divide by zero" error can probably be remedied with another if statement around the questionable variable.
-
The "divide by zero" error can probably be remedied with another if statement around the questionable variable.
Probably not. The issue is that the IF() is implemented as a function, and not as a high-level language branching construct.
An example of a neat idea: "Hey, what if we made a function that evaluated the first parm, and then returned the second or third? It would work like a Excel's IF() and give users high-level branching in a MATH box...and would take about as long to implement as it took to discuss this!".
It was not intended to be a replacement for ST though...
-
Maybe that explains why it takes me so long to even construct a complex IF. I can't do it in Excel easily either. I can't even figure out how to draw it out. Last time I did a quasi flowchart with a pencil - that has been easiest, even though I find flowcharts non-intuitive. I'm no good at "hold that thought" type stuff.
BASIC was much easier simply because you are allowed to do multiple things within it (IF something THEN do this, this, and that.)
I'm not complaining about the IF function as it is powerful, just has a few things to be wary of (like go fix a snack before embarking on packing a subroutine into a MATH box.)
-
BASIC was much easier simply because you are allowed to do multiple things within it (IF something THEN do this, this, and that.)
High level language vs ladder.
The IF() was low-hanging fruit and adds a nice bit of utility to the MATH box, but it absolutely was not intended to replace high-level language. We have a very long list of future improvements and an ST-like language is on that list.
-
When you get to ST (or even just in MATH), a SWITCH statement would be helpful if it's feasible.
-
I was just tweaking my program, and I was thinking, if there was an function to Increment By A Variable (or constant), it could really be useful here. As far as I know, we only have INC and DEC, which increment and decrement by 1. You could have the PLC INC or DEC the speed by the delta you need (which could be your total change in speed divided by your scantime / ramptime).
-
No RAMP in DmD 2.0 (other than the already existing RAMPSOAK), but it does add true subroutines. May or may not be helpful for this, but it is another tool in the box.
I really need to stay out of your 20% category. :'(
Subroutines will be good. :)
RAMPSOAK just doesn't get me there even for simple speed ramps. I tried it again and it looked promising until I tried to have a different decel rate. Then I realized it really didn't want to turn around if the setpoint was lowered to a value less than it already was. In other words, it isn't designed* for this at all. Since I don't do applications that need it, I'll put it back in the box.
As for wanting a RAMP, I just want clean and easy, what can I say? It's fun to tackle things as a challenge and just for fun, less so under the gun.
As for trying to get the zero ramp rate handled in the single MATH instruction, I did do it, but it would appear all of the expressions are evaluated whether they will be operated on/with or not, so I get Divide by Zero warnings even if everything is hunky-dory otherwise. It's just a warning and I know some warnings can be cleared programatically, but would require another instruction, which "moots the point."
* I swear you Host people must sit around and figure out all of the cool but unconventional uses of your instructions and defeat them ahead of time! :D
I use a delta contact and invert power flow before a RAMPSOAK to allow it to turn around. You could also OR that with a delta of the rate variable used in the RAMPSOAK. That will stop the rampsoak for 1 scan and allow the variables to update.
(https://forum.hosteng.com/proxy.php?request=http%3A%2F%2Fi67.tinypic.com%2F10px2ec.png&hash=e673ab18a3b74dba23c9a2da07c481f75a9492ae)
-
RAMPSOAK just doesn't get me there even for simple speed ramps. I tried it again and it looked promising until I tried to have a different decel rate. Then I realized it really didn't want to turn around if the setpoint was lowered to a value less than it already was. In other words, it isn't designed* for this at all. Since I don't do applications that need it, I'll put it back in the box.
I use a delta contact and invert power flow before a RAMPSOAK to allow it to turn around. You could also OR that with a delta of the rate variable used in the RAMPSOAK. That will stop the rampsoak for 1 scan and allow the variables to update.
Oh goody! I think. Now I'll have to dig it back out and try this. But right at the moment that looks more clever than my mind will deal with, what with all the negative logic stuff.
What sets C3700 in your example?
FeedLineTempSP vs FeedLineTemp.SP got me for a moment.
I've been wandering around in RSLogix 5000 all day. It's neat, but also mind-bogglingly frustrating and my brain is toast. In some places you can't cut and paste a huge tagname, you have to type it. In others, you can't type it, you have to select it from a list that is mind-numbingly huge. Yes it was a large program, but sheesh. Sadly, I don't have a photographic memory. (Was that a colon, a dot, an underscore, or just an uppercase? ???)
-
So, if I'm looking at this right, the following logic would accelerate/decelerate my process and ramp it to a stop?
The first rung "blinks" out to reset anytime the SpeedSet (the value in my HMI) changes for one scan, while the machine has its run logic active.
The second rung ramps the line to 0 speed whenever the run logic isn't active.
The third rung ramps to setspeed when the line starts.
This seems way too simple.
EDIT: Actually, I think the first line should be a delta contact and a NO contact for Run. Otherwise while running the delta contact does nothing. I thought myself into a little loop there. Updated the logic.
(https://forum.hosteng.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FEauZiW6.gif&hash=0bef626d5d2236512833c9e8ed6b3699cf1355a9)
-
I use a delta contact and invert power flow before a RAMPSOAK to allow it to turn around. You could also OR that with a delta of the rate variable used in the RAMPSOAK. That will stop the rampsoak for 1 scan and allow the variables to update.
Wow Scot! You should chip in more often. I just tried this and it is perfect. I added the OR for the rate and then added a rung before that: MATH RampRate IF(SPT >= OUTPUT, AccelRate, DecelRate) No glitches at all though you would have trouble using the .Done elsewhere without latching - it gets really energetic.
S-Curve isn't wanting to happen for me yet. It's easy enough to get end of ramp smoothing but beginning is eluding me at the moment. I need a different error at the start of a ramp than ABS(Spt-Output) which works well at the end of a ramp feeding a LERP to profile the RampRate. Too brain-dead at the moment anyway.
So, got any other amazing tricks?
-
Evilbeard:
I put the run contact after the Invert. That is my C3700. The Delta->Invert just means "no change". So Delta's OR'd together that you want to watch for changes (change in SP or change in ramp rate), then the Invert, then AND with the Run Bit.
Put C0 after your Invert and the 3rd rampsoak is not needed.
You also may need step 1 of the rampsoak to be Init to R103 to initialize the rampsoak. It's been a while so I can't remember if it worked without it or not.
Mike:
I noticed that same problem with .Done. So instead I use a check for .TimeLeft=0 (for .Done) and .TimeLeft>0 (for Not .Done).
I did something similar with the ramp rate. Mine is different depending on if it will be ramping up or down or if the generator goes offline (down really fast).
The only other neat trick I'm using in this program is a PID loop with a .Gain based on a formula that makes the gain logarithmic rather than constant or a liner ramp.
-
Mike:
I noticed that same problem with .Done. So instead I use a check for .TimeLeft=0 (for .Done) and .TimeLeft>0 (for Not .Done).
This will happen on Program->Run transition, the .Done will NOT be ON, but the .TimeLeft should be 0. Start Up conditions are one "gotcha" with ladder logic.
-
S-Curve isn't wanting to happen for me yet. It's easy enough to get end of ramp smoothing but beginning is eluding me at the moment. I need a different error at the start of a ramp than ABS(Spt-Output) which works well at the end of a ramp feeding a LERP to profile the RampRate. Too brain-dead at the moment anyway.
New platform adds S-Curve motion and has the concept of virtual axes. As long as you aren't using them for actual motion and/or don't require more than 4, you could use the motion engine to drive other stuff.
-
Another interesting use of Rampsoak is in my cooling tower PLC.
There are 3 turbine pumps for the cooling tower with 2 in use at any one time. Occasionally, the 3rd pump is ramped in while another is ramped out.
But that isn't the interesting part. After 2 pumps have been running together for an hour, another Rampsoak for each PID loop is used the normalize their PID .Bias. The average .Bias is calculated and used in 2 Rampsoaks to make the pumps run at the same speed, so one isn't working harder than the another.
-
Evilbeard:
You also may need step 1 of the rampsoak to be Init to R103 to initialize the rampsoak. It's been a while so I can't remember if it worked without it or not.
Mike:
I noticed that same problem with .Done. So instead I use a check for .TimeLeft=0 (for .Done) and .TimeLeft>0 (for Not .Done).
Without the Init in step one, I don't get it to work. Without the Init to Setpoint it doesn't work correctly either. (Calling the output "Setpoint" keeps tripping me up. I can guess why it got called that, but it stills feels strange.)
Mike:
I noticed that same problem with .Done. So instead I use a check for .TimeLeft=0 (for .Done) and .TimeLeft>0 (for Not .Done).
This will happen on Program->Run transition, the .Done will NOT be ON, but the .TimeLeft should be 0. Start Up conditions are one "gotcha" with ladder logic.
OK, but the .Done gets downright frantic looking when .TimeLeft reaches zero. ;)
New platform adds S-Curve motion and has the concept of virtual axes. As long as you aren't using them for actual motion and/or don't require more than 4, you could use the motion engine to drive other stuff.
But this is more of a preplanned move S-Curve, correct? I am still seeking the elusive (to me anyway) dynamic version as alot of VFDs and DC Drives have. So far I haven't glommed onto their secret recipe. It doesn't have to be perfect but does need to be smooth and respond to a setpoint change at any point in time.
I do use pulse and direction controls at times, so I value any new tools. I also desire to stay away from actual stepper motors and use servos instead. Steppers don't always play nice.
-
But this is more of a preplanned move S-Curve, correct? I am still seeking the elusive (to me anyway) dynamic version as alot of VFDs and DC Drives have. So far I haven't glommed onto their secret recipe. It doesn't have to be perfect but does need to be smooth and respond to a setpoint change at any point in time.
I do use pulse and direction controls at times, so I value any new tools. I also desire to stay away from actual stepper motors and use servos instead. Steppers don't always play nice.
Position moves, yes, pre-planned. Velocity moves, no, variable.
Speaking from (scar inducing) experience, S-Curve positioning is fairly painful for dynamic stuff. It was bad enough for pre-planned moves when using a mostly stateless implementation due to resource constraints. Not too bad if the path is pre-computed and stored.
-
But this is more of a preplanned move S-Curve, correct? I am still seeking the elusive (to me anyway) dynamic version as alot of VFDs and DC Drives have. So far I haven't glommed onto their secret recipe. It doesn't have to be perfect but does need to be smooth and respond to a setpoint change at any point in time.
I do use pulse and direction controls at times, so I value any new tools. I also desire to stay away from actual stepper motors and use servos instead. Steppers don't always play nice.
Position moves, yes, pre-planned. Velocity moves, no, variable.
Speaking from (scar inducing) experience, S-Curve positioning is fairly painful for dynamic stuff. It was bad enough for pre-planned moves when using a mostly stateless implementation due to resource constraints. Not too bad if the path is pre-computed and stored.
Well it is actually velocity S-Curve I am looking for, easier to keep tensions in a web if the ramp start and finish accel rates are also accelerated. It's so intuitive, yet so hard to program even for non-positioning.
-
Evilbeard:
I put the run contact after the Invert. That is my C3700. The Delta->Invert just means "no change". So Delta's OR'd together that you want to watch for changes (change in SP or change in ramp rate), then the Invert, then AND with the Run Bit.
Put C0 after your Invert and the 3rd rampsoak is not needed.
You also may need step 1 of the rampsoak to be Init to R103 to initialize the rampsoak. It's been a while so I can't remember if it worked without it or not.
Yeah, I don't know why I thought I'd need the redundancy of the run circuit. I was thinking that it would cause it to eliminate the delta contact when it was in run for some reason. I didn't use Step 1 as an Init because I want it to function at whatever the Setpoint is at. I figured it was redundant having a step saying Init to Speed, when I want to change speed anyway. I tested it in the simulator, and it seems to function fine. Whenever the rampsoak function is active, it just takes the speed, ramps it to the setspeed and then finishes. If I push stop and change from the "accel/decal" rampsoak to the "stop" rampsoak, the line ramps to a stop.
UPDATE: I streamlined the program in the production machine, and it worked like a charm. So much simpler.
It seems like this eliminates the 3 subroutines I wrote to do this. WHERE WERE YOU A MONTH AGO?!!! Thanks a ton! This will clean up my program tremendously!
-
Foiled again. :(
-
Foiled again. :(
What about just making another program to run using RUN and EXIT to leave it, much like a subroutine?
-
Well, you know it was really about trying to build a reusable block. A block that fits on a single rung in the ladder where it is used. A packaged subroutine or function block can be fleshed out (Pinky) more, but in the "control the world" area, I would like it to be clean and readable (which my nested IF was definitely not!)
I had my doubts when I tried it, "That'll never work!" but got a little hopeful when it pasted in from v1.4.3 ... which lasted right up until I tried to edit the RAMPSOAK.
Ah well, it'll be better to wait for those passed values that aren't global anyway. And I see 2.0.3 came out less than 24 hours after I got 2.0.2 installed. ;)
But the nested IF should work OK there if I need to use it before the new improved DmD gets here next month... right?
-
A RAMPSOAK is a timed operation. Where would you invoke it, and how do you define completion?
-
A RAMPSOAK is a timed operation. Where would you invoke it, and how do you define completion?
Ahh! I do believe the RAMPSOAK was offered up by yourself as a possible means to achieve a ramp function for an analog speed reference, if perhaps not in such detail. It is invoked when Line Run is pressed and only devoked when everything has stopped and turned off. As for completion, there is no completion so long as there is an operator who desires to change the speed on any whim whatsoever, never devoking the machine when a simple sweep of the speed pot fully counter-clockwise to the stop and a quarter turn past that will suffice. This is why I am looking for a ramp. Preferably the delectable, dynamic S-ramp that has been so elusive to achieve, except when it is simply included as a function as programmed by someone apparently much smarter than I.
Of course you did mention it before subroutines were available. (Why is there no tounge-in-cheek emoticon?)