I’ve been experimenting with GPIO EXTI as well and found it rather noisy. I’ve had a button hooked to one of the gpio pins and it would falsely trigger input sometimes - occurring more at higher speeds.
I think shorter cables or twisted pairs might help?
Here is a little more info on my step/dir adventure. I have been using the gnd from the J2 connector and it does act quite a bit better but still getting extra steps. I have put the controller (a leafboy 77 also known as AKZ250 USB card for Mach3 and am using Mach3 to control that). as close as I can get. Actually the M1 pins (gpio 3 and 4) act a little better than the M0 pins 1 and 2. I have routed my encoder wires and motor wires as well as I can. I am not sure what to try next but I’ll be sure to let you know.
In response to srk. Shorter cables are always a good idea but I don’t think that will help in this case. As far as twisted pair, that won’t help either because it is not a differential signal. My encoder cables are shielded but the shield is floating. I have huge motors so I am going to try and get them as far away from the board as I can.
Do you have access to an oscilloscope? If so, can you please make a measurement of the step pin(s) with the J2 GND as reference?
There is an electrical issue on ODrive that we uncovered, with significant help from @Bart’s testing.
For now it means you shouldn’t use J3’s GND, but instead J2’s GND when using step/dir.
Please see this topic:
Hi, I have a 3.4 ODrive and I’m having a problem getting Step / Direction working.
I’ve had the ODrive working in Velocity Control, both sensorless and with encoder and also in Position Control and now want to utilise the Step and Direction mode.
Firstly, I set the ODrive up to work in Position Control mode, verified that, then set the compile time parameters CONFIG_UART_PROTOCOL to none and CONFIG_STEP_DIR to y in tup.config. Ran make in the firmware folder and make dfu in the tools folder and the processor erased and flashed the firmware ok.
Restarted the ODrive, it goes through its calibration routine, a bleep then turning one way then the other, then stops.
Now, If I GND both the Step and Dir inputs, the motor turns at a fixed velocity, I put a scope probe on the grounded input Step and there is a regular pulse spike occuring every 60uS.
Little more info, when ERROR_DRV_FAULT occurs and the motor is de-enegised, the periodic spikes disappear.
I’ve got a v3.4 48volt version which looks a bit different, I’ll flash that tomorrow and retry.
Yes it’s very easy to have noise couple into the step/dir signals. ODrive v3.5 has some RC filters on the inputs to help mitigate this. On v3.4 I had good results when soldering in some RC filters, though it was a bit fiddly to get the capacitors into place. I used 330 ohm and 4.7nF. Here are some pictures of what I did:
I had some passive breakout boards that made it really convenient to insert the series resistors. If you don’t have this, you can just use through hole resistors. You can also see where I soldered in the capacitors next to the ARM chip.
I decided that it was more convenient and likely to yeild the best results for me to put the capacitors as close to the ARM chip as possible, connected directly to the GND that feeds it. You can see the GND is the upper of the thick top (red) traces if you zoom in the picture.
I scraped off the solder mask and used long solder blobs to reach across to get connections I wanted.
If you think it is too fiddly for you to install the capacitors the way I did, you can try to have them be external right at the J3 connector.
Thank you Oskar for your quick reply and fix, I’ll implement that mod and report back. Cheers.
Excellent, That’s fixed it. Thank you Oskar.
I’m having problems with Step and Direction mode picking up extra steps. The Step input seems to be sensitive to interference. I’ve played around with different values on the RC network, but can’t eradicate it totally.
My ODrive is within 15cm of the motor which I think maybe the source, so I’m going to try extending the motor and encoder wires.
I was also wondering if a configurable software dead time to the Step input could be possible, to ignore pulses less than a certain width?
Extending the distance of the ODrive to the motor to just over a metre didnt help.
In the interrupt routine for the Step input, I was thinking of inserting a short delay, then checking the status of that input and if it was still high, then perform the step, otherwise dismiss it as a false input and return without doing anything. Can you see any problem with doing that?
I’ll chime in here, and I really don’t know about odrive, but I would hesitate ever solving a hardware issue with a software patch of sorts. Creating a check is fine unless you are doing it as a solution to ignore a constant unknown problem. My experience has been this method, while easier, has a high chance of compounding the problem at high speeds or in even noisier environments. Even the resources allocated to the check itself can become a problem down the road. Grounding, shielding and understanding component isolation are a better direction in this case. Software should only come after the hardware is solid or you risk redesign at a painfully late stage. My 2c.
I don’t want to insult you so ignore if you’re past this, but twisted wire pairs solves a lot of these issues and often gets overlooked. Good luck.
@Neil_FV Where did you add in the capacitors for the RC network? Was it soldered close to the STM like my example, or somewhere else?
I soldered them over the “4” of the “48V” silkscreen, probably too far from the processor I’m guessing.
The Odrive 3.5 is doing much better! I have implemented the Step/Dir and it seems to be pretty stable. I am not getting extra steps or missing any so I am pretty happy. The Odrive is getting much more mature. The Odrive Tool ROCKS! I am having a couple of problems tho. For one thing I can’t get the Index to work. I am using an AMT102 and I do have the X (on the encoder) hooked up to the Z pin. The next thing is that the motor will go into high velocity free running at random. I have run through a G code file and sometimes it will go fine and other times it will go into the free run. I have read in the troubleshooting guide " Motor cuts off or spins uncontrollably at high rotational speeds (ie: > 5000 RPM)" but the G code I am running is not approaching any where near 5000 rpm.
and the last thing is when in the Odrive Tool after rebooting I get this
ChannelBrokenException Traceback (most recent call last)
~\Anaconda3\lib\site-packages\fibre\shell.py in
----> 1 odrv0.reboot()
~\Anaconda3\lib\site-packages\fibre\remote_object.py in call(self, *args)
160 for i in range(len(args)):
161 self._inputs[i].set_value(args[i])
–> 162 self._parent.channel.remote_endpoint_operation(self._trigger_id, None, True, 0)
163 if len(self._outputs) > 0:
164 return self._outputs[0].get_value()
~\Anaconda3\lib\site-packages\fibre\protocol.py in remote_endpoint_operation(self, endpoint_id, input, expect_ack, outpu
t_length)
313 return self._responses.pop(seq_no)
314 # TODO: record channel statistics
–> 315 raise ChannelBrokenException() # Too many resend attempts
316 finally:
317 self._expected_acks.pop(seq_no)
ChannelBrokenException:"
I have gotten a lot further in a lot less time than the first time around. Thanks for all the hard work!
Hi @Bart,
Do you use the shielded cable we provide for the AMT102? Or something else?
The runnaway is usually caused by mechanical slip of the encoder, or noise on the wiring to the encoder due to improper shielding.
Does anyone know about the “ChannelBrokenException” I asked about above?
That exception is normal after rebooting the ODrive.
Hi everybody,
We are trying to move a heavy load with the odrive step/dir interface. When we arrive at the desired position we use mechanical brakes mounted on the BLDC motor rotor to secure the position (we don’t want to only rely on the closed loop control).
The problem is that if we force the rotor to a fixed position the error in the control loop is never zero, so the controller try to move the rotor and rise the current, and we don’t want that.
Do you think possible to modify the firmware to use a GPIO to act as an enable pin?
