Jon, Jon Elson wrote: > John Kasunich wrote: > > >> This subject seems to come up every month or two. The answer is and >> will probably always be the same. >> >> Yes, it is possible to make a box that lives outside the PC and can >> queue up enough motion "in advance" that it doesn't require realtime >> performance from the PC. >> >> >> > I agree that taking the PC completely out of the real-time game is a > mistake in two senses. First, we've already done the "heavy lifting", > and it works. Second is, if you are NOT real-time, then there is no > upper bound to latency, and one day, the system won't get the data there > in time, and the buffer will run empty. The machine will crash to a > stop, possibly with disasterous consequences. > > But, there might be another way. Keep EMC real-time, but have a USB > device that can pump out parallel bytes from a FIFO. This requires EMC > to sync to the USB clock instead of the system timer. Every tick of > that clock, a whole batch of step pulses, just like they are spoon-fed > to the parallel port now, would be buffered and sent to the USB device > to be de-buffered at a constant rate such that as the last byte was > sent, the next buffer would be ready. I think the Cypress CY7C68013 can > do all this in hardware, once configured. > >> You can do that if you want, but you lose one of the big benefits of PC >> based control. On a PC based control, it is easy to find problems, add >> features, and update the software. If you embed everything in some >> external box with no keyboard, no screen, no development tools, etc, you >> are rather locked down. It's one thing to embed simple stuff that can >> be tested and proven robust, and that is unlikely to change. It is much >> tougher to embed complex code that will need to be debugged and changed >> to meet evolving needs. >> >> > Well, using the Cypress chip, or some other USB-FIFO device, is an > intermediate step. If it only has a one ms buffer, the user would never > know the difference. And, it would not be moving all the motion control > of EMC into some external device, it is just a FIFO and an interface device. > Of course, it needs real-time determinism on the USB. I have no idea > what state that is in, but I think there has been some work done in that > area. > A quick Google search appears to show that EVERY document containing the > text "USB" also contains "real time", using it to means something > happening within a couple of seconds! UGH! But, it looks like Jan > Kiszka, who did the rt-net package also has a USB stack for rtai, > originally started by Joerge Langenberg. I should point out that I am > NOT volunteering for this project, although after I get some hardware > and software expertise with this Cypress chip, I might be willing to > contribute to such a project. > > I have a bigger interest in possibly using this chip to connect my other > boards to a PC without parallel ports. It might also increase the > performance, as the CPU having to process each byte laboriously through > the parallel port is becoming a bottleneck. But, I don't know if the > chip, or the USB model, is really conducive to the existing boards' > model of communication. The fact that it can do one-way FIFO transfers > without intervention of the slow 8051 CPU is tantalizing, though. With > some additional FPGA logic to format blocks of data to be read from the > FPGA to the CPU, though, I think it MIGHT work. I need to learn more > about how many balls this chip can keep in the air at once. But, the > idea is : Every micro-frame, the FPGA sends encoder position and digital > inputs to the CPU, and every micro-frame, EMC sends new velocity and > digital output info the the FPGA, based on the last data it processed. > It would always be one microframe out of sync, as the commands it is > sending to the FPGA are based on readings taken 2 microframes ago. But, > as long as it is deterministic, it should work. > > Jon > > ------------------------------------------------------------------------- > 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 > >
maybe this is of interest RT-Firewire on Linux, using Xenomai (RTAI ) used for robotics, for realtime control of positioning systems it also enables RTnet over firewire several nice papers at http://www.rtfirewire.org regards TomP ------------------------------------------------------------------------- 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
