A Question on Nested If's Again

[Mike Nash]

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    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.

[Controls Guy]

I think DM equality test operator is a single equal, not double (just from memory).

[Mike Nash]

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!

[Controls Guy]

Yeah, I know what you mean about the meat memory (as my post illustrates)!   

[Garyhlucas]

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.

[Mike Nash]

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)

[Evilbeard]

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.

[Mike Nash]

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.

[Evilbeard]

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?

[Mike Nash]

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.

[BobO]

I don't think order is the issue. I suspect it is stack depth, but the math parse guru may have a different opinion.

[BobO]

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.

[Mike Nash]

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! 

[BobO]

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! 

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...

[ADC Product Engineer]

* 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! 

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.    

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???