Firmware and Github questions.

I keep trying to update the firmware and just this morning realized I am not doing something correctly. Well, a lot of things really but lets just focus on firmware today.

How do I use versioning in GitHub?

So I usually go in and ad my version number to config.h (303-403) yeas the project has been around and any two digit in creasing number I want after. I also like to go in and add it to Version.h so when the LCD boots you see “bugfix 2.0.x 303” so newcomers can easily tell us where there are. 3 issues with that. It is kind of a pain to keep track of, version.h says I should create a new file not edit that one, and with versioning people could just to my GitHub and use a previous version if there where issues/perhaps track new settings easier as well (diff).

 

Ohhh… Tags and branches, oh my!

Note that knowing the mechanism is not the same as being familiar with it…

You’ll probably want some form of tags. You tag the code, and release the tag, and there may even be a way to automate populating the version based on the tag. Depends on what hooks are set up for the repository.

I think… You’ll want more experienced confirmation.

It’s tricky, because you have 12 different branches of code. If you could somehow have one version of the code, and the users had to download it, and then copy a specific example configuration/configuration_adv for their setup, then this would be easier for you.

In Git, a branch is a moving target. It can be moved and describes only where that code is right now. So MPCNC_Rambo_T8_16T_LCD_DualEndstop is pointing to the current version.

Tags, however, are pointing to a specific version, forever. That’s typically how someone would point to v1.1.9, for example. 1.1.9 isn’t ever going to change.

You could make a tag like MPCNC_Rambo_T8_16T_LCD_DualEndstop_v403. But pretty quickly, you’ll have so many tags that they will all be lost in the cruft.

A way to simplify this is to change to fork into two different branches. Something like the ones you have now will need to stay on a stable version of the code. They won’t follow the latest changes, and anyone who just wants to cut some stuff will have to settle for this stable version of the code. Then, you also have a single branch for testing, development, and the latest Marlin features. You can call this something like ‘beta’, ‘unstable’, ‘wild_west’, ‘devel’. If someone wants to use that bleeding edge ‘devel’ branch, they will have to do a little work to configure it from the vanilla to work with a MPCNC Rambo T8 16T LCD Dual Endstop. If you decide your devel branch has become stable enough to make the base, you can fix your 12 stable branches to be based off of that, and move your devel forward.

This might become a lot simpler in a short while if they “release” 2.0 and you can base your branches off of that. Tracking the bugfix branch has meant we are getting some features earlier than otherwise, but we’re also getting new bugs faster than otherwise :).

As far as editing the configuration.h and version.h, that seems fine to me. Making a _Version.h like they are suggesting would mean you’d have to set the flag, which I don’t see a good way to do that unless everyone switches to platform.io.

1 Like

Cool, at least that means I was not missing something super obvious.

Thank you both.

To keep things moving and not get too crazy with changes. I have another account (waiting on the name I want…), maybe I keep this current one as is doing updates and changing the number manually. When we have tested them for a while in a forum beta release fork/branch (still unclear of the nomenclature) them to the new account, these will be linked from the firmware page and considered stable. Also keep a revision behind that archived on the site as well. Three versions, old, what we think is stable, and the moving target chasing the bugfix.

That would let me update more often and not worry about testing every single board each time. We could community source the testing as well as the documentation. Probably need some sort of testing standard though. This would also let people branch/fork for other boards easier as well from our “stable” bugfix version.

1 Like

I just got my machine up and running, sort of…

My LCD control is not working. If I depress the controller it brings up the menu but I cannot navigate with it. I have ZERO coding experience and I’m trying to follow the bouncing ball. I successfully added the U8glib.h to the library in my Arduino but not sure how to change the code in Marlin recommended on the LCD shopping page.

Also, I can draw beautiful crowns. Only they are 2 inches above my paper. From reading all of the volumes of information I’m currently digesting, I believe the LCD working properly will fix that problem.

I’d also like to use a Z touch plate and I’m guessing I need to update the programming for dual end stops. I don’t plan on using the end stops I purchased until I understand what I’m doing, if ever. If I program for the dual end stops strictly for the Z touch plate, will I screw up my entire system or is that the right move?

Thanks for all of the support you guys put in here.

Jeff, if you don’t mind, can you make a new thread in mpcnc troubleshooting? We can answer these questions, but this topic isn’t related. There is a list of questions there in a sticky too, like where did you get your stuff. That will help us.

Github also has the option of using “releases”. When you create a release, it can automatically create a tag for you as well. You are also able to attach multiple binaries to a single release so the release could contain zip files for each branch.

Promising, I think, I need to look into it deeper. I am so bambi legs around github. I still get turned around very easily with all the lingo.

https://help.github.com/en/articles/creating-releases

I think it worked. I did a release of the new MP3DP firmware and all I do is give it a version, and select the branch I want. Done. It adds another layer of selections but I think this will easily let you go backwards if there are any issues. Super cool, Thanks Joel.

To get to it just click on releases.

1 Like

Now try the RAMPS version so I can see how it lets me choose between different branch releases. I only see the mRambo version now.

I have a Ramps version up, New current version has not been tested, previous version is tagged as a release.

On the github you use abbreviations to label the varying platforms and bundled features, its probably something obvious but what does the LR stand for?

LowRider CNC, the bigger build.

so obvious, i thought it was something to do lasers :stuck_out_tongue:

Scope Error: LR is not defined in namespace:MPCNC, try global scope? Y/N

1 Like