do you have to delete the heated bed in the marlin firmware when compiling firmware for like rumba32 cnc
firmware for like rumba32 cnc
I’m not sure what this means. Does it mean compiling firmware for the MPCNC for a board like this one? If so, then my typical way to answer these kinds of questions is to go look at configuration.h and configuration_adv.h in a version of the firmware maintained by V1. I don’t find a any Marlin setting that “deletes” a heated bed, but I do find this line:
#define TEMP_SENSOR_BED 0
…which says there is no temp sensor for the heated bed.
From a practical standpoint I don’t think it matters if the heated bed is enabled or not. CNC postprocessors don’t generate an M140 g-code, and in the cases on this forum where I see a M140, it is a problem that can be fixed with the printer setup/start code in the g-code sending tool.
If you have the source to a version of the firmware that runs on your Rumba32 board, then you might consider doing a “diff” on the configuration.h and configuration_adv.h files of that firmware and the firmware maintained by V1 that matches closest to the Rumba32 board…probably the SKR Pro 1.2 or the SKR 1.3 firmware. These days I use Meld to do my “diffs.” This will show you how the Rumba32 settings are different than a V1 maintained version of Marlin. You can then elect to merge in changes starting from either version of the firmware.
thanks if there’s no thermister, it won’t read it.
what is meld and what do you mean by diffs. learning here. A why would I need to do my diffs. oh that sounds like I am being smart with you, but I am not thanks.
I’m going to be pretty basic here…and long. If I’m too basic or too long, I apologize in advance. I’m going to be writing about Marlin. There are other firmwares used for both 3D printing and for driving a CNC, but Marlin is the one V1 maintains, and is the primary one used by MPCNC users. Marlin starts out as this large body of human readable source code with dozens (hundreds?) of settings and options. Once the settings and options have been selected, the source code is compiled to produce a version that is readable by the microprocessor on your control board. This machine-readable version is often referred to as a binary and often will have the file extension of “.bin”. That binary is then installed (flashed) on the control board.
Making the changes to any of Marlin’s settings or options results in a different binary file. In order to run Marlin on particular board and for a particular use, you need select the right options and settings for both the board itself and for how the board will be used. These options and settings fall into these rough categories:
- Settings specific to a particular control board
- Settings V1 have selected to support the MPCNC
- Settings for the particular display you are using
- Settings for the particular stepper drivers you are using
- Settings for additional features
V1 maintains firmware for a list of control boards with specific displays and stepper drivers. You can find these versions here. If you download one of these versions, you will have a ZIP (compressed) file. If you open/uncompress that file, inside you will find the machine readable binary along with a ZIP file. If you then uncompress the inner ZIP file, you will have all the human readable source code setup with all the options and settings that produced the binary file for that version.
While there are a ton of files in the directory tree, typically in order to configure Marlin, only two files are modified: configuration.h and configuration_adv.h. These two, human readable files will be in the Marlin folder. They can be opened and modified with any text editor.
Some areas of these two files will look like this:
// // G20/G21 Inch mode support // //#define INCH_MODE_SUPPORT
The double slashes comment out lines. If you remove them on this specific #define line, you will enable Marlin to handle g-code that has coordinates in inches in addition to the default mm.
Other places have lines like this:
// This defines the number of extruders // :[0, 1, 2, 3, 4, 5, 6, 7, 8] #define EXTRUDERS 0
Where the value 0 is assigned and used. And for some defines (not this one) you may need to change the value(s).
So now to the heart of your question. Most of us hobbyists don’t know much about the inner workings of Marlin. So in order to make changes it is often beneficial to follow what someone who knows more than we do did in order to make the same or similar change in another version of the firmware. So for example, if we want to use a different stepper driver, we can compare a version of the firmware that uses our target stepper driver against a version of the firmware that does not use that stepper driver. Seeing the differences, we can make changes to match to enable support for the new stepper driver.
By “diff” I was referring to a class of tools that show the differences between two text files. They will show where lines have been added, where lines have been removed, and where lines have been changed. Meld is just one free, standalone tool that you can use to compare two text files to see how they are different.
Note getting the Rumba32 board running for an MPCNC is going to be significantly more work than using one of the V1 supported boards. Your staring point will likely be getting some version you compiled (even if it targets 3D printing) of Marlin running on your board and using your display. This will give you a base version from which you can make the changes to support an MPCNC. Note that manufactures often have github pages where you can download a version of Marlin for a specific board/machine.
Edit, if you take a look at my post in this topic, you will see an image of what the output from Meld looks like.
3 Likes