No more pringles cans?
2 Likes
Naa, I used soup cans.
2 Likes
I would like to help, I suspect I am not a good candidate due to lack of time and still working on this learning curve thing with all things CnC
Rambo compiles and moves.
1 Like
@vicious1 I would be willing to test with my 24x24 MPCNC using a Rambo1.4. If you had a basic test case and some gcode files to test with that would be really handy as well! I know marlin appears to be planning some laser improvements I would love to test some of that out if they manage to make some progress!
For now just run it, with a known good file, and let me know if you have any issues. I don’t have a concise test yet, I think it will be easy to build as we find errors. Typical issues are the LCD knob go the wrong way.
I have the latest laser stuff already merged, but have not tried it, I would love for you to!
I just did a large update to the rambo series firmware, 427, back to classic jerk (thinkyhead said junction deviation is pointless on non-delta machine) and a major catch up.
Anyone want to test it?
I can test it out tomorrow, but I am working on the new boards right now.
Yes!! I would love to test it, but won’t be until monday when I get back home
1 Like
All new firmware builds getting refined.
Any help running these on actual builds would be great.
This link will bring up a list, the largest number is the most recent RC. There are a ton more predefined boards and builds. Let us know if it makes sense or if you find any issues.
2 Likes
I’m wondering if it might be helpful to make a table of combinations. Here’s an example just to illustrate the idea:
MPCNC MPCNC LR2 LR2 V13DP ZenXY
Series Dual Series Dual
--------------------------------------------------------------
Rambo | here | here | here | here |modify|modify|
Mini Rambo | here | no | mpcnc | no | here | here |
Ramps | modify| modify| mpcnc | modify| here | here |
SKR 1.3 + 2209 | here | here | mpcnc | here | n/a | n/a |
SKR 1.3 + 8825 | here | here | mpcnc | here | n/a | n/a |
SKR Pro + 2209 | here | here | mpcnc | here | n/a | n/a |
SKR Pro + 8825 | modify| modify| modify| modify| n/a | n/a |
SKR 1.4 + 2209 |use 1.3|use 1.3|use 1.3|use 1.3| n/a | n/a |
SKR 1.4 + 8825 |use 1.3|use 1.3|use 1.3|use 1.3| n/a | n/a |
Archim 1 | here | here | mpcnc | n/a | n/a | n/a |
Archim 2 | here | here | mpcnc | n/a | n/a | n/a |
I’ve just included shorthand to keep the table manageable
- “here” means click here for the build specific to your configuration
- “mpcnc” in the LR2 series column means use the MPCNC series firmware
- “modify” means there would be instructions to take a different firmware and adjust it to your board, for example Ramps can be built from Rambo by changing just the motherboard and the steps per mm. Maybe SKR Pro + 8825 is just a matter of modifying SKR 1.3 + 8825 and rebuilding.
- “no” indicates that dual is not possible on mini-rambo because there are too few drivers
- “n/a” is for a configuration that is not yet supported and so far hasn’t been important
- if there are insignificant differences like SKR 1.4 vs. SKR 1.4 Turbo, or SKR Pro 1.1 and SKR Pro 1.2, it can explicitly state the compatibility and direct people to install the other one
I think this could achieve good coverage and perhaps even decrease the number of builds necessary. In my case I use Ramps (Ramps-like) on a non-dual setup which right now is not one of the pre-built packages and that is perfectly fine.
Thoughts?
All of those links would need to change with each release. I would rather just make a key or rename them since that is all automated.
I’m not very familiar with Marlin builder or anything more streamlined than (download firmware, change variables in arduino IDE, push to board), but is there a way of having an application that queries a server for a list of builds that can by picked from a list? Kinda like what Jamie has, but built into an app with a drop down box. Then whenever new builds are released, they become available in the list.
Good point. I hadn’t thought that far ahead, or whether this would belong in docs.v1engineering.com or whether it would be on the github MarlinBuilder landing page (README.md) and take the place of what used to be that CHOOSE_VERSION thing.
A lookup table is somewhat error prone but I’m not seeing a way to fix the links directly. The simplest I can think of is one commit to the README.md after the release. A manual step might have a silver lining in that it would also allow README.md to not point to the latest version if there are ‘stable’ and ‘latest/beta’ releases.
You are asking questions above my pay grade.
Yeah… I didn’t want to fill out many ramps builds but it shouldn’t be bad to add a few more soon since this is building well. We are trying to get more confidence and not more features right now.
The table would be great, but I do worry about any third dimensions. Specifically, 5160, 2209, 8825, etc. I have 8825 and 2209 in the existing configs, but that’s only because anttix did that. I don’t know if you agree, but the most common configs I see are skr pro/2209 and skr 1.3/5160 (because of tt). We currently have 22 configs, and I can see a few changes cause us to have to explode that number.
I think it would also be possible to do something like the little radio button/jquery thing we did for the calculator. But we don’t have every combination set up. Unlike the table, which lets you see what adjacent options are available.
Another example is an amazon or rei product page with color and size options. You might select a machine, and then invalid control boards might go gray. Then you pick a control board and the dual/series might disappear. Then you pick dual and a driver. This would be nice if we added a bunch of options like 24V or different screens or something.
I think there is a way to link to the latest, instead of a specific version. It also seems reasonable to change one place, and have it propagate to all the links. Last choice would be to do a search/replace. But that table is going to be a huge mess. Maybe I can play with it and see what comes out. There may also be a better way to organize the long list.
1 Like
This is all a side convo though (and there is an issue about it in github). The real thing we need now is to know the faults with the current version (we need to push a 505, because we found one small issue so far).
It we knew 504/505 was solid, then we can do more fun stuff in 506. It will be easier and if we hit trouble, people will have a backup.
2 Likes
I guess at the core what I am suggesting is that some combinations could resolve to instructions instead of resolving to a specific zip file or binary artifact. Whether it is a big table vs. drop downs with javascript is not essential. Javascript drop downs would be cleaner in handling dependent options and more than two dimensions, so that’s probably better.
The purpose is that it could keep the number of builds to a reasonable number while providing coverage to a very wide set of combinations, and people might learn something through the process (e.g. dual endstops on Rambo Mini).
There is a chance that it could incur a ton of documentation work, especially if it includes UART vs. SPI or using TMC drivers in Step/Dir configuration. I don’t have a good answer to that but in the spirit of guiding users to learn something through the process, it would at least provide a place to insert a piece of learning (or a link to a piece of learning) to help navigate the options. The quantity of documentation would expand linearly along each dimension but not exponentially to all combinations.
1 Like
Can’t the drive issue be limited to these are what are tested others will have to be at a later date or submit your fix to the cause or am I misunderstanding the issue some
It sounds like your going to support everything out there at some point it has to settle to this works and what is supported or the combinations are endless
The combinations are endless and we want to be reasonable with what we configure for and be clear about the “readiness level”. But when thinking about a way to organize them so people can find the right files, I don’t want to be backed into a corner if we don’t have to.
1 Like