Whats does the roadmap look like for variables?

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

[deckingman]

............... We are aware of the current firmware limitations and are working to address them.

I've heard that too many times over the last 15 months to be able to bring myself to believe it. Or rather, "working to address them" can have many meanings - up until now, it seems to be the case that fixing these outstanding limitations has been very low priority.

It's an unfortunately situation and we understand the frustration.

Ignoring the typo ("unfortunately situation" ?) but with respect, I don't think you have any idea how frustrating (and costly) it has been to come up with all the workarounds that I've had to do.

We apologize for the disappointment. All we can do is ask that you bare with us while work proceeds.

Apology accepted (although as stated above, 15 months and counting is a long time "bare with you" - I've known many marriages that have completely broken down in such a time scale).

You don't have to be happy about it, but at least accept that we're working on it.

On the basis that it's the squeaky wheel that gets the oil, I will continue to squeak out, at every opportunity, about these issues until they are resolved.

[Phaedrux]

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

I don't think you have any idea how frustrating (and costly) it has been to come up with all the workarounds that I've had to do.

I read all your posts, so I'm at least as aware as you've communicated.

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

I will continue to squeak out, at every opportunity, about these issues until they are resolved.

I'd expect no less. I'm not asking you to let us off the hook, I'm just telling you we hear your complaints, accept them as valid, and want you to know we are trying to resolve them.

And thanks for ignoring my typo.

[deckingman]

@Phaedrux Well at least you haven't called me an old fart this time around

[Phaedrux]

I haven't typed it anyway.

[deckingman]

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

I haven't typed it anyway.

........I'll wager you were thinking far worse than "old fart"

[dc42]

I admit that it's taking longer than I expected to resolve the limitations. Some of them relate to wiring schemes that are impossible to do with Duet 2, so they don't fall into the category of things you can do with Duet 2 that you can't do with Duet 3.

Here is a partial list of limitations that we have resolved since the launch of Duet 3 about a year ago:

Expansion boards:

• M143 additional heater temperature monitors are not supported
• Motor standstill current fraction is fixed at 70% and cannot be configured
• Emergency Stop only turns off heaters and motors on the main board, not on expansion boards
• Endstop switches attached to expansion boards are only partly implemented
• Z probes connected to expansion boards are not yet supported.
• If an axis has multiple motors, and there is a separate endstop switch for each motor, all the switches and motors must be connected to the same board.
• M950 cannot be used to configure a GPIO or servo port on an expansion board
• Tacho readings from fans on expansion boards are not available
• M581 triggers cannot be attached to ports on an expansion board
• Software reset data is not available for expansion boards (fixed in 3.2b1)
• Filament monitors for extruders driven by expansion boards and tool boards are not yet supported (fixed in 3.2b3)
• Achievable step rates are lower than expected (fixed in 3.2b1)

Main board:

• Connector IO_0 is reserved for PanelDue and cannot be used for other purposes
• DHT sensors are not supported

So I hope you can see that we are working through the limitations.

The current list of limitations is at https://duet3d.dozuki.com/Wiki/Duet_3_firmware_configuration_limitations. Next on my list to fix are the limitations relating to endstop switches connected to the main board, and heater tuning.

[deckingman]

@dc42 From my perspective, there was a flurry of activity around the time of the launch, leading up to the TCT show, and for a few weeks after. But then all progress more or less dried up for the next 12 months which is why my patience ran out.

Just out of curiosity, why is it taking soooo long to sort out PID tuning of heaters connected to expansion boards? It's a fairly basic thing to want to do. It's not my field of expertise but I wouldn't have thought that PID tuning is particularly processor intensive and most of the time is simply monitoring a single temperature channel or waiting for the temperature to settle/stabilise. Also the code exists for the main board so why is it so difficult to transfer to expansion boards?

[deckingman]

BTW, has anybody else ever reported the seemingly random hot end fan blips when the machine is otherwise idle, that I mentioned repeatedly way back then. It's a minor annoyance but if it's just my machine, I would gladly know what I can can do to fix it.

[A Former User]

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

BTW, has anybody else ever reported the seemingly random hot end fan blips when the machine is otherwise idle, that I mentioned repeatedly way back then. It's a minor annoyance but if it's just my machine, I would gladly know what I can can do to fix it.

I have noticed that occurring in tandem with when my PSU internal fan kicks in at idle, so it might be related.

[deckingman]

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

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

BTW, has anybody else ever reported the seemingly random hot end fan blips when the machine is otherwise idle, that I mentioned repeatedly way back then. It's a minor annoyance but if it's just my machine, I would gladly know what I can can do to fix it.

I have noticed that occurring in tandem with when my PSU internal fan kicks in at idle, so it might be related.

Interesting..........although my PSUs are fanless so........

[dc42]

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

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

BTW, has anybody else ever reported the seemingly random hot end fan blips when the machine is otherwise idle, that I mentioned repeatedly way back then. It's a minor annoyance but if it's just my machine, I would gladly know what I can can do to fix it.

I have noticed that occurring in tandem with when my PSU internal fan kicks in at idle, so it might be related.

That's interesting!

I have 2 tools using tool boards, and I have never heard it happening.

@deckingman , I could put some extra diagnostics in the firmware to try to track the cause down, but you would need to be using the beta firmware.

[deckingman]

@dc42 No I don't fancy the idea of running a beta firmware at this stage - it's one more potential variable that I don't want to throw into the equation. At least with 3.1.1, I know what the problems are.

As to the issue itself, it's a minor irritation as I said at the outset. And unless you have the printer in very quiet environment with no other fans running (such as board cooling fans), and the hot end fan is reasonable noisy, you might not notice it happen unless you happen to be staring at it. It's a short blip - maybe one second or less.

TBH, it may have even "gone away" on my machine running 3.1.1. - now that I've moved my printer out of my study into it's own "booth" in my garage, I can't say that I've noticed it (but I probably wouldn't due to the new location). Having said all that, I've just changed to liquid cooling so if it does happen again, I'd likely see/hear to coolant pump "blip" (although being a pump, it might not react to short sharp transient in any case).

I'd guess that the only time it might be a problem is if someone happened to be poking around with the hot end fan when the "blip" happened. But even then, it's unlikely to even draw blood or do any physical harm, given the power of the average hot end fan. But it might make you jump......

[Phaedrux]

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

No I don't fancy the idea of running a beta firmware at this stage

While I understand the reluctance, wouldn't it be helpful to test the firmware before release to ensure the bugs are resolved rather than wait for the final release and discover there are the same or different bugs meaning having to wait again for another firmware release? Just sayin.

[dc42]

The experience so far is that beta 1 is stable, but beta 2 has a few glitches. We hope to release beta 3 next week.

[Phaedrux]

@dc42 I assume there is a release candidate coming as well once it's deemed stable and feature complete?

[deckingman]

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

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

No I don't fancy the idea of running a beta firmware at this stage

While I understand the reluctance, wouldn't it be helpful to test the firmware before release to ensure the bugs are resolved rather than wait for the final release and discover there are the same or different bugs meaning having to wait again for another firmware release? Just sayin.

Up until a few months ago I used to do exactly that. But I've had my fingers burnt a few times in the past.

Classic example - earlier design versions of my hot end suffered a lot of stringing and I thought it was the complexity of the mixing chamber making retractions less effective. It turns out that the cause was the poor step pulse frequency. I had been using 64x micro-stepping (because that's what I used on Duet2) but RRF 3 did not report hiccups on expansion boards so I had no way of knowing about the firmware step pulse frequency issue. It was only when 3.1.1 came along that hiccups were reported and could see immediately that I was getting very high hiccup count during retractions. So I wasted a lot of time and effort re-designing my mixing chamber to reduce stringing when all I needed to do was reduce the micro-stepping from 64X to 16X to get around the firmware problem and restore proper retractions.

So if something strange or unexpected does happen with this hot end version, and I change the firmware as well, I can't be sure whether any problems would be related to the design or configuration of the hot end, rather than caused by a potential bug/change in behaviour of the firmware.

In a nutshell, I don't have a working hot end as a baseline against which I could evaluate any firmware changes. So any feedback I could give might be flawed due to some sort of mechanical issue with my experimental hot end.

The old adage "change only one thing at a time" is the only sensible way to develop something IMO.

[arhi]

This post is deleted!