replicatorg + send.py inconsistencies on ramps, windows xp and teacup

Hi,

I am building a Prusa Mendel with heat bed and have been playing around with Teacup firmware.

I try running some gcode like this in ReplicatorG and send.py

G21
G90
M105
G1 X50 F500
G1 X0 F500

In ReplicatorG, I get no temperature reading for the heat bed, but the motor moves.

In send.py, I get temperature reading for heat bed, but the motor doesn't move.

Thanks in advance for any suggestions on how figure this one out.

Here is some more info about this problem ... I just tried the send.py experiment on a macosx 10.5.8 and got no motors moving and this time no temperature readout for both the extruder and the heatbed.

I use Teacup and have issues with communications between repG/repsnapper due to some hardware issues. My solution is to turn on Xon/Xoff in Teacup and send the raw Gcode file to my Arduino/Ramps using GTKterm. Just make sure DTR and RTS are turned off in GTKterm (or mincom or other serial terminal) and Xon/Xoff flow control is enabled.

At 115200 and a 4kb buffer it never pauses at all. (default teacup)

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

GTKterm use in Ubuntu: apt-get install gtkterm

instructions here
[fedorahosted.org]

teacup is fairly experimental. i recommend everyone try it as it is incredibly efficient, but try the default reprap firmware first to ensure the host programs and serial communications work.


also here is a link that talks about recent changes to mcodes used for heating beds

[fabmetheus.blogspot.com]

read extruder temp is m105

i think repsnapper has issues returning both the extruder and bed heaters. does repsnapper work ok if your extruder is turned on? Any case there is a link about repsnapper bugs here [forums.reprap.org]

you may want to try this with send.py, i am not sure but there may be issues with the device initializing and not knowing where zero center is.


G21
G90
M105
G92 X0 Y0 Z0 E0 ; //sets all values to a known zero center
G1 X50 F500
G1 X0 F500

jamesdanielv Wrote:
-------------------------------------------------------
>
> G21
> G90
> M105
> G92 X0 Y0 Z0 E0 ; //sets all values to a known
> zero center
> G1 X50 F500
> G1 X0 F500


Instead of G92, you should use G28 to home all axis. G92 X0 Y0 Z0 will set the origin to the current position which will probably be different each time.

G28 X0 Y0 Z0 would home all the axis.

I think the issue is he is unable to get the teacup firmware to run. I am not sure if homing is an issue or not. the point was to provide the coordinates to the controller so it new where it should be in any case they were not set. repsnapper sets that right up front. i am not sure that send.py does...


All the same i still think using reprap firmware is the way to go first, then move on up to the teacup. the teacup again is very impressive.

G92: Set Position (just sets where you are at to whatever value you specify)
G28: Move to Origin ( I'd need to check but i think all uses of this require homing,often to a switch or opto)


either could work, but G28 could be dangerous if there are no limit switches.

Edited 1 time(s). Last edit at 06/03/2011 12:20AM by jamesdanielv.