What's new on Robo's GITHUB

I follow it off and on and today noticed that in their Marlin GITHUB repository, Robo appears to have a branch of Marlin 1.1.6. There isn't any changes from the default Marlin source as far as I can tell but I am sure it is coming. I do hope that every line they change is at the very least designated as changed with some sort of comment. https://github.com/Robo3D/Marlin/tree/RC/Marlin

There has been some work in the last few days on the Updater script. Nothing substantial, more under the hood and a new way of verifying if an section is updated during the update process.

Preliminary work on Cura 3 profiles in their Slicing-Profiles repository https://github.com/Robo3D/Slicing-Profiles/tree/cura-3-dev/Cura 3

If anyone spots anything else new please update this thread.

 

You will find that they do a lot of stuff then revert it all back when they find out it doesn't work like they expected. I think they tend to be better at hardware than software.

 

The other issue with watching GITHUB for changes is that Robo3D has scattered their repositories across multiple accounts.

Accounts that hold parts of RoboOS

https://github.com/AllenMcAfee?tab=repositories
https://github.com/victorevector?tab=repositories
https://github.com/Robo3D​

 

Not an issue, they are not using OctoPi 0.12

 

OG, I have complained about how the whole µSD was assembled, it could be so much cleaner than it is. They could eliminate OctoPi completely, they could install things in the default sub-directories, they could eliminate a few of the default addons (especially the one that spies), they could minimize their dependencies. Will it ever happen, I highly doubt it. I made an attempt at cleaning it all up but since I now nothing of Python programming I couldn't really fix a few things that needed fixing.

 

There is now a beta branch that is Marlin 1.1.6

 

Not really software people.

 

Looks like Robo is readying a new version of the firmware
https://github.com/Robo3D/Marlin/tree/r2-dev

Still think there is a bunch of unnecessary changes in their code. Why they keep changing CONFIGURATION_H_VERSION eludes me. Why they insist on using BAUDRATE 115200, instead of 250000. Still appears to use too high a DEFAULT_ACCELERATION of 1000 and too high a DEFAULT_XYJERK of 10.0. Changed short version to 1.1.8 even though it is 1.1.0 of Marlin.

A good thing is that they are changing the bed size to 197 x 197 mm.

They removed all the extra pins_ files even though all that does is save disk space since none of that code is compiled into the binary if not selected. Only one BOARD type can be selected.

Honestly, the only difference for R2 users appears to be adding 1 mm in both X and Y axes. Much ado about nothing.

 

So yesterday they decided to renumber it again and call Marlin 1.1.0RC8 Robo3D/Marlin 1.1.9 beta and then decided to use my numbers for acceleration and maximum acceleration. At least there is an additional comment on the commit suggesting the values came from the R2 forum. This was committed at between 2 and 3 AM PST, so obviously someone is burning the midnight oil.

Needless to say I won't be upgrading to RoboMarlin 1.1.9 since it is still six releases behind real Marlin (1.1.6).

 

@mark tomlinson & @OutsourcedGuru you guys should like this development. there is a new repository that is supposed to facilitate dual extruder setups here https://github.com/Robo3D/Dual_Extruder_Setup

 

If it will work on the C2
They were a bit flabbergasted (if one can be a *bit* flabbergasted) that I even went dual extrusion on the C2.

 

Check out this file https://github.com/Robo3D/Dual_Extr...truder_Setup/Octo_Setup/default_profiles.yaml

Apparently this is all done on the OctoPrint side and may appear to editable on the C2. Might need more sleuthing.

Don't know why this is, but their R2 Dual config appears to lose 46 mm of build space.

Of course this is a first post just within hours of posting.

 

There is a bit of space lost on the C2 as well just due to the layout of 2 extruders (and the spacing). I forget how much exactly.
It is worth noting that the actual physical constraints on what *could* be used vary based on which extruder is positioned where with respect to the build platform. I assume the slicer just takes a worst case approach

I'll dig through that config though and hack it up for the C2 as well.
Thanks.