Whats does the roadmap look like for variables?

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!

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?:

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..

Horse skat

The myopic outlook to the point blindness is unreal.

Pre-production units could be classed as being an early adopter, production units should be functional.

deckingman

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

....................If people don't want to deal with issue, then they shouldn't be an early adopter.

I've learned that lesson the hard way. At the time, the reason for being an early adopter was as much to help out the Duet guys (by having my machine on their stand at the TCT show to demonstrate their products) as it was for my own benefit. My "reward" is to be thrown under the bus by having the outstanding firmware issues repeatedly deferred for more than 15 months, in favour of other users who have requested additional "features".

But as you profess to being (quote) "a developer by trade" your statement is a classic excuse that I see is becoming more and more prevalent among your profession. Personally I find it insulting to blame purchasers of products for what is essentially inexcusably bad conduct on the part of the person who has not done his/her job properly.

If you had a trade person in to undertake some work which turned out to be sub-standard, would you find it an acceptable excuse if that trade person turned around and told you that he/she hadn't been in business or hadn't been doing the job for long, therefore it's your fault for being an early adopter?

A Former User

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

@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!

That point is valid I will admit, in the defence of many loyal customers it was "felt" that Duet was among one of the more "trustworthy" companies.

But they have proved that, that is not the case, and what makes it even worse is that they don't seem to care that those very same loyal customers have worked out that they have been openly screwed over.

They have majorly lost the support and trust of those loyal customers, who will never again support them to the same level ever.

deckingman

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

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!

The excuses for being bad at developing products just get more and more outrageous! Blame the customer for buying it - are you serious?

Gerald Ratner once said at an after dinner speech, that his jewellery business products were crap. Within days he was bankrupt and the business folded. People don't like to be told that it's their fault that they bought crap.

DanS79

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

But as you profess to being (quote) "a developer by trade" your statement is a classic excuse that I see is becoming more and more prevalent among your profession. Personally I find it insulting to blame purchasers of products for what is essentially inexcusably bad conduct on the part of the person who has not done his/her job properly.

You can be insulted all you want but your comments imo show a lack of understanding with regards to the subject at hand. No developer, team of developers, company, or even massive tech industry giant can ensure no user ever has issues, specially when you are talking about non trivial applications.

The number of potential issues grows almost exponentially with the complexity of the software. Thus, project/product managers usually focus on bugs/features/issues that are of a concern to the majority of the user/revenue base.

For example what would you fix first? A bug related to one users who is running a 15 year networking card, or a bug (that's not your fault) that affects several thousand people because Microsoft decided to make a change and then push it out in an automatic update without telling down stream companies/developers/manufactures?

Now scale that up to hundreds or thousands of bugs and feature requests.

If you had a trade person in to undertake some work which turned out to be sub-standard, would you find it an acceptable excuse if that trade person turned around and told you that he/she hadn't been in business or hadn't been doing the job for long, therefore it's your fault for being an early adopter?

I personally wouldn't find myself in that situation as i can do most trade stuff myself. Plumbing, electrical, carpentry, care repair etc. Even if i didn't have the skills I do, i'd still check a contractor's credentials.

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?:

But as you profess to being (quote) "a developer by trade" your statement is a classic excuse that I see is becoming more and more prevalent among your profession. Personally I find it insulting to blame purchasers of products for what is essentially inexcusably bad conduct on the part of the person who has not done his/her job properly.

You can be insulted all you want but your comments imo show a lack of understanding with regards to the subject at hand. No developer, team of developers, company, or even massive tech industry giant can ensure no user ever has issues, specially when you are talking about non trivial applications.

The number of potential issues grows almost exponentially with the complexity of the software. Thus, project/product managers usually focus on bugs/features/issues that are of a concern to the majority of the user/revenue base.

For example what would you fix first? A bug related to one users who is running a 15 year networking card, or a bug (that's not your fault) that affects several thousand people because Microsoft decided to make a change and then push it out in an automatic update without telling down stream companies/developers/manufactures?

Now scale that up to hundreds or thousands of bugs and feature requests.

If you had a trade person in to undertake some work which turned out to be sub-standard, would you find it an acceptable excuse if that trade person turned around and told you that he/she hadn't been in business or hadn't been doing the job for long, therefore it's your fault for being an early adopter?

I personally wouldn't find myself in that situation as i can do most trade stuff myself. Plumbing, electrical, carpentry, care repair etc. Even if i didn't have the skills I do, i'd still check a contractor's credentials.

I must thank you for this post, it has reminded me why it is folly to try hold a cognitive discussion with a fool who thinks he is clever, as it is akin to playing chess with a pigeon, because no matter how good you are at chess, said pigeon is still going to shit on the board and strut around like it won anyway.

And on that note any further input from myself is pointless.

deckingman

I agree and think that it's fair to say that everything that can be said, has been said any further posts are pointless. Mods may as well lock this thread if they seem fit.

DanS79

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

I must thank you for this post, it has reminded me why it is folly to try hold a cognitive discussion with a fool who thinks he is clever, as it is akin to playing chess with a pigeon, because no matter how good you are at chess, said pigeon is still going to shit on the board and strut around like it won anyway.

And on that note any further input from myself is pointless.

I wouldn't call you a pigeon, but if that's how you see yourself then so be it!

Phaedrux

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

Mods may as well lock this thread if they seem fit.

Civil discourse is apparently dead, but I'm loathe to lock anything. People are free to discuss their grievances as vehemently as they like, just please remain civil and refrain from personal attacks.

If the children are finished arguing, perhaps we can return this topic to its original purpose.

We are aware of the current firmware limitations and are working to address them. It's an unfortunately situation and we understand the frustration. We apologize for the disappointment. All we can do is ask that you bare with us while work proceeds. You don't have to be happy about it, but at least accept that we're working on it.