@jay_s_uk Thanks a lot. Doing it as soon as the current job finishes. I will report back.

I did not do the wiring.

But it seems the person who did it thought it was a good idea to put a couple of strands of wire to each one of the minus (-) inputs of the driver.

I guess they expected that to be GND, but they did not do the same in all the driver's wires.

So I am guessing the regular symmetric drive of the breakout board can work after we stop shooting in the foot.

For a tool-change device, I need to move Y-axis towards the tool-change location till an end-stop is triggered. That end-stop is not Y-axis end-stop but an additional one.

How can I achieve that? Let us assume that the additional end-stop belongs to U-axis.

A solution, ideally, should not change Y axis location information for future moves (so machine does not need to be homed in Y-axis after completing this move).

I am using version 2.05 but I guess I could upgrade my Duet 2 Wifi to a newer version if needed.

Thanks a lot,

misan

@dc42 I am glad to report the Duet breakout board works nicely with this driver. All the trouble was due to incorrect wiring.

Y-axis has its own end-stop for homing purposes.

But when Y-axis moves to "dock" the tool changer there is another end-stop involved (the input I am planning to use is U-axis end-stop, but I could use any other input if better).

Y-axis homing works as expected, and each time a tool change I have to send the Y-axis back (at a certain X location) so it will engage with the tool changer. I am backing the Y-axis for that purpose until the carriage "contacts" with a special end-stop for that only purpose.

One approach that seems possible is to change config as if now the Y-axis has to use this new end-stop and then to do a homey.g, but that approach would alter the Y-axis coordinates (nothing that could be fixed) doing a new (and now proper) home of Y-axis now using the real Y-axis end-stop (at a different X-location so I am not knocking down the tool-change mechanism).

But I wonder if there is another way to achieve a similar result that would not alter the Y-axis origin of coordinates.

Thanks a lot,

misan
P.S: drawing is coming soon

@jay_s_uk Wow, you read my mind then I am going to learn all about it. Thanks a lot!

Here you have a picture of the setup. Both X and Y axes have end-stops for homing purposes.

A third end-stop is located in the tool changer in a way that detects when the carriage bumps into it (due to tolerances and the need of some contact force the Y coordinate may change from one operation to the next one, thus the need of an end-stop here instead of using a pre-determined fixed Y coordinate for that move).

@dc42 I see the usefulness of H4 option (it does the homing move without affecting the origin, which is what I needed). But, I guess I need to temporarily change Y-axis home end-stop source for that coupling move. How can I do that?

Thanks a lot,

misan

Oops, my edit is being flagged as spam, maybe I attempted too many edits after the post (just trying to fix the typos

@T3P3Tony I would have already bought a Duet 3 Expansion 1XD board if it were for me. Unfortunately, it is for a research project with EU funding. Life is too short to go through the pain they cause us to validate orders from suppliers abroad.

Before asking, I saw the question was answered on the forum, but I insisted in case there was some "not recommended" but workable solution. Once this is off the table, I will bump up the VIN voltage to 48V and use one of the 6HC built-in drivers for the pellet extruder.

As usual, thank you guys for a quick and informative answer.

@T3P3Tony I would have already bought a Duet 3 Expansion 1XD board if it were for me. Unfortunately, it is for a research project with EU funding. Life is too short to go through the pain they cause us to validate orders from suppliers abroad.

Before asking, I saw the question was answered on the forum, but I insisted in case there was some "not recommended" but workable solution. Once this is off the table, I will bump up the VIN voltage to 48V and use one of the 6HC built-in drivers for the pellet extruder.

As usual, thank you guys for a quick and informative answer.

Hi,

I control a large format 3D printer with a Duet3 6HC board, which works great. However, I use a large pellet extruder that calls for an external driver. I have read several similar questions, and the answer was that a CAN-FD card should be used for that job. But then I checked the 6HC schematic and saw that the built-in drivers are driven from GPIO pins from the processor.

I would use some of the available I/O pins to control the STEP/DIR /ENABLE pins of an external stepper driver for my extruder. The Duet 3 Expansion 1XD board is the "standard" way of doing that with the Duet 3, but I wonder if there is any other way (other than soldering a few wires to the inputs of an unused TMC :-). My local supplier does not sell the expansion board, so I am looking for alternatives.

Thanks a lot,

misan

@dc42 Hmm, maybe I will try it the next time I visit the workshop. Thanks for the clarification.

@jay_s_uk Wow, you read my mind then I am going to learn all about it. Thanks a lot!

While the same could be applied to a 3D printer, I am interested in a dual-head CNC machine. That would have six axis, as two groups of XYZ axis. We can name them X1,Y1,Z1 and X2,Y2,Z2.

At any moment, two independent movements could be happening. G-code could be created so there is a decent balance in the movements' duration for X1Y1Z and X2Y2Z2 so that a new movement for any of the two heads becomes available moments before the previous one is over. If one of the two heads has not had a pending move on time, it just sits at the last position until a new movement becomes available in an upcoming g-code line. G-code is generated in a way that prevents any collision between the tools.

I do not think the above behavior can be obtained with RepRapFirmware. However, all the building blocks are there. Using two independent boards would work, so each one controls three axes independently. But in that case, two independent g-code files would be operated and that could raise synchronization problems in case one of the controllers is paused while the other continues. Bear in mind the two independent heads could crash into each other if sent to coordinates close enough.

Anyone can think of a way to handle that with a Duet board?

@dc42 since I disabled Dropbox LAN synchronization and moved all cell phones to another Wi-Fi network, the problem I reported is gone.

Given 2.1beta2 is reported to feature slower upload speeds plus being a beta version, and our use case is a CNC farm where every bit counts, I have decided not to update wifi firmware on our boards.

@joseiarca Parece que has conseguido que se conecte a tu wifi, ahora pon 192.168.0.15 en tu navegador para acceder al interface web de la tarjeta.
Tienes instalado un firmware bastante antiguo pero eso no debería de ser un problema, aunque posiblemente quieras actualizarlo, pero eso lo puedes hacer más fácil una vez tengas el acceso web en marcha.

@dc42 Sure. I will do it and report back.

Oops, I just saw I cannot do that remotely (wifi parameters must be re-entered). That means I have to go to the workshop. This will then take longer.

@T3P3Tony I have set the systems not to use LAN synchronization for a while to see if that helps or fixes the problem entirely. I will know more at the end of the day.

Please note I added a link to a more comprehensive network capture in the previous email I edited.

@T3P3Tony I am going to test the SD replacement, but my order is in the mail

Anyway, what seems to be the cause is Dropbox's operation. It looks like some of the network traffic it broadcasts might be setting the ESP8266 into a weird state.

We know that the problem does not appear if we stop Dropbbox on our workshop computers from synchronizing.

I have a longer traffic capture, with the problem starting at 15.2 seconds (approx) but the file is too long for your system, so it can be downloaded from here (for a limited time) https://we.tl/t-m0dDrqfM2K