Help us design our next Do-more platform!!

[Controls Guy]

The larger bricks would not have the limitations of the bottom model, but would obviously cost a bit more. When you consider that we are talking about putting the exact same CPU we are currently selling for $299 and $399 (and more for Terminator) into an expandable brick that can be a reasonable alternative to existing low end DL CPUs, we're already stretching. But price sells and we realize that the closer we can get, the more we will sell.

If the non-E version of the 205 Do-More is $299 (IOW competitive with classic non-E 205's and $100 more than an 06) where do you see the price range for the line of small Do-Mores?  The entire range, as well as the smallest expandable model?

In fact, is there room for as many distinct models as you're envisioning, especially since most of them are expandable?

[BobO]

If the non-E version of the 205 Do-More is $299 (IOW competitive with classic non-E 205's and $100 more than an 06) where do you see the price range for the line of small Do-Mores?  The entire range, as well as the smallest expandable model?

In fact, is there room for as many distinct models as you're envisioning, especially since most of them are expandable?

Too early to talk pricing, too many unknowns.

The second question is a good one and part of why we are having this discussion. Anything that can be included in the brick itself will be lower cost than expansion. The thought was to pick the brick size closest to your basic I/O requirements, then add modules as needed to complete the system. In truth, the simplest answer is fully modular...no brick I/O...but that isn't the most cost effective to the user.

[ATU]

Here's a great question: How much more would you spend for a Do-more CPU than a Click CPU? I'm not trying to compete with Click, but there is a point where the added benefit of Do-more exceeds the additional cost. Is that $50? $100$ $200? Or am I missing it completely...do you view Click as more preferable than Do-more (without regard to price) for the applications it can handle?

That's a complex question. For small jobs (2013 was the year for small jobs, quoting jobs this year was like being at a country village bazzaar) This is when size is really important. The CLICK CPU is only 2 inches wide with no PS, which most of the time, I run it off one PS for everything. I like a smaller enclosure because it costs less all around, parts and labor. Customers like a smaller enclosure because they can find a place for it on an extremely compact machine on an already cramped factory floor. When you're dealing with less than 8/8, that's the case.  When the program is only 10 lines or less, DoMore is overkill. $100 for a CPU is acceptable.  When you start getting into 16 or more inputs and the operation is a little more complex, Yes, I would pay $100 - $200 more for a better instruction set and Ethernet. Better yet, the customer is willing to pay more. You have to pick the right pair of shoes for the job.

[BobO]

Great feedback all!! It's very helpful!

So what about encoder inputs and pulse outputs...how critical are they in the brick itself, as opposed to an option module?

Assuming they are useful built-in, how many channels would you have?

What speed in and out to be useful?

[jwbaker3]

For the projects we have done if we need encoder input or pulse out we will use an option card, our needs for this have been very low to have it built in. I think built in analog would be more useful (voltage/current selectable like others have) 2 in 1 out or 4 in 2 out. (To beat the dead horse a little more) A motion control card would be nice, we use a stand alone motion controller for these type of projects now. (I know I saw the other posts, but now I feel better) I agree with ATU, we have to use what is the best fit for each project (if the customer does not require a brand). There is always a little salesmanship, education, cost vs performance vs labor (programming and maintenance) and must haves in every project.   

Have a Great New Year!

JW

[b_carlton]

We use a high speed counter input in almost all of our applications. The HS input on the DL06 comes in perfect.

[BobO]

For the projects we have done if we need encoder input or pulse out we will use a card, our needs for this have been very low to have it built in. I think built in analog would be more useful (voltage/current selectable like others have) 2 in 1 out or 4 in 2 out. (To beat the dead horse a little more) A motion control card would be nice, we use a stand alone motion controller for these type of projects now. (I know I saw the other posts, but now I feel better) Have a Great New Year!

JW

I don't see any reason that we couldn't build in an 'analog out/encoder in' motion axis feature. I would need to be educated on what that looks like in practice (who's the best example? AB? Siemens? Other?), and we would likely chose to keep it pretty simple to minimize the hit to ADC support staff, but I am certainly not opposed to it. I doubt that we would consider coordination or scripting, but I would think simple closed loop positioning and velocity would be very manageable.

I keep seeing the request for analog voltage/current to be select-able. Most of ADC's existing modules are one or the other, but not both. Is that a common thing, or just the preference if possible?

[BobO]

We use a high speed counter input in almost all of our applications. The HS input on the DL06 comes in perfect.

It's pretty slow, isn't it Bernie? Speed isn't an issue?

[jwbaker3]

I don't see any reason that we couldn't build in an 'analog out/encoder in' motion axis feature. I would need to be educated on what that looks like in practice (who's the best example? AB? Siemens? Other?), and we would likely chose to keep it pretty simple to minimize the hit to ADC support staff, but I am certainly not opposed to it. I doubt that we would consider coordination or scripting, but I would think simple closed loop positioning and velocity would be very manageable.

We currently use ABB/Baldor, Yaskawa and AB for motion. It would be nice to be able to handle 2 axis closed loop.


[/quote]

I keep seeing the request for analog voltage/current to be select-able. Most of ADC's existing modules are one or the other, but not both. Is that a common thing, or just the preference if possible?
[/quote]

Siemens, Omron, GE and AB (there may be others) all have selectable analog cards 0-10, -10-+10, 0-20ma, 4-20ma. It makes it very nice to not have to stock all the different types of cards in the shop and on every service truck. I wont say it is a must have but it would be great.

JW

[b_carlton]

The high speed counting we are doing is an encoder attached to a chain transferring product through the machine. It's only about 200-500 hz. Not very fast but too much for capturing in a scan. OK - 'medium speed counter'. But it's nice to have.

[ATU]

The 06 is limited to 7khz. It wouldn't hurt to bump that up a bit, maybe 25kHz - 50KHz.  Some features I like on the 06 are the preset data tables for the HS counters and the interrupts. Easy to setup , easy to use. Don't try to do too much and make it more complicated to configure. Plug and Play. Reserve high end stuff for separate motion modules. I just want to hook up my encoder (Quad or dual counters) and see my counts and presets in your memory map, like you did with the DL HS modules. Analog in and Out would be great. Single channel PID control with optional pulse output in one box. I would like to see configurable Analog, but if I had a choice between that or a better price I would settle for 0-10V. Enough to control a drive, temp control or add a Pot. Anything more demanding, buy the add on Analog module or use a converter.

[Controls Guy]

For me, analog would more often be useful than high speed inputs and outputs.

My suspicion, though, is that the differential cost to make a few of the general purpose I/O's high speed / interrupt capable like the 06 is pretty low, probably lower than analog. If it's cheap, why NOT do it?  If you do the high speed discrete, it would be convenient to be able to do both high speed inputs and pulse outputs at the same time, if feasible.  I don't think you can do that on the 0x.

Like b_carlton, I sometimes get into that gray area where I need to count something faster than generic I/O but not super high speed.  Maybe a few hundred Hz to a kHz or two.

It's not going to be a huge deal to me if neither analog nor high speed I/O is included directly on the CPU, so long as there are expansion modules available.

Are all sizes planned to have the same memory size as the 205 DM?  A controller with that much memory can do some interesting things, even if it doesn't have to interface to a lot of I/O.  Even if somewhat less than the H2-DM, that's still a heck of a lot of memory for a micro PLC.

Oh, and if you do a motion module coupled to an analog output, please make sure the output can be configured as a torque reference, not just velocity.

[BobO]

For me, analog would more often be useful that high speed inputs and outputs.

My suspicion, though, is that the differential cost to make a few of the general purpose I/O's high speed / interrupt capable like the 06 is pretty low, probably lower than analog. If it's cheap, why NOT do it?  If you do the high speed discrete, it would be convenient to be able to do both at the same time, if feasible.  I don't think you can do that on the 0x.

Like b_carlton, I sometimes get into that gray area where I need to count something faster than generic I/O but not super high speed.  Maybe a few hundred Hz to a kHz or two.

We plan on making all inputs use software based filtering, so the only difference between 'normal' and 'high-speed' is the speed of the opto-isolator. Faster optos do cost more, and enough to be relevant in a low-end machine like this, but I'm sure we'll make some of them fast.

Are all sizes planned to have the same memory size as the 205 DM?  A controller with that much memory can do some interesting things, even if it doesn't have to interface to a lot of I/O.  Even if somewhat less than the H2-DM, that's still a heck of a lot of memory for a micro PLC.

We'll be using the DM1 CPU...same specs as existing units.

[tmoulder]

For the projects we have done if we need encoder input or pulse out we will use a card, our needs for this have been very low to have it built in. I think built in analog would be more useful (voltage/current selectable like others have) 2 in 1 out or 4 in 2 out. (To beat the dead horse a little more) A motion control card would be nice, we use a stand alone motion controller for these type of projects now. (I know I saw the other posts, but now I feel better) Have a Great New Year!

JW

I don't see any reason that we couldn't build in an 'analog out/encoder in' motion axis feature. I would need to be educated on what that looks like in practice (who's the best example? AB? Siemens? Other?), and we would likely chose to keep it pretty simple to minimize the hit to ADC support staff, but I am certainly not opposed to it. I doubt that we would consider coordination or scripting, but I would think simple closed loop positioning and velocity would be very manageable.

I keep seeing the request for analog voltage/current to be select-able. Most of ADC's existing modules are one or the other, but not both. Is that a common thing, or just the preference if possible?

Hallelujah!  I am one hundred percent in favor of fully-closed-loop analog motion control.

For us, this would entail eliminating a Trio motion controller.  The specs to do this would mean an isolated +/- 10 VDC analog output for speed or torque control of the drive, 10MHz - capacity encoder feedback (Trio can do 7 MHz, but hey, shoot for the moon), and inputs for positive over-travel, negative over-travel and home limit switches.

Termination-wise, all of this could be managed on a single card - 2 for analog, 6 for encoder (a, /a, b, /b, z, /z) and three switch inputs, so grand total of 11.

Altetrnatively for motion, you could embrace protocols - ether-CAT, CanOpen 402, even Devicenet or Mechatrolink.

An SSI or EnDat encoder option is also good.

Seriously, the lack of integrated motion control in PLCs today is pretty mystifying to me.  I use motion controllers all over the place.  I don't need interpolated motion, I'm not laser-etching in cursive, I just need reliable movement, point-to-point, and the ease of use of a PLC of switches and outputs.  Somehow, many companies seem reluctant to touch this.

As a latter note - having done a large project in do-more, I am personally unhappy with the stage-method.  My wish list would include an option to program in IEC 61131 with full UDFBs.  You could even charge a markup for it (like several companies do) and I would pay it.

Thanks!

TM

[BobO]

For us, this would entail eliminating a Trio motion controller.  The specs to do this would mean an isolated +/- 10 VDC analog output for speed or torque control of the drive, 10MHz - capacity encoder feedback (Trio can do 7 MHz, but hey, shoot for the moon), and inputs for positive over-travel, negative over-travel and home limit switches.

Termination-wise, all of this could be managed on a single card - 2 for analog, 6 for encoder (a, /a, b, /b, z, /z) and three switch inputs, so grand total of 11.

What you are describing would have to be an option card. What I was committing to look into for inclusion on the brick wouldn't be line driver and wouldn't be anywhere near that fast.

Seriously, the lack of integrated motion control in PLCs today is pretty mystifying to me.  I use motion controllers all over the place.  I don't need interpolated motion, I'm not laser-etching in cursive, I just need reliable movement, point-to-point, and the ease of use of a PLC of switches and outputs.  Somehow, many companies seem reluctant to touch this.

I can't speak to other PLC companies, but I have some sense of ADC. It's largely two things: 1) they know their customers, and 2) they know what it takes to support them. While I'm sure some of our customers do the kinds of things you are describing, in my experience they are 3 sigma...or more. ADC reminds me pretty often that the folks I deal with here on this forum are a generally savvy subset of their overall customer base. I have been using the Do-more development effort to push the envelop a bit, and I really hope to broaden the base, but ADC's business model tends to cater to a certain type of customer so there is a bit of inertia to overcome. We'll see how a true encoder in/analog out motion axis goes over. If the sky doesn't fall, I'll push harder.

As a latter note - having done a large project in do-more, I am personally unhappy with the stage-method.  My wish list would include an option to program in IEC 61131 with full UDFBs.  You could even charge a markup for it (like several companies do) and I would pay it.

I'm sorry you don't like stage. I personally love it, but you are certainly not alone. I have kicked around the idea of offering a 61131 product, but that goes back to my point about support requirements. ADC has been very reluctant to consider such products. I have no doubt that licensing a product and porting their engine would be a very manageable effort, but I gotta have ADC's buy-in before we would do it.