projects:sand_drawing:work_logs:software
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
projects:sand_drawing:work_logs:software [2020/04/23 12:42] – tjhowse | projects:sand_drawing:work_logs:software [2020/04/23 22:54] (current) – tjhowse | ||
---|---|---|---|
Line 15: | Line 15: | ||
I'm concerned that handling network traffic might interfere with smooth operation of the stepper motors, so I think I might unsubscribe from time-consuming MQTT topics while a pattern is playing, and then subscribe again once a pattern is finished to get new patterns from persisted topic publications. | I'm concerned that handling network traffic might interfere with smooth operation of the stepper motors, so I think I might unsubscribe from time-consuming MQTT topics while a pattern is playing, and then subscribe again once a pattern is finished to get new patterns from persisted topic publications. | ||
- | == Microcontroller choice == | + | === Microcontroller choice |
- | I initially picked the Wemos D1 Mini for the microcontroller, | + | I initially picked the Wemos D1 Mini for the microcontroller, |
+ | |||
+ | At the time I was running with 16x microstepping, | ||
+ | |||
+ | Note these numbers are with some minimal console debugging enabled, so perhaps increase performance by 30% and you'll be close to accurate for performance with debugging disabled. | ||
+ | |||
+ | There are a few reasons for wanting more speed. The geometry of the system mean that while drawing circles near the circumference is super fast, close to the centre is much slower. I also wanted to use 32x microstepping in the final version, as higher microstepping means smoother movement means less noise. To move the steppers faster I'd need dedicated hardware. | ||
+ | |||
+ | Many microcontrollers have built in timer hardware that can be used to generate high frequency output waveforms. Memories of TCCR1A in the ATMega8. As far as I could tell the ESP8266 had none available to me. There was a Timer library I could use, but it was pure software and could only manage 1kHz. I needed a 7kHz square wave. The ESP32 has lots of dedicated timing hardware, so I set about testing it. Results were great! I was able to drive a pin too fast for the steppers to handle! Great success! However... | ||
+ | |||
+ | My initial naive approach on the ESP8266 had a hidden benefit: I tracked every transition of the step pin. I could keep a perfectly accurate index register of how far the stepper had turned. Once I offloaded responsibility for twiddling the step pin to hardware, not software, I lost the ability to exactly track what step I was up to. My first pass at the PWM implementation was to convert my step interval to a frequency, set the duty cycle to 50% and Just Go. It was a disaster! My slow loop logic was still managing timing the movements, running at its reduced speed, while the PWM hardware was merrily thrashing the stepper 'round and ' | ||
+ | |||
+ | My plan is to have two modes of operation: 1) Accurate slow, 2) Less accurate, fast. You'll be able to switch between modes in gcode. The accurate mode will have the waveform generation purely in software, and will track each pulse. The less accurate mode will use the PWM interface and measure the time it takes to move. If I use timer interrupts I should be able to say "move at 270 degrees per second and stop the movement after 1 second" | ||
+ | |||
+ | I could start motion with a PWM setting, then set a hardware interrupt timer for the duration of the move. During movement my main loop could update the index based on the time since the last update and the rate of movement. | ||
- | At the time I was running with 16x microstepping, | ||
====== What I want to accomplish next time ====== | ====== What I want to accomplish next time ====== | ||
* Build the electronics. | * Build the electronics. |
projects/sand_drawing/work_logs/software.1587645720.txt.gz · Last modified: 2020/04/23 12:42 by tjhowse