Motor Controller Project
Moderators: rjlittlefield, ChrisR, Chris S., Pau
Motor Controller Project
Hello,
I'm posting this to see if folks are interested in getting involved with a custom stepper motor controller based upon the Trinamic or Pololu Tic controllers. I have both of these controllers fully operational now in a Fully Automated Precision S&S System I've been developing.
The idea would be to develop a custom PCB for the Raspberry Pi 3 that could be assembled (like an electronics kit) by those with moderate skills. These controllers would work with the Stackshot, Wemacro, MJKZZ, THK, HIWIN and most other rails, allowing "tuning" to optimize the controller/rail performance by means of programmable parameters.
This should allow those to customize the hardware as well as the software for their particular needs, but keep the overall cost reasonable. Below are some controller examples I've developed and have fully operational.
Anyway, let's see if any folks are interested and want to participate.
Best,
Single Axis Controller based upon Tic-500 and Raspberry Pi Zero W
3 Axis Stack & Stitch Controller based upon Tic-500 and Raspberry Pi 3B
3 Axis Stack & Stitch Controller based upon TMC-5130 and Raspberry Pi 3B
I'm posting this to see if folks are interested in getting involved with a custom stepper motor controller based upon the Trinamic or Pololu Tic controllers. I have both of these controllers fully operational now in a Fully Automated Precision S&S System I've been developing.
The idea would be to develop a custom PCB for the Raspberry Pi 3 that could be assembled (like an electronics kit) by those with moderate skills. These controllers would work with the Stackshot, Wemacro, MJKZZ, THK, HIWIN and most other rails, allowing "tuning" to optimize the controller/rail performance by means of programmable parameters.
This should allow those to customize the hardware as well as the software for their particular needs, but keep the overall cost reasonable. Below are some controller examples I've developed and have fully operational.
Anyway, let's see if any folks are interested and want to participate.
Best,
Single Axis Controller based upon Tic-500 and Raspberry Pi Zero W
3 Axis Stack & Stitch Controller based upon Tic-500 and Raspberry Pi 3B
3 Axis Stack & Stitch Controller based upon TMC-5130 and Raspberry Pi 3B
Research is like a treasure hunt, you don't know where to look or what you'll find!
~Mike
~Mike
-
- Posts: 3417
- Joined: Sat Nov 20, 2010 10:40 am
- Location: Santa Clara, CA, USA
- Contact:
Saul,
That's something that might be useful, but not within my immediate plans. This might be an area where you or someone could contribute, the Tic-500 and Trinamic support encoders.
Another area where help is welcome is someone to layout the circuit boards. These shouldn't be hard and someone with layout skills should have a easy time, I think some of the DIYer PCB houses actually have on-line layout tools to use at no cost.
The way I do this (familiar with the limitations of the other controllers, although the Stackshot under Zerene control solves this nicely) is to move to the desired start position, iterate around, select, then move to the desired end position, iterate around and select, then select the desired step size. You can redo these selections or move on to the next command input. The movement speeds are handled for you, so moving short distances is easy to select the spot and moving long distances (like from start to end positions) is brisk and slows upon approaching selected position. This works for me and is the way I coded it, of course with your own custom setup you can code things anyway you choose. The base language I use is Python, this is not compiled like the flavors of "C", so it's easier to work with....very similar to old BASIC.
Welcome aboard!!
Best,
That's something that might be useful, but not within my immediate plans. This might be an area where you or someone could contribute, the Tic-500 and Trinamic support encoders.
Another area where help is welcome is someone to layout the circuit boards. These shouldn't be hard and someone with layout skills should have a easy time, I think some of the DIYer PCB houses actually have on-line layout tools to use at no cost.
The way I do this (familiar with the limitations of the other controllers, although the Stackshot under Zerene control solves this nicely) is to move to the desired start position, iterate around, select, then move to the desired end position, iterate around and select, then select the desired step size. You can redo these selections or move on to the next command input. The movement speeds are handled for you, so moving short distances is easy to select the spot and moving long distances (like from start to end positions) is brisk and slows upon approaching selected position. This works for me and is the way I coded it, of course with your own custom setup you can code things anyway you choose. The base language I use is Python, this is not compiled like the flavors of "C", so it's easier to work with....very similar to old BASIC.
Welcome aboard!!
Best,
Research is like a treasure hunt, you don't know where to look or what you'll find!
~Mike
~Mike
Lou,Lou Jost wrote:I'm very interested Mike, for a single-axis controller. As you have pointed out on other threads, the vibration-free movement would be a major advance for people like me who shoot subjects in liquid.
Just completed a test with the subject (small flower) floating in water.
https://www.photomacrography.net/forum/ ... 993#247993
Note the lack of camera/lens/rail/motor induced movement to the subject. The stand is very rigid for common mode effects, so the movements directly couple to the subject!!
Note that the subject is constantly moving at a slow rate due to thermal or relaxation effects, this is not due to lens/camera/rail/motor induced movements.
Best,
Research is like a treasure hunt, you don't know where to look or what you'll find!
~Mike
~Mike
- rjlittlefield
- Site Admin
- Posts: 23564
- Joined: Tue Aug 01, 2006 8:34 am
- Location: Richland, Washington State, USA
- Contact:
Mike, that video does a great job of convincing me that your system is free of troublesome vibrations caused by rail movement.
However, I find that I'm at least a bit skeptical about this one part of your description:
I'm very familiar with that behavior, because it occurs with every system I've ever put together, including my current one that uses a 1" optical table with 1.5" optical post, sitting on 4 sorbothane feet.
However, I've always interpreted that behavior to mean that in fact my systems are not very rigid -- at least not rigid enough to pass such a stringent test. If they were rigid enough to maintain common mode movement, then touching the table would have no effect on the live view image.
I wonder if you can clarify exactly what you mean by "very rigid for common mode effects", and how you've gone about testing that rigidity.
--Rik
However, I find that I'm at least a bit skeptical about this one part of your description:
As I recall your previous videos with non-liquid subjects, there was a recurring theme that simply tapping the table, on which your rig was sitting, caused a high mag image to bounce around quite a bit.mawyatt wrote:The stand is very rigid for common mode effects, so the movements directly couple to the subject!!
I'm very familiar with that behavior, because it occurs with every system I've ever put together, including my current one that uses a 1" optical table with 1.5" optical post, sitting on 4 sorbothane feet.
However, I've always interpreted that behavior to mean that in fact my systems are not very rigid -- at least not rigid enough to pass such a stringent test. If they were rigid enough to maintain common mode movement, then touching the table would have no effect on the live view image.
I wonder if you can clarify exactly what you mean by "very rigid for common mode effects", and how you've gone about testing that rigidity.
--Rik
Rik,
Good to hear the video helped show the vibration effects of the concepts involved. The original (electronic) concept dates back about 20 years ago with a cascade of wideband active filters and trying to manipulate the time domain response of the 1st filter to minimize the settling time of the 2nd filter. The math behind this was solutions between Laplace and Time Domians with functions not in tables (I recall using the Central Limit Theorem to help with the translations, but can't remember the details). It seemed to me that similar concepts could help with our stacking efforts, and it does seem to help.
Rigid is relative to a typical setup one would use for a portable stacking setup (not actually tested). Very rigid was probably not the best choice, maybe reasonably rigid would be better. It's not nearly as rigid as my Thor Labs setup which is probably similar but not as good as your proper optical setup (my base is just an aluminum base instead of a 1" thick optical base).
The kitchen table I used in the earlier videos is very wobbly and unstable, so about as bad a table selection as one could get I imagine. I'm sure this helped augment any vibrations coming from anywhere, certainly a worst case test....but that's what I was looking for.
I'm hoping that some folks will give this a try, I think it works really well but that's just my opinion.
Best,
Good to hear the video helped show the vibration effects of the concepts involved. The original (electronic) concept dates back about 20 years ago with a cascade of wideband active filters and trying to manipulate the time domain response of the 1st filter to minimize the settling time of the 2nd filter. The math behind this was solutions between Laplace and Time Domians with functions not in tables (I recall using the Central Limit Theorem to help with the translations, but can't remember the details). It seemed to me that similar concepts could help with our stacking efforts, and it does seem to help.
Rigid is relative to a typical setup one would use for a portable stacking setup (not actually tested). Very rigid was probably not the best choice, maybe reasonably rigid would be better. It's not nearly as rigid as my Thor Labs setup which is probably similar but not as good as your proper optical setup (my base is just an aluminum base instead of a 1" thick optical base).
The kitchen table I used in the earlier videos is very wobbly and unstable, so about as bad a table selection as one could get I imagine. I'm sure this helped augment any vibrations coming from anywhere, certainly a worst case test....but that's what I was looking for.
I'm hoping that some folks will give this a try, I think it works really well but that's just my opinion.
Best,
Research is like a treasure hunt, you don't know where to look or what you'll find!
~Mike
~Mike
Ray,ray_parkhurst wrote:I'm interested, but I'm not sure how I can help. Let me know what you need.
Laying out the circuit boards is something that would certainly help, hopefully you or someone with those skills will "sign up" for this task.
Best,
Research is like a treasure hunt, you don't know where to look or what you'll find!
~Mike
~Mike
Hi,
I have just finished a controller - albeit using an Arduino Mega or Due and a Big Easydriver. Stand-alone controller - inputs and feedback on a 3.5" tft screen. Input parameters allow different stepper angles, leadscrew pitches, sensor sizes, lens combinations, flash recharge rates, microstep sizes from full steps to 1/16th steps etc Controls the stepper, from input parameters, calculates Magnification, DOF, number of shutters, steps between shutters, effective fStop etc etc. Uses opto-isolator to fire the shutter after selected delay to allow any vibrations to subside. Backlash from the leadscrew is factored into the unit. Setting the IN and OUT points from the touchscreen, stepper returns to the IN point after the run to allow repeat runs. As an alternative it is possible to input the distance to travel from the IN to OUT point.
A screen example attached.
Let me know if interested.
I have just finished a controller - albeit using an Arduino Mega or Due and a Big Easydriver. Stand-alone controller - inputs and feedback on a 3.5" tft screen. Input parameters allow different stepper angles, leadscrew pitches, sensor sizes, lens combinations, flash recharge rates, microstep sizes from full steps to 1/16th steps etc Controls the stepper, from input parameters, calculates Magnification, DOF, number of shutters, steps between shutters, effective fStop etc etc. Uses opto-isolator to fire the shutter after selected delay to allow any vibrations to subside. Backlash from the leadscrew is factored into the unit. Setting the IN and OUT points from the touchscreen, stepper returns to the IN point after the run to allow repeat runs. As an alternative it is possible to input the distance to travel from the IN to OUT point.
A screen example attached.
Let me know if interested.
Mike, There is another big advantage of your smooth movement over jerkier systems. Lots of us work with water-dipping objectives, where the front of the objective is actually in the water, usually quite close to the subject. Sudden movements of the objective must produce shock waves which could disturb the specimen. Smooth movements would be very useful in this application.
- iconoclastica
- Posts: 486
- Joined: Sat Jun 25, 2016 12:34 pm
- Location: Wageningen, Gelderland
I agree. I had dismissed the Pi for being too much computer and not enough micro-controller. But I am not too happy with the arduinos either since they depend on C++ and debugging the software is near to impossible.mawyatt wrote:Also like the stand alone capability, I use VNC with the Raspberry Pi.Best,
This week I tried a third way, viz. the ESP32 with a micro-python image flashed onto it. I figured that apart from the hardware interactions I could develop and test the python source code on my pc before uploading it to the controller. It was disappointing.
Micro-python is (said) a compact implementation of python with a few limitations and its own versions of the standard libraries. It is distibuted as images to be flashed to the various boards. Each board type (PyBoard, bbc, ESP) has their own ports. Regrettably, the implementations deviate more from standard python than the documentation suggests. Even the standard object model is defectively implemented. The libraries sometimes are to be called with different functions and parameter lists and even when identical, they may behave in unexpected ways. Python boasts about its duck-typing phylosophy. In this view, micro-python may quack like a duck, but is doesn't walk like a duck, so it isn't a duck..eh.. python.
So, like arduino, for the lack of a decent developing environment with test and debugging support, writing sophisticated applications in micro-python is for the masochisticcaly inclined. It still could be suitable for simple script-like applications. It seems worth a try to me to avoid falling back to c++. The esp-board itself seems a better alternative to the arduinos, but I havent really tried it sofar yet.
-- Wim
--- felix filicis ---