Y-axis behaviour

As in another thread stated, there seem to be homing problems with the axes, so I would like to isolate the issue with the y-axis in this thread.
In the meantime I can reproduce the y-axis crashing.
Everything is done from Pronterface:

Code looks like this:

G1 X60 Y20, move to position for setting Z to zero
G92 Z0; setting z-axis to zero when reaching bedplane
G1 X55 Y0; moving to left corner for proximity sensor measuring, proximity sensor has to be clear above foil
G31;repeat as long as value is between 600 and 700 as stated in the instructions
M114;command for seeing z-axis value in pronterface (ethernet/ web is not working on my board)
G31 Z1.6 P666; my values, yours might vary

Then I call setbed.g, mine looks like this:

;bed plane compensation
G30 P0 X60 Y20 Z0.0
G30 P1 X60 Y180 Z0.1
G30 P2 X180 Y180 Z-0.2
G30 P3 X180 Y20 Z0.1 S
M556 S75 X-0.65 Y0 Z-0.65

Then I open circle.g (notice circle.g is NOT homing before "priniting")

Circle.g gets printed. Everything looks ok. Z-gears moving shows compensation in effect.

Then I either try to home the y-axis or open a file to print.
In both procedures y-axis is crashing into the right end.

My y-axis endstop is working - you can monitor if the y-axis endstop is working by looking a led D9 on the pcb (above the y-axis endstop connector). "ON" means y-endstop not activated, led "OFF" means activated. For the EEs - the endstop seems to be debounced via an RC-circuit (C41: 0.1µF/ R57:100ohm).

After discussing with Ian, it might be wise to comment out homing before printing (at least) from Pronterface. I will try that later.

Markus

Edited 4 time(s). Last edit at 12/18/2013 06:12AM by markbee.

---

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

Hi Markus,

I was about to post something similar (and treth has mentioned this in another thread I think) - my Y axis takes off in the wrong connection after setting the bed compensation too (generally I edit the homing commands out of gcode files to run them after I've manually homed and compensated). In repetier host you can edit teh file you're about to run (you can also kill a file when it is running), I can't see this facility in pronterface


Ray

Hi Ray,

you could hit "Pause" and "Restart" to cancel and restart a print in Pronterface. No stop-buzzer though (my hand is always near the PSU switch while testing this beast ).

Interestingly if I print circle.g coathook.g or snowman.g (from the SD-image) everything runs fine after zeroing z-axis and calling my compensation file.
Looking at the gcode they have no homing sequence (G28: Move to Origin) at the beginning compared to the other "problematic" files (like the gcodes provided by RepRapPro to print Ormerod print parts). This might be one of the problems.

[EDIT] Just tried: Commenting out G28 will print the files. But new errors come to light. Extruder sometimes reverses way too much filament and then the print will fail. Arrghhh. This is a step by step beta test ;(

One word to the proximity sensor: it looks like the sensor is very sensible to ambient light. If in my setup (low winter) sunlight is falling through the window on the printerbed, the values vary in the tens or even by 100 points (thats some tenth of millimeters) to situations with no sunlight. In my opinion this almost renders the sensor as useless. It's obvious why IR remote controls are sending data-signals which are modulated on about 36kHz carrier waves to avoid any influence from ambient light.

Markus

Edited 2 time(s). Last edit at 12/18/2013 09:04AM by markbee.

---

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

I finally got the machine to start printing ormaxis.g, it got about half way through and the Y-axis suddenly jumped 50mm to the right and crashed.

Just got my printer up and running (after having to buy new SD card and resolder USB connector).
I had the issue with Y axis crashing when hitting the home button.
Resolved by changing the end stop microswitch connection from normally open to normally closed (two outermost pins).
Hope this helps.

Hi mdearman,

how did you print? From ethernet, Pronterface/ serial oder Pronterface/ SD card? Between Pronterface serial and Pronterface from sd card are major differences in printing. Printing from serial seems to be too slow and gives blobs.

Markus

---

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

I printed from the SD card using the ethernet interface. After many failed starts it was looking good then just screwed up mid print

Finally got it to print the axis compensation parts without crashing, when i did there is a lot of creep in the Y axis on the lower layers, (see attached photos).

Hi mdearman

As I said in another thread: the Y axis belt, where the two belts interlock, needs to be tightly held in the y-rib. To check it is, hold the Y axis motor pulley and try to move the Y carriage. I had to slip a small piece of paper, folded, below the two belts where they interlock, or it slipped in one direction. I have added this to the build instructions (last step) [www.reprappro.com]
We're looking at altering this a little for the next set of printers, to improve the belt location.

Ian
RepRapPro tech support

Edited 1 time(s). Last edit at 12/18/2013 03:46PM by droftarts.

With my Y axis, the two belt ends hold each other securely. The problem is that the Y axis rib does not grip on the two belt ends.
In one direction (away from the motor), the belt loop stops relative movement by tightening up. It is when the table is pulled towards the motor that everything slips through the wood.
We need to increase the friction between the wood and the outsides of the belt - I'm not sure wedging paper between the belt ends will do the trick.
Greg

That sounds more likely, I couldn't insert anything in the gap because it was so tight but the prints are still distorted in the Y axis. About to glue the belt in place and see what happens

I used one of the bulldog clips snugged up to the rib and clamping the belt end to the main belt - seems to work fine.

Gluing the belt to the rib seems to have fixed the Y-axis distortion.

What glue did you use?
Greg

Hot melt glue from a glue gun

@Markus

I now have board levelling correct, thanks.

I started a print and the PLA didn't stick so hit "Pause", tried adjusting the z height, but having made a mistake, decided to restart.
Home X was OK, Home Y crashed into the right end stop!
It has never done this before.

Did you resolve this?

@treth - I think that the y probe axis crash after bed levelling has been addressed in the latest firmware (noticed it uploaded last night but was too busy printing to try it out ) - I'm only presuming this as Ian asked me if I had the problem in irc yesterday, and the latest post refers to his notes on homing problems ... presumably this is the first time you've levelled the bed

Edited 1 time(s). Last edit at 12/20/2013 05:39AM by rayhicks.

Quote
rayhicks
@treth - I think that the y probe axis crash after bed levelling has been addressed in the latest firmware (noticed it uploaded last night but was too busy printing to try it out ) - I'm only presuming this as Ian asked me if I had the problem in irc yesterday, and the latest post refers to his notes on homing problems ... presumably this is the first time you've levelled the bed

Thanks Ray, I shall update later......
Foolishly I thought it was level I had been trying to get the PLA to stick, not realising it was a bed levelling problem, so yes, this is the first time I levelled it.

@treth - just asked ian and it appears it's other homing issues that are addressed - but the Y issue is being looked at.

In the meantime: - If I'm in a hurry (all the time these days...), I home Z at roughly where the print will be, then move the head to somewhere near the x/y origin and tell the printer that that is home (in repetier host for mac I use the "set home" button) - essentially it's the same command you use to manually home Z when levelling the bed but you include the other two axes: G92 X0 Y0 Z0 (remember that I already homed Z using the probe where the print will take place).

As far as adhesion goes, I've stopped using kapton (except as a replacement for the bulldog clips - I use it to bind the glass to teh mdf, makes for more rigidity without any obstruction) and coat the glass with a thin smear of plumbers PVC pipe cement (it contains a bit of epoxy and I think ABS?) this dries instantly and the PLA sticks really well. Any patches left by removing a print are touched up in two seconds, and it doesn't rive up and make a mess if teh head hits it. (it also probes fine on my machine).

Ray