Niggle Build

Re: Niggle Build

Postby tommythorn » Sat May 03, 2014 1:24 am

Congratulations. Yes, you definitely want to configure it as a Cartesian. QU-BD has been great for me for the stuff I order through the web, but my experience with their Kickstarter has not been smooth.

For a lot of stuff I got from them I've later found better or cheaper sources, notably the
SureStepr Stepper driver which are cheaper from the source: http://www.panucatt.com/product_p/sd8825.htm
tommythorn
 
Posts: 90
Joined: Tue Dec 03, 2013 12:14 am
Location: Silicon Valley, CA, USA

Re: Niggle Build

Postby Nicholas Seward » Sat May 03, 2014 1:26 am

Use cartesian mode on Repetier. Delta is for the column delta bots.

I will update the links. I should probably put a few different links. QUBD is cheap but has gotten some bad press so I dony want that to be a hangup for people. I just use them because they are down the road.
Nicholas Seward
 
Posts: 738
Joined: Mon Nov 25, 2013 10:41 pm

Re: Niggle Build

Postby Niggle » Sat May 10, 2014 5:04 pm

Various tweaking in progress.

After swapping the firmware, the Home procedure is ugly. It is set to move the Z arm first which can get the Y arm stuck without enough leverage to lift the hub. I'll be hacking on the firmware to get a simultaneous move until one of the stops triggers.

I have a hot end with a groove mount barrel. However, the barrel is too narrow for the hub bottom. The horizontal bolts let the barrel slip through. I have a mounting plate for the hot end, so I've printed a modified hub bottom with bolt holes to match the mounting plate.

At this point, I realized that the nut that goes in the nut trap in the hub screw is supposed to be in contact with the hot end, which changes the assembly order. I also decided that filling the Bowden tube with filament might help to ensure that the hot end aligned correctly with the tube.

This lead to the discovery that the nut on the end of the tube compressed the tube preventing the filament from getting out.

While the shoulder mount for the filament drive is cool, I really don't like where that requires the spool of filament to be placed. I've added a flange plate to the filament drive block so that I can mount the drive to something flat (e.g. an extension to the base plate) and feed the filament horizontally. It requires a slightly longer Bowden tube but allows the spool to sit on the table with the printer.

When I was originally printing parts, I used an UP! to print the hub in ABS. I am beginning to think that this was not a good idea. The hub screw is very loose in the hub bottom and it is very easy to get it to jump threads. Is this normal?
Niggle
 
Posts: 84
Joined: Tue Feb 11, 2014 7:27 pm

Re: Niggle Build

Postby timrwilliams » Sat May 10, 2014 8:27 pm

I had a similar experience with printing the hub in ABS. The threading was very loose.
I solved this by some experimental scaling. I can't remember exactly which way, but I am fairly sure
I scaled the bolt to 104% which gave a very secure locking action.
The M4 nut on the end of the PTFE tube will almost always compress 1.75 filament.
I usually ream out with a new 2mm bit and well blow through to clear any PTFE fragments.
The 'Home' action is a trap! Pronterface wants to treat each axis sequentially. (The Delta firmware does not,but Homes the columns together).
One way round this is to send a G1 code for large -ve values ie -500 x 3. These are executed together
and stopped by the limit switches. After that 'Home' works fairly well.
timrwilliams
 
Posts: 87
Joined: Fri Feb 14, 2014 10:32 pm

Re: Niggle Build

Postby NeoTheFox » Sun May 11, 2014 1:04 pm

timrwilliams wrote:I had a similar experience with printing the hub in ABS. The threading was very loose.
I solved this by some experimental scaling. I can't remember exactly which way, but I am fairly sure
I scaled the bolt to 104% which gave a very secure locking action.
The M4 nut on the end of the PTFE tube will almost always compress 1.75 filament.
I usually ream out with a new 2mm bit and well blow through to clear any PTFE fragments.
The 'Home' action is a trap! Pronterface wants to treat each axis sequentially. (The Delta firmware does not,but Homes the columns together).
One way round this is to send a G1 code for large -ve values ie -500 x 3. These are executed together
and stopped by the limit switches. After that 'Home' works fairly well.


This is how segmentize do it
Code: Select all
G1 X-1000 Y-1000 Z-1000
G28


Still not preventing the singularity, though.
NeoTheFox
 
Posts: 92
Joined: Tue Jan 28, 2014 5:54 pm
Location: Moscow

Re: Niggle Build

Postby timrwilliams » Sun May 11, 2014 2:18 pm

Thats interesting.
As I understand it, the singularity occurs when the Motor arm and Slave arm ends are at the same height.
More by luck than planning, I seem to avoid this by using a 15mm granite disc on top of the upper plate and an adaptor to hold the hot end well below the hub (this for cooling improvement).
This means that at bed Z0 the Slave arm end is 70mm above the Motor arm end.
So the Segmentize approach does work for me
timrwilliams
 
Posts: 87
Joined: Fri Feb 14, 2014 10:32 pm

Re: Niggle Build

Postby Niggle » Mon May 12, 2014 3:09 am

Tim,

Thanks for the hints on redoing the hub screw.

If the hot end is low, fully extending one arm will push it off the bed and then it drops below the plane of the singularity. In general, this is a bad approach to homing the hot end. Do this at the end of a print and it could push the hot end through the print. It needs to be fixed in the firmware, and I'm about ready to take on the job.

My frustration of the afternoon was tweaking the steps/mm in firmware, uploading it and seeing it not take effect. Eventually I realized that I had to manually update the EEPROM because Repetier cleverly overwrites your compiled values with the ones it finds in the EEPROM. Repetier also takes care NOT to tell you how to create the necessary M206 commands
M206 T3 P3 X53
M206 T3 P7 X53
M206 T3 P11 X53
For X, Y, and Z respectively.
The low values are because I sanded the spool a bit and because I'm only 16x steps instead of Nicholas' 32x steps. Just to add to the fun, Repetier host made it difficult see the right bit of the output from M205.

OK. It is time for a new hub screw as the hub is not staying vertical while I am messing about.
Niggle
 
Posts: 84
Joined: Tue Feb 11, 2014 7:27 pm

Re: Niggle Build

Postby Niggle » Fri May 16, 2014 5:02 am

Repetier firmware has me totally confused.

I tell the printer to Home and it does that.
I look at my LCD panel and it claims the cords are [-3000, -3000, -3000]
I send G92 X0 Y0 Z0 E0
And it claims the cords are [-3000, -3000, -3000] but Repetier Host claims [0,0,0]
Any move to absolute positive coordinates drives the hub into the bed.

I'm looking for a hint as to how to fix this, other than dumping Repetier and starting over with Marlin.
Niggle
 
Posts: 84
Joined: Tue Feb 11, 2014 7:27 pm

Re: Niggle Build

Postby Niggle » Sat May 17, 2014 7:45 pm

Switched to Marlin firmware.

It is more than twice the size so it takes longer to download. However, home ends up at 0, 0, 0.

Even better, I can control movement from my SmartRapDiscount LCD + click encoder, which makes it a lot easier to get bed coordinates to plug into 'simpson segmentize.py'.

Next step. Find a small object, slice it and push it through the segmentize script.

Next problems. The resulting gcode has X coordinates walking off to the edge of the bed. It is almost as though segmentize is doubling the coordinate values from the original gcode file. Investigating will give me something to do this weekend.
Niggle
 
Posts: 84
Joined: Tue Feb 11, 2014 7:27 pm

Re: Niggle Build

Postby Nicholas Seward » Sat May 17, 2014 7:57 pm

It sounds like a simple slicer layout problem. Make sure you setup the slicer to have your part centered on 0,0 instead of width/2,height/2.
Nicholas Seward
 
Posts: 738
Joined: Mon Nov 25, 2013 10:41 pm

PreviousNext

Return to GUS Simpson

Who is online

Users browsing this forum: No registered users and 3 guests

cron