would be interesting to know, how good the firmware handles different (quasi onboard) drivers? Especially for input shaping.
The external toolboards have the advantage of their own CPU and FW to handle their drivers.
that's a premier for me too, but we'll try.
With a toolchanger you could poll the diameter of the current tool in tpost#.g by using M118 S2 P"toolnumber"
Now the arduino reads this message and sends the aquired data, but here it get's shady for me. It is easy to receive messages and display them on DWC, but reading data into a global variable is unknown to me. I tried it over I2Cport, but fell into the same dark hole...
Maybe @dc42 has a solution now?
You can totally, do that, your stepping just changes the position target.
In a test run the Due was quick enough to answer every step pulse. There is no 'piling up' of steps I could apply a PID algorythm to.
The hardware QDE is capable of reading the encoder pulses at 42MHz. Not sure about the other interrupts, though...
If you like, we can discuss it here
I understand that a minor revision is planned for the Duet2 series. If it hasn't been asked for yet, I would like to request some sort of protection on the fan outputs to prevent idiots like me from blowing the output mosfet's.
We looked into providing fan output short-circuit protection some time ago. Unfortunately, thermal fuses are too slow to provide protection. Electronic fuses for 12V circuits are readily available, but not for 24V circuits.
A related question - is the Duet3 more idiot proof? If so that would be a big bonus for me.
Yes it's more idiot-proof, for example against shorting the external +3.3V or +5V rails to a higher voltage. The fan mosfets have a higher surge current rating; however they will still fail if you short a 24V fan output. They may survive shorting a 12V fan output, but I haven't tested it.
Will inductive/capacitive sensors that need these high voltages not just die please (just kidding!)
We thought we had nailed with with the IO ports right now that work for a BL touch and then you go asking for VFUSED on the same port..
More seriously I can see the appeal for the specific case of a high voltage indictive probe - the down side is it makes it much easier for people to (mis)wire up something that feeds the 24V into the 3.3V, 5V etc
I purchased 2 each of 8 different inductive sensors - 2 models were rated for 5V - the other 6 models for 10V-30V.
The performance of the 5V units was decidedly inferior to the 10V-30V units.
Thus my decision to stick with the far more common 10V-30V units and my suggestion regards the connector.
The other problem with inductive sensors is there seems to be no standard output configuration.
I didn't bring this up because I don't know of an simple solution - but I'm working on one.
To begin with you have NPN or PNP outputs. Then the outputs can be NO or NC.
Now if these were done sensibly the NPN units would be open collector and pull the signal low, while the PNP units would be open emitter and pull the signal high.
Then everyone could pick a NPN unit and activate the pull-up on the Duet.
No such luck.
I had to come up with a scheme using two resistors for each model to get the signal to match the logic levels of the Duet inputs. The required values and arrangement of the resistors tended to be unique to each model sensor.
I found it very frustrating.
Here is how I ended up doing it so I could easily swap probes during testing.
fcw Inductive Probe Connection.jpg
I had to make up several different resistor assemblies and use the correct one for each probe.
The RPi has far more RAM than a Duet so it can use very large buffers. Also it has a disk cache, so not all reads/writes involve a transfer to the SD card (writes will eventually go to the SD card, but depending on the test they may not complete until after the test has finished).
This is why uploading GCode files over Ethernet to a Pi+DSF+Duet is faster than uploading them directly to the Duet.
On the Duet 3 series we have some scope for improving the upload speed, due to the extra RAM compared to Duet 2. But I have more important things to work on before I address this.
external qi receivers are quite inexpensive and slim if thats your cup of tea
I use them but are not ideal for all situation, they are ugly patch you glue on back of your phone - I do use them on all my printoid phones as none of them support external charging but I kinda hope I'll soon upgrade them to once that support it natively 😄
now only to make android/ios app that talks to rrf
DueUI might fit the bill if a browser isn't an issue?
tried it, but I still believe more could be achieved with the app .. I actually checked dueui for the reason of figuring easy way to make app myself but time constraint is impossible these days so..
Thanks so much - cannot wait to get my hands on it, meanwhile only using the duet2-ethernet to get somehow started with RRF3.x but as soon as it is out the company I work for, for sure like the "new" maestro/duet3-mini then because of price, because on the longrun there are quite a few anycubic here, with dying original mainboards (I think the board is called "gorilla" or something like this) over time...
Yeah - half a year ago I couldn´t have imagined it, but recently my boss started playing around with Poly-Carbonat material and the printer sits in a chamber with heatplate reaching 120°C and extruder around 300°C... the chamber heats on long prints up (without any chamber-heater just because of heatplate and extruder) to around 60°C. You can build a printer with all motors outside, but as long as you have a direct-extruder this motor gets quite hot then -> One possiblity to extend its lifetime and avoid the the filament gets too soft too early in the extruder is an additional fan on the motor, that is driven via an additional thermistor attached to it that measures the quasi-chamber-temperature a few millimeters over the extruder motor...
On the other side when you print PLA at considerably lower temperatures for heatplate and extruder you do not need at all the fan for the directdrive-motor to run.
I hope this also explains why I do not want to wire it together with the heatbreak-fan. Also they are quite diffrent in size and power and first test have shown that they need completely different pwm-values if I want to use pwm. The only way to have them work realiable if driven via one single fan-port/-pin, is to make it 0/1...
a cheap chinese thermistor + fan is around 3-5 euro which is the same as a beer in the next "biergarten"(beer-garden), so it is mainly something to play around.
just wanted to "vote 1 up", that in my opinion especially for something like the entry-board like the maestro, an entry level priced minimal-interface like those little (non touch-) screens with an encoder wheel would be a nice companion!
The Maestro already supports 12864-style displays with encoder using the ST7920 controller chip.