I am, and will start building soon. What are you working with, openscad?

 

OpenSCAD for now, but planning to rewrite in a higher level language that generates OpenSCAD after I finish prototyping. I've had some bad luck with parts breaking in the last few days that has delayed my ability to test some of my designs, but I'm planning to release my 2040 prototype parts soon (hopefully within a week). The goal is to create a parametric design that allows you to input your choices (extrusion profile, build size, etc.) and get a full set of STLs, bill of materials, and 3D mockup at output.

Also please note that I have not started on a re-implementation of the top rear brackets that contain the belt idlers. I plan to tackle this in the future, but I haven't decided on my strategy yet.. If I want to support belts of different sizes I will likely need to depart somewhat from the current design, as it hinges on the belts fitting within the extrusion channel, which could cause incompatibility issues with the C-Bot (which I'm trying to avoid). Otherwise I could use the same constants as the C-Bot but allow for wider extrusions (2060 or 2080) and have the idlers level with the top and bottom extrusions, but this will limit the choice in belts.

I'm actively seeking testers for larger extrusion profiles. If you're willing to test them, I will prioritize support for the rear corners so that you can have a fully functional printer. I don't have the money to buy extra extrusions at the moment, so this has been a time-consuming process of tearing down and rebuilding my printer with new parts, so having someone who can test these changes would allow me more time to focus on the design If you're able and willing to work on the coding side I would also be glad to have help on that as well.

I have a github repository for my changes, though there are some local changes I haven't pushed yet.. If you're interested, it's at GitHub - spiffcow/r-bot: R-Bot is a collection of modifications for Carl Feniak's C-Bot 3D printer

 

So despite finding many workarounds that made my old RAMPS/Arduino combo that originally came with my Kossel Mini usable on my C-Bot, I think that I might have to consider retiring it. Turns out that when it comes to the 5v stuff, there's not a whole lot of headroom. I guess with the endstops and LCD, I'm already pushing it. I noticed that when I use my fancy new BLTouch the servo uses 5v as well and it lags a bit when engaging. This has caused a couple head crashes. (The mount I rigged up however works nicely and I will upload the 123D file to this post shortly) All of this and I haven't even started using the 4 channel relay, which also uses 5v. Currently, when the servo engages, the LCD dims a bit; same with other things. The full graphic LCD that I have in a drawer is almost unusable for the same reasons. After a bit of research, I find out that the 5v regulator on the Arduino doesn't provide a lot of juice. So at this point i'm going over options. I could get a different Arduino (Taurino Power) but they're not cheap. Looked at an MKS GEN v1.4 and seemed ok. Looked at an MKS SBASE smoothiware based one, I am tempted but smoothieware is lacking 1 or possibly 2 things that I would really prefer to have. Software enstops (a whole can of worms on other forums) and I'm not sure if it does safe-z-homing. (can't find answer on that) The Duet looks nice but is VERY not cheap.

So far I seem to be leaning towards the MKS solutions. What do you guys think?

 

External 5v power supply to augment the ramps.

Also look into the Duet board. I switched to that from the smoothieboard/smoothieware (the lack of soft ends stops, and lack of desire to add them, being a big deal breaker for me).

The web interface on the Duet is the biggest seller for me. With that later versions, you can update the firmware through it. Configuration is done with G-codes so it is easy to enter the new setting and see how it works. You can then edit the config file on the web page and it will restart the controller to enable the changes.

 

Hmm ..... is this the same with all Due based boards? Also, I'be been told to shy away from RAMPS FD
(The Duet v0.8.5 is $190 CDN btw)

Also, how would you suggest I augment the 5v? I have a ton of old 5v 2A D-Link power adapters I can sacrifice ... lol

 

Basically just connect the grounds together and apply the external to where it is needed. For example, the LCD display. You might need to cut the wire bringing the 5v from the board and connect the external to that line.

 

If you are referring to the web interface, this is something that the Dc42 fork of the RepRap firmware supplies. I don't think it is compatible with non-duet boards.

 

I have the MKS SBASE and have been very happy with it. It corresponds pretty closely to the Smoothieboard documentation, does a very good job of adhering to the jerk control (which it uses by defining the maximum deviation from intended movement point) and I love the ability to define the pins in the config file. The only downside is that you can't use the Z probe as the endstop.. I chose to make my Z endstop a maximum endstop near the bottom and use the Z probe and G30 to determine the bed location.

 

I do like the ease of the config file on my delta; it's pretty straight forward. I however did not know that the probe couldn't be the endstop as well. Good to know. The price of the SBASE does make it pretty tempting, but let me ask another question if I may?
From a printing standpoint, not conveneince features, has anyone noticed a quality difference by switching from 8-bit to 32-bit on a CoreXY?

 

I haven't. Moving to 32bit is more for supply compute power for other things, like a web server. Given most 8bit controllers run at 16MHz and can get the job done, moving up to a system running at a 4x or more clock speed just makes other features possible.

 

Makes sense. I understand how it was computationally beneficial on my delta. I wasn't positive if CoreXY required the same amount of "brain juice". I'm not super concerned with a web interface as I run OctoPrint on a RPi and I have some 3.2" touchscreens enroute for them (might ditch the RAMPS LCD altogether) Speaking of orders, the LM2596 converters (2) I ordered a month ago just showed up about 15 minutes ago. Might solve my 5v problem with those by running one of them off the 24v PSU.

 

With the Duet, there is no need for Octoprint. I use it on my Printrbot, but the Duet's Web controller does the same.

 

I like the webcam
Means I don't have to babysit it in the shop; wife likes the too and in turn keeps me out of poo.... (less of it anyway)

Happy Wife = Happy Life

 

I can't compare directly since I never ran a RAMPS on my C-Bot, but comparing it to my Kossel which runs a RAMPS system it has dramatically better bed correction. I hate manually leveling, so I mount my print bed directly to the extrusions and use Z correction, and so far it has worked out beautifully.

 

So first-- RAMPS FD. Yeah. Avoid. The only design that's out in public has some known flaws, because the people designing it got annoyed and stopped development.

Due + RADDS is very strong, if you can get a RADDS board (US distributers are having difficulty keeping them in stock)-- it runs Repetier firmware, and now, RepRapFirmware (a version of dc42's version). It also supports LCD's which can be a Good Thing(tm).

Second: You can update just about every setting inside Repetier firmware (AVR or DUE) through the eeprom interface in Repetier Host (or via G-Code, if you really want). Later versions of Marlin allow you to edit the values for endstops, arm length, delta radius, etc., without recompiling the firmware.

There are some things on the eeprom based firmwares that you will need to recompile for, but they're largely to do with changing out hardware, or customizing firmware features (scroll speed on menus, for an example).

RRF and Smoothie firmwares both allow you to customize config files, reboot the firmware and have the new config take effect, which is verra nice.

 

Anyone tried using this stuff for lubricating the lead screws?
Finish Line Teflon Plus Dry Cycle Cycling Bike Chain Oil Lube Lubricant

Any opinions?

 

Never tried any sort of dry lubricant. I'd be interested to see how it performs or if it has any advantage over more traditional ones or if there are any particulate issues. Personally, I just use lithium grease on all of my lead screws without issue.

 

Not too long ago I switched from RUMBA/Marlin to RADDS/Repetier: But Repetier is still a port of 8-bit software running on the 32-bit hardware. I didn't notice any quality difference. Then last month I switched from that to RADDS/RepRap Firmware (now hardware and software are both true 32 bit): Last night I was printing at 150mm/sec, seemed to have no issues, print quality was good, Marlin would have never done that. I'll keep pushing the speed and seeing what happens....

 

150mm/sec? Wow! That's fantastic! It seems that the Arduino Due solution seems to be the preferred route here by many. Perhaps I should pass on the MKS GEN1.4 that I almost clicked on, make my RAMPS last a bit longer and save up a few pennies for a RADDS or Duet.

 

Look Ma, no wheels!



And yeah, I know the belts are no longer at a 90 degree angle --gonna fix that soon... But hey, it actually works!

 

Also, here are the STLs if anyone is interested.. The code to generate them is on my github. The jury is still out as to whether this is any "better" than wheels. My sample size is small so far, but it looks like they have much less of an echo in places where a lot of retraction is used, but sharp corner tend to jut out slightly. Noise level is about the same.

edit: thingiverse entry
MakerBot Thingiverse

 

Has anyone seen if the BLTouch is su-pported by Duet? Does RRFW or the DC42 branch support safehoming, software endstops?
I noticed that when looking at the Due/RADDS setup, I'd need to get stepper drivers. The drivers used in combination with are pretty pricey. According to what I've seen, Duet would actually work out to be less expensive, mind you with only 1/16th microstepping drivers.

Again I apologize for all the questions; I'm just trying to get an idea of what the next step is. I knew from the get-go that my RAMPS 1.4 would be a temporary measure to a degree.

 

New version of Duet is in process, and should have improved stepper drivers.

 

Cool .... guess an eta?

 

Nope. beta units have gone out recently. There's a thread over in google groups "Delta Robot 3D Printers" called "Duet hardware development news", and a new website for the board at https://www.duet3d.com/.

 

So as it turns out, I wasn't printing at 150mm\sec: Today I sat down to see how fast I could push this thing. As it turns out, it's currently somewhere between 90 -> 120 mm\sec:
I used a 2cm wide by 1cm tall calibration cube, printed it hollow with 2 shells (outside shell 100%, inside shell 70% speed, to recreate my normal print settings), no floor, no roof. These were my times:
60mm/sec : 3:01
90mm/sec : 2:10
120mm/sec : 1:45
150mm/sec : 1:45
So from 60-90 there's a 1:1 correlation between speed and time, but it drops off between 90 & 120: This is expected as jerk and acceleration values start to clip max speeds based on the short travel distances.

Here's what I've found interesting\vexing: I've started jacking up both my acceleration & jerk values (doubling them), and I'm seeing no increase in print times. And if you're wondering, my firmware max print speeds are 450mm/sec, so no clipping there.
I've tried both adjusting firmware values via the SD, and live after boot, but no noticeable effect in overall print time.

Any thoughts? Maybe I'm approaching the limits of the steppers themselves? I'll continue to poke at this, and try the same tests with a much larger model to see how that effects things.

 

I'll answer my own question: The speeds were being clipped.

I wasn't declaring a M203, and instead was going off of what the wiki said the defaults were:
RepRap Firmware G-Codes - RepRapWiki
That said this:

Maximum feedrates mm/min (M203): X25000 Y25000 Z25000 E8000:8000:1200:1200:1200:1200​

But when I entered in M203 via my serial console, I was getting 6000 for XYZ. That would explain things.
So I manually set M203 to the above values, and suddenly I started getting results.

I used a hexagon with a 10" radius to give the printer ample time to get up to speed regardless of acceleration and jerk: no floor, no roof, no infill, 2 shells all printed at 100% speed. Only the first layer was slowed down by 75% to help stick to the bed (but based on these speeds, that probably wasn't needed).

Here are the values:
120mm/sec @ 6000mm/min max feed rate : 3:29
Change firmware values to above listed values (250000mm/min), start new test:
120mm/sec : 3:09 (delta :20 from above).
135mm/sec : 2:49 - delta :30
150mm/sec : 2:34 - delta :15
165mm/sec : 2:22 - delta :12
180mm/sec: 2:12 - delta :10
I stopped there, print quality was starting to suffer: I think you'd have to start upping the extrusion volume a those speeds, the walls were starting to look a wee bit stringy (but still solid). But I'm confident I could hit 200 no problem.
+1 for RADDS & RRF.

 

Silly question - Are you using EEPROM? Have you cleared it out? Updated and saved new settings into it?

I know it's possible to drive a RAMPS / 2560 at those speeds and they will start dropping steps. I would expect to see the same if the steppers, current or processor was unable to achieve those speeds. It sure sounds like there is still an artificial limit still.


NVM - I see you figured it out at the same time I posted this...

 

"Silly question - Are you using EEPROM? Have you cleared it out? Updated and saved new settings into it?"
Figured out indeed, but anyway:

RRF is different that Repetier (I presume that's what you're referring to) that with Repetier you can change the EEPROM on the fly via the LCD. With RRF (as I've been learning), you can change it on the fly via gcode over a serial connection, but it's not permanent: Only the stuff in the .g macro's in the \sys file are actually persistent. But it's nice that it lets you do that configuration on the fly in a temp fashion, or even via say, your 'start gcode' in simplify 3d: I can now configure profiles that not only adjust the mm\sec print speed, but the acceleration & jerk as well.
Learning is fun

 

How are people managing these high speeds? I now have my C-Bot up and running, but find the ability to extrude at speed to be the limiting factor. I am using 3mm filament and a geared Wade extruder. With a V6 E3d bowden setup and 0.4mm nozzle I am getting problems at around 60mm/minute. Trying to push a length of PLA filament through the hotend manually is difficult so I am not surprised this is going to be a problem.
The motor turns okay, but because of the opposing force, the hobbed bolt strips through the filament.
I have tried setting the extruder to 193 and 210 degrees but this appeared to make little difference.

For comparison I pushed a length of filament throught the V6 direct drive extruder on my prusia I3. The forces seemed comparable

Am I missing a trick here?