@aprz As it stands we are not planning on supporting higher than 48V on the 1XD. If your motors need >48V then you need to use a separate supply for the 1XD. If you have a brake on the motor then it may need 24V which would work for the 1XD as well.

The 3HC is unlikely to have a change to >32V soon, but we are looking at maximum voltages for the boards that use the TMC2160 drivers to review the changes needed to go to 48V safely. Our closed loop board that uses a TMC2160 and is in beta uses a TMC 2160 and has a maximum input of 48V

@gixxerfast blinking slowly and continuously in time with the one on the main board is good, it means that it has established time sync with the main board. There is a separate green LED that indicates that the 1XD board is receiving CAN commands from the main board.

@tlas the closed loop board is about to go into the beta test phase.

It also locks you into a single type/generation of SBC.

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

@erfreuterstudent
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?

@luke-slaboratory there is some discussion of it here https://forum.duet3d.com/topic/14441/higher-input-voltages-for-steppers

@ansonyang you'll also find that the maestro won't get new features such as input shaping going forwards so is it worth the effort?
you could just use one of the boards supported by the STM32 RRF Project https://teamgloomy.github.io/supported_boards.html#stm32-boards-with-native-support
I wouldn't bother going with an LPC board

@lee7670 said in TMC4671 expansion board:

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
[\OT]

@alankilian thank you for the suggestion

@jens55 said in Protection for fan output shorts:

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.

@T3P3Tony said in Z probe connector:

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.

Frederick

Meanwell and similar PSUs have a voltage adjustment pot, which usually provides more than 10% adjustment each way. So a 36V PSU could be turned down to 32V.

Hello! Can you please post what is m1 mmos and what pins used ? or post close photo module of both sides, need to fix fan whine on my ender 3, thanks alot!

@bearer said in Toolboard V1.1 Update Request:

could having the resistor factory installed (possibly a smaller size as well) and giving the option to close a solder bridge to enable termination be a alternative approach?

Thanks for the suggestion. We will implement it in the next revision of the tool board.

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.

@bearer said in PanelDue future hardware direction:

(or wireless charging if phone support it)

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

That makes sense. Thanks for the feedback.