bdring wrote:Well, my original response was to Ben's engraving with G-code question. There is more going on than just G-Code. You should profile the read time for the SD card. You may need to adjust the code around that timing.
The XMOS is a better chip for the problem if being a popular open source platform is not part of the problem. That is why I stopped working on the project. There was no collaboration interest.
bdring wrote:I would continue with the Arduino. Even if it is vector only, I think it would be a nice option. If you switch to the Maple or XMOS, I would be glad to sponsor you with some hardware.
BenJackson wrote:Bart & Dirk,
I'm definitely interested in driver collaboration. My goals would be:I can get a Mini-ITX motherboard, a stick of RAM (1G or more) and a USB flash drive to boot off of for about $100. In terms of enabling Ethernet, a PostScript interpreter and having tons of memory, this combo is impossible to beat with any kind of "dev board" solution. I could run something like EMC2 and have a known-working motion control system good to at least 1000mm/s on the 2.x setup. What it lacks is any GPIO more sophisticated than a parallel port.
- Ethernet connected
- Acts as network print server, accepting PostScript
- Automatically handles raster and vector operations based on color and possibly other in-band information
- Configurable via webpage for out-of-band settings
- Perhaps also accepts gcode on a separate port
That leaves laser PWM. Back-of-the-envelope math says 500mm/s at 600dpi would take about 115.2k bps, so the serial port bandwidth is probably enough. Perhaps a small board that accepts serial bytes and clocks them out (as PWM) based on strobes from the parallel port (to sync). That would be something Bart could even add to his control interface.
Users browsing this forum: No registered users and 38 guests