Hydra-MMM Software and Firmware Release!

So after having lots of trouble modifying the Reprap firmware, I decided I would start from scratch and create all the software and firmware needed to control our multi-headed machine. The firmware is a little less "matured" than the full blown reprap firmware, but it is able to perform all of the functions that we are going to need and is much easier to modify and play with IMO. The host software is written in Processing and has some advanced features not present in the reprap host. It has the ability to send Gcode files as well as individual files. When a file is being sent, the process can be paused and individual commands can be sent mid build. The firmware has support for multiple stepping modes via my custom Arduino library (cpwStepper). It supports wave drive, half stepping, full torque, and micro stepping all the way up to 64x. These stepping modes can also be changed on the fly, mid-build. There are a lot of additional gcodes I have also added support for to be more in-line with standard gcode packages.

I started up a project on Sourceforge to store all the release files. The project is labeled Hydra-MMM for Hydra Multi-headed Manufacturing Machine. Please go here to download the files: https://sourceforge.net/projects/hydra-mmm/

The entire thing has taken me about 2 weeks to write along with all my other work on the machine, but I feel it is coming along nicely. Here is some more background on the project:

Hydra is a multi-headed manufacturing machine that is originally being designed and built for ME463 (senior design) at Purdue University. The general idea is to make a personal manufacturing machine that will be able to perform multiple, simultaneous operations such as milling, additive prototyping, pcb fabrication, laser etching, etc. For the most part, current industrial workplaces have dedicated machines for each one of these functions. By having multiple independent toolheads on the machine, Hydra will be able to perform compound operations that are not possible on dedicated machines (ie FDM rapid prototyping and milling for more accurate part outlines). Hopefully the project will lead to potential discoveries of new manufacturing techniques through the use of compound operations, as well as create a very cost effective product for small business or educational institutions who cannot afford current commercial machines.

The Sourceforge project will contain the microcontroller firmware and host software for the machine. The firmware was written in the Arduino development environment (http://www.arduino.cc/) and is currently being used on an Arduino Mega microcontroller. The software is written in the Processing development environment (http://processing.org/) and is written in Java. Because of this the host software can be run on Windows, Mac OS, and Linux operating systems. The software and firmware communicate via a serial interface. Standard machine language (Gcode) as well as custom M codes are being used for communication.

Please see: [cpwebste.blogspot.com] for more information about the project




So again, I have uploaded all of the software to the sourceforge project here: https://sourceforge.net/projects/hydra-mmm/

I would love some feedback on the code as far as optimization, bugs, additional features I should add, or anything like that!

I'm adding a screenshot of the GUI. It shows the new file previewer I added which makes it really easy to skim through the timeline of a gcode file and see what the build will look like and look for any incorrect gcodes. Thick lines are used for extruded movements while thin lines are used for movements without extrusion. The color of the line also corresponds to the z height of the line to help with 3D visualization.



Edited 1 time(s). Last edit at 02/25/2010 10:10AM by cpwebste.

cpweste, you may want to use this page for your permanent software notes and photos:

[objects.reprap.org]

I've linked to it from the [[HydraBot]] page as well.

Good idea. I went ahead and made 2 pages on the wiki.

One for the machine and the actual physical build at: http://objects.reprap.org/wiki/Hydra-MMM_Prototype

The second is for handling all the software and firmware and it located at: http://objects.reprap.org/wiki/Hydra-MMM_Software_and_Firmware

Just wanted to let everyone here know that I have updated the Hydra-MMM software and firmware to v1.1 with added support for machines using external motor drivers (step and dir pins). Origninally, I was using 4 pins to drive individual MOSFETs attached to each coil of a unipolar stepper motor, but I got a lot of feedback from people who already had Gen3 or similar electronics with external motor drivers. I also did some work on the extruder calculations and routines. Here's the complete list of major changes:

v1.1
- Extruder support added that automatically determines correct extruder speed based on XYZ specified federate
- Support for external motor drivers added, the option is now at the top of the firmware to choose to use dir/step method (for external driver) or defining each coil and using MOSFET transistors or something of that nature (see below)
- Wiring diagram added by request to show how to hook up a stepper motor without an external motor driver
- Made GUI preview window larger and added ability to change the size easily in the Processing sketch (variables pw_width and pw_height)
- Sample gcode file added by request


Head over to the sourceforge page to get the newest release and let me know what you think! https://sourceforge.net/projects/hydra-mmm/

Clayton

I have been using you firmware for my machine and it is really good . I did a little debugging now my machine is a little more complete and found a few areas that need attention. I don't know how to contact you other than through this forum, so here goes.

Firmware

1) The following integer variables need to be larger otherwise when using metric units and microstepping they can go out of range. (This effectively restricts you to a small working area). Declaring these as long variables cures this.

x_steps_to_take, y_steps_to_take, z_steps_to_take, e_steps_to_take;

The linear_move variables "x_steps_remaining" etc. need taking from int to long also
as does the acceleration variables that keep hold of the number of steps.

2) The feed rate uses the longest distance of either x y and z to compute the speed. This may be inaccurate for diagonal moves. (a simple pythagoras equation would calculate the accurate distance and give better feed on diagonals).

3) G and M codes that are not implemented cause problems. A quick fix would be to handle them in the "process_commands" routine with a "break" command until you get around to implementing them fully. for example.

case 999: // M999, call the fire brigade
break;

or just have a catch all to recieve all unhandled types at the end.

GUI

1) The GUI seems to hang when its finished a file so you have to reload it before sending another file.

2) The G code viewer has a few scaling issues when working in metric.

Thanks for the code it is really helping me a lot.

www.HeliumFrog.com

Edited 2 time(s). Last edit at 04/18/2010 04:14PM by martinprice2004.

@martin - thanks for the tips! And just so you know I have email alerts for this thread so this would work as a way to contact me, but I also have a blog at cpwebste.blogspot.com that has more frequent updates and you can post comments there on anything I have posted. Also I should let you know that I have made a LOT of progress over the past 3 weeks for v1.4 of the GUI and firmware and will be releasing those soon (depending on how much free time my schooling allows). I have solved some of the problems mentioned above in the 1.4 revision, but you had some other good ideas that I will implement. I haven't printed any parts big enough to overrun the steps_to_take variables, but I can see how that would happen with 16x microstepping real quickly. I will look at revising my feedrate calculations as your second point for the firmware is definitely a good one. Maybe I can use some find of modified Pythagorean percentage instead.... I'll investigate. However, as for point 3, can you elaborate on why it is giving errors? From my experience if you send a command such as G537 that is not one of the recognized commands, it simply skips it and asks for the next command without doing anything. Switch/case statements usually just exit out if none of the cases are recignized kind of like a giant if, else if, else if, etc. However, I do coding in ~4 different languages so maybe I am getting them mixed up. I think you can also add a default state where it will go to if none of the cases are recognized. But again, I am not seeing these problems so it is hard to troubleshoot. Most of my testing experience is with the 1.4 firmware though so maybe this was an earlier issue that I somehow fixed. As for the GUI issues those are all fixed in v1.4 along with a couple other bug fixes I found.

I'm thrilled that you are using the firmware though! We have been able to do some very high quality prints with it so I think other Reprap users should be pleased with the results. Keep the feedback coming because I only have so much time to test and a bigger user group would definitely help with identifying errors. Look forward to hearing more from you!


Edit: here is some more information about how the Arduino case/switch statements work. Again, it looks like the default case is optional and nothing happens if a case isn't recognized. Someone please chime in if I am wrong about this.

Example from the Arduino reference:

switch (var) {
case 1:
//do something when var equals 1
break;
case 2:
//do something when var equals 2
break;
default:
// if nothing else matches, do the default
// default is optional
}

Edited 2 time(s). Last edit at 04/18/2010 07:34PM by cpwebste.

Is there an advantage to using external driver boards rather than running them directly from the Arduino mega?

Hi,

I'm sorry, but in the v 1.4 package, no release folders for the GUI , no .exe file to run ..

Please can you tell me if it's normal ?
The 1.4 is an update ? I try with the 1.0 version , but handshake problem ... (Backward compatibility exist ? Firmware 1.4 with Hydra_GUI_v1_0 ?

Best regards,

Anyway, thanks for your works !!

Didier.