Replies: 2 comments
-
|
Difficult to give advise without seeing your sketch or the schematics. Your are sure, that the moveTo() does not return ? From the description of yours, I would guess, that the running motor creates noise on your power supply, so the IR-receiver does not work. Any chance to check the IR-output electrically, while the motor is running ? |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for your fast reply. You finally brought me onto the right track: When I disconnect the stepper in my production environment, all is OK. AND I am noticing the IR receiver's LED flickering when the stepper is moving AND no key is pressed on the IR remote. That means I have cross-talk between them and indeed the wires are in parallel for quite a distance. So it should be solved by twisting them or putting them apart. Thank you! |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I have a really weird problem. I have a NEMA23 stepper motor driven by the DM556T driver, using HIGH levels for ENA, PUL, DIR. The uC I am using is an M5Stack Atom Matrix. On its pin 25, I attached an IR receiver. On its pins 19, 23, 33 I attached DIR, PUL, and ENA. I am using setAutoEnable(true) and setEnablePin(driverENA, false). Atom Matrix pinout: https://docs.m5stack.com/en/core/atom_matrix
My IR remote is used to enter levels (10 rotations each) for a kind of lift to drive the stepper to. Subsequently pressing the "Plus" button increases the level, "Minus" decreases it. You can imagine it like a two-key only lift control instead of having a number key for each level.
Desired behaviour: Coming from level n, I press "Plus". The motor starts moving. While it is moving (and has not yet reached the desired layer n+1) I press "Plus" again, say 2 times. Means it should go not only to level n+1 but n+3. Feedback for pressing the button is a level number shown on the LED matrix of the uC. This is WORKING ALRIGHT in my test environment when the driver/motor are not connected.
When I bring the uC to my production environment with connected driver/motor with UNCHANGED CODE it behaves as if I had made the call of moveTo() blocking (but I did not): I can press "PLUS" and the motor drives to level n+1. But a subsequent pressing won't be accepted as new level while the motor is moving. I have to WAIT until the motor has reached level n+1, only then a subsequent press is accepted and carried out. I can see that already from the LED matrix which won't increase if the motor is moving.
How can this be? Also in my test environment, the output pins for ENA/PUL/DIR are switched. But when they are actually connected to the driver, the behaviour changes. How can this have an impact on the AccelStepperLibrary - it appears my loop() won't be called.
Any hint appreciated ...
Beta Was this translation helpful? Give feedback.
All reactions