Strange behaviours

I've seen some strange behaviour from my Ormerod on several occasions. The problems started after I created and started using a setbed.g file, although they may be unrelated to that because I didn't do very much before that. The issues I see are:

1. Sometimes, when homing the Y axis when the current Y position is already zero, it doesn't drive the carriage to the endstop. Instead, it tries to drive the carriage in the other direction, as if it is already at the endstop. This usually results in the Y-belt coming off. When this happens, the Y endstop LED is on, as it should be when the carriage is not on the endstop.

2. Sometimes when I try to print (normally immediately after running setbed.g), it brings the bed up to 65C but then starts printing immediately, without waiting for the extruder to come up to temperature, or even turning it on. Once I tried to get round this by presetting the extruder temperature to 205C, but when I started printing, it turned the heater off.

Here is my config.g file:

; RepRapPro Ormerod
; Standard configuration G Codes
M111 S1; Debug on
M550 POrmerod; Set the machine's name
M551 Preprap; Set the password
M552 P192.168.1.80; Set the IP address
M553 P255.255.255.0; Set netmask
M554 P192.168.1.254; Set the gateway
M555 P2; Emulate Marlin USB output
M92 E420; Set extruder steps/mm
G21 ; Work in mm
G90 ; Absolute positioning
M83 ; Extrusions relative
M558 P1 ; Turn Z Probe on
G31 Z1.0 P368 ; Set Z probe height and threshold
M906 X800 Y800 Z800 E800 ; Motor currents (mA)
M557 P0 X60 Y0
M557 P1 X60 Y160
M557 P2 X230 Y160
M557 P3 X230 Y0
T0 ; Select extruder 0

and here is setbed.g:

; RepRap Ormerod bed setting procedure
G1 Z10 ; raise 10mm
G28 X0 Y0 ; home the X and Y axes
G1 X60 Y0 ; move to nearest corner foil
G28 Z0 ; home the Z axis
M557 P0 X60 Y0
M557 P1 X60 Y160
M557 P2 X230 Y160
M557 P3 X230 Y0
G32 ; execute bed plane measurement procedure

Any ideas? I used to home the X and Y axes again after the G32 command, but when I did that, problem #1 always happened.

I'm printing via the web interface - I can't print anything via Pronterface, it just says "illegal M27 command" forever when I try.

Hi, That Y homing after bed compensation is a known issue, and I hope they may have addressed it in yesterdays build (I haven't tried to see if it works) ...

Quote
https://github.com/reprappro/RepRapFirmware/commit/10bf338aa4bb118827d2e53d7ea9d805b9051074

Homeing after bed transform applied bug fixed in the duet branch.

Not sure that the behaviour described in the blurb is the one that you mentioned, but hopefully it is, since it shakes the belt loose after a couple occurences

Ray

@dc42 I Have precisely the same/similar issues that I believe occurred after the setbed.g operation. As Ray points out and I have an email from Ian this is being investigated. You can print by deleting any g-codes for homing in the file.

I also have similar if not the same for the 2nd points see [forums.reprap.org]
I get the M27 errors but I think they are ignored when I print (using pronterface) from file (which works with 'homes' deleted), but I can no longer get the files on the SD card to print, they just sit there with no action as shown in my post.

Sorry to say this, "but I am glad I'm not alone", I hate unique problems!
I can't try anything now for a week, sob but hope to be very active after that. I'll watch any developments with interest.

Hi @all,

I just installed the new firmware and it looks like the y-axis homing error is ironed out.

Markus

---

XBee & electronics blog: [lookmanowire.blogspot.com]

Yes, it's a bug. Well, not a bug, more that Adrian sets up his printer in particular way, and hadn't expected people to do it another way! And we had been doing it the same way, without realising. Which is:

1. Turn on
2. Home axes
3. Send setbed.g
4. Print!

The proviso is that you don't home AFTER sending setbed.g. Because of the bed compensation, if you home again after sending setbed.g, the movement of the other axes (due to axis compensation) causes odd triggering of the endstops. I think Adrian has created a work around. If you update to the firmware in the 'duet' branch, you also need to update the contents of the SD card, I think.

Also, use our profiles for Slic3r, which doesn't home the axes at the beginning of the print, or remove any G28 commands (first 20 to 30 lines) of any gcode file.

Ian
RepRapPro tech support

@Ian, any thoughts on our second issue?
See dc42 original post and my own.
Thanks

Probably not related to problem #2, but I spotted a bug in the firmware. When processing the G10 command, there is no range check on the P parameter. As a result, if you pass any parameter other than -1 (which would set the bed temperature) or 0 (to set the extruder temperature), memory will be corrupted.