New features wanted!! Apply here!

[Controls Guy]

Every time I think we're on the same page you lose me!  Are you talking about trapezoidal a/t plots or trapezoidal v/t plots?


Edit: OK, if I got my napkin scribbling right, the equation V = f(t) to decel from initial velocity V₀ in distance d with full parabolic S-curve (no constant-a section) is:

V_t = v₀ - (v₀³/2d²)t²

...and everything on the right side is constant except for t, so it simplifies to

V_t = v₀ - kt², where k can be precalculated once for the entire ramp.

If I get a chance I'll try to confirm that tonight or tomorrow; it checks out dimensionally at least.  That's for the first half of the S-curve (negative accel, negative jerk).  For the second half (negative accel, positive jerk), you could either do the math again or just build a table while you're doing the first half and crawl it backwards.

So IMO the math isn't demanding CPU-wise, I think the bottleneck is going to be CPU-CTRIO comms or the analog.

[BobO]

Nothing hard. Just saying that an S-curve velocity is produced by a linear accel, and the linear accel can be either triangle or trapezoidal...triangle being a subset of trapezoidal.

The velocity math is easy. The brute force part is determining the required change in position to decel to a specific velocity...in most cases 0, but for blended moves the velocity may not be zero. So for a given position, velocity, and accel, how many pulses y will it take to get to velocity=x?

[Controls Guy]

Nothing hard. Just saying that an S-curve velocity is produced by a linear accel, and the linear accel can be either triangle or trapezoidal...triangle being a subset of trapezoidal.

OK, you spelled it out well enough even for me! That was the same point I was trying to make.  Also, linear A does produce an S-curve move, but it doesn't have to be linear.  Any function whose integral is a curve and has horizontal tangents would work.  Sin/cos for example, or A could be quadratic and make V a cubic, which would still yield an S-curve.  Most apps I'm sure won't justify the extra effort, but it's there if for whatever reason we need it some time.

The velocity math is easy. The brute force part is determining the required change in position to decel to a specific velocity...in most cases 0, but for blended moves the velocity may not be zero. So for a given position, velocity, and accel, how many pulses y will it take to get to velocity=x?

I don't think it will be a whole lot worse.  Bit of a different situation -- in a decel ramp, the final velocity and position are critical and time will become the wagged tail.  In a ramp to a non-zero V, the final V is obviously important, but time might overshadow the position at which the ramp terminates.

[BobO]

Ideally you'd love to be able to enter current position, current velocity, current accel, and target velocity into a formula and have it spit out resulting position. That's pretty easy to manage with fixed accel/decel, but my guess is that it isn't quite so easy for S-curve and will require either PHD math (and I ain't that smart) or simple math iteratively (processor must be fast enough).

Gotta figure out when to start stopping the train to perfectly hit the station without the passengers spilling their champagne...even while we were still accelerating from the previous stop.

[Controls Guy]

Very doable (and I ain't no PHD either)!

In addition to the initial conditions you list, you'd need to input maximum achievable values for velocity and accel (a really thorough model would have separate accel and decels to account for limits due to overhauling loads) as well as max jerk (which is more a design constraint than a physical barrier).

I'll check my inventory of napkins and get back to you. 

[BobO]

I'm all for doable. Franj is actually a math major from an elite nerd school. Me, not so much.

[Controls Guy]

If I can't count it on my fingers, I'm outta luck.  Fortunately, I got calcoolus fingers.*

*"Stand and Deliver" reference.  Stand and Deliver is the classic nerd movie.  Like Star Wars, but for nerds.

[Mike Nash]

Well as for my needs and the reason for the request, I am needing "simple" velocity control, not positioning. I need to ramp a machine up and down in speed with multiple drives and motors typically. The need for the "S" has more to do with tension control in a web. Position needs are usually (although not always) much more basic or even non-existant. More demanding is the need for an operator to be able to crank the line speed pot wherever he/she wants at any time and have smooth control. Overshoot is probably just fine to prevent transients due to a setpoint change, but should not be unreasonable.

Research over the past weekend was indicating multiple equations needed at various times and probably the foggiest part for me is predicting when to transition from one to another without transients being introduced.

I am looking at total ramp times from 10-120 seconds, not pick and place speeds at all.

[Mike Nash]

I was going to ask for MATH IF THEN ELSE nesting that allowed for comparisons that were equations along with results that were equations because I could not get that to work a couple of days ago. But I just tried it again and it works very, very fine.

So instead, I would like to humbly request that MATH IFs get some type of nice formatting so I can figure out just what I am trying to do. I really like not having to have scratch values as required with comparison instructions (which won't take equations, hint, hint.) along with the multiple rungs needed, but without some kind of clean formatting it seems like a bad idea for me to get into that kind of complexity.

This is what I tried (Bogus Stuff)

MATH
Result R0
IF((R1 + R2) > (R3 + 3.0), IF((R4 + 1.0) <
(R5 + 5.0), 1.0 + R3, 0.89), 2.0 + R6)

It works, but is kind of hard to follow, especially with nicknames or PID_Control1.Output added in liberally and broken up randomly. Maybe different colors or true IF THEN ELSE or something.

Or MAYBE I am looking for a decision tree instruction! Hang it off the left rail and branch off from the results to the right. Wait, this sounds like a flow chart, huh, maybe not.

But I would love Function Block Diagrams for analog type stuff.

[Controls Guy]

I was looking at this exact issue over the last couple days (legibility and troubleshooting with MATH box expressions), and I came to similar conclusions.

I'd like to see some live status within the expression, and also the ability to format it a little, at least when the box is open for editing.  Let us put in carriage returns for instance, and retain them, at least when editing the box.

AB on the CLX has a pretty good what I'd consider a partial solution to showing status in CPT (MATH) boxes; if you hover over a variable, the value pops up in a tooltip.

And yes, CMP complex compares are a feature I LOVE in CLX and use often.  Very much more powerful than previous AB generations that had only simple compares such as EQU, NEQ, GRT and so on.

(Hosties, in this feature you can write a complex comparison like SQRT(R100) + D500 / 3 > 5, and place it midline in a rung like a normal compare.  It's not an output box like CMPD in DL-classic)

[BobO]

The engine already supports expressions for virtually any input, and already has an expression contact. The hard part is handling the display and editing. The issues with the MATH box...no auto-complete, for instance...are the types of things we need to resolve before we add expressions throughout.

[Controls Guy]

Really looking forward to the expressions-everywhere thing.  That's going to be extremely cool (and unique in the field)!   

[Controls Guy]

First of all I don't think I've ever thanked you guys for adding the Delta contact.  You can use it in all sorts of ways.   

One place I chose not to was one of those cases where you want to do something on the stroke of midnight (clear some daily total registers in my case).  You could use an equal comparison of $Now.Hour with 0, but then you must use an inline one-shot or add minute and possibly second compares so it doesn't hold the totals to zero till 1am, and besides, with this equipment some users may not let it run 24/7.  If it's off at midnight, I still want the totals to get cleared on power up.

What I ended up doing was remembering the last day on which the totals were cleared, and do a not-equal compare of $Now.Day with that.  If not equal, clear the totals registers and set the date memory register.  This works both at midnight and on power up on a new date.

So this brings be back to the delta contact.  I could have simplified the ladder if I could have started the ladder with a simple delta contact of $Now.Day, which works great at midnight but not on power-up (apparently the last-scan state isn't retentive).  So that starts me thinking about how the delta contact SHOULD work.  In this case it would be better if last state were retentive, and it could potentially go true on first scan, but I could also come up with some cases where you wouldn't want that.

I concluded that it would be more flexible if it were the other way, because we could turn it back into this version with NC ST0 if needed, but there's no way to turn this version into the other.  Any thoughts?

[BobO]

Edge retention is tricky. Not hard, just difficult to predict how people really want to use it. Ditto for startup states in general. Do you assume a clean start, or do you attempt to resume. A perfect resume is hard, so you generally wind up with startups that are "only mostly dead". Sorry...poor movie humor.

In this case I would probably resort to a relational != on $Now.Day to edge trigger the DoMyDailyThing task or program, which would update the retentive DayLastDone variable. Not as simple as a delta, but pretty easy and reasonably robust.

[Controls Guy]

Right, that's what I ended up with, and I agree it is relatively clean.  It just started me thinking about the details of the delta so I posted about it.  This is the first time first scan behavior has even been an issue using that instruction, so it's evidently somewhat of an edge case.