Hi All,
You might want to take a look at a Saxo board sold through the
www.knjn.com site. It combines the Cypress CY7C68013, with an Altera FPGA
and an ARM7 microcontroller. both the FPGA and the ARM7 can be reprogrammed
through the USB port, which simplifies code development. Even if you do not
use this board, the fact that you can update embedded code through the USB
port is worth knowing.
Separate subject: In my 3-axis microscope stage controller, I have a means
of mixing imperative commands like Stop into the the positioning command
stream. At the upstream end of the USB connections, the imperatives are
inserted ahead of buffered positioning commands, and at the downstream end
these commands are acted on without going through the FIFO buffer used for
the positioning commands. Each positioning command, that is like a G Code
block in binary is given a 1/100 second timestamp at the upstream end and
this timestamp tells the embedded control system when the command is to be
executed.
John Harris
----- Original Message -----
From: "Jon Elson" <[EMAIL PROTECTED]>
To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
Sent: Thursday, October 30, 2008 10:05 PM
Subject: Re: [Emc-users] Parallel port in the future - query
> 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
> Emc-users@lists.sourceforge.net
> 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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
