Thanks John I knew you'd give a comprehensive reply. Notwithstanding, many hobbists build their own stepper drives. There's a plethora of them. So now now it's open loop. Otherwise cobble your own Step/Dir drive. Got closed loop, but two of them that meet in the middle. If you want to build your own EMC-closed loop DC drive, which is fairly simple in hardware terms, you have to do quite a bit of work on EMC. I think? Or get something off the shelf.
Anyone building their own drive, would be faced with a similar cost in all three options, except a path has'nt been beaten for the third, and I suppose that's the essence of it. If there was a generic data format, it could be worked at from both sides, EMC fundi's and embedded tinkerers. I would be a taker for the Pic side, but amending EMC is long way off for me. Anyway, thanks for the thoughts. Regards Roland Jollivet 2008/11/20 John Kasunich <[EMAIL PROTECTED]> > Roland Jollivet wrote: > > Hi > > > > I have been wondering the last few days on an 'open' data format for > > controlling low cost, user built servo's. > > Interesting project - my comments are interspersed.... > > > The scenario of using a 'proper' closed loop servo for a small mill is > very > > appealing over a stepper. > > While parallel ports are almost free and sufficient for steppers, to > > implement a servo it looks like you have to spend order of $100, mostly > > because of the encoder reading, which is a big jump. > > > > I was wondering on the viability of a PIC (or other) system driven off > the > > parallel port. An 18F24J10 per axis(~$2) could handle the PWM and > quadrature > > in. (At 40MHz, probably two axis) The micro would have to count encoder > > pulses, set the PWM out, and write/read it's designated data on the bus > at > > it's allocated slot. Another micro would handle I/O, directly with a 40 > pin > > chip, or multiplexed. > > Don't fall into the "$2 PIC" trap. Moore's law is driving the cost of > microprocessors and other integrated circuits toward zero, but the rest > of the physical world isn't so cooperative. There is a minimum cost for > just about any electronic "thing" made in small quantities. It comes > from the bare PC board, cables, connectors, bypass capacitors, and other > basic parts. > > For example, a quick search at Digikey says that the cheapest (qty 1) > parport connector (25 pin D-shell) is $2.62. So the connector alone > costs more than the PIC. And that doesn't even start to address the > connectors on the other end - going to the encoder and motor or drive. > > If you have a CNC mill that can mill PC boards, then you can do small > boards for maybe $1 per square inch, or a little less (assuming you > place zero value on your time, and count only the copper-clad stock and > tooling). If you have to buy etched boards and are only buying one or a > few, the lowest price is often between $25 and $50, whether you are > buying one board 1" square, or several boards 3" square. > > I don't want to discourage you, but if you have a cost target that is > well below $100, you need to pay attention to where the money really > goes. It is NOT the sexy new micro-controller chip that will be the key > to the project. It will be how you manage the interconnections. > > One way to minimize the PC board costs might be to go modular. If you > design a very small single-axis PC board, you can divide the setup or > batch charge over many boards. But if you do that, you need to find a > cheap way to interconnect them, or you'll spend all your savings on > connectors and cables. > > The opposite approach is to put everything on one board, to keep the > connectors and cables to a bare minimum. That approach has its own > trade-offs. > > > So the idea is that EMC would clock out a semi-standard data string, and > > read likewise. A user could could have 1 -4 servo's and general I/O > > connected. They would basically sit on the parallel port bus and pick up > or > > drop off their data as required. The four axis would be identical except > for > > data intercepted. > > > > EMC would send out an unconditional? 11 byte packet, something like' > > - start byte > > - PWM > X (2 x 8 bit, but 10 bit used on micro) > > - PWM > Y (2 x 8 bit, but 10 bit used on micro) > > - PWM > Z (2 x 8 bit, but 10 bit used on micro) > > - PWM > A (2 x 8 bit, but 10 bit used on micro) > > - I/O (3 x 8 bit, user allocated as set up in EMC) > > - end byte > > > > and then do an unconditional 15 byte strobed read, something like' > > - Encoder X (3 x 8 bit) > > - Encoder Y (3 x 8 bit) > > - Encoder Z (3 x 8 bit) > > - Encoder A (3 x 8 bit) > > - I/O (3 x 8 bit, user allocated as set up in EMC) > > > > While this brief needs some re-hashing, > > - would the developers at EMC consider supporting something like this? > > That question really doesn't matter. If you write (or convince someone > else to write) a HAL driver for your protocol, it will work with EMC. > The HAL architecture means that EMC itself doesn't know or care what is > happening at the lowest level of motor control. > > If the driver is GPL and reasonably well tested, it would almost > certainly be accepted into the standard EMC source tree, and be > distributed with EMC. "Support" for the users of that driver and the > matching hardware would typically come from the commmunity, with an > emphasis on the maker of the hardware and the author of the driver, just > as it happens with other drivers and hardware like Mesa and Pico Systems > today. > > > - is it viable ? > > Simple question, hard to answer. Servo covers a huge range, from tiny > benchtop machines to multi-HP monsters. People have done the former > with software PWM and encoder counting, using L298 bridges for the power > stage. That can be very inexpensive. On the other hand, large motors > need large and expensive power stages and power supplies, and once you > get into that class, the $200-500 for a Mesa or Pico system is not that > big a price to pay compared to the hundreds of dollars each servo amp > costs. I don't know if there is a viable niche in there somewhere for > what you are describing. > > > - would the system get sufficient use? > > See answer to above question ;-) > > > I realise that the controllers is an enterprise in itself, but EMC would > > only support a fairly strict packet format. It would then be up to users > + > > forums to build/buy a servo driver that complies. > > It would have to be "build" I suspect. > > The major makers of servo drives have two interfaces: +/-10V, and > proprietary digital. They have no incentive to build to an open digital > interface. > > Normal people do have an incentive to build such drives, but designing a > power section (for medium to high power) is far trickier than designing > the interface protocol. A pre-designed and GPL'ed power stage (with PC > board layout) that individuals with minimal electronics skills could > build would be an neat idea. Unfortunately power levels vary. If you > design a 500W drive, half of the people would want 200W, and the other > half would want 700W. > > Regards, > > John Kasunich > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Emc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-users > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
