Just checking in, How are we doing on the Step - Dir interface, Any ETA?
I think I can get started on it in about a week from now or so.
That’s great. With the hardware changes to the GPIO in the new release of the hardware board how much performance increase do you expect for Step-Dir? Should I consider getting the new hardware?
Thanks
I don’t know yet, I don’t have a good model for this. I think we will find out with testing.
How is the step - dir going?
I did get started a little bit, but now there’s some other stuff coming I have to deal with. I’ll be busy with that for about a week, then I can get back to firmware development again.
I think maybe I should look at taking in investment, to have money to hire a firmware developer, or something. Turns out running a business eats a lot of time away from the engineering.
1 Like
The 1st version of step/direction is now up on master on the github repo.
The pinout is:
- GPIO 1: M0 step
- GPIO 2: M0 dir
- GPIO 3: M1 step
- GPIO 4: M1 dir
There is also a new config variable called counts_per_step, (seen here, and here) which specifies how many encoder counts a “step” corresponds to. It can be any floating point value.
Please note that on ODrive v3.1, and v3.2 the GPIO pins are NOT 5V tolerant, so 3.3V signals only!
ODrive v3.3 will have 5v tolerant GPIO pins.
I have no idea what the maximum step rate is. I tried up to 16kHz, but I don’t know what the limit is. If someone want’s to test it, please be aware that the failure mode on too high step rates is expected to be that the motors shuts down and coasts.
Let me know how it goes!
1 Like
Here is a quick demo video:
1 Like
Thank you very much for your work on this feature, I think I will be picking up a 3.3 board to integrate with my CNC project. The ability to integrate other drivers (or even multiple ODrive boards) via step/dir running from the same overall control board is very attractive.
1 Like
Schweet! Now we can really get this thing into action. Thanks Oscar!
I am a little confused, Is the index enabled now? So it could initialize under load. I was reading in the getting started guide that the index is optional.
Thanks
Sorry no the Index pulse feature is not in place yet.
I am using a level shifter for the step dir signals, Is that going to be OK? Any special cautions implementing the step dir?
What levels is your original signal?
Step pulses are only about 5us long or so, so make sure your level shifter has a rise time of 1us or less.
Yes, please be aware that there is no enable line right now. So if whatever is driving the step/dir has disabled their outputs, the step/dir wires may pick up electrical noise, and see step pulses.
So just as a precaution, make sure that whenever you have the step/dir wires plugged in to the ODrive, that the motion controller is turned on when the ODrive is running.
Another option to achieve a similar protection is to have somewhat strong pull-down resistors on the step lines.
My output signal is 5v and according to the datasheet the transistors in the level shifter are as follows.
Turn–On Delay Time 2.5 5 ns
Turn–On Rise Time 9 18 ns
Turn–Off Delay Time 20 36 ns
As for now I am keeping the controller on and connected so the motor should hold position unless it has input to change.
The problem I am having now is with the new firmware. The only thing I have changed in the low_level.c file is “ENCODER_CPR (2048*4)” which works with the last version. It seems to flash OK when I run “make flash” but then it does not initialize.
Here is the output from make
make output
mkdir -p build
MotorControl/low_level.c:1060:13: warning: ‘FOC_voltage_loop’ defined but not used [-Wunused-function]
static void FOC_voltage_loop(Motor_t* motor, float v_d, float v_q) {
^~~~~~~~~~~~~~~~
MotorControl/low_level.c:1042:13: warning: ‘scan_motor_loop’ defined but not used [-Wunused-function]
static void scan_motor_loop(Motor_t* motor, float omega, float voltage_magnitude) {
^~~~~~~~~~~~~~~
arm-none-eabi-size build/ODriveFirmware.elf
text data bss dec hex filename
84624 1648 36204 122476 1de6c build/ODriveFirmware.elf
Here is from make flash
make flash output
$ make flash
openocd -f interface/stlink-v2.cfg -f target/stm32f4x.cfg -c init -c reset\ halt -c flash\ write_image\ erase\ build/ODriveFirmware.elf -c reset\ run -c exit
GNU ARM Eclipse 64-bits Open On-Chip Debugger 0.10.0-00113-g0f83948 (2017-01-24-18:48)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport “hla_swd”. To override use 'transport select '.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
none separate
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : clock speed 1800 kHz
Info : STLINK v2 JTAG v17 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.228458
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
adapter speed: 2000 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0800e8d4 msp: 0x20020000
auto erase enabled
Info : device id = 0x10076413
Info : flash size = 1024kbytes
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x20000046 msp: 0x20020000
wrote 131072 bytes from file build/ODriveFirmware.elf in 5.284302s (24.223 KiB/s)
adapter speed: 2000 kHz
Thanks
Contact me on Skype, I’ll make sure you get up and running (:
Loaded the 0.1 firmware. Worked without any modification at all. (Except for putting a brake resistor). So, Where in the code do I change the speed. I am not sure is this is working like other step interfaces I have used. If I increase the step velocity (the frequency of the step pulses) Should the drive increase in speed too. Or is it limited somewhere?
Good work it seems to be good.
There is a velocity limit you need to configure, please see the turning parameters instructions.
If your step rate times the counts/step velocity is higher than the velocity limit, then the motor will fall behind the specified trajectory. It will catch up again once the step-rate falls below the limit. That is, if you exceed the velocity limit, the motor will physically fall behind, but the ODrive won’t lose track of counting the steps and where the implied specified position setpoint is.
I must hang my head in shame. All of my problems were from my heatsink. Let that be a lesson, When I put it on I checked every connector to gnd and I didn’t have any shorts as far as I could see. But somewhere it was. This thing is working wonderfully. Thanks for your patience.
Bart
Please record a video once you have something cool going ;D