makerbot / replicatorg Goto Github PK
View Code? Open in Web Editor NEWAn open-source gcode interpreter for driving RepRaps, Makerbots, and other similar CNC beasties
Home Page: http://replicat.org
License: GNU General Public License v2.0
An open-source gcode interpreter for driving RepRaps, Makerbots, and other similar CNC beasties
Home Page: http://replicat.org
License: GNU General Public License v2.0
ReplicatorG is an open-source GCode based controller for RepRap / CNC machines. It has 3 main goals: 1. Be as simple to use, and as easy to install as possible. 2. Be driver oriented and abstract the GCode away, allowing users to easily create drivers for their own machine. 3. Support as much of the GCode specification as possible. For more information, see the website at: http://www.replicat.org INSTALLATION Windows: http://replicat.org/installation-windows Mac OSX: http://replicat.org/installation-mac Linux: http://replicat.org/installation-linux CREDITS ReplicatorG is an open source project, owned by nobody and supported by many. The project is descended from the wonderful Arduino host software (http://www.arduino.cc) Arduino is descended from the also wonderful Processing environment (http://www.processing.org) ReplicatorG was forked from Arduino in August 2008. See changelog.txt for a list of changes in each version. People who have worked on ReplicatorG include: Zach 'Hoeken' Smith (http://www.zachhoeken.com) Marius Kintel (http://reprap.soup.io) Adam Mayer (http://makerbot.com) Far McKon (http://makerbot.com) A full list of contributers is in contributers.txt
Twitterbot M-code is executed all at once when a gcode file is loaded into a Twitterbot enabled version of RepG.
Using a >= Batch V Cupcake [Gen3 electronics] and printing/building a gcode file that contains Twitterbot M-code using a Twitterbot enabled version of RepG.
Twitterbot M-code is executed as the file is printed.
Twitterbot M-code is executed all at once when the file is loaded.
After an abort, the temperature still reads at the previously set temp instead of 0.
Feature Request:
When a print goes wrong (typically, because the begin of the raft doesn't stick to the build platform properly or the extruder nozzle comes up against an obstacle and throws the print out of alignment) I find myself hitting the Stop button to stop the print -- leaving the hot nozzle still down near the build surface and extruding plastic as fast as possible. I have to quickly bring up the jog tools to bring the nozzle away from the build stage and stop the extrusion process.
I'm looking for a "Panic button" (better terms for this no doubt exist) that brings the plastruder head at least 10mm up away from the build stage and stops the printing. Perhaps brings up the jog controls so that I can adjust things before attempting the print again.
Requested functionality:
A instructions and/or tools with aid with calibrating the stepper motor movement direction and precision.
A few possible solutions:
At simplest: diagram showing which direction the stage should go when x- axis is + or - (likewise y- and z-).
At medium, integrate the tools to reverse the the polarity of the stepper motors to match operator's goals. (And also integrating the board reset that "fixes" the alignment reversal -- I'll submit that as a bug separately.)
At fantasy highest complexity, a barrage of simple benchmarking tools similar to inkjet or laser printer calibration tools to have the plastruder lay down rafts, weaves, circles, that will allow the operator to make adjustments so that at the end of adjustment the operator has confidence the bot is ready to print the design.
Op Notes:
When I open RepG to prepare to print on a bot with a plastruder head I haven't used before, I always throw open the Jog tool immediately to set the a temperature for some test extrusion, check the x-axis alignment, check the y-axis alignment, and reposition the build stage. While the Jog tool is a pretty good way to do this, my uses of the tool are all learned from experience and not particularly intuitively indicated by the UI.
from MakerBot Operators' Listserv:
On Apr 12, 2010, at 4:48 PM, Craig Link wrote:
I wasn't quite sure of the correct place to post a feature request for
replicatorG.
I'd like to have the ability to configure a max user inputable
temperature for extruder. Occasionally I've accidentally typed in the
my desired motor speed(255) into the target temperature box. I've
caught it before I burnt the ABS, but it would be nice if the software
prevent me from entering such a value.
An extension to this would be to have a button which sets the target
temperature to this temperature.
And to follow that, one that sets the motor speed for a set value.
I pretty much always use 255 for motor speed and 220 for target
temperator, so it seems silly to always have type these in when
starting the bot or changing material.
-Craig
please display the total number of commands/lines in a file when idle and a gcode file is open.
The current Driver Factory is hard coded with the 3 known drivers: sanguino3g, serial pass through, and null. To use replicatorG to control your own homemade CNC or Plotter this needs to be opened up. Ideally, the XML configuration could be dropped for Spring configuration.
I also think the packet handling could be factored out of the sanguino3g code so that roll your own drivers could take advantage of the packet building code. Futhermore the packet* classes are protected, so any new driver class has to be part of the replicatorg.drivers.gen3 package. Perhaps this could change.
Noticing that some users resize the uploader dialogs; contents should scale with the dialog.
Add a button that walks you through the process of changing your filament for a given extruder type.
There have been complaints in the past about builds from the SD card causing random motions of the machine before the build starts.
I believe I have narrowed the problem down, and it seems it is NOT caused by the SD card, but by ReplicatorG itself. I think it is getting junk in some output buffer that isn't properly initialized at the beginning of a build.
I get random motions at the start of a build every time under the following conditions:
o if I build to file, and then build an object, either live or from SD card
o if I build from card and then build live
o If I build to card and then build live or from card
o Occasionally it occurs if I abort a build and then start a new build.
However, if I quit ReplicatorG in between the first and second builds (without resetting anything else), the random motion does not occur.
Also, if in between I go into control panel and play with all the buttons, things work normally, but as soon as I start the next build, I get the random motion again. Whatever the problem is, it has something to do with ReplicatorG being left in a strange state after the previous build, and then starting a new build without resetting that state.
When I have attempted to invert the x- or y-axes for a bot whose stepper motors were either mis-wired or actually reversed when the motor arrived from the factory, I was unable to get the inversion to "stick" until Adam told me to reset the board after changing the setting. This detail is not mentioned in the "Onboard Preferences" tool -- and perhaps the reset could be built into the process of setting "Onboard Preferences" changes?
this would most likely be better accomplished with a general system for mapping outputs, mcodes, and hardware, but for now what I need to happen is that for the Frostruder the outputs that are currently labeled 'Fan' and 'Valve' need to be relabeled as 'Pressure Valve' and 'Relief Valve'. This change needs to only affect the Frostruder entry and should hopefully be done on the machines.xml level so that we can easily change them on a per-configuration setting.
The Gen3 connection sequence has a number of small bugs:
If 0015 is launched for the first time with no network connection present, the error dialog is created in the wrong thread and locks up the interface.
There's a feature I'd like to see in the control panel.
Currently, the position coordinates are read only. It would be nice if I could type new coordinates in those boxes. There's some obvious confusion if the new numbers are where I think the machine currently is, or if that's where I want it to go...
So I propose adding two buttons... a SET and a GO button.
One possible way to do this in the UI without adding too much would be to make X Y Z normal typeable text fields. Normally, if something is typed there, it is ignored and overwritten next time the fields are updated.
However, if SET or GO is pressed, the machine either sets its current location to the typed numbers, or it moves to that location, as if the jog buttons were pushed in the right sequence to get it there.
The bot should get reset after eeprom settings are changed. Ideally we'll see a dialog.
EEPROM writes are the only operations guaranteed to be slow and block the system. We need to extend the packet timeouts for these operations so they don't fail. This should be updated in the packet spec as well.
We need to ban println and only log via the logging mechanism to ensure that we get timestamps on all messages. It would also be nice to make sure that the logging output is a bit more concise.
Feature request:
It would be helpful to me be able to see a print layer count (or other element) posted to the interface during the printing process to help troubleshoot elements so that the gcode and file generated from Skeinforge can be investigated for improvements. Perhaps this could be accomplished with LED blinks on the board if that is a better place to post updates.
In the ReplicatorG control panel the set temperatures (extruder heater temperature and build platform temperature) are reset each time the control panel is reopened. This expected action is that temperatures will continue to persist at their previously set levels.
The set temperature fields have no values so it is possible they are being reset to zero because they were not explicitly initialized to the currently set makerbot temperatures.
To get replicator g 11 (unstable) working just comment out the STLPreview references in STLFrame then run ant -buildfile build.xml run from the top directory of replicatorg. Alternatively if someone just made a placeholder STLPreview class simply by extending JPanel I'm fairly sure this'd work as well until the real code is made.
BTW props to the replicator g team for bringing what looks like STL import to replicator g I cannot tell you how much I hate using the skeinforge gui! Make sure to include a nice conversion progress bar :)
Add a real time temperature monitoring graph to the control panel, so you can view temperature behavior. Should be made collapsible if not too hard to save on control panel layout space.
Offscreen tab painting makes fonts look blocky and lame. We should either switch to an ordinary tab widget or rewrite paintComponent to not look awful.
This may be a feature rather than bug, but until I learned of the existence of the beta firmware at the bottom, I didn't know to scroll down to find it.
with the addition of the heated build platform support, the 'valve' and corresponding m codes no longer work. please re-enable support for this command in the firmware. they should be able to live side by side.
It use to be that you could leave the control panel open while building, but this caused contention over the serial bus.
Instead of ReplicatorG polling the serial, would it be possible to add codes to the firmware to ask for status updates, and then have the firmware send them when the serial bus is not very busy? This could be fairly frequent (not more than once a second?) when building from SD card, but maybe not at all when drawing lots of small circles or something like that.
Things that it would be interesting to update:
I don't know if this would cause problems if the serial is suddenly disconnected.
If it does, then there should be a safety that turns it back off if something goes wrong rather than abort or pause the print.
There is an additional thermistor table available in the v2 firmware for the heated build platform. We should support tweaking it in the same manner as we support the tweaks for the extruder thermistor table.
ReplicatorG does not work with the RepRap.org firmware due to a significant difference in their communication protocol. If ReplicatorG were to become a firmware agnostic tool as I propose then experimenting with firmware and hardware modifications would be much easier for RepRap and Makerbot hardware modders as they cross the lines of RepRap/Makerbot firmware supported configurations (5d/3d/stepper extruder/reprap paste extruder/dc geared extruder - there are many differences in supported hardware here).
With the encouragement of Rick from MakerGear.com I have taken a stab at the problem but resulted in very little end result other then multiple reverts on my git repo and a fork which somewhat resembles a very early attempt to hack in some compatibility (the scope of which greatly exceeded my expectations).
If someone would like to take a shot at this it may help you to take a look at my code at Replicate.rb github => RepRapDriver.rb for a simple example of how to interface with a 5D RepRap. Good luck!
ReplicatorG sometimes freezes, the best solution is often to force quit and restart. In ReplicatorG 0013, restarting kept the settings in the nozzle and HBP so they would stay warm. New in RepG 0014, if you quit and relaunch RepG, the nozzle temp and HBP are reset after about 10 seconds, and their temperatures start to drop rapidly.
Please revert this behavior to RepG 0013 behavior.
Jordan
Deleting a sketch from ReplicatorG 10, ERASES the Gcode file on the hard drive and also all the files in the same folder. In my case the desktop folder...
Mac OS 10.6.2 Snow Leopard
ReplicatorG 10
This is a combined bug report / feature request...
ReplicatorG seems to randomly decide to remember the last sketch it had open and reloads it at next start. I can't seem to see a pattern in when it remembers a new one just loaded and when it doesn't and loads the previous one instead.
The feature request would be either a button or menu entry for "Return to this sketch on next load" or a preference somewhere for the name of the default sketch (with the default being BLANK probably).
The v2 firmware stores the motor reversal parameters in eeprom and loads them at start time. We should support this in the onboard preferences in replicatorG.
RXTX's timeout functionality is broken on most platforms. I'm going to have to replace input stream reads with event handling. Was hoping to avoid on this release, but it's a terrible bug and need to go away stat.
Preferences are all over the map; refactor to be a little cleaner.
The firmware uploader should include illustrations to make sure that people have their cables hooked up correctly.
Please delete the old 'EXPERIMENTAL - Cupcake PBJ' entry and add the following entry to the machines.xml in preparation for the Frostruder release:
<machine>
<name>Cupcake CNC w/ Frostruder</name>
<geometry type="cartesian">
<!-- different pulleys on X and Y axii -->
<axis id="x" length="300" maxfeedrate="5000" scale="11.767463"/>
<axis id="y" length="300" maxfeedrate="5000" scale="11.767463"/>
<axis id="z" length="300" maxfeedrate="150" scale="320"/>
</geometry>
<tools>
<tool name="Frostruder MK2" type="extruder" material="abs" motor="false" floodcoolant="false" mistcoolant="false" fan="true" valve="true" collet="false" heater="false"/>
</tools>
<clamps></clamps>
<driver name="sanguino3g">
<!-- optional, defaults to first serial port found. <portname>COM1</portname> -->
<!-- required: we need 8 bit and 38400 baud. -->
<rate>38400</rate>
<parity>8</parity>
<!-- optional, defaults to 1. <databits>1</databits> -->
<!-- optional, defaults to N. <stopbits>N</stopbits> -->
<debuglevel>0</debuglevel>
</driver>
<warmup>
</warmup>
<cooldown>
(Turn off steppers after a build.)
M18
Currently, the connect and disconnect buttons are alternately wonky and nonfunctional. Get them working reliably, and ensure that disconnecting before closing either:
A crash should not halt the machine in most cases.
Current help menus are a hangover from processing; fix or remove
To repeat:
Results:
New contents are saved in the old filename and the new filename is not created.
related to issue #42. when drawing things comprised of many small line segments (such as an exploded ellipse from a DXF) the movement bogs down. a filter that would not issue a movement until the total length exceeds a built-in threshold would hopefully prevent this from happening. if done at the right level, it might even be able to solve #42 automatically.
After closing the firmware updater, reopening it fails to start the updater again.
During timeouts, we just get horrible exception warnings and then lose access to the extruder parameters panel. This should instead yield a popup and recover.
The arc/circle code (G3) is generating line segments that are way too small and bogging down movement. Modify to use larger line segments (perhaps based on the axes scale since the root problem is # of steps per segment and not physical size of move)
The firmware uploader should have step-by-step instructions displayed to help the user get it right.
Because replicatorg on every start tries to access the internet and i am behind a http proxy, i have added some lines to the "replicatorg" start script (Linux) to respect the system-wide proxy settings. Eventually this can be used generally. This works on the http_proxy environment variable.
if [ ${http_proxy} ]; then
PROXY=echo -n -e ${http_proxy} | sed -n 's/http:\/\/\([^:]\+\):\([1234567890]\+\)/-DproxySet=true -DproxyHost=\1 -DproxyPort=\2/p'
java
else
java replicatorg.app.Base "$@"
fi
Create a simpler, more standard installer for the Mac OS X version.
Figure out a decent window sizing and positioning policy for ReplicatorG (in terms of what most platforms expect, etc.)
After clicking home z-axis in the control panel the makerbot (w/ heated build platform) homes and then proceeds to stop responding to commands. Only after force exiting ReplicatorG and starting a new ReplicatorG instance do subsequently sent commands execute
for example the sequence: home z, left 10mm, exit, reopen replicatorg
would cause: home z and then a unresponsive state until the program is reopened and then move left 10mm
People expect the control panel to work as expected without having to worry about the machine's state.
We need to allow the user to choose the endstop technology in use by setting an EEPROM bit.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.