generic_cartesian: Allowed arbitrary primary carriages names and introduced 'axis' option

[dmbutyugin]

One of the comments in the discourse thread about allowing mapping of dual carriages to dedicated GCode axes was to move away from requiring single-letter carriage names, and so I thought about making this consistent for all types of carriages of generic_cartesian kinematics, including primary. Besides, this would open up a path to fully support multi-gantry printers like IQEX printers. And I also added a possibility to deprecate "Not providing a parameter" in a configuration, that is, a soft nudge to provide it via Mainsail/Fluidd notifications.

[KevinOConnor]

Thanks. In general it seems find to me. I have a few comments.

It seems a little "picky" to me to require users to specify "axis" if the carriage name is "x", "y", or "z". I'd expect most users would use these basic names for the main carriages. Thus the deprecation warnings seem a little pedantic. YMMV.

If we're updating the example configs to use longer names, I think names something like "my_x_carriage" or "my_second_extruder_carriage" would be easier to understand (instead of, for example, "xc").

In all of the above, though, I'll defer to your judgement. So, let me know when you are ready to commit and I will.

Cheers,
-Kevin

[dmbutyugin]

Thanks Kevin,

It seems a little "picky" to me to require users to specify "axis" if the carriage name is "x", "y", or "z". I'd expect most users would use these basic names for the main carriages. Thus the deprecation warnings seem a little pedantic. YMMV.

Well, if we want people to use longer, more descriptive names for the carriages, then it could make sense to promote the ideal configuration while the adoption of generic_cartesian kinematics is low (so that fewer users would be affected), before we start deprecating hybrid_corex? and dual_carriage outside of generic_cartesian, and it also makes documentation a bit simpler. Another reason for that is the work to let the users map carriages to extra axes. I do think there's no reason to forbid the following sequence of commands

SET_DUAL_CARRIAGE CARRIAGE=u_carriage MODE=PRIMARY
SET_DUAL_CARRIAGE CARRIAGE=x_carriage MODE=DIRECT GCODE_AXIS=U

but the counterpart

SET_DUAL_CARRIAGE CARRIAGE=u MODE=PRIMARY
SET_DUAL_CARRIAGE CARRIAGE=x MODE=DIRECT GCODE_AXIS=U

(the second command) would look a bit out of place.

However, I do get another train of thought that [carriage x] and alike are nice and simple shortcuts. So I could be swayed either way, TBH.

If we're updating the example configs to use longer names, I think names something like "my_x_carriage" or "my_second_extruder_carriage" would be easier to understand (instead of, for example, "xc").

Thanks, I will consider that. My biggest dislike here is the kinematics description part of steppers, like

[stepper my_stepper_x]
carriages: my_x_carriage+my_second_extruder_carriage

like, the names of carriages distract a bit from the actual kinematics part, but it is not too bad.

[KevinOConnor]

I think those are all good points.

My biggest dislike here is the kinematics description part of steppers, like
[stepper my_stepper_x]
carriages: my_x_carriage+my_second_extruder_carriage

True. Maybe there is a middle ground though (somewhere between very verbose and very terse).

Cheers,
-Kevin

[dmbutyugin]

OK, so I updated the documentation and examples to have a bit more descriptive carriage names. As for the axis option, my proposal is the following.

I separated all the deprecation into a separate commit 230f7e5, and I suggest that we go with deprecating the automatic axis inference right now, since it does simplify documentation and code. For now this is just a warning and existing configuration will not be broken. However, if we receive complains and/or alternative suggestions on discord or discourse, we can have a discussion there, and we can ultimately decide to revert just that commit, I would not mind it then.

[KevinOConnor]

Okay, thanks. I'll commit when you are ready.

Cheers,
-Kevin