Wednesday, May 12, 2010


Hydra-MMM v1.4 Finally Released!

I have gone ahead and released v1.4 of the Hydra-MMM software and firmware (, and let me start off by saying that this release is HUGE! There is a ton of new features and changes from the previous release. I probably should have made 2 or 3 intermediate releases over the past few months, but the end of my undergraduate degree required a lot more time than I anticipated. So onto the major additions in the new firmware

If you want more details, the full list of changes from the readme file in the sourceforge release is below

- Added slave temperature control so that the master Arduino can allocate all its resources to handling the machine movement and not dealing with PID temperature control, see the new Hydra_Slave_Temp_Control sketch for the slave firmware and be sure to edit the master firmware to use slave control as well
- Added M301 and M302 commands so you can easily check to make sure your slave Arduino is communicating to the master correctly
- Internal PID control (if you chose to not use slave control) is now updated so that up to 3 temperatures can each be PID controlled by the master (extruder 1, extruder 2, and heated table)
- EEPROM position logging so that absolute positions can be retained even after being powered off, exiting the GUI triggers this to happen (M900 command)
- Added G80 and G81 drill cycle commands for intended use with PCB milling (advanced drill cycle operations not currently supported), this is untested though so use at your own risk!
- Added support for Ncodes at the beginning of each line with the program line as the parameter (ie "N51 G1 X1.00 Y0.00 Z0.00 F30") as programs like MasterCAM like to add this in the gcode file
- Added M120 and M121 codes to run the stepper extruder forward and backward, can use these to pull filament backwards at the end of a move to prevent excess nozzle oozing or to start filament flow at the beginning of a layer
- Added a G5 jog gcode for simple movements without needing to know your current position
- Added ability to jog individual Z-axes using the T18 command without triggering the switch_tool routine
- Added a M6 tool change Gcode, the continue_pin button must be pressed once this is done to continue
- added M500 Gcode command that waits for user confirmation (by pushing the continue_pin button) before proceeding
- Limit switch current position handling updated to give more accurate end positioning
- Extruder federate calculations updated to provide better results with our current setup (0.5mm nozzle)
- sticky federates are now supported
- minor bug fixes to multi-headed tool operations (Tcodes) now that I actually have a machine to test them on
- several updates to the startup and exit routines
- updated steps_to_take variables to be longs instead of integers because users with high microstepping rates were able to overrun the integer data types on long moves (thanks martin!)
- stepper motor driver enable logic can now be swapped for different motor drivers so that HIGH or LOW can be used to enable the driver

As always, the release files can be downloaded from the Hydra-MMM Sourceforge page at Give it a try and let me know what you think!

Now, onto the second reason for this post; finding some beta testers to help me improve this firmware! The firmware has a lot of different functions, and for that reason there is a lot that needs to be tested. While most users don't have a 4-headed machine, rapid prototypers and homemade CNC machines are both relatively common. If anyone out there is interested in helping out with testing or developing the Hydra-MMM software or firmware, please email me at or shout out in the comments!

Labels: , , , , , , , ,

Looks good! Are the Gcode's buffered on the firmware side?

Also, how is the G5 command different from G91?
I actually experimented with buffering a large number of gcode commands onto the external EEPROM I was using, but as it turned out the time it took to read a line off the EEPROM was slower than the time it took to send the same line over the serial connection. I2C communication isn't that fast and this method likely requires something faster than the AT24C1024s I was using.

As for the difference between the G5 and G91, the G91 command changes the entire distance mode over to incremental. This would last until it was switched back to absolute positioning (G90). The G5 command would only last for the current line. I found myself constantly wanting to jog my Z-axes while setting up for a prototyping build and I didn't want to have to deal with typing a G91, the actual movement command, and then a G90 every time I wanted to do that. Also, I haven't actually tested sending entire programs using incremental distance mode so I think using the G5 commands is safer at the moment.
Ah, cool. I'm assuming you're still buffering a small number of gcode's in the firmware? I had a lot of trouble with non-realtime OS's causing burps in the builds before the firmwares did any buffering. Plus there's the delay between gcodes - that gets to be a major problem when you're trying to move at 50 mm/s.
We have successfully ported the 1.3 firmware to make it a drop-in replacement of the official reprap firmware, and added support for a Sanguino with a separate extruder controller. There's still a few issues to be solved, but it's printing.

Unlike the official firmware, we have no communication errors with this firmware, and are able to run the serial communication at up to 1.000.000 baud !

I guess we'll update it to 1.4, and then maybe you would consider using that for Hydra too? - It's really just small differences.

The hydra firmware is no doubt much better then the official firmware. Good job!
"We" means Tonokip and Logick did most of the work, I helped debug it :P
@Kulitorum - Good to hear! Glad the firmware is working for you. I always intended the firmware to be as compatible as possible with the current Reprap firmware so hopefully you guys didn't have too much that you had to do. I was actually planning on supporting the Sanguino in v1.5 as well so glad to see you guys beat me to it. Why don't you email me at and we can talk about the details of what modifications you guys had to make. I would definitely be interested in implementing your changes for future releases as it would likely make it easier for others to use it as well.

And I echo your comment about not having any communication errors even with high baud rates. What host software are you using to send gcodes to the firmware?
I think Tonokip has the latest version, I'll get him to mail it to you.

The host software is my own, RepSnapper. It's still in beta, as the gcode generation iteslf suffers from a bad shrink function, but the printing part has lots of users already.

It runs on Windows and Linux. It should be portable to MAC, only nobody who's a MAC programmer has tried.

you can do a SVN checkout from or get the windows exe at

If you do a checkout, you'll get a lot of libs that are really only needed on windows, even if you are doing a linux checkout - I'll change that before a real release.
What about something like a touch-probe? Do you have in mind do some scanner ?
Post a Comment

Links to this post:

Create a Link

<< Home

This page is powered by Blogger. Isn't yours?

Subscribe to
Posts [Atom]