reprap Marlin/Sprinter gcode printer originated responses.

Hi all,
I've been making some good progress recently after a long hibernation of a project I started about 5 years ago to design an ARM STM32F103 3D printer controller but I'm stuck at the moment,

My X Y and Extrude processing seems to work just fine but after I get an M106 command from Cura and respond with "ok\n"
I don't think Cura is sending me the next line with a Z move i.e: line below ending "Z0.65".

G1 F1200 X14.44 Y-13.00 E85.62775
G0 F3600 X13.64 Y-12.67
;LAYER:1
M106 S255
G0 F9000 X14.70 Y-12.72 Z0.65
;TYPE:WALL-OUTER
G1 F1620 X14.80 Y-11.99 E85.67294

My symptoms are that the layers keep printing at a constant height off the bed as my machine is not seeing the G0 Z axis changes.
At the moment I've only implemented absolute values and I can do G0 and G1 moves fine with hyperterminal, even following an M106 Fan command.

My software is currently physically responding correctly to comments (starting ";"), G0, G1 and most of the M commands with "ok\n", which seems to work fine on Cura for everything apart from the M106 so far. X, Y and Z moves all working fine including with Extruder.

Does anyone know of a different response to an M106?

p.s. for anyone going down this path themselves, Cura expects "ok T:220 B:70\n" replies to the M105 command which it uses to confirm machine presence (where T:220 is an example of the hot end temp and B:70 is an example of heated bed temp.)

Thanks..
Graham.

Edited 1 time(s). Last edit at 12/21/2013 03:09AM by grael.

---

My CNC/extruder creation: [grael-minifactory.blogspot.com]

Sorry guys... I tracked the error.
sorted.
Got to work on a move buffer next...

Hi, I'm looking at running on an mbed LPC1768 (also an Arm Chip)

have you seen the Sprinter board? I believe that's written to run on ARM.

I'm waiting for steppers and controllers before I fire up some firmware.

Is the sprinter and Laoslaser firmware of any use to you ?

Hi Dave,
I haven't tried that hardware.
At the moment I can print some cad shapes but anything with a lot of corners or curves tends to lead to an extruder jam as the head stalls too long (mS) at each floating point calculation.
Stm32f103 doesn't have the maths co processor and the half precision floating point directive for ATM brings up an error, won't compile. So I think it's doing full precision floating point multiply,
Actually making the float calc SLOWER than on a modest little AVR based printer. Embarrassing!
Anyway, I chose ST because they are great at upgrading the hardware that fits on the same footprint, so I'll be getting hold of some stm32f407 soon (with maths co-processor). That should have it up to speed and not oozing at each fp calc.
As for code, I've adapted some gcode state machine logic from an arduino listing + the Rostock delta calcs, no point in calculating the square of the arm length three times for each delta calc so I perchlorate that.
I'm using a 3d variant of bresenhams line algorithm with x, y, extrude amounts.
With a co processor I'd probably up date that to float calcs, faster then for multi filament.

"pre calculate"
Not perchlorate!

WHOOSH !!

That's the sound of 99% of that flying straight over my head.

I think I was confused when I posted my original post, I'd been reading a different thread, and my mind misplaced STM32 for LPC17nn for some reason.

but here is something you will find VERY interesting !

[mbed.org]

ARM / ST are about to support the STM32 chips on the mbed platform.

Having used the LPC on that platform, I can heartily recommend it.