New features wanted!! Apply here!

[BobO]

I had never heard of it, but Google is your friend.

The hardware interface is obviously custom, but could easily be done. The protocol sounds trivial. I guess the big issue is that after 20 years of doing this, this is the first request for it...probably due to the fact that PLCs are rarely used for building access/security. If there were a market for it, I'm sure it would be very simple to do it...just not sure there is enough of a market to cover the development cost.

[WRT]

I just found this topic, so I hope someone is still monitoring.

My biggest wish that I scan every new PLC for, and so far have failed to find (with the exception of the heavy lifting NI Compact-RIO) is an event timer card.  It would have the following capabilities.

1. Allow the PLC to adhoc access a fast clock, say 16 or 32 bit running at 1uSec per count.
2. Log the precise time of input events (separately log rising and falling edges) using that clock. Interrupts would be optional.
3. Allow Output channels to turn on and off at precise times, again based on the 1uSec clock. Interrupts would be optional.

This opens up all sorts of application options that are currently poorly met by such as the CTRIO card.

OH OH, I forgot something...

Since Modbus is always going to be the lowest common denominator for data access, it would be nice if the Ethernet interface incorporated a little security, such as restricting write access to a settable range.

[BobO]

My biggest wish that I scan every new PLC for, and so far have failed to find (with the exception of the heavy lifting NI Compact-RIO) is an event timer card.  It would have the following capabilities.

1. Allow the PLC to adhoc access a fast clock, say 16 or 32 bit running at 1uSec per count.
2. Log the precise time of input events (separately log rising and falling edges) using that clock. Interrupts would be optional.
3. Allow Output channels to turn on and off at precise times, again based on the 1uSec clock. Interrupts would be optional.

We have actually been considering similar functionality in some yet-to-be-developed hardware.

Since Modbus is always going to be the lowest common denominator for data access, it would be nice if the Ethernet interface incorporated a little security, such as restricting write access to a settable range.

Do-more actually does this, at least partially. Modbus access is already limited to Modbus specific memories, although we do not currently allow limiting writes to a subset of that. Doesn't seem like it would be particularly difficult to do, and would definitely enhance the security further.

[LWgreys]

I have something simple to add!

In 'Data View' and 'Change Value', It would be great to have a toggle button and a momentary button.
The toggle button would turn OFF what is ON and turn ON what is OFF.
The momentary button would turn ON momentarily what is OFF while the button is presses and OFF momentarily if it is ON.

The ON OFF buttons are OK, but when you want to emulate a Push-Button you have to first turn it on then turn it off.

[Mike Nash]

Well, I have been using the Do-more on a couple of jobs now and I really like it. Definitely a few quirks yet, but very, very powerful and super fast. Unfortunately, I have found that not all vendor's ethernet comms are up to snuff speed-wise, so I am still stuck using analog on them. This is not Do-more's problem though because it is able to service another vendor's product at the same time at a very respectable speed.

I am hitting all of the slow devices about 4-5 times a second (write a change, internally linked, read the change back). The quick one at least 10 times faster. The slow devices were about 3 seconds per device sequentially! on a D2-260 with Ecom-100! I was still disappointed, but it wasn't Do-more bottle-necking me. I almost forgot to mention how easy it was to set up the comms for 7 Modbus/TCP devices!

Now for the requests:

I would also really like to have LWgreys' request for the toggle and momentary buttons.

I would love to have a RAMP instruction or RATE LIMITER maybe, but RAMP (as in accel, decel with S-ramp ideally) for use in drive control systems. I can build my own (INTEGRAT!), but we don't quite have the user structures yet that would make that painless. BTW, that S-Ramp has to be "on-the-fly" as opposed to a positioner type as the input could be changed at any time.

Yes I would love to have Add On Instruction ability, and User Data Types (say Drive_2.AccelTime etc.) And not being able to have a User Memory type with a number in the name is a drag (Drive2).

If Then Else in the MATH instruction is cool! But it's kind of hard to read after it's built so I dropped my one use of it in favor of MATH + CLAMP (another cool instruction along with LERP)

I would like to love the Nicknames, but I am having access consistency issues. Like in a MATH instruction I don't seem to have an Auto Complete or pickbox at which point I was better off with R20 instead.

And one last nit to pick (for now  ) when will we ever see our software installed under Program Files\AutomationDirect ? I am none too keen on software installing into C:\ though Host is not the only one to do it.

Seriously, I love these products (mostly)!

[Controls Guy]

When I click in a MATH box, I get a list.   Not sure if it's just symbolic constants or if it also has nicknames.

As far as directories,  look for a utility called COA (Change Of Address).  It will move installed apps, and go fix all the registry entries and shortcuts and so on to point to the new directory.

I was usually using it the other direction (to get stuff OUT of Program Files and into a logical hierarchy).

[Mike Nash]

Well blow me down! I've loaded DMD at home (less stress don't you know) and discovered two new things.

1) The Previous, Next and Output Cross Reference search buttons! (Don't press that button, you may blow up the world!) are fabulous. I was having issues with the Cross Reference View when following the cursor doing weird things, but those buttons work great.

2) That useless, annoying, Element Browser that was always popping up unwanted, works alright once you untick the "Filter on Selected Range" box (each and everytime so far, maybe I can find how that turns off too.) Now I can find the nicknames. Better and better. Thanks Controls Guy!

[BobO]

I would love to have a RAMP instruction or RATE LIMITER maybe, but RAMP (as in accel, decel with S-ramp ideally) for use in drive control systems. I can build my own (INTEGRAT!), but we don't quite have the user structures yet that would make that painless. BTW, that S-Ramp has to be "on-the-fly" as opposed to a positioner type as the input could be changed at any time.

RAMPSOAK isn't S-Curve, but can you not build a ramp profile with it?

Yes I would love to have Add On Instruction ability, and User Data Types (say Drive_2.AccelTime etc.) And not being able to have a User Memory type with a number in the name is a drag (Drive2).

User data types and functions are coming in DmD 2.0.

Because we don't use a token to delineate normal array type memories (X0 vs X[0]) it becomes very difficult to parse if you allow numbers in block names. If I have MyBlock2 and MyBlock22, what does MyBlock221 reference? As much as we would like to support it, sanity must prevail. I would say that user data types will help to a significant extant.

I would like to love the Nicknames, but I am having access consistency issues. Like in a MATH instruction I don't seem to have an Auto Complete or pickbox at which point I was better off with R20 instead.

It's something we want to address.

And one last nit to pick (for now  ) when will we ever see our software installed under Program Files\AutomationDirect ? I am none too keen on software installing into C:\ though Host is not the only one to do it.

The issue is that we run into many painful side effects of Microsoft's ever-changing security-of-the-week. Writing to the various files that store states (options, comm links, etc) become problematic. They could be (must be) written elsewhere, but that tends to create support issues. We're not opposed, but there are a dozen issues that have to be addressed...and there are many other higher development priorities.

[Mike Nash]

RAMPSOAK isn't S-Curve, but can you not build a ramp profile with it?

Well I tried it, but I don't think it is what I am looking for. The simulator is pretty fun at home though and I have the beginnings of an S-Ramp kludged up (I am not even trying to do the fancy math a true S-Ramp seems to use.) It is trending pretty decently. Now I need to clean it up so it looks like a digital drive's S-Ramp.

I am looking forward to DMD 2.0!

[Controls Guy]

Just do a parabola or a sine function.   I think that's what all the commercial implementations are doing.  A constant third derivative (jerk)  will produce a parabola on the velocity plot.

[BobO]

Accel/decel is a trapezoid.

[Mike Nash]

Accel/decel is a trapezoid.

Only in the simplest case. An elevator is a good example of why you want an S-Curve and want it well tuned. Too little S and it is harsh, too much and you are wondering if you are ever going to get there.

Controls Guy has it right as far as Jerk, but it is actually pretty complicated to get a good curve and a real time change to speed setpoint completely hoses the look-up tables as best I can tell.

http://www.pmdcorp.com/news/articles/html/Mathematics_of_Motion_Control_Profiles.cfm has an article about it but it is aimed more at position profiles where you already know precisely where you are going.

My applications are much more like driving a car. You don't just push the pedal for how fast you want to be going, you feather it at start and at up-to-speed. You do the brakes the same way. (Yeah I know, some people just hammer both.) And the situation is constantly changing so you may need to slow back down before ever arriving at your earlier setpoint and you want the same smooth-rate acceleration changes.

Anyway, it is one of those "all you gotta do" type problems I just hate to be assigned...

[Controls Guy]

Accel/decel is a trapezoid.

If you're saying that a plot of the accel during the accel (or decel) ramp is a trapezoid for an S-curve profile, yes, for certain cases that's true (the ones with a straight section of accel/decel with only the corners rounded).  Sometimes though, the S sections actually meet in the middle.  For that case the accel plot wouldn't have a horizontal segment, it's always increasing or decreasing according to some function (which function could be as simple as linear).  In the linear case, the plot will look like a triangle.

Since the integral of mx+b is 1/2(mx^2) + bx, then the velocity profile will have an s-curve made from two parabolic segments.  The jerk profile will look like a bipolar square wave (positive then negative, or positive, zero, negative depending if there's a constant accel segment in the middle).

[Controls Guy]

it is actually pretty complicated to get a good curve and a real time change to speed setpoint completely hoses the look-up tables as best I can tell.

The math shouldn't be that bad.  It's just going to end up being a quadratic you can derive pretty easily if you know your new velocity target and how long you have to get there.  The iffy part is that you'll have to do it in ladder and the ways you have to get the data out to the drive (write new velocity setpoint to a CTRIO, or use an analog output), may be too low bandwidth to give you the performance you want.

[BobO]

If you're saying that a plot of the accel during the accel (or decel) ramp is a trapezoid for an S-curve profile, yes, for certain cases that's true (the ones with a straight section of accel/decel with only the corners rounded).  Sometimes though, the S sections actually meet in the middle.  For that case the accel plot wouldn't have a horizontal segment, it's always increasing or decreasing according to some function (which function could be as simple as linear).  In the linear case, the plot will look like a triangle.

Since the integral of mx+b is 1/2(mx^2) + bx, then the velocity profile will have an s-curve made from two parabolic segments.  The jerk profile will look like a bipolar square wave (positive then negative, or positive, zero, negative depending if there's a constant accel segment in the middle).

The triangle case is just a special case of the more generalized trapezoidal accel/decel. My point was simply that S-curves aren't really that mathematically complicated. The hard part is in developing the math to predict the correct values for the accel/decel profile to hit the exact target point at 0 velocity. For a basic trapezoid it's easy. S-curve not so easy and I'm guessing brute force may be the preferred solution. Only problem is whether you have enough CPU to crunch the numbers fast enough.