Show all posts by user
Page 1 of 2
Pages: 12
Results 1 — 30 of 38
There is a github feature request for a Marlin firmware feature to pause the print when a filament out sensor is triggered (but obviously could also be linked to an explicit pause/resume button).
The discussion isn't getting much visibility and so I wanted to hear other people's thoughts.
For SD card prints with an LCD this is not too difficult because the Marlin firmware is in control of the
by
buildrob
-
Firmware - experimental, borrowed, and future
Hi Steph ane,
This was a suggestion I had to solve the problem of wiping to the left and right with dual extruders - unfortunately there wasn't any interest in it.
Cheers,
Rob.
by
buildrob
-
Slic3r
Ah yeah - apologies. It was something I was planning on implementing but decided to pull it out (too many places that I would have needed to change to properly implement it). I obviously forgot to remove the values from Configuration_adv.h
Also, really I think you would be better to get the two extruders to be at the same height. Consider using small washers or shims (e.g., circles of thin alumi
by
buildrob
-
RAMPS Electronics
It attempts to accelerate up to DEFAULT_MAX_FEEDRATE when changing tool heads - so make sure they are set to sensible values in Configuration.h
by
buildrob
-
RAMPS Electronics
Excellent.
It is usually simplest to keep the co-ordinate systems indexed from the end-stop (i.e., 0) in the firmware.
Every slicer I have seen allows you to configure where the print bed is located with respect to the origin (i.e., by specifying the bed center and size, or bed left/right/top/bottom).
Hope that helps.
by
buildrob
-
RAMPS Electronics
Hi mate,
You should pretty much be able to use any pins as long as they don't conflict with other pins in use. They don't need to support PWM or PININT.
Set DEFAULT_DUAL_X_CARRIAGE_MODE to 1. Then you should be able to change between the x-carriages on the LCD just by changing your active toolhead. The new toolhead will move into position once you adjust the position of the head.
by
buildrob
-
RAMPS Electronics
Hi Conrad,
The Marlin code has two primary modes of operation in dual X-carriage mode (ignoring the duplication mode):
Mode 0 (M605 S0) requires slicer support. Each time you do a tool change it reassigns the current position of the "active" toolhead. As the toolheads can move independently the slicer must also have the same understanding of the position of each of the two tool heads. This mode
by
buildrob
-
Mechanics
Another update on my dual x-carriage printer project: I've just finished implementing a software enable-able "duplication mode" for the Marlin firmware.
This allows you change into a mode where you can print two arbitrary sized objects using the the independent x-carriages (as long as they fit on the print bed of course). I added a video of it in operation here: .
Thingiverse link is here: .
by
buildrob
-
Mechanics
Given this is the mechanics forum I thought that the following subsequent change to my dual x-carriage design might be of interest to some people.
This dual-x carriage design requires that the distance between the two endstops is properly calibrated to ensure that the printing from the two extruders is aligned. I found that that the variability in triggering of the mechanical microswitches led
by
buildrob
-
Mechanics
Yeah, that was my initial plan for implementing the independent x-carriages, i.e., to either use a gripper or clutch mechanism. I even bought some relay and solenoid parts for doing this but decided to change my plan to adding an additional stepper instead.
I still think that approach is possible but I decided that that the design was a little too finicky/difficult to get right, i.e., absolutely
by
buildrob
-
Mechanics
I've been playing with multi-material prints for a few weeks now and thought I'd discuss a couple of issues I've seen.
It seems that when planning travel moves, slic3r doesn't take into account the material type much. You can see this in the video here: (you can see white lines internally through the red center).
The two main areas of concern/improvement I see are:
a) it doesn't retract or rer
by
buildrob
-
Slic3r
This is my effort for improving dual extruder performance - independent x-carriages - I think it works pretty well.
If you're interested I wrote it up here:
My next change will be to also extend the firmware to allow it to print two copies of an object at once. I'll post some more video when I get that working.
by
buildrob
-
Mechanics
The new 6th stepper controls the second X-axis stepper. This kept the pin allocations on all the other stepper unchanged (so the Azteeg's 5th stepper is on the second extruder).
Robert.
by
buildrob
-
RAMPS Electronics
I finally finished my dual parking extruder project. Getting some good results.
I eventually decided just to build a separate stepper driver board and connect the enable/direction/step signals to 3 of the digital expansion pin headers rather than mess around with relays.
I did a write up here:
by
buildrob
-
RAMPS Electronics
Thinking about this approach more, you would need to ensure that you disable the FET outputs (by pulling the ENABLE input high) before switching the relays to the other motor.
I guess in the worst case this would happen simultaneously if you reset the Arduino when the second stepper was powered. Not sure if this is a problem but you are disconnecting both sides near-simultaneously which means t
by
buildrob
-
RAMPS Electronics
Frustrated with the dual extruder ooze problem ... or the standby warm up and down time to avoid it - so I am thinking of doing exactly the same.
Did you get any further on yours?
My Bukobot Duo (Dual Head) already consists of two single extruder x-carriages which are held together with a link, so all I need to do pull out the linking plate and design new X-axis ends to mount & route the s
by
buildrob
-
RAMPS Electronics
The Azteeg X3 base board has 5 independent motor drivers (XYZE1E2) and the v1.1 expansion board (which now comes standard as far as I understand) now adds the connectors for 3 more motor controllers - which is actually 8 independent axis not 6 as I originally said (although they don't include the Polulo style headers for the ones on the expansion board).
The question is: do you need to drive al
by
buildrob
-
Developers
Rather than using markers before the filament is extruded ...
What if you had a cluster of markers on the x-carriage each of which is connected to a solenoid which raises and lowers it.
You would print a white substrate layer and then "go over" the printed layer with the necessary marker colors.
As the markers have a felt tip your tolerances on the raising and lowering of the markers probably
by
buildrob
-
Developers
@plexus Perhaps a better question would be, assuming we did do a reasonable job of defining a common interface and a couple of implementations were done, would firmware designers be likely to be interested adopt it?
@bobc I don't think the Arduino comms bandwidth is the main issue here - it is mainly a CPU overhead issue for advanced features or high speeds. So I don't think that simply using a
by
buildrob
-
Firmware - experimental, borrowed, and future
I thought I see what sort of support this idea has.
Sorry this is a long post. If its too long, please feel free to TL;DR and move to the next thread.
Observations:
- there are currently a number of people in the process of designing different 32bit ARM single board printer controllers
- there are a huge number of people already with Arduino-based 3d printer controller boards who will be reluct
by
buildrob
-
Firmware - experimental, borrowed, and future
buildrob Wrote:
-------------------------------------------------------
> Currently there is just one custom Gcode block for
> all tool changes but its seems that it would be
> very useful to be able to specify custom Gcode
> when it changes to or from a specific extruder.
>
> As you know not all extruders are equal.
>
> For instance, lets say that when I change away
&g
by
buildrob
-
Slic3r
Currently there is just one custom Gcode block for all tool changes but its seems that it would be very useful to be able to specify custom Gcode when it changes to or from a specific extruder.
As you know not all extruders are equal.
For instance, lets say that when I change away from one tool head I need to wipe the head on one side of the bot but when I change away from the other toolhead I
by
buildrob
-
Slic3r
If you are interested I created a change to improve the M600 command along the lines I've been proposing. Have a look and let me know what you think: (I'm actually really happy with it - I've been using it from my host as well by binding to the custom command buttons. Also still works like the old one did on the LCD menu. I think its going to be a really popular feature.)
by
buildrob
-
Firmware - mainstream and related support
Other short comings of currently implemented M600 command is that you can't change temperature when changing filaments. Even when changing within the same brand of filament, the different colorant properties mean you often have to use a slightly different temperature.
Another application I was thinking of for this feature is to automate temperature calibration for a new filament type. Here you
by
buildrob
-
Firmware - mainstream and related support
I was thinking more about this overnight.
Its seems that a good middle ground is that the instead of the combined M600 command is to split it into a "park printhead" command (using all the parameters you specified expect final retract) and then a "unpark printhead" command. This way the printer can do a lot of the hardwork and you can avoid the complexity of co-ordinate modes, extruder temps an
by
buildrob
-
Firmware - mainstream and related support
bkubicek Wrote:
> I have no way of sending a "click" from a host
> software to the printer, without heavy invasion
> and touching the many different host
> implementations. My first approach was to send
> another M600 as a click, its impossible. The
> second approach was to send a special character.
> Well, not very nice either.
I agree it's messy - which is why I think spli
by
buildrob
-
Firmware - mainstream and related support
Consider that this functionality could more generally be implemented through adding the following commands:
- save position command (saves xyze position)
- restore position command (moves back to saved position)
- wait for button press while sounding beeper command
Then all other functionality can be (more flexibly) driven through insertion of standard Gcodes rather than a specific 5+ argument c
by
buildrob
-
Firmware - mainstream and related support
Hi Bernhard,
I had a look at the link you posted in your comment here:
My problems with the command as it is currently implemented:
a) it has been designed to only work with LCD based panel printers. If we are designing and adding new features as important as this then they should be generally usable - or at least it should be clear how it would be used without LCD displays. I.e., consideratio
by
buildrob
-
Firmware - mainstream and related support
This is a continuance of a discussion regarding the M600 Change Filament command which was recently added to the Marlin firmware. I have move the discussion here so that it has wider visibility.
Details of change: ... 872588ad4b
QuoteAdded a feature to have filament change by gcode or display trigger.
syntax: M600 X Y Z E L
if enabled, after a M600, the printer will retract by E, lift by Z,
by
buildrob
-
Firmware - mainstream and related support
Page 1 of 2
Pages: 12