Firmware to-dos
phooky
I'm working on in firmware land over the next couple of weeks.
* I've been transitioning the codebase to a form that's easier for
automated builds to handle. The Arduino environment is just C++, but
it performs all sorts of goofy tricks on the .pde files--
autogenerating and sorting function prototypes, concatenating files,
using #includes in the code to implicitly construct include paths,
etc.-- that make it difficult to do builds outside the arduino
environment. This means recasting .pde files as .cpp/.h files,
breaking functionality out into different blocks, etc. There's also
been some general maintainability refactors as well.
* I'm starting to give the RS485 comms code some attention. Dropped
packets between the extruder and motherboard are the primary cause of
blobs and hangs, and it looks like the current comms are marginal
enough that the quality of the patch cable is a real issue.
* There's been requests for supporting RepRap-style acceleration in
the firmware. This should be easy enough to do, but the gcode needs
to be generated differently. I'm thinking we'll add support for a new
M-code to toggle this behavior on and off.
What do you want to see in the firmware? What's your biggest gripe?
-a
Keith Neufeld
hangs that are more and more often ruining the entire build, so I'd
worship you for fixing this.
You mention that the quality of the patch cable is currently
important. I've tried a couple of different ones and I haven't
noticed any change in frequency of errors in the ReplicatorG monitor
panel. Do you have a recommendation for what I should be looking for
in a patch cord? With differential signaling, I'm surprised that a
cable good enough for 1Gbps ethernet isn't good enough for low-speed
data. I'm a little freaked out that we're running unterminated, but I
don't really know enough about RS-485 to speak to that with
confidence, though.
Would it help to move power out of the comms cable? I've occasionally
wondered if edges in motor or heater current are messing up comms.
Regarding other firmware issues, is the firmware watching the endstops
during the build? Several times when the nozzle snagged and the build
table ended up in a radically different place on the X or Y stage than
the firmware thought it was, I've observed the CupCake grinding the
table against the end of travel on one axis or the other, while the
stick was clearly triggering the endstop.
While manually moving the table with the control panel, I think I've
noticed a behavior that might explain this. It seems as though it
tries to move the motors one step or cycle _before_ checking the
endstop, instead of checking the endstop first and refusing to move
that direction at all. When I'm running it from the control panel,
this results in a brief "grunt" and then it stops moving. Maybe the
"grinding" is repeated grunt-grunt-grunt as it tries to move a little
before realizing it shouldn't be?
Adam Mayer
I'm hoping the problem is one that I can fix in firmware. The RS485
comms *should* be completely solid, and it's kind of befuddling that
they're not. (The comms lines are terminated with 100-ohm resistors
at either end, which should approximately match the impedance of a
short cable.) It could be noise coming in over the power pins to the
rs485 chip, or any one of dozens of things. If I had a capture scope,
this would probably be a lot easier. :/ Anyway, for now, I'll just
try to improve error handling on the comms (we have CRCs on every
packet, so it shouldn't be hard to force resends).
The firmware should be watching endstops both during control panel
movement and builds, so you can test that they're working by
triggering them by hand while moving the platform in the control
panel. The LED on the endstop should illuminate when the endstop is
triggered. If it's not triggering reliably, try putting a bit of
black electrical tape on the endstop flag to help block the light.
The platform shouldn't move at all in the wrong direction while the
endstop is triggered; I've just tested this, but I'm using v1.6 (which
is going to be released in a few hours); it's possible this was a bug
in the last revision that got fixed during some of the refactoring.
Try v1.6 later today and see if you still have that problem.
-a
Keith Neufeld
that were omitted from the kits and Zach said in some emails and forum
messages to leave out? Am I thinking of something else?
I'll wait (eagerly; I'm pumped about the PID heater!) for v1.6 and
give the endstops a try. Thanks!
Adam Mayer
the boards, which don't have the resistor. -a
Keith Neufeld
> the boards, which don't have the resistor. -a
I expect you won't see much reflection on this short a cable (well,
won't distinguish it as reflection), so it probably doesn't matter,
but I still wonder every time I see the error on the console.
Adam Mayer
you'd just need a couple of 1206 100-ohm resistors to try it out.
-a
Keith Neufeld
is the same as the one you're describing. I get a lot of "Error:
payload not big enough." on the ReplicatorG console at times that
correspond to the table freezing and a blob forming. Is this the same
thing you're talking about? This would seem to be a problem with USB
serial comms between the motherboard and the host, not necessarily
RS-485 comms between the motherboard and the extruder.
Oh, I remember an idea I had -- I'll try capturing a model to the SD
card and printing from there. If I still get hangs and blobs in
random places, it's RS-485 comms. If I can't even capture to the SD
card, it's host comms.
I added the 100-ohm resistors this morning and already had payload
errors showing while I was just moving the Z axis in the control
panel. It feels like termination made things worse -- which supports
your idea that it's the RS-485 causing the problem.
Tim Myrtle
* Move development to github. Much easier to fork experimental
code. Also much easier to follow and understand code changes. And
the issue tracker would be nice.
* I'm still trying to figure out how to do online firmware debugging.
With the command/response communication format, adding print
statements on the master or slave don't work. If anyone has figured
out a workaround for this I'd love to hear about it.
* Jogging: We really need to be able to jog the printhead at a slow
speed by holding down a direction key. Moving in fixed increments is
painful. I guess because of the way move commands are buffered we
can't do this. Would love to see this fixed.
-Tim
Adam Mayer
Traditionally the payload underflow error has occurred on a failed
rs485 comm. I'm turning on a lot of debugging code to try to get to
the root of the issue.
I wasn't expecting the termination resistors to make the situation
that much worse, but it's entirely possible. I'll be playing around
with those as well.
-a
Adam Mayer
Moving to git is definitely in the works. Our codebase is currently
spread between several repositories (replicatorG on google code;
firmware on makerbot svn), and I'd like to get everything on github
soon.
The packet format makes debugging a little goofy, but I'm comfortable
with adding some debug polling to the protocol.
The easiest solution I see to the interactive jogging problem at the
moment would to be to essentially send the equivalent of "keydown" and
"keyup" commands. They could be implemented as queries rather than
queued commands to keep the response times low. The only tricky bit
would be ensuring that they don't stomp on queued commands that are
being run and vice versa (it would probably make sense to ignore these
commands while the buffer is not empty).
-a
Rick
Adam -
- Is there a way to decrease the time it takes to transfer a print job
to the SD card. It seems to require an entire build cycle to transfer
the file. What about copying the file directly (insert card into
machine -> copy file)?
- (not sure what reprap acceleration means since I haven't used a
reprap. variable accel?) However, on MB when the motor change
direction the result is often jarring - especially at faster build
speeds - is there a way to smooth the direction changing process to
reduce the vibration and such?
- when printing a column, for example, is there a way to do continuous
printing (z is constantly increasing at a gradual rate rather than the
typical step approach). Not a high priority, more of how-to curiosity.
Tim -
When you say - online firmware debugging - what exactly do you mean?
Rick
Tim Myrtle
> Tim -
>
> When you say - online firmware debugging - what exactly do you mean?
>
extruder to the host console. Print statements (Serial.println)
don't work -- the host expects communication to be in a query/reponse
format.
-Tim
Rick Pollack
Rick
Safety feature suggestion - if printing and the thermistor stops
working (like a wire comes out of the port), it looks like the heater
temp goes up and up...and there is a lot of smoke... If the thermistor
stops responding (not showing a value or the value is way off the
previous value), the extruder should immediately shut down.
Rick