BUG: Issues mixing external and on-board drivers for XY axes

[bass4aj]

Using the Duet 2 Maestro, I attempted to map the X axis to an external motor driver (Drive 5), and the Y to the standard Y axis stepper (Drive 1). In this configuration, the motors did not operate as expected. I cannot remember at the moment if neither axis worked, or if only one of them worked.

[dc42]

1. Please don't jump to the conclusion that you have found a bug just because you didn't get something to work.

2. If indeed there is a bug, the information you have given is totally inadequate to facilitate reproducing it.

3. As per the documentation on M584 in the GCodes wiki page, when re-assigning axes to drivers that default to being extruder drivers, you must redefine the extruder drivers in that same M584 command. Did you do that?

4. Depending on the type of external driver you use, it may need more than 3.3V drive voltage, and it may need the step timings extended using the T parameter in the M569 command. You haven't said what type of external driver you are using.

[bass4aj]

Sorry, I do have more information that I did not post. I apologize for not being as explicit.

For #4, the external driver is an ODrive which is a BLDC motor driver that is independently powered. It converts STEP and DIR inputs into BLDC motor movements. It does not use the Enable pin.

For #3, I did not try defining the extruder in the same line. However, when not using M584, Drives 0 and 1 were X and Y as expected, and worked as expected. When using M584 X5 Y6, both BLDC motors received input from the duet and moved as expected. It was only in the case where I defined M584 X5 Y1 that the ODrive did not receive proper inputs from the Duet. I do not know if it was missing STEP, DIR, or both. In addition, as stated, I cannot remember if the Y axis was still moving properly. I will have to re-test that if that information is important.

As you suggested, I will also try to define the extruders in the same command and see if that resolves the issue.

Therefore, for #2, what other information would you like me to gather in order to better troubleshoot the issue?

[dc42]

@bass4aj said in BUG: Issues mixing external and on-board drivers for XY axes:

Therefore, for #2, what other information would you like me to gather in order to better troubleshoot the issue?

The information I would need includes:

• In what way the motors did not behave as expected
• Your config.g file
• The specification of the external drivers you are using including: input voltage and current requirement for the STEP and DIR pins, minimum step pulse width, minimum step pulse interval, and direction-to-step setup and hold times.
• How you have connected the external drivers to the Maestro

However, the additional stepper outputs on the Maestro are intended primarily for the 2x-TMC2224 stepper driver daughter board. I don't think we've tested them with any other type of external driver. It's possible that a firmware change would be needed, because I'm not sure how the firmware will behave when you try to use the additional stepper drivers but no response has been received from them via the UART.

[bass4aj]

In what way did the motors not behave as expected?

• The externally driven motors did not turn at all. No response, but only in the configuration of one external motor and one on-board stepper. If I ran 2 external motors for the XY and no on-board steppers, then they behaved exactly as they should.

The specification of the external drivers you are using including: input voltage and current requirement for the STEP and DIR pins, minimum step pulse width, minimum step pulse interval, and direction-to-step setup and hold times.

• I am not sure how much of this information is available, but I can look around. As I mentioned, the external driver is a conversion for BLDC motors, so it most likely does not function in the same way as a stepper driver. I do believe the design is open source though, it it should be accessible somewhere... https://odriverobotics.com/

How you have connected the external driver to the Maestro?

• They are connected via step, dir, and gnd pins only. The external driver is independently powered.

Your config.g file

• I dont have this handy at the moment but I will post it here once I do.

[dc42]

@bass4aj, I don't have time to search for the specifications of the ODrive. It is your responsibility to provide them if you want me to help you with using them.

If the external drivers did not turn at all then my best guess is that it is for one of the following reasons:

1. The 3.3V drive and few mA current drive capability of the extra stepper driver output pins is insufficient for the ODrive. If the ODrive has optically isolated inputs, this is very likely to be the case. If so, then 5V level shifters might solve the problem.

2. The step pulse timings are too fast for the ODrive. If the ODrive has optically isolated inputs, this is almost certainly the case. You can use the M569 command to lengthen the step pulse timings.

3. We didn't expect the Maestro to be used with external drivers. There may be a firmware issue with controlling external drivers that don't respond to the TMC2224/TMC2208 UART commands. If this is the cause, recompiling the firmware with NumSmartDrivers reduced from 7 to 5 should fix it.

[nhof]

This post is deleted!

[bass4aj]

@dc42 Not trying to be a pain, just trying to understand how this works:

For any of those reasons, how does that exactly apply? What I have seen is that when driving 2 external motors via the step and dir pins on drives 5/6 (both external driver outputs), there is no issue. On the ODrive, those inputs are isolated for each motor so it is effectively a separate board for each motor. The only issue is when using one external motor and one on-board TMC stepper for specifically the X and Y axes. (To also be clear, I understand there is not a good reason for doing this functionally, it is something I discovered when trying to test my BLDC calibration). I am not using UART pins, and if it were a step pulse or current issue, those external drivers should not work in any situation, right? If my deductive reasoning here is flawed, please let me know. I am happy to hunt for any necessary information, but I want to be sure I am not wasting time hunting for irrelevant info.

[dc42]

I'm sorry, I didn't read your original post properly. I think you are saying:

• M584 X5 Y6 works: X and Y move one ODrive each
• M584 X5 Y1 doesn't work: commanding X movement doesn't move the ODrive, but commanding Y movement works as normal

Is that correct?

If so, please repeat your tests, but this time use G91 followed by G1 S2 Y10, G1 S2 Y-10, G1 S2 X10 etc. to test drive movements. This will eliminate the possibility that the firmware is denying movement because the axis is not flagged as homed or is outside the bed limits.

[bass4aj]

@dc42 Yes that is what I observed. I will go repeat my tests and report what I find. Might be a bit since its in the FRC robotics shop and we are in the middle of build season. I will try to get it done in the next week or two. Thank you for being patient with me haha