Multiple spindles of the same type

[nils]

FluidNC v3.4.1/Adafruit Huzzah32 Feather

Hi,

first of all, FluidNC is amazing! Only getting started with a self-designed wall plotter project, but I like it a lot already.

One thing I wonder though is whether it's possible to instantiate multiple spindles of the same type, e.g. like this:

[ ... ]
besc:
  - pwm_hz: 50
    output_pin: gpio.12
    enable_pin: gpio.13:low
    direction_pin: NO_PIN
    disable_with_s0: false
    s0_with_disable: true
    spinup_ms: 0
    spindown_ms: 0
    tool_num: 0
    speed_map: 0=0.000% 255=100.000%
    min_pulse_us: 500
    max_pulse_us: 2500

  - pwm_hz: 50
    output_pin: gpio.33
    enable_pin: gpio.27:low
    direction_pin: NO_PIN
    disable_with_s0: false
    s0_with_disable: true
    spinup_ms: 0
    spindown_ms: 0
    tool_num: 100
    speed_map: 0=0.000% 255=100.000%
    min_pulse_us: 500
    max_pulse_us: 2500

Doing it exactly like that results in

[MSG:INFO: Configuration file:config.yaml]
[MSG:ERR: Configuration parse error: Expected identifier. Line 52 column 4]

Am I doing it wrong or is that not possible?

If it's not possible but considered merge-worthy, I'd be happy to take it as a junior job :slightly_smiling_face: I would try to enhance the logic that it accepts both an object as well as an array. Any thoughts?

[MitchBradley]

Arrays in configurations is not a "junior" project, but rather a huge can of worms, affecting the whole naming scheme in the tree.

[nils]

Thanks @MitchBradley for the warning... I'll see then if it turns out to be a quick fail :+1:

However your response also tells me that there is no work going on in that direction and it's definitively not supported right now.

I'll just give it a try, then we can see how far I can proceed and judge the result, if any.

[MitchBradley]

If you do it as an array underneath the besc node, then the spindle selection logic now has two levels instead of one. If you do it as multiple besc nodes, like

besc:
   blah blah
besc:
   blah blah

Then you need a way to distinguish them when you refer to a path with $besc/pwm_hz

If we introduce something like this, it should not be done just as a wart on spindles, but rather as a general purpose feature, which has profound implications on the overall syntax, and thus compatibility issues, documentation requirements, support implications.

[nils]

If we introduce something like this, it should not be done just as a wart on spindles, but rather as a general purpose feature,

Definitively! Was thinking about putting the instantiation logic into GenericFactory (after the parsing is enhanced, obviously).

[MitchBradley]

Please do not just start hacking away. Consider the implications for the multiple phases of tree management - parsing, conversion to JSON representation for WebUI config page auto-generation, pathname resolution for runtime settings, etc.

[nils]

Did not understand that there was such an interest on your side to do it at all :+1:

I'll try anyways with hacking away. In my spare time, I can waste as much of the available time as I want.

If the result is something to learn from and throw away (edit: and potentially redo from scratch), that's not an issue for me. I like to iterate code as much as iterating ideas. In such an exploration phase, code is just a more explicit writedown of ideas, that accidentially also can be executed.

[MitchBradley]

The basic point is that this, in effect, changes the syntax of pathnames in the tree. Syntax additions are always profound, because they introduce characters that used to be ordinary, but now are magic. That ripples though everything.

If you embark on this and then issue a PR, someone - almost certainly me - will have to either engage with it - which takes time that I don't have right now - or ignore it - which is also problematic from a community relations standpoint.

Bottom line - I would be happier if you were to first contribute in other areas, like working down our existing todo list, instead of pushing into uncharted territory that I already know will have profound architectural implications.

[MitchBradley]

There is something related that has been on our radar for a long time. Instead of declaring motors underneath axes - which gets messy for different kinematics - it would be better to declare motors separately and then refer to them in axes and kinematics. There is a similar problem with uarts, whose declarations should really be separated out of the nodes that use them.

The reason this is related to your problem is that it introduces a naming issue for multiple objects of the same type.