I made changes to switch to a 1-based numbering so a detected 8 = version 8 where before, a detected 7 = version 6. In the code shown above, We skip version 7 and went to version 8 so the numbers match up. That was why I suggested the next board should be 8.
@eastbaysource board version 1.5b and pin identifies as 6
TLE9201 id’s as 6 as well, but it can be version seven by cutting the pin shorting pin 22 to ground. I think those with the tle board can make the change manually or modify the firmware. @jonatpridesleap is taking 8 with a TB6643 board version 1.8. @Maxwebber is taking 9 with the BTS7960 distributed board setup to be version 1.9
version 1.10 open
version 1.11 open
version 1.12 open
Any others working on boards want a number? We simply get this section of code PR’d into the master and the numbers will be set. Can you include it @jonatpridesleap with your PR if it isn’t in yet? I have this section of code shown in the 51.29 version of holey I’ve been working on.
actually we have 6 pins, so with 6 bits, we should be able to get up to 128 versions. a couple numbers are overlapped because the first few boards used a different high/low scheme it appears, but we should be good for a long long time… I bet there will be a major brain overhaul before the board numbers run out.
Bar just merged my PR for the MaslowCNC master, so it’s been updated with my v1.8 board but NOT your additional version number changes (v9, v10). I’m going to work on the WebControl PR next so I can include your changes in that one though. Should I go back and re-submit those additional changes to the MaslowCNC master just to keep every body on the same page? Or, since webcontrol is a fork of MaslowCNC, do changes to WebControl get passed on up the chain to IT’s master (MaslowCNC master)?
only if someone merges it will it show up. If you have to make modifications to your branch from testing, you can add the changes then. if not I can make the changes and submit a PR just for that. Either is fine.
Given the newness of this whole process for me, it might be best for you to handle it for now.
I am kinda stuck and confused anyway. I went to github.com/WebControlCNC and see the repositories. I see one for Web Control and another for Firmware. The Firmware repsitory shows that its a fork of MasalowCNC:master. It also shows that it is 6 commits behind MaslowCNC:master. Is this the repository that I need to fork?
Ok, now I think this whole thing is getting clearer.
I see that the WebControl:Firmware fork does not have any of the additions that EBS implemented in order to get his board to work with Holey. Because that is what you are doing in your fork. His changes were however implemented in the MaslowCNC:master which is what I THINK I have been beta testing with my changes. I say think only because I have been using firmware originaly sent to me by @bar. I just assumed it was from the MasloCNC:master but I could be wrong.
It appears that I am in a situation where I need to wait for you to get your changes merged into the WebControl:Firmware repository first, then I can merge mine. Alternatively, I could fork yours, add my changes and then issue a pull request to you?,
Out of curiosity, other than the MaslowCNC:master and WebControl:Firmware fork, how many other branches should I be prepared to fork and pull to get my board recognized?
you only fork the repository once. With that fork, you get all of the branches from that repository. you can select branch and the files will change to show / be that version. Make the changes to the one repo and then submit a pr to the master for webcontrol with the same changes and see if it will take it. This is where my inexperience begins to show because I think there is a way to submit the same changes to both repos or a way to merge the changes from the one repo to the other, but I don’t know how to quickly and easily get that done. There are others who know how on here that are probably laughing and the blind leading the blind. Hopefully our discussion will get corrected and others will find some value in the information that is correct.
they both reside in the webcontrolcnc/firmware repo as separate branches. When you clone the repo, you get them all and you have to select the correct one or make a new branch based off of one of them to start your changes and then you merge your changes back in with a pull request.
to answer your specific question, you would branch holey and add your changes and branch master and add your changes. however, since bar’s version is going in the maslowcnc/firmware repo, you could submit your changes as a PR to the webcontrolcnc/firmware master branch as well. I don’t know how many differences there are between them, but if only 4 commits, then the webcontrolcnc/firmware branch is pretty close and branching off of the maslowcnc/firmware repo that is ahead will bring the webcontrol repo up to date with your PR. I’d try it. We likely want them in sync anyway at least for triangular calibration.
Ah, ok. NOW what you have been saying makes sense. Thanks again for yet another detailed explanation. Let me soak this in for a bit.
So here is my take on the path as i understand it:
MaslowCNC was the original and ONLY firmware master.
WebControl forked it into it’s Triangular master.
The WebControl Triangular master was then branched into the Holey firmware.
Am I close?
Just so that I am clear on this. Your thought is that since the MaslowCNC master (Triangular) is only 4 commits ahead of the WebControl Firmware master (Triangular), I could submit a PR to the WebControl Firmware master to merge in the changes from the MaslowCNC master. This would bring the WC master in line with the MaslowCNC master. I could then PR the Holey branch to merge the changes from the WC master.
I think you got it… at least as far as I understand it. The only think I would add is that the webcontrol triangular version was at 1.28 and the maslow version was 1.26, so webcontrol had some improvements and there had not been movement with outstanding PR’s in the maslow version for a couple years, so the firmware “master” had defaulted to the webcontrol repo to work with webcontrol. If the maslow repo has merged the updates from the webcontrol repo, then it should be up to date. To me it does not matter which is the “master” as long as they are active and accepting and testing new additions and features in a reasonable timeframe.
One thing I am confused about is the work YOU have been doing with EBS to get his board to work with Holey. It sounded like you were trying to get his firmware changes merged into the WebControl. I may be mistaken, again I’m not sure about all of this anyway.
My confusion is this:
If getting the EBS changes into the WC master and then the Holey branch was as easy as submitting a PR to WC, referencing the MaslowCNC master. Why didn’t you just do that? Again, I am new to all of this so my question is beyond naieve. I suspect that I am misunderstanding what you previously said, the situation is way more complex than I believe it is, or some combination of the two. Don’t mean to sound like I am questioning what you have done. It’s more of a learning exercise for me.
Here’s the story as I think about it… not trying to make excuses for the slow code turn time, just lay out the events/process. The work I did was take the EBS triangular code that was not in github and merge it with the holey firmware I was working on that has a few more changes to it. It was a bit more than just a merge and it was only for holey firmware not for the triangular calibration that he recently completed. It included doing a diff of each file individually and sorting out what needed to merge and what was superfluous. Once I completed that, it had to be tested and verified before it could be pulled in. It took some time to get feedback that it didn’t work the first couple iterations.
After some time I was able to work out a trade to borrow a board to speed up the cycle and my available time to spend on it decreased dramatically. My system has the high speed z axis motor, so I had to deal with that and it took more time. In that time EBS merged the code with maslowcnc, so triangular calibration of an easbay motor shield on mega should work with webcontrol as it did before, but now it will also work with the firmware flashed from the maslowcnc repository. EBS users don’t have to get the firmware soley from EBS now and it should work with most of the shields. The process of the Holey firmware for EBS motor shield admittedly has taken more time than it should both in testing and in the time elapsed given my availability, but we press on. If it doesn’t pass my testing, I can’t PR it because it will fail the code review and not get pulled in. If it does get pulled in and doesn’t work, then there will be a number of unhappy EBS users that want to use holey as we have seen those that attempted to use it already and it doesn’t work.
There was a pwm frequency issue that is controlled by the firmware that was specific to the TBS chip that EBS worked out in that time and I have taken his changes for that and it should be good to go now, but I still have to test it completely, submit a pr, get it reviewed and THEN it should be incorporated in the next webcontrol build and be available as a webcontrol action menu button press upgrade.
Thank you again for a very detailed explanation. It clarifies a lot. I’m going to DM you a followup because if others watching this thread havent started to laugh at my elementary understanding of this process they surely will.
