reprappro / reprapfirmware Goto Github PK
View Code? Open in Web Editor NEWOO C++ RepRap Firmware
License: Other
OO C++ RepRap Firmware
License: Other
This firmware is intended to be a fully object-oriented highly modular control program for RepRap self-replicating 3D printers. It owes a lot to Marlin and to the original RepRap FiveD_GCode. This is the version for the RepRap Duet: http://blog.think3dprint3d.com/2013/12/Duet-Arduino-Due-compatible-3DPrinter-controller.html To edit and compile this you will also need the libraries in this repository: https://github.com/jmgiacalone/Arduino-libraries A complete uploadable executable version is in the directory Release/RepRapFirmware.bin in this repository. For details of how to flash it to a Duet see here: https://reprappro.com/documentation/commissioning-introduction/maintenance-duet/#Installation_8211_Flashing_the_Firmware For details of how to compile the source code, see below. General design principles: * Control by RepRap G Codes. These are taken to be machine independent, though some may be unsupported. * Full use of C++ OO techniques, * Make classes hide their data, * Make everything except the Platform class (see below) as stateless as possible, * No use of conditional compilation except for #include guards - if you need that, you should be forking the repository to make a new branch - let the repository take the strain, * Concentration of all machine-dependent definitions and code in Platform.h and Platform.cpp, * No specials for (X,Y) or (Z) - all movement is 3-dimensional, * Except in Platform.h, use real units (mm, seconds etc) throughout the rest of the code wherever possible, * Try to be efficient in memory use, but this is not critical, * Labour hard to be efficient in time use, and this is critical, * Don't abhor floats - they work fast enough if you're clever, * Don't avoid arrays and structs/classes, * Don't avoid pointers, * Use operator and function overloading where appropriate. Naming conventions: * #defines are all CAPITALS_WITH_OPTIONAL_UNDERSCORES_BETWEEN_WORDS * No underscores in other names - MakeReadableWithCapitalisation * Class names and functions start with a CapitalLetter * Variables start with a lowerCaseLetter * Use veryLongDescriptiveNames Structure: There are eight main classes: * RepRap * GCodes * Heat * Move * Platform * Network * Webserver, and * PrintMonitor RepRap: This is just a container class for the single instances of all the others, and otherwise does very little. GCodes: This class is fed GCodes, either from the web interface, or from GCode files, or from a serial interface, Interprets them, and requests actions from the RepRap machine via the other classes. Heat: This class implements all heating and temperature control in the RepRap machine. Move: This class controls all movement of the RepRap machine, both along its axes, and in its extruder drives. Platform: This is the only class that knows anything about the physical setup of the RepRap machine and its controlling electronics. It implements the interface between all the other classes and the RepRap machine. All the other classes are completely machine-independent (though they may declare arrays dimensioned to values #defined in Platform.h). Network: This class implements a basic TCP interface for the Webserver classes using LWIP. Webserver: This class talks to the network (via Platform) and implements a simple webserver to give an interactive interface to the RepRap machine. It uses the Knockout and Jquery Javascript libraries to achieve this. In addition, FTP and Telnet servers are provided for easier SD card file management and G-Code handling. PrintMonitor: This class provides methods to obtain statistics (height, filament usage etc.) from generated G-Code files and to calculate estimated print end-times for a live print. When the software is running there is one single instance of each main class, and all the memory allocation is done on initialization. new/malloc should not be used in the general running code, and delete is never used. Each class has an Init() function that resets it to its boot-up state; the constructors merely handle that memory allocation on startup. Calling RepRap.Init() calls all the other Init()s in the right sequence. There are other ancillary classes that are declared in the .h files for the master classes that use them. For example, Move has a DDA class that implements a Bresenham/digital differential analyser. Timing: There is a single interrupt chain entered via Platform.Interrupt(). This controls movement step timing, and this chain of code should be the only place that volatile declarations and structure/variable-locking are required. All the rest of the code is called sequentially and repeatedly as follows: As of version 057r-dc42 the tick interrupt (which is set up by the Arduino core) is also used to set up ADC conversions, read the result of the last conversion, and shut down heaters when temperature errors are detected. All the main classes have a Spin() function. These are called in a loop by the RepRap.Spin() function and implement simple timesharing. No class does, or ever should, wait inside one of its functions for anything to happen or call any sort of delay() function. The general rule is: Can I do a thing? Yes - do it No - set a flag/timer to remind me to do it next-time-I'm-called/at-a-future-time and return. The restriction this strategy places on almost all the code in the firmware (that it must execute quickly and never cause waits or delays) is balanced by the fact that none of that code needs to worry about synchronization, locking, or other areas of code accessing items upon which it is working. As mentioned, only the interrupt chain needs to concern itself with such problems. Unlike movement, heating (including PID controllers) does not need the fast precision of timing that interrupts alone can offer. Indeed, most heating code only needs to execute a couple of times a second. Most data is transferred bytewise, with classes' Spin() functions typically containing code like this: Is a byte available for me? Yes read it and add it to my buffer Is my buffer complete? Yes Act on the contents of my buffer No Return No Return Note that it is simple to raise the "priority" of any class's activities relative to the others by calling its Spin() function more than once from RepRap.Spin(). ------------- Compiling from Source RepRap Firmware was developed using the Eclipse IDE, which is much more powerful for big software projects than the Arduino IDE. We use Eclipse Juno, which is available here: http://www.eclipse.org/downloads/packages/eclipse-ide-cc-developers/junosr1 You will also need the Eclipse Arduino support: http://www.baeyens.it/eclipse/Install.html And the Arduino IDE itself (make sure you get the one for the Due/Duet - version 1.5.5 at the time of writing): http://arduino.cc/en/Main/Software As of this firmware version 0.57r-dc42, the Arduino IDE must be patched to enable watchdog support. Locate function init() inside file variant.cpp (....\hardware\arduino\sam\variants\arduino_due_x) and comment out the call to WDT_disable(WDT). If you don't do this, the firmware will still work but you won't get the benefit of watchdog protection. Finally you will need our libraries for driving the peripherals: https://github.com/jmgiacalone/Arduino-libraries Start by getting the Arduino IDE programming your Duet with a simple Hello World program that prints to the USB (SerialUSB.print("Hello World"); on the Due/Duet, not Serial.print("Hello World");... ) Then install Eclipse and the Arduino plugin. Make temporary copies of RepRapFirmware.cpp and RepRapFirmware.h from your download in another folder (you will only need to do this once). Finally use Eclipse to open the Arduino project called RepRapFirmware in the folder where you have downloaded the RepRap Firmware code. Tell Eclipse to use the Arduino-libraries files you downloaded as the local libraries. Eclipse will complain that the project already exists (which it does - it is your download). Ignore this and it will open the project anyway. Annoyingly the first time it may also overwrite RepRapFirmware.cpp and RepRapFirmware.h. So close the project, overwrite its overwrites with the two files you saved, open the project again and refresh it. Everything should now be ship-shape. Add the libraries Wire EMAC Lwip MCP4461 SamNonDuePin SD_HSMCI to your project. Under no circumstances be tempted to add standard Arduino libraries for devices like Ethernet - these are for the Due, and will not work on the Duet. You should now be able to compile the code and upload the result to the Duet. ------------- Note on dc42 fork of this firmware: As well as containing various bug fixes and performance improvements, I have added various functionality compared to the original RepRapPro version. The major changes are: - Z probe reading is included in the web server poll response - Homed status (i.e. whether homes since reset) is maintained for all 3 axes and included in the web server poll response - Once the X and Y axes have been homed, movement is limited to the range of the axis, except when the G0 or G1 command includes the check endstops (S1) parameter. Use the M208 command to set axis travel if the default values in the firmware are incorrect for your machine. - Implemented M301 (hot end PID parameters) and M304 (bed PID parameters) commands. Extended these commands to allow setting of thermistor resistance at 25C (R parameter) and thermistor beta (B parameter). A negative P parameter means don't use PID, use bang-bang control. - Implemented M999. This resets the Duet. - Added temperature (T) and temperature coefficient of height (C) parameters to the G31 command - Added support for modulated IR sensor (M558 P2) and ultrasonic sensor (M558 P3) - Various parameters are now saved to flash memory (Z-probe parameters, network parameters, PID parameters) - FAN0 line is driven at 25kHz and pin 25 on the expansion header (Duet) can utilise the tacho line of 4-pin PWM fans ------------- Note on zpl fork of this firmware: Based on dc42's long-time proven Duet firmware fork, I have implemented a couple more features and (partially) merged in features from RepRapPro's development firmware branch. The most significant changes are: - FTP and Telnet support - Reliable low-level networking and implementation of the internal EMAC ISR - Internal G-Code queuing to execute non-movement codes just-in-time and not ~20 moves too early (due to the look-ahead) - M25: SD-card prints are paused as soon as the current move finishes - M0 does no longer disable any stepper motors or heaters if the print is paused. This shall simplify print restarts (requires my web interface fork) - Implemented cold retracts, minimum temperature is 90C - Flash usage is optional; only one line needs to be commented out to disable it See the "Changes in ... fork" text files for complete lists of all the changes dc42 and zpl have contributed. ------------- Version 0.mn beta Started: 2012-11-18 This README dated: 2014-10-12 Adrian Bowyer RepRap Professional Ltd http://reprappro.com Licence: GPL
Allow one or more axis/axes to be specified after G28 to reference only the specified axes.
Implement M201/M204 equivalent to set the accelerations in config.g.
M206 just defines a move, then sets the co-ordinates it has moved from as the current location. The offset is lost as soon as you home the axes again. It would be far more convenient to be able to define the offset once in the config.g and for it to be persistent, rather than having to edit all of the homing macros, so it does it after every homing command. This would mimic use of the command in Marlin, then.
At next upgrade from duet branch to master branch
Fixed in dc42 fork 0.65i release, with an improved fix implemented in 0.65j.
Note: there is also an issue with using M550 or M551 with an uppercase G in the password or machine name, already logged as a different issue.
When there are a number of short moves, the velocities may be calculated incorrectly, leading to jarring and missing steps. See http://forums.reprap.org/read.php?340,353333.
M220 (set speed factor override percentage) and M221 (set extrude factor override percentage) commands should be implemented.
Fixed in dc42 fork version 0.59a, commit Duet3D/RepRapFirmware@a416c36.
Web interface 'stop' button sends M112 gcode, which is intercepted and carried out immediately. M112 isn't supported by USB communication; Gcodes.cpp has a null function for M112. It should be simple to add the function call 'reprap.EmergencyStop();' to M112 in Gcodes.cpp
While running V0.69 (duet branch) I hit the problem that I can only set tool temperature (via web-interface) a few times and afterwards setting the temperature doesn't have an effect anymore. It was no issue in earlier versions V0.60 and V0.64
current workaround is restarting the duet after each action
The firmware should support long filenames on the SD card.
Fixed in dc42 fork.
If a print is started with the USB cable connected, under certain conditions the PC will stop accepting data over the USB connection, e.g. if it goes to sleep, or if Pronterface is closed, or sometimes when another USB device is connected, or if the USB cable is disconnected. When this happens, if the firmware tries to send data to the USB, it will block. This causes the main spin loop to stop executing. Not only does this pause the print, it also causes the heaters to become uncontrolled.
Fixed in dc42 fork.
Should be fixed, but maybe only in duet branch? Simple change to homey.g and homeall.g
Expand it or remove it.
Set axis direction by M code.
Hi,
It would be helpful to use different directories for gcodes as I have some longer running projects with lots of files and sort of a multi-user environment
Hello,
I am trying to use newest duet firmware on my duet with duex, I have two extruders on the machine, I see right temperature, but when I try extrude material or heat the hottend I had this message:
Attempting to extrude with no tool selected
or
Setting temperature: no tool selected
Optimise these for Ormerod and set as defaults in config.g.
Three points:
Get nozzle offsets working.
Hello,
sometimes I have an issue with homing axis when using printer with Pronterface.
For example I press Y home, but actually X start to homing, sometimes button for homing all axis doesnt work and I need to press X home first and then homing all axis works fine...
I am not sure if the problem is in Pronterface or firmware, but with firmwares I havent these problems in Pronterface....
Thank you
The web server needs to be improved so that all web-related files can be served from the SD card on the Duet, instead of having to serve .js, .css files etc. from the internet, which isn't possible for some users running behind a firewall.
Fixed in dc42 fork version 0.59.
Via web interface and USB.
The G31 command in the original firmware allows only one P and Z value to be configured. Multiple values may be required under the following conditions:
dc42 fork implements (1) by storing separate G31 Z and P values for sensor types 0, 1/2, and 3.
I am trying to upload T3P3 firmware on duet board. Printer is working fine, but I have just one problem. After pressing home all axis on Pronterface all axis are homed corectly, but when I send M114 it's like X:194 Y:197, Z:195, but I would like to have everithing on 0 after homing, what should I change in firmware? I have now default setting in firmware, changed is just build area.
Thank you
Allow G92 to set current position from the USB connection, with equivalent functionality available from the web interface.
Hi, I tried upgrading my FW to the RepRapFirmware-065b, 065c and 065D. But the Z motor is making a clicking noise every so meany revolutions. I can go back to the 057a and the Z motor work fine. Any way’s, I don’t have a Debug port or I would give it a go
Set minimum and maximum speeds optimally for moves of all three axes at once (in development in the vel branch).
Give finer control over specifying which axes use a sensor. Something like:
M558 P1 X0 Y0 Z1
Where P0 is sensor off and P1/2/XXX is used for probe type (already implemented). X0 Y0 Z1 define which axes use the sensor - 0 for off, 1 for on.
While waiting for the temperature to reach the target temperature, no temps are sent via USB. I think that the web interface does report them during this time.
If a G1 command includes the S1 parameter to enable endstop checks, then the movement will be terminated if the endstop is hit but the following move will be calculated assuming it starts from the position that would have been reached had the endstop not been reached, leaving the head in the wrong position. For example, G1 Y240 S1 followed by G1 Y0 does not place the head at Y=0.
Fixed in DC42 fork version 0.57r and later.
Workaround: always follow a G1 S1 command by a G92 command that sets the position of the axis concerned to the known position of the endstop. In the case of using a high endstop (e.g. Ormerod Y axis), this requires knowledge of the axis length.
If the firmware locks up for any reason (e.g. a mains transient coupled through the USB cable ground) then the heaters become uncontrolled and overheating may result.
In the dc42 fork this has been fixed by (1) adding a tick interrupt routine that checks for overheat situations, (2) enabling the watchdog timer, and (3) kicking the watchdog during the tick interrupt.
Hi,
my printer is two extruders machine. Extruding, heating and move in x and y axis works fine.
but strange thing happens, when I try to print something, when its time for move layer up Z axis doesnt move as it should (just tiny move) and I hear some strange noise, almost beep...
When I move with hotend in Z axis in pronterface or do Z homing, Z axis works fine, problem is only when printing, I found that it happen directly after the code "G92 E0" even it doesnt make sense for me, when I deleted all "G92 E0" in gcode file, moving in Z axis was fine,
Here are my sd/sys and my platform files, the only files that I changed on firmware.
https://drive.google.com/folderview?id=0B_zsCEMKg3fibmVtaTZ5bXZMT0U&usp=sharing
Thank you for any help!
Neither the web interface nor Pronterface can upload or delete an SD card file if the filename sent in the corresponding Mcode includes an uppercase letter G. When attempting to upload such a file, typically the Duet starts printing the file instead. This also affects M550 commands if the machine name contains an uppercase G, and M551 commands if the password contains an uppercase G.
Fixed in dc42 fork as at version 059a-dc42, commit Duet3D/RepRapFirmware@a416c36.
Fixed in dc42 fork sometime prior to version 0.59.
Or significantly improve Pronterface upload speed.
When I use DC42 FW the problem go's away. Its just the RepRpPro FW from the master branch. Note - I think this is the issue I have been having all along. Its just gotten more defined
A means to set all extrude heads to standby temperature.
Also, a means to turn all extrude heads' heaters off.
Fxxx sometimes ignored by G1? Maybe - needs to be checked.
... so 2 Duets can't coexist on network.
http://forums.reprap.org/read.php?340,350570
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.