Whats does the roadmap look like for variables?

[jay_s_uk]

I use workplace coordinates when I need to save a recall a variable.

[DanS79]

@arhi The firmware will run on the DUET 2 ETHERNET/WIFI already, so it doesn't need to be tied to the DUET 3 issues.

[Phaedrux]

@DanS79 said in Whats does the roadmap look like for variables?:

@arhi The firmware will run on the DUET 2 ETHERNET/WIFI already, so it doesn't need to be tied to the DUET 3 issues.

Only if there were infinite development resources.

[arhi]

@DanS79 I see very few ppl working on the firmware so they need to choose their battles... variables are not a small battle and is not really crucial for the RRF ... on the other hand basic features not working on duet3 (like for e.g. pid tuning heater connected to external can connected board) are imho damaging for the RRF (and maybe slowing down money flow too as ppl are maybe not buying duet3 'cause not all functionality is there). I have few duet2eth boards so I personally could not care less about where duet3 is but as someone doing development for 35 years, I understand choices they have to make.... as as @Phaedrux said, there's no infinite dev. resources... that's btw pretty weird, I expected a project like RRF to have much more community contribution.. there's total 13 open and 98 closed pull requests, that's freakishly low for a project that's this good.. check out smoothieware, 1120 closed pull requests or klipper that's rather new kid in the block 765 closed pulled requests... maybe if the code itself is better documented (not only build instructions but the code organization and phylosophy ) more ppl would get interested in chiming in, dunno..

[HebigT]

@oliof How exactly does this work? If I define a virtual axis and then set a position (using G92, I presume) how then do I use that position as a variable?

I've seen people refer to "hidden axes" before.. is that the same as a virtual axis?

[arhi]

@jpomo10 you read it trough model

you can find some ideas:
https://forum.duet3d.com/topic/14280/invitation-to-share-your-conditional-gcode-scripts/12

something like this was suggested by dc42

; assuming you do not have tool 2
M563 P2 S"variables" 
; set variables
G10 P2 X7 Y7 Z7

; increase third variable by 5
G10 P2 Z{tools[2].offsets[2] + 5}

; show variables
echo {tools[2].offsets[0]}
echo {tools[2].offsets[1]}
echo {tools[2].offsets[2]}

now you can create more tools
and you can create virtual axes so each tool will have more variables in it

[dc42]

Assuming we can release firmware 3.2 soon then variables will be in 3.3. If the release of 3.2 gets delayed much longer then they may make it into 3.2.

[deckingman]

@dc42 said in Whats does the roadmap look like for variables?:

Assuming we can release firmware 3.2 soon then variables will be in 3.3. If the release of 3.2 gets delayed much longer then they may make it into 3.2.

Whoopee doo! Yet another new feature gets added ahead of fixing all the outstanding firmware limitations which prevent basic functionality of expansion boards, which still exist after 15 months. How come the implementation of variables is seen as being more important than being able to (say) home a printer (if you happen to want to use one of the many currently unsupported combinations of board/probe/switch/motor)? Or how come variables are seen as being more important than PID tuning a heater? Or how came variables are seen as being more important than stall detection?

Also, why in the documented list of limitations have some items now been moved to "semi permanent" with the comment "We have no plans to remove the following limitations, although removing them would be technically possible."

What is the reasoning for saying to users who might want to use a different type of Z probe than type 8 or 9 on a tool or expansion board, "Tough sh*t - we could support that but we are not going to"?

[dc42]

@deckingman, FYI I spent the last week implementing filament monitors on tool and expansion boards. This was a critical limitation, because there was no workaround for users with tool boards who wanted to use filament monitors. If you wanted to use filament monitors on your machine, I'm sure you would have been screaming for it to be implemented.

[deckingman]

@dc42 said in Whats does the roadmap look like for variables?:

@deckingman, FYI I spent the last week implementing filament monitors on tool and expansion boards. This was a critical limitation, because there was no workaround for users with tool boards who wanted to use filament monitors. If you wanted to use filament monitors on your machine, I'm sure you would have been screaming for it to be implemented.

I'm sure that if I had been waiting 15 months for filament monitors to work then yes, I would be delighted that this will shortly be the case. But how is a filament monitor a critical limitation? How does not having one prevent a printer from working? What's wrong with a pair of eyes?

But what is the point you are trying to make? I would still be pretty miffed that it had taken this long to implement functionality that exists on gen2 products because additional "features" such as variables, object models, support for dot star leds, etc, etc, have all taken priority over fixing these limitations.

I'm sure that the OP of this thread will be delighted to know that he will shortly be getting the additional new functionality he requires to (quote) "customise various aspects of his printer". Those of us who just want the basic functionality that gen 2 had, will have to continue to invent various "work arounds" and keep swapping things back and forth between boards.

I will continue to be pretty pi**ed off as long as the implementation of new features continue to take priority over fixing the basic functionality limitations that exist with gen 3 product firmware .

[pixelpieper]

@deckingman just because you don't use a feature doesn't mean others aren't waiting for it. I have a good use case for variables and plan on heavily using it throughout my configuration. Also, the object model is an important interface to obtain the printer state for use in advanced scripting. Neopixel LEDs are needed for a certain type of 12864 displays supported by the upcoming duet 3 mini as they are used as the LCD backlight and without firmware support the display stays dark and unusable.

Also, you have to consider that a lot of the limitations is driven by the use of a CAN bus instead of direct pins. Yes, this is third generation firmware, but it is also third generation hardware implementing a distributed system and you do not want to flood the bus with traffic - 3d printer firmware is a real time system after all. Analog sensor values constantly streamed consume much more valuable high priority bandwidth then a single "i have triggered".

[deckingman]

@pixelpieper This isn't a matter of which new features should take priority. This is a case of restoring basic functionality that already exists in version 2 firmware to version 3 firmware before adding new features.

You might be waiting for variables and have a good case for needing them - so do I as it happens. But I've also been waiting over 15 months for the basic ability to PID tune my hot end heaters!! And that basic functionality keeps getting pushed back further and further while additional features get implemented. The same applies to basic things like end stops, Z probes, fans and heaters which only partially work depending on which board they are connected to. Whereas with the Duet/Duex combination, no such limitations exist.

Prior to "upgrading" to gen 3, I used to run a Duet ethernet plus Duex5. I changed to Duet 3 in good faith because I wanted to run more motors than the Duet+Duex combination would allow. Had I known then that it would take years for the basic functionality that existed with the gen 2 firmware to be made available on the gen 3 firmware, then I most certainly would not have made that change. The other reason I "upgraded" was for the Duet guys benefit so that they could have my machine on their stand at the TCT show to demonstrate the new hardware. That turned out to be an embarrassment for them and for me because the firmware wasn't ready - it seems it still isn't and I have doubts that it ever will be.

Also, you have to consider that a lot of the limitations is driven by the use of a CAN bus instead of direct pins

Where is that documented? How come the Duet team make no mention of this "fact"? Why would the ability to (say) PID tune a heater be impacted by the CAN bus when most of the time is spent waiting for the temperature to rise/fall/stabilise?

Of course, it's entirely the Duet guys prerogative to decide which aspects of the firmware get priority. They are obviously comfortable with throwing existing customers and former supporters under a bus, although that seems a strange business model to me. But equally, as a former loyal customer and ex long time supporter I will also exercise my prerogative to hold their feet to the fire until they get this mess of a firmware sorted out.

[dc42]

@deckingman said in Whats does the roadmap look like for variables?:

And that basic functionality keeps getting pushed back further and further while additional features get implemented. The same applies to basic things like end stops, Z probes, fans and heaters which only partially work depending on which board they are connected to.

Ian, can you tell me which of these limitations stops you from doing what you want? I realise that manual heater tuning is an annoyance to you, and I think you had to connect the Z probe switch to a different board from the one you had planned originally. Is there anything else?

I believe the heater limitation that you refer to is that a heater may only be controlled by a temperature sensor connected to the same board as the heater. There are good safety reasons for this. So it is a limitation by design.

Similarly, the fan limitation is that temperature sensors used to control a thermostatic fan must be connected to the same board as the fan. The safety argument here is less compelling; but even so, connecting both to the same board would obviously be sensible - and generally the most practical, because the fan will generally be close to whatever it is cooling, and so will the sensor. I've yet to hear a complaint that a user needs something different. Maybe some water-cooled systems might be easier to wire if the limitation were removed; but does the possibility that someone might want that justify prioritising that above e.g. variables in conditional GCode?

Anyway, now that I have remedied the limitation that had no workaround (filament monitors for extruders controlled by tool and expansion boards), the limitations that do have workarounds (e.g. connection of endstop switches) are closer to the top of my work list.

[deckingman]

@dc42 Well I've managed to find/design/make workarounds for most of the firmware issues with this machine. There are numerous issues which make my life difficult but the main thing which prevents me from doing what I want is the appallingly bad step pulse frequency. But I'm not making a big song and dance about it because I believe that you have addressed this in 3.2 which I will try as soon as a stable release becomes available.

With a mixing hot end, it is necessary to run high extruder micro-stepping (ideally 128X with a 3:1 geared extruder) in order to attain the necessary resolution when one or more filaments are providing single digit percentages of the whole. But I can't even run 32X without getting a high hiccup count during retractions.

Also, I could not drive the Z axis at the desired speed. For normal printing moves this is not an issue, but for long homing moves it is. My workaround for this was to buy 3 new lead screws with 2mm lead to replace my original 1mm lead screws. This halved the steps per mm which enabled me to drive the axis at twice the speed but it's an expense that I would rather not have had to incur.

But I won't dwell on that because it might be fixed in 3.2.

Another workaround I had to to do was related to the Z axis switch state not being recognised when homing at anything other than a crawl. I posted it here https://forum.duet3d.com/topic/17404/z-switch-on-expansion-board-latency-issue/22. I came up with a "hardware solution" as a workaround which works well it was more expense (both time and money).

I've mentioned the inconvenience of having to.....
1.Disconnect the heater and thermistor from the expansion board
2.Connect to the main board, change the configuration
3.Re-boot the machine
4.Run the heater tuning
5.Enter the values into config.g
6.Turn off the machine
7.Change the wiring back
8.Change the configuration back and then re-boot the machine
I appreciate that most people won't have to do this often but as you know, I'm trying to develop a new hot end and I've had to do that process multiple times with every design iteration and every time, it makes my blood boil.

For sure, there are (almost) always workarounds but my point is that none of these workarounds are necessary with Duet 2. None of the other current limitations cause me much grief except to say that the wiring is not as neat and tidy as it otherwise could be.

Surely the whole point of using CanBus for expansion boards is that those boards could be placed anywhere on a machine, rather than having all the wiring go back to a single point. The last time I counted, with my main board and 3 expansion boards, I have in excess of 80 IO connectors of one sort or another. Yet it is surprising how few of those 80 odd connectors I can actually make use of due to firmware limitations. They just take up space.

As an aside, when you were seeking users input on gen 3 boards, I suggested that it would be best to have driver boards with just stepper drivers and separate IO boards to which peripherals could be connected. The rationale being that as a general rule, end stop switches for example are seldom anywhere near the motors that they control. So "motor boards" could be placed in reasonable proximity to motors and IO boards reasonably close to the peripherals they control. IMO that would lead to much neater machines with smaller boards and far less wasted connectors. But that could never be accomplished if the firmware limits the combinations of IO devices\boards\motors.

EDIT. Regarding the safety aspect. Presumably this is because a failure in the Can Bus communications might prevent (say) a heater being turned off if it were connected to a different board to the sensor. That being the case, would it not be possible to simply highlight that risk factor in the documentation so that users could decide for themselves if the risk outweighed the benefit, rather than having that limitation imposed upon them?

[A Former User]

@deckingman said in Whats does the roadmap look like for variables?:

I've mentioned the inconvenience of having to.....
1.Disconnect the heater and thermistor from the expansion board
2.Connect to the main board, change the configuration
3.Re-boot the machine
4.Run the heater tuning
5.Enter the values into config.g
6.Turn off the machine
7.Change the wiring back
8.Change the configuration back and then re-boot the machine

Indeed a pain in the ass even having to do it once.

I resorted to building the hot-end assembly up and tuning it with another Duet-3 on my test rig before installing the completed hot-end assembly on the printer it is to be used in....

Im also fighting an issue with Duet-3's ( i will open a thread on that soon)

[DanS79]

@deckingman said in Whats does the roadmap look like for variables?:

@pixelpieper This isn't a matter of which new features should take priority. This is a case of restoring basic functionality that already exists in version 2 firmware to version 3 firmware before adding new features.

I'm a developer by trade i think you need to consider a few things!

• Just because a piece of software functionality worked on one piece of hardware doesn't mean it will work on another with different architecture.
• I'd be willing to bet their are substantially more v2 boards in the wild than v3, so the wants and needs of v2 users will most likely take precedence.
• Some of the new features might make it easier to fix outstanding issues. On several occasions i have done this, mainly because it involved rewriting a sub system from scratch.
• From what I can tell, your use case is very much and edge case, so you should expect issues imo.

[deckingman]

@DanS79 That's an interesting point of view. I'll bear that in mind but I suspect anyone who bought the latest generation of a product such as a 'phone would be somewhat miffed if many of the bundled apps (which worked on the previous version and are still bundled with the new version), didn't work.

It might of course be different if the vendors or software developers made it clear that would be the case, but no such case was made when I upgraded from gen 2 Duet to gen 3. On the contrary, much was made of the higher spec processor leading to the expectation that this would give additional or faster capabilities. Sadly the opposite is true. I foolishly thought that being a long time supporter and one who has spent many hundreds of hours helping out the Duet guys with firmware testing and exhibition support, that they would be honest and truthful with me. My fault entirely for being so naive.

This thread has also highlighted the fact that some users have different ideas about what is important and what is not. I foolishly assumed that all users would consider basic things like being able to print something would be more important than new features that enabled something like fancy LCD backlights. Clearly I was wrong and the majority view of people posting in this thread is that not being able to home the printer (if an unsupported combination of board/switch/motor are selected) or tune a heater are insignificant inconveniences compared to being able to use DotStar LEDs to backlight an LCD screen. Silly of me to think that users would actually want to be able to do something useful with their machines.

Yes for sure, my usage case is somewhat different. But I only have a single hot end heater and thermistor - just like the majority of users. Yet I cannot PID tune that heater. Again - entirely my fault for foolishly wanting to connect it to an expansion board.

I also could not run extruders at anything like the micro-stepping that I could on gen 2, nor could I run the Z axis at the same speed as before. Neither could anyone else, even if they only had a single extruder. Of course, this is all my fault because I foolishly assumed that the step pulse frequency would be as good as the previous generation product.

Normally this sort of information would be in the documentation but isn't. All my fault of course for having balls that are made of flesh and not crystal, otherwise I could have predicted these shortcomings. I'll go and get myself castrated and pay a visit to mystic Meg to prevent myself making the same mistakes in the future.

[DanS79]

@deckingman said in Whats does the roadmap look like for variables?:

I'll bear that in mind but I suspect anyone who bought the latest generation of a product such as a 'phone would be somewhat miffed if many of the bundled apps (which worked on the previous version and are still bundled with the new version), didn't work.

The underlying hardware architecture for phones hasn't changed in a long time though. I think almost every phone on the market is based on ARM. If the next generation was x86 based, people would go mad because all kinds of things would break.

If people don't want to deal with issue, then they shouldn't be an early adopter. Doesn't matter if it's phones, sbcs, tvs, cars etc.

[A Former User]

@DanS79 said in Whats does the roadmap look like for variables?:

@deckingman said in Whats does the roadmap look like for variables?:

@pixelpieper This isn't a matter of which new features should take priority. This is a case of restoring basic functionality that already exists in version 2 firmware to version 3 firmware before adding new features.

I'm a developer by trade i think you need to consider a few things!

• Just because a piece of software functionality worked on one piece of hardware doesn't mean it will work on another with different architecture.
• I'd be willing to bet their are substantially more v2 boards in the wild than v3, so the wants and needs of v2 users will most likely take precedence.
• Some of the new features might make it easier to fix outstanding issues. On several occasions i have done this, mainly because it involved rewriting a sub system from scratch.
• From what I can tell, your use case is very much and edge case, so you should expect issues imo.

Being a user I don't give two fornications about any of the issues encountered by those developing hardware/software.

As a user I expect the "evolution" equipment (that I have paid for) to "fit for purpose" its not as if the end user is forcing the supplier into supply, but the supplier does use the "evolution" features to entice existing (and new) users into making a purchase.

In this case it is a brutal fact that full functionality (at least on par with previous equipment) has turned out to be of secondary importance.

And again I don't give two fornications if what worked on older equipment doesn't now work on the newer equipment, newsflash (meanwhile back in the real world) is that IT SHOULD, or it shouldn't have been released.

[DanS79]

@CaLviNx said in Whats does the roadmap look like for variables?:

As a user I expect the "evolution" equipment (that I have paid for) to "fit for purpose" its not as if the end user is forcing the supplier into supply, but the supplier does use the "evolution" features to entice existing (and new) users into making a purchase.

No one is forcing you to buy it, and it's on you if you fall for a sales pitch, or can't control your consumerism!