Whats does the roadmap look like for variables?

DanS79

Do we know what release will have variable support?

I've been getting into customizing various aspects of my printer, and in a few scenarios variables are pretty much mandatory.

Are we looking at 3.2, 3.3, something even further out?

oliof

For now people "cheat" by defining virtual axes and setting arbitrary positions on them as makeshift variables.

fcwilt

Hi,

I needed some text variables.

I created some "dummy" fans and used their names as a variable.

I created macros to set the name as needed and I could view the current name in DWC along with all the real fans.

Frederick

DanS79

Someone just mentioned the fan/axes cheat to me in a discord conversation, but it seems like that could cause potential problems if you wanted to share a macro you made with someone else. Basically you could override someone else's config.

arhi

defining virtual axes is a cheat but would be cool to know when the real variables will come, and with real variables, the macro parameters too ... it is cool I can execute M12345 and m12345.g will be called but I really want to execute M12345 X10 Z15 S22 and have these variables in the m12345.g usable

far from "super important" I believe core functionality needs to be solved first (I hear bunch of basic stuff is still not working for duet3 and toolboards, I'm sure that's waaaaaaaaaay more important than variables) but as op asked, would be cool to have idea on the dev-path ..

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)