Wednesday, May 12, 2010
Hydra-MMM v1.4 Finally Released!
- One of the biggest changes to the new firmware is the addition of slave PID temperature control. This allows the main Arduino Mega to focus all its attention on the movement and acceleration computations, while the slave Arduino is busy doing PID calculations to regulate all the temperatures. Using this method, I was getting a 20% performance increase on the master firmware which means less pausing between print commands. This leads to improved print quality and smoother motion. See the readme file in the sourceforge release for details about the slave setup. In addition to the option for slave PID control, the internal PID control on the master firmware has also been updated so that it can control up to 3 different temperatures. This is intended to be used with 2 extruders and a heated build table. I don't think many users will require more than that at this point in time, but it is very easy to add more if required.
- Another big change in the v1.4 release that has been very helpful to me is the addition of absolute position logging via an attached EEPROM. This allows the machine to retain its knowledge of position even after the machine is powered off. While the user coordinate system may change from build to build, an additional absolute coordinate system has been added, and this is what is stored on the EEPROM. I have tested this using the 512 byte EEPROM already included with most Arduinos as well as an external AT24C1024 connected via I2C. While I am currently only using this storage for the absolute positioning variables, there is lots of potential here for new features in the future.
- There has also been a lot of changes to the multi-headed operations included in the firmware. Now that I have a machine that I can test these functions on, I have been able to improve the routines and fix any minor bugs that were present. I have successfully used these functions in several multi-tool builds that I have done and they are very simple to implement. My next big task in this arena is likely going to be figuring out how to generate multi-funtion Gcodes that can be used for doing both milling and prototyping or something of that nature. At the moment I am just splicing together 2 seperature Gcodes with the appropriate tool switching commands in between. Automating this process would be a nice addition and I believe skeinforge has the ability to calculate both additive and subtractive toolpaths so it should be possible.
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
Also, how is the G5 command different from G91?
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.
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!
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?
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 http://svn.kulitorum.com/RepSnapper or get the windows exe at http://svn.kulitorum.com/RepSnapper/MSVC/Release/RepSnapper.exe
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.
Links to this post: