Cherry Pi III Is Available

Hate to repost, but do all the endstop switches have to be at the same height? ( Only two are at the same hieght and one is off, one wont fit into the hole)

Edited 1 time(s). Last edit at 05/22/2015 01:35AM by mikes3ds.

I think it's reasonable to assume that they should be at the same level - they define the height of each tower, and thus the home position.

But if anyone has a more accurate answer then I won't be offended!

Quote
mikes3ds
Hate to repost, but do all the endstop switches have to be at the same height? ( Only two are at the same height and one is off, one wont fit into the hole)

I think I would agree with DavidJ on them being at the same level IF USING A RAMPS with a DUET it doesn't matter because each endstop height can be adjusted in firmware (DC42's Autocal function does this automatically).

If need be you could make some small packers to fit to your carriages to back them all in line or lift the corner bracket on the vertical for the one that is low.

HTH Doug

I am sure someone with more knowledge on Ramps and Deltas will answer but it may also be an idea to post a general Question rather than in the Cherry pi thread (I know it is Cross posting but just thinking of addressing the whole community)

Quote
David J
For the first run I only used the default 5 probing points - 4 near the periphery, one in the centre. In the next session I plan to get more ambitious. I haven't worked out how to change the number of probe points yet - is it simply a matter of adding lines to the config.g file, where it currently shows a list of 4 probe points?

It sounds to me that you may have started from the wrong config file. 5-point probing is typically used for Cartesian printers I suggest you do the following:

- If you are not running version 1.04f or 1.09a of my firmware fork, upgrade the firmware.

- Take a look at the files in [github.com]. You will find that the config.g file does not have any M557 commands in it. All the configuration for G32 bed probing is done in the bed.g file, which looks like this:

; Auto calibration routine for delta printers
; Before running this, you should have set up your zprobe Z offset to suit your build, in the G31 command in config.g.

M561					; clear any bed transform, otherwise homing may be at the wrong height
G31 X0 Y0				; don't want any probe XY offset for this
G28					; home the printer

;*** Remove the following line if your Z probe does not need to be deployed
M98 Pdeployprobe.g			; deploy the mechanical Z probe

; The first time the mechanical probe is used after deployment, it gives slightly different results.
; So do an extra dummy probe here. The value stored gets overwritten later.
G30 P0 X0 Y0 Z-99999

; Probe the bed and do auto calibration
G30 P0 X-73.6 Y-42.5 Z-99999		; X tower
G30 P1 X0 Y-85 Z-99999			; between X and Y towers
G30 P2 X73.6 Y-42.5 Z-99999		; Y tower
G30 P3 X73.6 Y20 Z-99999		; between Y and Z towers
G30 P4 X0 Y67 Z-99999			; Z tower
G30 P5 X-73.6 Y20 Z-99999		; between Z and X towers
G30 P6 X-36.8 Y-21.25 Z-99999		; half way to X tower
G30 P7 X36.8 Y-21.25 Z-99999		; half way to Y tower
G30 P8 X0 Y42.5 Z-99999			; half way to Z tower
G30 P9 X0 Y0 Z-99999 S7			; centre, and auto-calibrate 7 factors

;*** Remove the following line if your Z probe does not need to be retracted
M98 Pretractprobe.g			; retractthe mechanical Z probe
G91
G1 S1 X170 Y170 Z170 F15000		; go part way up to speed up homing, endstops activated just in case
G90
G28					; Home the printer again

You can get rid of the deploy and retract probe calls, they are for the Mini Kossel mechanical probe. You can also get rid of the dummy G30 call, that is for the mechanical probe too. Adjust the XY coordinates in the ten G30 commands to define suitable probe points, making sure that the IR sensor is over the bed at all of them. I suggest you have them approximately at the positions indicated in the comments, but they can be anywhere as long as they cover all areas of the bed. You can have more probe points if you like (up to 16), just increase the P parameter from each one to the next, and move the S7 parameter to the final one. Change the S7 parameter in the final G30 command to S6 if you don't want the diagonal rod length adjusted, or to S4 if you don't want the tower positions to be adjusted.

The final homing call isn't actually needed any more because the firmware now takes account of the new endstop adjustments immediately.

If you want to see what is actually going on, then connect Pronterface and send M111 S1 P4 to enable Move debug before you execute the G32 command. Don't forget to cancel it with M111 S0 before you print.

Edited 1 time(s). Last edit at 05/22/2015 04:24AM by dc42.

---

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].

I'm on 1.04f, but I can't remember where I got the config file - I'll update it ASAP, and also sort out bed.g.

Are there any advantages to upgrading to 1.09a? Or shall I stay on 1.04f for now?

Thanks again.

The main improvement in 1.09 is to support DHCP and Netbios names, to make connecting via Ethernet easier.

---

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].

Quote
mikes3ds
Hate to repost, but do all the endstop switches have to be at the same height? ( Only two are at the same hieght and one is off, one wont fit into the hole)

Ideally, they should be as close as humanly possible. In the non-ideal world, one of the first steps in manual calibration is setting the endstop offsets for each tower, since the printer is usually more accurate than a ruler/eyeball. If you know that one switch is off by a few millimeters, you can estimate the difference and set the offset for that tower appropriately before starting the calibration process.....

For a change, today I have Cherry Pi question rather than a Duet one (I think).

My printer is now fully wired and running - there are a few details to sort out, such as devising a way to fix the print bed glass in place, but generally there's nothing more to add.

Now I've noticed a problem: when I print a small cube everything is OK, but if I print something thats 6 or 7 cms across the bed the first layer is uneven. The filament laid down at the front is reasonable, with a sensible thickness and width. However, as the effector goes towards the Z tower (i.e. Y value increases) the filament is laid down very thin, almost to the point of not printing anything. It's as if the bed is on a tilt (I don't think it is). I've tried various gcode files, I've swapped the rods around (actually they fell out as I was fiddling, so they must have been refitted in a different and random order!). Auto-calibration has been run (frequently) and it looks like the dimensional values in the config file are very close to those that auto-calibration generates.

So now I'm looking for possible causes - any suggestions for causes, recommended checks & tests gratefully received.

Setup:
Standard Cherry Pi IIIs
220mm dia bed
Duet controller board
IR Z-probe

It sounds to me that you have a sensor height error near the back tower. Here are some suggestions:

1. Are you certain that the effector is is remaining in exactly the same plane as it moves in the X and Y directions? If the effector tilts as it translates, then because the IR sensor is offset from the nozzle a little, the relative heights of the nozzle and sensor will change, leading to the sensor triggering at different nozzle heights. This is a potential problem with any sensor that does not use the nozzle itself as the probe. You can tape a drinking straw (or something else long, straight and light) across the effector, parallel to a line between the nozzle and the sensor, to make it easier to see any tilt. Another way is to place the nozzle so it is just touching the bed, then use feeler gauges to measure the height of the edge of the sensor board above the bed. Repeat at different points on the bed (e.g. at the centre, and near the back tower).

2. Try executing G30 commands at various points, for example in the centre, near the front, and near the back tower. A plain G30 command will lower the nozzle to the trigger height and stop. Measure the nozzle height after each G30, for example by seeing how far you need to drop the nozzle before it grips a piece of paper on the bed. If the trigger height changes from front to back, then the effector may be tilting as it moves, or if the sensor is behind the nozzle then perhaps it is too close to the edge of the bed at the probe point near the back tower.

---

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].

I hear what you're saying, and it makes sense - it's a strong possibility.

I'm currently making parts to fix my heatbed glass down firmly, and once that's done I can start investigating the geometry. My effector plate is not the standard one, so it's always possible that there's an error in its design; in the original part designed by Maso, the probe tip is the sensing point so any errors are irrelevant. That sounds like I'm criticising Maso, which is not the intention - his effector works if used as designed - it's me who re-purposed it. At least I have the OpenSCAD source so I can always 'tune it' if I find an error.

I'll report back once I get a chance to play with it.

Hmm - the printer's definately got a slight tilt. I didn't need to measure it, as I can clearly see the difference in sensor height going from front to back in the Y plane.

Now I've got to do some checking to see if I can identify the cause... I guess it's going to be:

* towers vertical
* rod lengths equal
* rods parallel in all positions on the bed

Anything else?

Quote
David J
Hmm - the printer's definately got a slight tilt. I didn't need to measure it, as I can clearly see the difference in sensor height going from front to back in the Y plane.

Now I've got to do some checking to see if I can identify the cause... I guess it's going to be:

* towers vertical
* rod lengths equal
* rods parallel in all positions on the bed

Anything else?

I spent days trying all sorts to correct it on mine and eventually gave up tho I will probably return to it at some time, In the mean time I have bought some Alluminium Kossel parts from Robotdigg and everything is much more solid now going to attempt final wiring and calibration this afternoon.

Need to wire in endstops and Hotend/Fan/Sensor/Extruder and update firmware on the Duet.

Doug

Aargh!!!

It never rain but it pours...

While fiddling around trying to check the printer's geometry, I had to unhook the GT2 belt on one of the columns - and now the damn thing won't stay put when I try to replace it. The problem is that the 2 sides of the slot in the rod carrier have been wedged apart due to the belt tension, the slot is now wider, and now the belt teeth slip over each other. I've tried various dubious fixes (e.g. tape on the back of the belt to make it thicker) but nothing seems to resolve the problem.

I wish the belt fixing was a bit more positive, e.g. some form of screw clamp.

...and breathe, deeply...

Quote
David J
Aargh!!!

It never rain but it pours...

While fiddling around trying to check the printer's geometry, I had to unhook the GT2 belt on one of the columns - and now the damn thing won't stay put when I try to replace it. The problem is that the 2 sides of the slot in the rod carrier have been wedged apart due to the belt tension, the slot is now wider, and now the belt teeth slip over each other. I've tried various dubious fixes (e.g. tape on the back of the belt to make it thicker) but nothing seems to resolve the problem.

I wish the belt fixing was a bit more positive, e.g. some form of screw clamp.

...and breathe, deeply...

David

Are they the Std carriages or Pointy's modified ones (I Have a set of each that you can have to get you going again if you wish) Can't remember where you are mind I am ~Near Chesterfield.

Doug

Doug,

They're the standard ones - they've been a source of frustration for me from the beginning.

I've decided to have a go at designing something more straightforward in OpenSCAD... something simple like a post to loop the belt around, fixed with a cable tie. if that fails, I'll take up your offer!

Thanks,
David

Edited 1 time(s). Last edit at 05/24/2015 11:26AM by David J.

So here is my alternative rod carrier:



Thingiverse 846838

It is a remix of the excellent work by maso27 - he created the original alternative rod carrier in OpenSCAD, which I then modified to incorporate the belt fixing posts. Modifying his code was easy as it was very well written and well commented. Please note that my changes account for about 5% of the total code, and the rest is down to maso!

At the moment the posts are quite small so that I could use my original belts - if they prove to be fragile then I can easily make them larger as all my additional code is parameterised (as is all of maso's work). Unfortunately that would mean replacing the belts. The posts are holding up well at the moment though.

Now perhaps I can continue to investigate my geometry problems - although they don't seem so pronounced since I change the rod carriers...

I used to use belt posts and cable ties - although the posts were square, not oval like yours:



I found it unsatisfactory. The tension on the belts caused the cable ties to slowly slip along the belt. I mostly solved the problem by using two cable ties instead of one. When I rebuilt the machine, I switched to these carriages:



The belt is held locked to itself in the groove. I have found this to be far more satisfactory.

---

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].

I realise that it's a bit basic (I have no shame!) but already I have found it far easier than the original system. It took me just a couple of minutes to fit the belt after attaching each new rod carrier to the carriage, which is a massive improvement over the original system. After all, this is the way that all the belts on my Prusa i3 are fixed, and they haven't shifted in the past umpteen months.

However, a future development might be to put teeth on one side against the belt and a flat plate on the other, so that when I push the belt in it's locked - backed up by a cable tie round the corner. This depends on me working out how to do it in OpenSCAD of course!

As an aside: I have found these belt tensioners to be easy to make and to use: Thingiverse 717447.

Edited 2 time(s). Last edit at 05/25/2015 02:53PM by David J.

Finally got my prusa i3 steel up and running,its nice having both so different in printing

Could anybody tell me why my lcd display is dim and if its not plugged into pc it just lights up no writing?

I've been playing around with the effector on my CherryPi, trying to do some diagnostics on the problems I encountered when using dc42's IR Z-probe (nothing wrong with the probe, it looks like my effector's tilting and messing up the readings). I thought I'd try a 'zero X/Y displacement' probe to see if the results differ.

The temporary replacement effector is from the design by maso (Thingiverse) and is the type that activates when the hot-end tip touches the bed surface. This is a lot like Andy's original design, but the E3Dv6 hot-end is held under the effector plate. It works, but I'm having problems setting the probe height.

For a start, I'm using a Duet board, and the z-probe type has been set to P4 in the config.g file. The Duet has been loaded with version 1.09a of dc42's firmware.

Here's what I've done so far:
1. Moved the effector down until the tip is at the ideal height off the bed (thickness of a piece of paper).
2. Moved down further until the z-probe switch is activated.
3. Calculate the difference between the 2 values.
4. Enter the value in the config.g file, as follows (e.g. for a difference of 0.5)

     G31 X0.0 Y0.0 Z0.5 P500			; Set the zprobe height and threshold (put your own values here)

I have assumed that the Z offset value should be positive as the Z-probe trigger point is 'below the bed' as far as the effector is concerned. Is this reasonable?
5. Ran the Auto Bed Compensation, then tried a test print.

Trouble is, the nozzle is running hard against the glass when printing. Is there anything wrong with my technique, or should I do things differently?

Another problem I'm having is that the stiffness of the bowden tube and the hot-end wiring is triggering the probe in one position - but I hope that will be relatively easy to fix by rotating the effector so that the stiffness has less effect.

Any comments on the main issue will be gratefully received!

David

Note: dc42's IR probe would be the ideal solution, and it's currently doing sterling service on my Prusa i3 (allowing me to print on glass once more). Once I've done my investigations I'll probably try again (or order another!).

Hi David, you need to use a negative Z parameter in the G31 command if the trigger point is below the bed.

---

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].

David J , change your Z height in the config file. it might too high that why your nozzle is dragging on the bed when probing.

Quote
dc42
Hi David, you need to use a negative Z parameter in the G31 command if the trigger point is below the bed.

I convinced myself that it should be positive - it's been a long day!

I'll give that a try tomorrow...

Edited 1 time(s). Last edit at 06/07/2015 04:46PM by David J.

Quote
Cammi
David J , change your Z height in the config file. it might too high that why your nozzle is dragging on the bed when probing.

That's what I was trying to do - but likely that I was doing it wrong!

Incidentally, during my playing with this problem, I may have found something that may be causing my effector to tilt when doing auto bed compensation - the bowden tube and associated wiring puts a lot of pressure on the effector in some locations, particularly when it's near the Z tower. This is the region where it's getting wrong readings that result in it printing thinly on that side.

Investigations will continue...

Well, you were correct again!

Printer now printing reasonably well (although I still think that the bowden tube & wires are influencing the effector in some positions).

Quote
mrorange26
Could anybody tell me why my lcd display is dim and if its not plugged into pc it just lights up no writing?

Sounds like an issue with the 5V regulator on the Arduino. It's easy to check with a meter on the limit switch +VE and -VE pins. If you read 5V with the USB connected and not with it unplugged (with 12V power on) the regulator chip is popped.

Has anybody managed to make a holder so I can use a e3d lite head on the cherry pi?

Folks,

I've recently started a CPi III build from a kit supplied by Andy and I'm following along with the pictorial build from gowen starting on page 17 of this thread. However, I've stumbled at the first hurdle (well perhaps the third) in trying to work out how many T-Nuts need to be installed in the top and bottom of the frame. I see that Andy said:

Quote
AndyCart
I also included a drawing that shows how many T nuts slot into the base extrusions and where they fit. The top frame is easy, just 4 in each inner V slot.
Andy

I think I must be missing something; can anyone tell me where the drawing referred to lives?

Best regards

Edited 1 time(s). Last edit at 06/09/2015 04:54PM by bower-andy.