makerbot / g3firmware Goto Github PK
View Code? Open in Web Editor NEWThe firmware for generation 3 and later RepRap electronics.
The firmware for generation 3 and later RepRap electronics.
This is the catch-all repository for public Makerbot code.
Currently FIND_AXES_MAXIMUM does not read flags from the received packet as find_axes_minimum does and instead uses 0 as flags. Find a patch below to fix that.
---
SanguinoMaster/PacketProcessor.cpp | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/SanguinoMaster/PacketProcessor.cpp b/SanguinoMaster/PacketProcessor.cpp
index f07922f..060d0cd 100644
--- a/SanguinoMaster/PacketProcessor.cpp
+++ b/SanguinoMaster/PacketProcessor.cpp
@@ -404,6 +404,9 @@ void handle_commands()
// Belay until we're at a good location.
if (!is_point_buffer_empty()) { return; }
+ //which ones are we going to?
+ flags = cursor.read_8();
+
//find them!
seek_maximums(
flags & 1,
--
1.7.0.3
handleToolQuery() is sending empty payloads in the responses when a NOISE_ERROR occurs while receiving a response from the extruder. The patch below makes handleToolQuery() a little more robust to errors and makes sure that a proper error response is sent back to the host.
This also fixes a read timeout problem in ReplicatorG. Without this fix, responses with a 0 length payload are sent to the host when a NOISE_ERROR occurs. The ReplicatorG packet handling code doesn't handle 0 length payloads properly. It consumes the CRC byte as a payload byte and then sits there waiting for a CRC byte. The read eventually times out and an error is reported to there ReplicatorG console. I'll post a patch to the ReplicatorG code shortly
diff --git a/v2/src/Motherboard/Host.cc b/v2/src/Motherboard/Host.cc
index a7f635b..26a97bf 100644
--- a/v2/src/Motherboard/Host.cc
+++ b/v2/src/Motherboard/Host.cc
@@ -269,6 +269,12 @@ inline void handleToolQuery(const InPacket& from_host, Ou
}
if (in.getErrorCode() == PacketError::PACKET_TIMEOUT) {
to_host.append8(RC_DOWNSTREAM_TIMEOUT);
} else if (in.hasError()) {
// An error occurred during response reception.
to_host.append8(RC_GENERIC_ERROR);
} else if (in.getLength() < 1) {
// Tool returned an invalid response payload.
to_host.append8(RC_GENERIC_ERROR);
} else {
// Copy payload back. Start from 0-- we need the response code
for (int i = 0; i < in.getLength(); i++) {
please disable steppers when not building and machine has been inactive for X minutes (5?)
The new replicatorG/firmware combo results in unexpected moves at the end of the build; probably due to a synchronization problem between the motherboard's and replicatorG's idea of the current build position.
Sending a reset to the motherboard should send a reset to all toolheads.
In EC firmware 1.8 and 2.2, the makerbot heated build platform cycles on and off correctly and maintains temperature.
With EC 2.3, in the control panel the board power is cycled on and off correctly, but while building, the power never turns off, causing the heated build platform temp to skyrocket.
Axis inversion needs to be supported. Default should be Y inverted, rest non.
In the T2 tests, the mixed passthru packet test is getting errors after a time. The board enters a bad comms state and stays there. The problem is not corrected by an extruder reset; a mobo reset is required.
Add individual PID control for the HBP.
We've been hedging on this for a while; it's time to fully bring up support in the firmware.
Add support for the v3.X series of extruder controllers
The Gen3 protocol spec is a mess of obsolete cruft and wacky comments. It needs to be compiled into something more along the lines of a reference, preferably on a wiki.
Tag v1 as v1.
Move v1 to v1 dir and v2 into trunk (for now).
default the name to the first 8 letters of the gcode name + .s3g (or somethign similar)
eg: teapot.gcode -> teapot.s3g
eg: whistle-posse.gcode -> whistle-p.s3g
I've been trying to build the makerbot mini (thing:2626) for the past 2 days now and the last 5 tries failed due to the x stage trying to commit suicide or a high pitched whine from the y stage.
After pressing "stop" and opening the control panel the x or y will be at values around 2000 or so. It doesn't happen always at the same point.
This is with printing from SD, since printing from serial will give a timeout after 3-4 layers.
This is with the latest firmware from git master on both extruder and mainboard, as well as the latest git of repG.
Host thread isn't responding to commands while waiting for toolhead. Should at the very least handle reset commands, etc.
With the current firmware from git (e7776e4) and the latest repG (ade5e498ece44b80c11b) the extruders stops extruding (as in, the DC motor doesn't turn) at random moments. It usually resumes a bit later on. It doesn't seem gcode related, since using the same gcode file it stops at different places when retrying builds.
I used repG to slice the cupcake transformer body and the bug usually happens in the first 4 layers.
To rule out EMI I moved the extruder controller next to the mainboard and used a 40cm cat6 cable to connect them.
It happens when printing from repG as well as printing from SD.
Reported by Nick Starno:
(Looks like a sign extension issue on fixed point conversion.)
Re-add homing support.
Ignore - my mistake.
The fan needs to be toggleable in v2.
Soft resets are getting "unsupported command" responses.
Widget here,
Could you include something in the startup code to blink all the leds on both boards when they are turned on? This will help my Q&A process to pick out boards with bad leds.
as a safety measure, we should turn off all motors, and the atx power supply after X minutes of inactivity (no comms, not actively printing)
burning motors left on overnight = bad!!
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.
Multiple reports: pause does not halt extrusion with mobo 2.0, ec 2.2.
Protocol needs to be added for debugging communications issues, especially on the (currently very twitchy) RS485 bus.
An oscilliscope needs to be brought to bear on the issue, at the very least. Termination needs to be examined.
If for some reason the extruder heater fails the build should abort to stop the extruder motor from forcefully pushing the filament into a cold barrel.
The mk5 drive gear works a bit too well in these kind of situations.
Double-check for any regressions before release
Motor reversal flags require a firmware restart to take effect. They should be operative immediately.
Hi,
I fired up the latest RepG 0015 with 2.1 mobo and 2.3 EC firmware. I am still getting this error:
http://www.youtube.com/watch?v=qnM4YaDsiKo
which has not yet been addressed. It makes the temperature fluctuate like crazy. Please help!!
Re-add support for endstops.
Test timeouts and ensure that they do not fail on clock rollovers. Now that we have unattended multibuilds, this is actually a priority.
Add an eeprom configuration byte to assign HBP and fan mosfet channels.
Waiting on command processing is probably OK with the tighter loops, but we should probably reintroduce the point queue again.
Add support for upcoming motherboard v2.X to v2
Several reports that the build platform is not reaching the set point temperature
Although I have no idea how to recreate this bug, whenever I try to compile the ArduinoSlaveExtruder of today's code in git after copying config.h.dist to config.h I get the following error in the arduino debugging text area:
o: In function __vector_11': multiple definition of
__vector_11'/tmp/build3741553984868595993.tmp/Servo/Servo.cpp.o:/home/rob/Desktop/arduino-0017/hardware/libraries/Servo/Servo.cpp:104: first defined here
My machine specs: Arduino 0017 [0013 was previously installed], Linux [Ubuntu 9.10]
However, if i try it on my windows box (Arudino 0017, Windows 7, no previous Arduino installations) it works.
I am unsure how to recreate this problem, but I'm posting this in the hope that more people with the same issue will post and we will begin to see a pattern.
Some movements (like each vertical z increment) are very jerky. We should implement some sort of stepper speed ramping implementation to handle this gracefully. There is an example implementation in adrians 5axis firmware.
If I name parts ending in sequential numbers (e.g., part1.s3g part2.s3g ) then part2 is sometimes deleted and part1 may also be corrupted. The corrupted part sometimes will print part way and then just stop, with the extruder going and the machine not responding to serial commands until I reset. A subsequent chkdsk on the card releases abandoned blocks, so whatever happened didn't update the freemap correctly either.
Sometimes part2 will dissapear even when I haven't tried to print part1 yet.
Why is the firmware writing to the card at all? I would think the only time it should be writing is if a part is uploaded via serial to the card.
Blink codes are cool and all, but it would be nice to be able to send a debug packet to shut them off. Define such a packet and implement in v2.
While we're at it, why not include a "set blink code" packet for testing? There is no good answer for that, so it should happen.
If the eeprom contains a machine name, display it in the big bar so you know exactly which machine you've connected to.
Spend one full day just building and running tests.
Create a "how to build the firmware" page on the wiki that explains how to do a build with scons and avr-libc/avr-gcc.
Review and Merge RevarLCD code. He modded v2.0 BETA 2 for LCD with accompanying 16-button keypad support. I merged with master and made one additional change to update it.
It was possible to compile the 1.8 firmware to support stepper driven extruders, either directly from the extruder board, or (with Rick Pollack's patch) via a separate stepper driver.
More people are becoming interested in a stepper driven extruder as an option, so it would be good to have support for this in the latest firmware. (There was mention at the initial release of 2.0 firmware about plans to support this, but I haven't seen anything since, and there are no current issues that seem to track this).
If the heater is on for a specified interval and the thermistor does not register a temperature increase after that time, shut down the heater and indicate that the thermistor is shorted, malfunctioning, or disconnected. The parameter should be configurable in the extruder eeprom.
Halts are not stopping the extruder head.
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.