On Wed, Jun 03, 2009 at 09:32:58AM -0700, Kirk Wallace wrote: > > I prefer to have EMC2 do as much as it can. If I understand the term > "state" correctly, I would just use parport I/O and handle the logic in > a hal component.
In the context of the tool changer, state is e.g. "Awaiting Tool Docking", with a transition to "Tool Docked" if the input is received, or maybe a transition to "Docking Error" on a timeout. (Software timers are part of the state machine environment.) The state machines do what ladder logic does, but there can be multiple state machines, e.g. one for the tool turret, one for a transfer arm, and one for ... , all exchanging events (called "signals" in SDL) with each other and hardware. (One advantage over ladder logic is that signals can carry parameters.) Simply, instead of running about endlessly in subroutines, code is not executed until an event arrives. When it does, the event is handled at the current state of the state machine, by a single transition (i.e. short list of program statements), on the way to the next state. This is well suited to control of robotic devices such as tool changers, because they don't need to do a lot of background complex mathematics while waiting for a tool to come back. :-) > For the rest of the machine, I've gotten away with software signals, > but in this particular situation I need to have a fast hardware PWM > signal. I could use a Pluto-P or something similar, but for just one > signal, it's over-kill. Ideally, I would have a $20 board with an SPI > input and a PWM output, which I could use where ever it's needed. Then > not worry about, when I upgrade the rest of the machine to a grown-up > I/O controller. This ST L99H01 seems to fill the bill: > http://www.rutronik.com/index.php?id=939 > > but I don't know if they are available yet. > Ah, the floating current sense is attractive. I started on a board with an AVR and H-bridge, but need to go back and verify that the proposed ground-referenced sampling of the bridge current will work as in my mind's eye. But I'm sidetracked with EMC2 now, chasing up parts to make that a reality first. > A micro-controller can also be a cheap solution, but the problem is that > they can also do a lot more, so it's tempting to add more features and > lose the original intent. And when you've spent several decades doing that for a living, it's so easy to say "I can do that in my sleep.", but then not find the time for it, because it's more stimulating to do something new and weird, like a mill conversion. I've found it hard to stick to one cheap AVR, one H-bridge, and one motor per card, when there's easily PWM for three motors on the chip. > Another rambling thought, is that you could have these $20 > micro-controller boards that you plug into a socket and turn them into > whatever function you need at the time. If a bootloader is included, then firmware upgrades can be downloaded from the EMC2 host, if there's a serial channel for that. I've chosen RS-485 for the obvious noise immunity benefits. > I think this is what the Arduino is about. When I last looked at them, they looked more like a chip, a crystal, and screw terminals. (Perhaps there's been progress since.) It's more convenient to have the motor controller on the board, than have to lash up drivers and a bridge externally. > I suppose this is just a > matter of creating an EMC2 "hardware comp" application. The card could > have a few EMC2 terminals that connect to a parport (for SPI), a few > machine side terminals, then a USB port. You plug the board into the > PC's USB port, a window pops up, you press a button to select the > function you need, and presto, you have an ADC input, fast PWM output, > fast encoder input, or whatever you need that the parport can't > normally do. > > The problem here is that there is no good way to handle > all the machine side signal conditioning and still keep things simple. True, but it's easier to do with the new XMEGA devices, because they can route signals in on-board hardware in that way. Still, a suitably flexible firmware environment on an ordinary AVR could be configured in EEPROM to enable ADC channels, set up PWM outputs, and select pins as input or output. Interconnecting them efficiently, or doing anything specific with them, would require recompilation and download of new firmware, though. Erik ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
