makerbot / g3firmware Goto Github PK

Re-add support for endstops.

Axis inversion needs to be supported. Default should be Y inverted, rest non.

Spend one full day just building and running tests.

Halts are not stopping the extruder head.

Tag v1 as v1.
Move v1 to v1 dir and v2 into trunk (for now).

Reported by Nick Starno:

• Setting I at 0.8 causes bad behavior and returns -0.203 when revisited.
• Setting I at 1.8 returns 0.79.

(Looks like a sign extension issue on fixed point conversion.)

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.

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++) {
  

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.

Add individual PID control for the HBP.

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 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.

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.

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.

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!!

Host thread isn't responding to commands while waiting for toolhead. Should at the very least handle reset commands, etc.

Waiting on command processing is probably OK with the tighter loops, but we should probably reintroduce the point queue again.

• Add better documentation to the code body.
• Ensure that license is at the top of each source file.

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

If the eeprom contains a machine name, display it in the big bar so you know exactly which machine you've connected to.

Several reports that the build platform is not reaching the set point temperature

Ignore - my mistake.

Motor reversal flags require a firmware restart to take effect. They should be operative immediately.

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.

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.

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

Soft resets are getting "unsupported command" responses.

Add an eeprom configuration byte to assign HBP and fan mosfet channels.

Sending a reset to the motherboard should send a reset to all toolheads.

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).

Add support for upcoming motherboard v2.X to v2

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.

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.

Multiple reports: pause does not halt extrusion with mobo 2.0, ec 2.2.

We've been hedging on this for a while; it's time to fully bring up support in the firmware.

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.

Add support for the v3.X series of extruder controllers

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!!

please disable steppers when not building and machine has been inactive for X minutes (5?)

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.

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.

Re-add homing support.

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.

Double-check for any regressions before release

Test timeouts and ensure that they do not fail on clock rollovers. Now that we have unattended multibuilds, this is actually a priority.

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.

• M126 valve open
• M127 valve close

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.

The fan needs to be toggleable in v2.

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.