Easier to use Software
-
I believe that one good strategy is to separate between a stable version, even if it's a year old, and a bleeding edge one that covers the big leap from a stable 2.x to a stable 3.x.
It will provide latest and greatest to users that want and can take risks, a pool of testers for the developers, and stability for the users that need it. It will also reduces the pressure on the developers to get it right and fast, and will bring peace and harmony to the Duet community.
My 2c.
-
@zapta said in Easier to use Software:
I believe that one good strategy is to separate between a stable version, even if it's a year old, and a bleeding edge one that covers the big leap from a stable 2.x to a stable 3.x.
It will provide latest and greatest to users that want and can take risks, a pool of testers for the developers, and stability for the users that need it. It will also reduces the pressure on the developers to get it right and fast, and will bring peace and harmony to the Duet community.
My 2c.
This will work for some people, but as a developer I can tell you it almost never works with those that complain the loudest. The ones that complain the loudest are usually the ones that want to be on the bleeding edge.
-
@DanS79 said in Easier to use Software:
@deckingman said in Easier to use Software:
The last 18 months have destroyed any confidence I had in the firmware. I just can't trust it any more............
They why are you still using it?
I'm not - other than the pile of crap I just produced because I needed a container in a hurry, my printer sits idle - as it has done for many weeks.
Longer term, I'm still weighing up my options and looking at alternatives.
-
@DanS79 said in Easier to use Software:
The ones that complain the loudest are usually the ones that want to be on the bleeding edge.
It's hard to complain about a version that is called 'nightly build'.
-
@DanS79 said in Easier to use Software:
............. The ones that complain the loudest are usually the ones that want to be on the bleeding edge.
Yes this accusation keeps getting levelled at me - basically it's all my fault for having a complex machine.
But let's explore that a little more (though I understand that you'd prefer a physical altercation - usually a sign that the arguiment has been lost IMO).
Firstly the machine is fundamentally the same as it was 3 years ago. I haven't been asking for anything new or special - simply the functionality that it had when I used gen 2. It's almost there now, but arguably that's because I have "screamed and shouted" as @dc42 put it. I suspect that had I kept quiet, it would have taken much longer than the 19 months it has taken so far.
Secondly, the complexity is mostly mechanical. Sure it's CoreXYUV with a mixing hot end but that's not desperately complex or wildly exotic. We can forget about the load balancing gantry - the only reason it's still on the machine is that I can't be bothered to remove it.
The Z axis is a simple as it gets - just a single motor driving 3 screws via a continuous belt. The complexity is making it such that it is mechanically flat, level and stays that way. It doesn't need, nor do I use any firmware levelling. Nor do I use and firmware flatness compensation. Nor does it need multiple motors.
The Z "probe" is the nozzle itself on a kinematic mount. Again, the complexity is making that mechanical mount such that the hot end is constrained from any XY movement but allowed to move in Z. The physical stop is also the switch - two metal parts that come together and make a circuit. It doesn't get any more basic than that. The firmware just has to react to an IO pin being pulled high or low. No probe to deploy, no IR or inductive sensor - nothing more than the simplest of switches.
All other end stops are simple micro switches.
The hot end is heavy and rigid. As such it has low resonant frequency so ringing just doesn't happen. So the machine does not need DAA.
The extruders are dual drive BMGs which do not slip. So the machine does not need non-linear extrusion.
All temperature sensors are simple NTC thermistors . So no need for thermocouples or PT100s.
I don't use any filament monitors.
Which brings me to the other accusation, that it's all my fault for not now testing beta firmwares. But as illustrated above, I don't use half the things that other users do, so their input is likely to be more relevant than mine.
-
@deckingman said in Easier to use Software:
@DanS79 said in Easier to use Software:
............. The ones that complain the loudest are usually the ones that want to be on the bleeding edge.
Yes this accusation keeps getting levelled at me - basically it's all my fault for having a complex machine.
If I was referencing to you specifically, I would just call you out by name.
-
@deckingman said in Easier to use Software:
The last 18 months have destroyed any confidence I had in the firmware. I just can't trust it any more............
I have three printers of different designs. Two are using Duet 2 WiFi/Duex5 combos, one is using a Duet 3 Mini 5 WiFi.
I have a Duet 3 MB6HC/3HC combo on the bench for testing but it's going to be a long while before I will be able to try them in an actual printer.
I'm using firmware 3.2.2 on all of the boards.
All three of my machines turn out good prints.
You are using the MB6HC correct? So does that suggest your problems are related to that family of boards?
Thanks.
Frederick
Printers: A FT-5 with the 713 upgrade bits, a custom MarkForged style, a small Utilmaker style, a small CoreXY from kit and a E3D MS/TC setup. Various hotends. Using Duets (2 and 3) running 3.4.6
-
@fcwilt said in Easier to use Software:
@deckingman said in Easier to use Software:
The last 18 months have destroyed any confidence I had in the firmware. I just can't trust it any more............
I have three printers of different designs. Two are using Duet 2 WiFi/Duex5 combos, one is using a Duet 3 Mini 5 WiFi.
I have a Duet 3 MB6HC/3HC combo on the bench for testing but it's going to be a long while before I will be able to try them in an actual printer.
I'm using firmware 3.2.2 on all of the boards.
All three of my machines turn out good prints.
You are using the MB6HC correct? So does that suggest your problems are related to that family of boards?
Thanks.
Frederick
Since the advent of RRF3 and the Duet-3 ecosystem things have IMHOP gone so far south they are being asked for ID McMurdo Station.
Whereas a Duet-2 on RRF2 "just works"
-
@JayJay said in Easier to use Software:
Since the advent of RRF3 and the Duet-3 ecosystem things have IMHOP gone so far south they are being asked for ID McMurdo Station.
I was thinking that since 3.2.2 works fine on the Duet 2 family and the Mini 5 - none of which are using the CAN bus could the problems be related to things unique to the MB6HC/3HC family which rely on the CAN bus or the parts of the firmware the handle the CAN bus.
Frederick
Printers: A FT-5 with the 713 upgrade bits, a custom MarkForged style, a small Utilmaker style, a small CoreXY from kit and a E3D MS/TC setup. Various hotends. Using Duets (2 and 3) running 3.4.6
-
@fcwilt said in Easier to use Software:
...................You are using the MB6HC correct? So does that suggest your problems are related to that family of boards?
Thanks.
Frederick
Let's just say that in 2017 using Duet 2, at the TCT show, I was producing multi-colour vases (different colour on every layer). Two of those vases were requested by, and given to, employees of E3D on an adjacent stand. (E3D did not have the abilty to reproduce them). A third vase was requested by, and given to, a guy who owned museum of printing somewhere in Switzerland. As far as I know, it's still there on display.
In 2019, I converted to Duet3 hardware (MB6HC plus three MB3HC expansion boards) and I've had nothing but problems since. I've never been able to get replicate those vases. I once came close but the quality was far below show stand or museum display status.
My gut feel is that it's all related to the way expansion boards communicate with the main board. But that's just a gut feel.
I've made a conscious decision to ditch gen 3 hardware. I'm just considering whether to resort back to the Ethernet plus Duex5, or ditch all Duet products completely. Or maybe even ditch everything and settle for a cheap desktop all in one.
Anyone fancy making an offer on a part working CoreXYUVAB with 6 extruders?
On the other hand, there is enough extrusion, motors, belts etc to build a farm of small, single input machines - I might just do that..........
-
@fcwilt said in Easier to use Software:
@JayJay said in Easier to use Software:
Since the advent of RRF3 and the Duet-3 ecosystem things have IMHOP gone so far south they are being asked for ID McMurdo Station.
I was thinking that since 3.2.2 works fine on the Duet 2 family and the Mini 5 - none of which are using the CAN bus could the problems be related to things unique to the MB6HC/3HC family which rely on the CAN bus or the parts of the firmware the handle the CAN bus.
Frederick
I have (and continue to have) issues if I install RRF3 on my Duet-2 board (but not with RRF2) and have niggly issues on my Duet-3 mini 5+ with RRF3, there is no point in opening new threads on those issues because the fan boys will roll out the stock "post your config.g" etc when its not a config issue. and i just stopped using my 6HC board as its a complete waste of time.
-
@JayJay said in Easier to use Software:
I have (and continue to have) issues if I install RRF3 on my Duet-2 board (but not with RRF2) and have niggly issues on my Duet-3 mini 5+ with RRF3, there is no point in opening new threads on those issues because the fan boys will roll out the stock "post your config.g" etc when its not a config issue. and i just stopped using my 6HC board as its a complete waste of time.
That's curious.
I have hundreds of print hours on my Duet 2 based printers and my Mini 5 based printer, both running 3.2.2.
No issues at all.
If you are interested to share your problems perhaps I might have some insight.
Frederick
-
@deckingman said in Easier to use Software:
My gut feel is that it's all related to the way expansion boards communicate with the main board. But that's just a gut feel.
Well that would be reasonable as the boards I have are running 3.2.2, without issue but none of them use the CAN bus.
It may well be that the CAN bus implementation has timing issues that introduce tiny motion errors leading to reduced print quality.
I wish I had the time to setup a printer using my MB6HC/3HC and see if print quality issues arise.
My two printers using the Duet 2 WiFi/Duex5 combo are working fine and I have no plans to replace those boards.
Perhaps reverting to the Duet 2 is your best option.
Good luck and thanks.
Frederick
-
@fcwilt said in Easier to use Software:
It may well be that the CAN bus implementation has timing issues that introduce tiny motion errors leading to reduced print quality.
That's an interesting proposition.
Using signal busses has the potential of significantly reducing the writing in 3D printers.
-
@zapta said in Easier to use Software:
That's an interesting proposition.
Using signal busses has the potential of significantly reducing the writing in 3D printers.
I don't think the concept is flawed - just, perhaps, the current firmware which handles the CAN bus.
While my speculation is just that, speculation, it would help to explain why the current firmware (3.2.2) works fine on non-CAN based systems but seems to have problems, as reported by @deckingman, with regards to print quality on CAN based systems.
Frederick
-
@fcwilt, it may be tricky to control steppers that need to coordinated but sit on different bus nodes. Would be interesting to hear from dc42@ what the challenges are and if the introduction of a bus degrades degrades significantly the time shift and jitter between the steppers.
The good news is that the movement control is done in open loop and can be planned ahead such that each node just need to perform the plan assigned to it with perfect timing relative to the system's time ticks.
Wireless earplugs have a similar challenge, they need to provide perfect phase matching through two different wireless nodes.
-
The CAN bus was made for stuff like this. There is only a delay in the transmission, and unlike many other serial physical layers that delay is fixed and known. So it is fairly trivial to synchronise a clock over all the CAN-connected boards, down to microsecond level. Once we have a synchronised clock, we have synchronised motion.
I cannot look in the head of the developers, but I am fairly certain that clock synchronisation was the first thing implemented and thoroughly tested since it is so vital.
-
@deckingman said in Easier to use Software:
Here are some of pics of a little case I just printed using a simple single input hot end and with pressure advance disabled. It's bloody awful - like the first print ever produced on a crap machine by a rank amateur.
You've declined my suggestion of starting a new thread about this, so I don't know whether you are serious about wanting us to help resolve this. But if you are, then this is what I suggest:
- You haven't told us what the perimeter print speed was, or the filament, or the hot end temperature; but the bad corners look to me like the filament taking shortcuts due to printing over-temperature or with poor print cooling, and possibly too fast. Maybe worth printing a temperature tower?
- If you install firmware 3.3beta1 then the improved diagnostics in that release will tell us precisely whether the synchronisation of moves over the CAN bus has contributed to the poor print quality.
- Leave pressure advance and DAA disabled until we have yout machine printing reasonably without them. Then we can look at the effect of enabling them.
-
@JayJay said in Easier to use Software:
I have (and continue to have) issues if I install RRF3 on my Duet-2 board (but not with RRF2) and have niggly issues on my Duet-3 mini 5+ with RRF3, ... and i just stopped using my 6HC board as its a complete waste of time.
I can’t see any obvious threads from you reporting problems. If there are, please link them, or please start a thread and we’ll try and get any issues sorted out. This may involve posting your config files for each firmware version, though, so we have at least a baseline to work from.
Ian
