CBot Marlin to 'mainline' marlin 1.0 or 1.1

I just got a 3d printer by Createbot, a Prusa i3 clone, that I have their firmware for (albeit it was broken as sent to me and I had to fix it to get back to square one), and it works, but I'm interested in trying out the 'real' Marlin 1.0 or 1.1 firmware - I can't imagine there aren't improvements since the 1.0.0 RC2 that is apparently running on my controller (this one, that is set up as Motherboard '33' in their firmware). But when I try to build the 1.0 or 1.1 versions, I get errors. If I try to build them as opened from the zip files as downloaded, they compile fine - but once I go through the firmware that they sent me and modify settings as needed (I think the 'killer' here is dual extruders..), when I try to compile, it fails.

Any suggestions as to what I need to do to port the CBot 'version' of Marlin (if it's really anything 'special' other than a REALLY old version of Marlin) over to the latest 1.0 branch or maybe the 1.1 branch of Marlin? Like I basically said earlier, Marlin hasn't gone from 1.0.0 RC2 (that is on my controller) to 1.1.x without improvements and/or enhancements.

Edited 1 time(s). Last edit at 12/31/2017 12:42AM by Cougar281.

For sure... You want to move to Bugfix v1.1.x

Use a visual diff program like Notepad++ (with the visual diff add on enabled) to help with the migration. It should only take 10 minutes to cross your setting over if you have a visual diff program up and running.
(Move settings from both configuration.h and configuration_adv.h)

I upgraded for 1.1.0 RC8 recently to Marlin 1.1.5 using the previous version of that controller without the SD card.
Though the firmware is Identical with the On board SD Card.

I Can help you to make upgrade if you want the help.

Edited 1 time(s). Last edit at 01/02/2018 09:55AM by Roberts_Clif.

I'm open to any tips/tricks/suggestions anyone has to offer - my first hurdle is with compiling though. Initially, I compiled the latest version of 1.0 with all the settings from the configuration.h that were different in the firmware file provided to me by Creatbottech, and it compiled fine and loaded, but... it didn't work. Bonehead me, I neglected to change the '#define MOTHERBOARD' line from '#define MOTHERBOARD BOARD_ULTIMAKER' to '#define MOTHERBOARD BOARD_RAMPS_13_EFB' (The 1.0.0 firmware from them has the board as '#define MOTHERBOARD 33'), so no surprise it didn't work.

After I changed it to '#define BOARD_RAMPS_13_EFB', I started getting compile errors. On 1.1, for example, with two extruders configured and the right board selected, the first compile error I get, which stops me in my tracks, is '#error "HEATER_1_PIN not defined for this board.". If I set it up with only one extruder, I get '#error "TEMP_SENSOR_1 shouldn't be set with only 1 HOTEND."' It's like the firmware/compiler is bipolar or something. 'I don't know what to do with temp sensor 1 when I have two extruders, but temp sensor 1 isn't valid with only one extruder. That's using Arduino IDE 1.8.0. If I try 1.0.6 that works right with the firmware CBot sent me, it blows up all over the place. Given how goofy Arduino IDE is from version to version, maybe there's a *specific* version that'll compile Marlin 1.0/1.1 right? *sigh* lol.

Roxy, thanks for the 'configuration_adv.h' tip I missed that - perhaps that'll fix my compile issues. I'll give that a shot.

You can also use
'#define MOTHERBOARD BOARD_RAMPS_14_EFB'

Tried changing it to '14_EFB' and still getting the compile errors.

Looked further up the error and this is what it's complaining about:

SanityCheck.h:1065: error: #error "TEMP_SENSOR_2 shouldn't be set with only 2 HOTENDS."

     #error "TEMP_SENSOR_2 shouldn't be set with only 2 HOTENDS."

If I extract the zip file and try to compile it without changing anything, it compiles fine. If I change just the number of extruders, it takes a walk and won't compile. I did just notice that while the 1.0 version default board is 'BOARD_ULTIMAKER', the default in 1.1 is 'BOARD_RAMPS_14_EFB'. But dumb question, which is also relevant to their stock firmware, since there are two hot ends, shoudln't it be one of the 'EEB' boards, not 'EFB'?

It's also interesting that 1.1 seems to be compiling to 53,774 bytes, but their original firmware compiles to 158,308.

That would be correct. I have a configuration.h setup file for Dual extruders but have never used it. Take a look see.

Configuration.h

Have been using this program to compare different files you should try. Load two different Configuration.h file and compare side by side with edit right to left or left to right
[winmerge.org]

Edited 4 time(s). Last edit at 01/02/2018 04:28PM by Roberts_Clif.

Just a quick update - I finally got somewhere. After digging around, I realized the reason it was complaining about the temp sensors was because I hadn't configured sensor 1 so it was still set to '0'. Changed that and it got happier. I then moved all the settings I could find over. I tried initially using Winmerge, which is a great program for this kind of task, as long as the two files are reasonably similar. There are so many differences between the to files in terms of comments and new things that Winmerge actually made it more difficult, IMO. Now, if/when I get 100% sorted out on this version of 1.1, and later I want to update to a newer 1.1, it'll probably make it easy to do. It compiled and uploaded, and was recognized fine by Octoprint, but the LCD isn't working. I was able to print a 1cm test cube, but it printed about 1mm too tall, and the first layers were a bit messed up. When I re-printed it, I noticed that the nozzle was a mile off the bed, so it was basically depositing the filament into thin air. Probably an offset I missed somewhere.

Edit: There must be something I'm missing - the Z-home sets the nozzle to the same height off the bed for both firmwares, but their firmware starts the print lower than Z-home, which is why when set up the way the instructions said, so that the stop/sensor activates just as the nozzle barely touches the tape, it was driving the nozzle into the bed. Even with Z-home calibrated to a business card thickness off the bed, it was driving the nozzle lower than Z-home and hitting the bed. There must be a better way to set the nozzle height calibration other than adjusting the probe or end stop every time it needs to be adjusted.

With 1.1.8, it's homing to 0,0,0 according to the LCD, which is placing the nozzle at about .72mm off the build plate. I'm concerned about adjusting the sensor to bring the nozzle closer because I don't want to start chewing the nozzle up on the print bed again - or is it likely that with 1.1, if I set the stop to tip just as the nozzle touches the tape, will it adhere to that better than the original firmware did?

Edit 2: Got the LCD working. Had the wrong 'RepRap Discount' LCD defined.

I've attached the two 'configuration.h' files for reference.

Edited 5 time(s). Last edit at 01/03/2018 05:53PM by Cougar281.

I see your delima with so completely different configuration.h files. I have been working with Marlin 1.1.x files where they are really similar to each other.

Edited 1 time(s). Last edit at 01/03/2018 05:49PM by Roberts_Clif.

Look at your 1.1-Configuration.h found these

#define FIX_MOUNTED_PROBE // You Need this line

#define Z_MAX_POS 2350 // this must be an error

You have two LCD defined is this a error
#define ULTRA_LCD // Character based
#define REPRAP_DISCOUNT_SMART_CONTROLLER

I think you wanted this one

#define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER

Edited 2 time(s). Last edit at 01/03/2018 06:24PM by Roberts_Clif.

Thanks got the catch on the max Z height - that was a typo. Was supposed to be 235. Yes, 'REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER' was the correct one. After wading through again, I discovered the multiple controllers and then that I had the wrong 'RepRap' one selected, so I got that working.

Then I decided to adjust the Z probe to where the nozzle was just touching the tape. After using some gluestick on the bed, it printed one of the better 1cm test cubes - it seemed to lay down the initial layer nicely after getting the skirt printed, but the cube had two anomalies - first, the base was a touch bigger than the rest of the cube, and the corners were raised.

I went back and made the '#define FIX_MOUNTED_PROBE' change you recommended, which changed it's behavior - on initiating Z-home, it then raised back up to 10 or 15mm, rather than sitting at 0, and I noticed that now, there is a Z offset option in the 'motion' menu that wasn't there before, set to 0.8. Only problem with that is if I enter it's option, say to lower it to 0.4 for example, it shows -5.0 in the menu, and I can only go further negative. I fear that will really try to drill through the bed. I then have to reset the controller to reset that.

One issue that I'm seeing, that is persisting with the v1.1.8 firmware, is it seems it starts to extrude before the nozzle is at it's start destination, so by the time it gets there and starts to print, it's got a 5mm or so length of cooled filament that it has to try and work around, and usuallyu results in it getting dragged, not laying filament down right and goofing up a little unless I manage to grab it in time.

When I tried to print another cube after changing that, it started extruding pretty close to a full mm off the bed, which obviously wasn't right.

Any suggestions there?

Edited 1 time(s). Last edit at 01/03/2018 10:27PM by Cougar281.

This is sometimes done in the Slicer. As in my case it primes the extruder before it starts to print. I print a couple skirts to keep it away from the print.
And usually get bothered by it a grab it with a pair it tweezers.

G1 E4.0 ;prime extruder

Had a strange one this evening - I set the bed to heat up to 80C and after a little bit, set the hot end to heat up to 235C, and after a fairly short amount of time, I got a 'Thermal Runaway' message, but the OctoPrint graph didn't show anything remotely out of the ordinary. While an alert/shutdown to a thermal runaway is nice, this was clearly a false positive - is there something I might have to modify in the firmware to prevent this kind of false positive?

If you post your new configuration.h file will have another look see if anything jumps out at me.

Here's the Configuration.h that's loaded in now - To allow me to turn on the bed heater and actually let it heat (Takes longer for the actual bed to get hot than the temp indicated on the display and in OctoPrint shows), I've temporarily disabled the bed thermal protection.

Did not see anything in your configuration.h that looks off.

Let me get some more information. lets say you just turned the 3D Printer on what is the temperatures reading on the display before you start to preheat the printer.
If the temperature is below 15C It will never start to heat. unless you use a hair dryer to heat it to above 15C this was a problem. I had and decided to change a setting.

Since it's printing now and has been for about three hours, the temp of hotend 1 (which is not being used or heated right now) is a bit off, but I believe the typical starting temps are in the 20C range, give or take a degree or two. I'll double check in the morning when everything has cooled off and stabilized.

I did read about 'Bang-bang' vs PID mode, and I believe it's set to 'bang-bang' mode, and apparently, PID mode can help with this. It seems PID mode might be better overall - is enabling that a simple uncomment a line, or is there more to it (like a few lines)?

Edited 1 time(s). Last edit at 01/07/2018 08:10PM by Cougar281.

PID is a calibrated, However I use the " Ultimaker " default on my hotend

// FIND YOUR OWN: "M303 E0 C8 S190" to run auto tune on the hot-end at 190 degrees C for 8 cycles.
#define DEFAULT_Kp 22.2
#define DEFAULT_Ki 1.08
#define DEFAULT_Kd 114


Have tried to use PID here keep giving me errors and gave up. I Us bang Bang for the Bed (no problem when using PLA)
// FIND YOUR OWN: "M303 E-1 C8 S90" to run auto tune on the bed at 90 degrees C for 8 cycles.
#define DEFAULT_bedKp 10.00
#define DEFAULT_bedKi .023
#define DEFAULT_bedKd 305.4

I might have something else that's not right in the firmware. Spent a little time over the last two evenings swapping out the hot end heaters, throat cooling fan and re-wiring the bed for 24V and buttoning it all back up nice and neat. Just got the 24v power supply today and fired it up. It does seem like it heats faster with 24V. Anyway, the problem appeared when I tried to heat the second notzzle. Until now, I'd never done anything with it - the heater wasn't even connected to the controller (Only the temp sensor was). It's not the heater (at least I'm pretty sure) - I measured the resistance at the board and it's where it should be, and it's not the temp sensor as when I disconnected it, the temp for the second nozzle dropped to -14.

Any ideas what it might be, since I've got it set with 2 extruders?

Edit: For grins, I tried extruding the second extruder, although it's not loaded, it should have moved when I did so, but it didn't - so it seems like whatever's goofy is not just with the hot end heater but with everything related to the second extruder.

Edited 1 time(s). Last edit at 01/13/2018 12:42AM by Cougar281.