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