Can I get a stupidity check on my idea please?

TL,DR... Rather than calculating coordinate translation on the fly is it possible or desirable to have a translation map or algorithm in logic where we could plug in cartesian coordinates and get values for the positions of the various steppers in whichever geometry of printer we're using.

Last night I ran across the Cypress PSoC line of chips, essentially a PSoC 5 is a Cortex M3 cpu sitting in a fabric of CPLD/FPGA elements, programable logic in essence. This led me to thinking that if we had sufficient logic and memory to create a large enough look up table it would be possible to generate in advance a full resolution map of the printable area.

Heres my reasoning. Currently translation between cartesian coordinates from the Gcode and stepper positions is done on the fly using significant amounts of processor grunt and yet for each point in the print volume the stepper positions are the same for every print suggesting that these calculations only need doing once.

Advantages:
Lower processor demand -> Cheaper chips or overhead for doing other stuff.
Firmware doesn't need to concern itself with the geometry of the printer hopefully making it easier to try out new and interesting printer ideas.

Disadvantages:
Need somewhere to store the map with quick access (How big would a map be?)
Calibration might be problematic

Comments, critisisms?

Moriquendi

Edited 1 time(s). Last edit at 08/10/2015 06:39AM by Moriquendi.

Hi Moriquendi,

I was thinking the same kind of thing. I think an object is ultimately defined by a series of step instructions for the X,Y, Z axes and the extruder(s). I don't think the timing between the steps needs to be stored. So
I figure that a small simple interrupt-driven stepper driver (one programmable timer for each stepper motor) would do for the printer controller. This device could also look after the nozzle & bed temperatures. This driver would be fed a stream of step instructions from some other, smarter processor. The stepper driver would be responsible for managing the stepper motors in real time.... it would issue the stream of steps at the right time for maximum acceleration, quality, etc. This would require some lookahead and buffering of the step stream. Generation of the step stream would be done by a bigger smarter processor (e.g. desktop PC, Raspberry Pi) which would stream it to the stepper driver. The source of this stream could be a Gcode file, or it could even be generated by a slicer program.

I don't think you need to store the whole object map on the printer. I think you could certainly get away with storing only the current layer. You would need at least a small buffer, because before accelerating you need to know when you need to begin decelerating, so you want some lookahead. If the buffer was too small, the driver would have to assume the next thing it received was an immediate stop, so couldn't accelerate too much. More buffer memory (up to enough for the entire current layer) would mean further lookahead and therefore faster printing.

Frank

Hi Frank,

Perhaps my explanation isn't very good, I don't want to generate a map per printed object rather to have a map for the print area/volume of the printer.



Moriquendi

Im just spit balling here off the top of my head, so could be totaly wrong.

table would need all values from 0 to 200 in X Y an Z (presuming 200x200x200 build area)

even limiting to 2dp (100 points between intergers) thats 20,000 rows, * 3 dimentions = 8,000,000,000,000 rows of data!
thats 8 terabytes just for the index. * what ever your datasize your storing..

sure you could optimise this to only list the points that are used.... but would still be very large and I suspect would take a long time to compute all the pints in advance.

Sure it could be done... but it would be insane!

Edited 2 time(s). Last edit at 08/10/2015 11:36PM by Dust.

I agree with Dust. Also, what's the point? ARM Cortex M3 processors are dirt cheap now (cheaper than the atmega2560), and Cortex M4 are not far behind. Even the M3 is fast enough to compute precise step times for delta printer in real time.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

FWIW

Wally 3D printer uses a pre-program (python) GCODE PreProcessor
to make X Y Z coordinates to polar commands to move the printer motors

[reprap.org]

[forum.conceptforge.org]

GCODE PREPROCESSOR
[github.com]



because functions complex and would really slow down Arduino system

You're cool if you manage to implement such a map in a working fashion.

If you use relative positioning instead of absolute, you could give the map a much smaller memory footprint. Divide long lines moves into smaller ones in firmware before applying map.

Such a relative positioning map would only work by itself if there is a constant relation between motor rotation and hot end movement. In a polar printer or delta style printer you would need mappings between motor rotation and hot end movement, to accompany your relative positioning mapping, which would eat up some of the benefits of your idea. However, cartesian printers would be the ones with the least need for mapping/caching optimizations, so I guess motor rotation -> hot end movement mappings would be needed to make relative positioning mappings interesting and useful.

Anyways, if you limit yourself to cartesian 2d and have maximum movement length of 2 mm, you only need 2*2*70*70=19600 elements in your mapping array, where 70 is my number of steps per mm. Halving your number of steps per mm (for example by choosing 1/8 microstepping instead of 1/16) divides the size of your mapping array by 4.

I would be impressed if you managed to save in on processing time with this idea. But there's no hope for an idea that doesn't sound insane at the outset, or something like that ;-)

cheers

Edited 1 time(s). Last edit at 09/05/2016 05:01AM by tobben.

---

torbjornludvigsen.com