Marlin v1.1.9 release date?

[rmcbc]

I know that this is not an issue but only a question, sorry to place it here. I don't know other place it.
When are v1.1.9 being released? Do you have a date for it?

[th33xitus]

It's like everything else in software development.
It will be released when it's done. shrugs

[Sineos]

Let me quote @thinkyhead from 7 days ago:

I hope that will be very soon, but the recent refactor of the planner/stepper/endstops code has introduced some new issues that we need to debug first. I hope that we will be able to put 1.1.x behind us and move forward by the end of this month!

[rmcbc]

Thank you for your information, I try to use bugfix-1.1.x but It's not stable enough for my needs, that why I ask for the v1.1.9.
I'm a developer too (since 1982) and know it's time comsuming and I want to thank you all for the great job and give part of your free time to do this after a day at work.

[th33xitus]

Try the bugfix-2.0.x instead, thats the one where almost daily at least one commit is made.

[teemuatlut]

If you have problems with either one of the bugfix branches, please post so they can be fixed before the release. You may not be the only one experiencing the issues.

[rmcbc]

I'm going to use bugfix-2.0.x, but I'm finishing converting my Anet A8 to AM8 frame, and the extruder works better with 1.1.8, after stablizing all mechanical issues I'm going to use bugfix-2.0.x.

[thinkyhead]

I try to use bugfix-1.1.x but It's not stable enough for my needs, that why I ask for the v1.1.9.

Since the bugfix-1.1.x branch is the basis for 1.1.9, it's clear why 1.1.9 is being delayed.

[wjax]

I use bugfix from a month or so and it works great for me. Except for my issue with bed leveling :)

The only thing that seems extrange is some glitches in the temperature readings.

[rmcbc]

I'm using bugfix-2.0.x and seems to work ok. I've a MKS GEN L V1.0 with A4988 drivers and even with DRV8825 seems ok.
So thanks again for your work.

[forkoz]

Yea, I moved to 2.0 and no real issues other than junction dev being too jerky so I switched back to regular jerk. When there is a bug its usually an obvious show stopper and you roll back to the previous until its fixed.

[marcio-ao]

So, curious on the status of this... not because I want to use 1.1.9 in particular, but because there is a backlog of PRs waiting on 2.0.x.

[thinkyhead]

I think it's pretty close to ready. There are some obscure issues but I think those will be worked out pretty quickly as 2.0.x becomes the new spearhead of development and 1.1.9 is officially tagged. I could do a release of 1.1.9 tonight, but the weekend may be better.

[Roxy-3D]

So, curious on the status of this... not because I want to use 1.1.9 in particular, but because there is a backlog of PRs waiting on 2.0.x.

This is how I see it: (I know other people will see it differently)

When 1.1.9 is tagged... We leave it behind except for bug fixes. And if a feature is real simple to do and people want it in 1.1.9... Somebody will move it there. But we already have a couple of candidates for another branch parallel to 2.0.0. We can't have 3 branches that we keep in lock step at the same time.

(I'm thinking we might want to try keeping the Marlin_RTOS thread at par with 2.0.0 for 4 or 5 months. If everything goes good... Maybe we freeze 2.0.0 and jump ship. Or if it doesn't go good... We kill it and find another experimental branch to run in parallel. )

[marcio-ao]

@Roxy-3D: What's Marlin RTOS?

[marcio-ao]

@thinkyhead: That's great! Doesn't need to be this weekend, but good to know its coming soon. We are needing to push out Marlin 2.0.x to our customers in October, so it would really help if those various PRs I have open where merged sometime in August. The UltraLCD menu reorg in particular would be very useful as it is the most difficult one for me to maintain independently.

[Roxy-3D]

What's Marlin RTOS?

https://github.com/MarlinFirmware/Marlin/tree/Marlin_RTOS

It is an experimental branch (and idea) with FreeRTOS under the Marlin firmware.

[marcio-ao]

It is an experimental branch (and idea) with FreeRTOS under the Marlin firmware.

Fascinating! Seems like this would be a good way to make use of the extra CPU power in 32-bit boards.

[Roxy-3D]

Yes. And to help simplify and clean up the code. Instead of having one large loop that has to watch out and handle everything... Tasks can be defined and they can sleep or wake up to do things as it makes sense for them to do it.

The problem is, the AVR's have so little memory. I have it working with the AVR's. But I'm not really sure it is viable on those platforms.

[marcio-ao]

Congrats on the Marlin 1.1.9 release! Whoohoo!

[teemuatlut]

Now we go on towards 1.1.10 because 1.1.9 broke a few things.

[p3p]

@teemuatlut My understanding was 1.1.9 would be last 1.1.x but it doesn't exclude 1.1.9.x bugfix additions, just don't have to worry about feature parity with 2.0.x anymore.

[thinkyhead]

If users discover that something is broken for them in 1.1.9, we'll patch the issue in 2.0.x and they will need to migrate to that version. We might also patch bugs in bugfix-1.1.x while it still exists, but we'll see whether it needs to get any more version tags. Beyond a possible courtesy patch at some later date, we should consider 1.1 retired and focus on 2.0 going forward.

[teemuatlut]

11411 #11387 #11389

These apply to 1.1.x as well and it affects other configurable drivers too, besides just TMC2130/2208.

I hope I was able to shed some light on the cause on Slack.

[thinkyhead]

@teemuatlut — I've applied another patch that should help. Hopefully it helps enough!

[teemuatlut]

Well it largely works as it should now. I actually don't think the inclusion order change was necessary after all since the macros are expanded only when called and drivers.h doesn't do that anymore.

But I still think it would be better to just disable/comment the drivers that are not used. It's much clearer for the user and less hassle for the devs. We can rather do a sanity check for extra drivers enabled that are not used.
But how it is now, try enabling TMC2130 on X2 without enabling a feature that uses it and you'll go down a rabbit hole where you need to update quite a few macro calls everywhere in Marlin.

[thinkyhead]

I still think it would be better to just disable/comment the drivers that are not used.

I'm trying to avoid adding another point of failure and keep it simple. Requiring the option to be disabled for nonexistent axes adds an extra burden on the user (and config maintainers) and implies that these settings indicate to Marlin which axes exist. Since we can check for the existence of axes we might as well do that, let users set these options or not, and make it just a little more foolproof.

[teemuatlut]

I'd argue that the leaving defined but unused axis promotes confusion among users and the current selection of macros confusion among developers.
Having users uncomment the axis that are to be used would be a very clear indication to tell Marlin what the hardware looks like. As of now, if you enable TMC2130 for example on X2 without enabling a feature that makes use of it, it will actually result in a compile error. This is because it's only the collective AXIS_IS_TMC and HAS_DRIVER macros that use the conditions that check for options like _DUAL_STEPPER_DRIVERS.

For developers we don't have a guide line on whether or not AXIS_DRIVER_TYPE or AXIS_DRIVER_TYPE_X should be used. If we were to use the latter, it needs to applied globally on more than 200 places. Otherwise we have the aforementioned compile issues.

I'm not proposing anything new here. The same method has been used for a long for all the smart drivers; if you have a driver installed, let Marlin know about it and it will work. If you don't have a driver installed, leave the definition disabled.
I'd call that simpler than making it seem like you have eleven A4988 drivers on a board that supports 4 or 5.

The validity of the configuration can be done in sanity check, not behind the scenes.

[thinkyhead]

I'd argue that the leaving defined but unused axis promotes confusion among users…

Hmm. I think it's a wash. You either have the confusion that "this enables my stepper driver" or you have the confusion of "I need to set all these to something." I'm not sure which is preferable. But I do like having code that automatically works around user error.

[thinkyhead]

As of now, if you enable TMC2130 for example on X2 without enabling a feature that makes use of it, it will actually result in a compile error.

Then that should be fixed. As this is a fresh new set of options there are of course kinks to work out. When we create new features sometimes we miss side-effects. So, let's get these conditionals formalized, make sure they're used consistently, and eliminate the compile errors. I'm sure a PR can be fashioned quickly. What is the minimum config change required to produce the compile error?

[teemuatlut]

You either have the confusion that "this enables my stepper driver" or you have the confusion of "I need to set all these to something."

Or "Why do I need to set E4 to something when my board doesn't even support so many."
Or "I've enabled TMC2130 on E1. Why does it not show in M122."

I still maintain that configuration validity should be done in sanity check. Doing the same or ignoring an invalid configuration seems like a workaround to me. I think we should rather guide the users to valid config files.

What is the minimum config change required to produce the compile error?

Enable TMC2130 on X and X2. Will need to define X2_CS_PIN as well.

[thinkyhead]

Or "Why do I need to set E4 to something when my board doesn't even support so many."

Of course, a quick test of whether this is so will show it ain't.

[teemuatlut]

By default all 11 drivers are set as A4988.
This is not how it should be.

[thinkyhead]

Indeed. Maybe they should all be disabled by default, which will set them all to A4988 anyway. Then users can enable and alter only the ones that use something else.

[teemuatlut]

Well that's one way to go about it, but I don't think that's how it works. If you don't enable any driver types, the machine will still work but with timings that are mostly suitable for DRV8825. Except for MINIMUM_STEPPER_DIR_DELAY 0, which technically is not suitable for _any_ driver type. None of the timings follow the A4988 parameters.
I believe the default drivers should be the ones that are the most common; A4988.

Also I've stated this before, but we need to either use AXIS_DRIVER_TYPE_E0(A) or
AXIS_DRIVER_TYPE(E0, A). And we need to use it _everywhere_.
I would highly favor the latter and not merely ignore invalid configurations.

[thinkyhead]

…we need to either use…

Try this change on for size:

#define _AXIS_DRIVER_TYPE(A,T) ( defined(A##_DRIVER_TYPE) && (A##_DRIVER_TYPE == T) )

#define AXIS_DRIVER_TYPE_X(T) _AXIS_DRIVER_TYPE(X,T)
#define AXIS_DRIVER_TYPE_Y(T) _AXIS_DRIVER_TYPE(Y,T)
#define AXIS_DRIVER_TYPE_Z(T) _AXIS_DRIVER_TYPE(Z,T)
#define AXIS_DRIVER_TYPE_X2(T) (ENABLED(X_DUAL_STEPPER_DRIVERS) || ENABLED(DUAL_X_CARRIAGE)) && _AXIS_DRIVER_TYPE(X2,T)
#define AXIS_DRIVER_TYPE_Y2(T) (ENABLED(Y_DUAL_STEPPER_DRIVERS) && _AXIS_DRIVER_TYPE(Y2,T))
#define AXIS_DRIVER_TYPE_Z2(T) (ENABLED(Z_DUAL_STEPPER_DRIVERS) && _AXIS_DRIVER_TYPE(Z2,T))
#define AXIS_DRIVER_TYPE_E0(T) (E_STEPPERS > 0 && _AXIS_DRIVER_TYPE(E0,T))
#define AXIS_DRIVER_TYPE_E1(T) (E_STEPPERS > 1 && _AXIS_DRIVER_TYPE(E1,T))
#define AXIS_DRIVER_TYPE_E2(T) (E_STEPPERS > 2 && _AXIS_DRIVER_TYPE(E2,T))
#define AXIS_DRIVER_TYPE_E3(T) (E_STEPPERS > 3 && _AXIS_DRIVER_TYPE(E3,T))
#define AXIS_DRIVER_TYPE_E4(T) (E_STEPPERS > 4 && _AXIS_DRIVER_TYPE(E4,T))

#define AXIS_DRIVER_TYPE(A,T) AXIS_DRIVER_TYPE_##A(T)

#define HAS_DRIVER(T)  (AXIS_DRIVER_TYPE_X(T)  || AXIS_DRIVER_TYPE_X2(T) || \
                        AXIS_DRIVER_TYPE_Y(T)  || AXIS_DRIVER_TYPE_Y2(T) || \
                        AXIS_DRIVER_TYPE_Z(T)  || AXIS_DRIVER_TYPE_Z2(T) || \
                        AXIS_DRIVER_TYPE_E0(T) || AXIS_DRIVER_TYPE_E1(T) || \
                        AXIS_DRIVER_TYPE_E2(T) || AXIS_DRIVER_TYPE_E3(T) || \
                        AXIS_DRIVER_TYPE_E4(T) )

[teemuatlut]

Sure, should work alright.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.