A Question on Nested If's Again

[BobO]

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:

[plcnut]

The "divide by zero" error can probably be remedied with another if statement around the questionable variable.

[BobO]

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

[Mike Nash]

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

[BobO]

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.

[Controls Guy]

When you get to ST (or even just in MATH), a SWITCH statement would be helpful if it's feasible.

[Evilbeard]

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

[Scot]

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! 

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.

[Mike Nash]

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

[Evilbeard]

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.

[Mike Nash]

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?

[Scot]

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.

[franji1]

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.

[BobO]

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.

[Scot]

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.