Lee, glad you got the bugs sorted out on the stepper motor. I finished automating my Boyar Schultz 6-12 about a year ago. Like one of the other commentors I had not done any programing since Fortran IV. I decided to use an Arduino because they are about $17 and have enough capability for this kind of project even though it was a big learning curve to program it. I originally thought about using a stepper motor for the X axis but I have a collection of gear motors and went with one of them. I used limit switches with long levers to account for the enertia overtravel. This also allows for a little more than 12 inches of travel which allowed me to regrind my chuck. The switches are each adjustable in the slot and a bumper is fixed in the middle. I did use a stepper motor to control the Y axis though. And I have switches on my control panel to make a 1/4, 1/2 or a full turn. I can also stop the X axis and quickly reverse the Y direction to start another cycle. Since you have all that computing power I'm guessing you will automate the Y axis as well. Good job with the videos.
Glad you got it sorted Lee. I would still be tempted to put more steps into the acceleration and deceleration stages. Some capacitors and inductors should fix the problem with interference. All the best from UK.
Outstanding! I haven't done any programming in 40 plus years (and it was Fortran) but I understood the logic you were describing. I also have a Harig Super 612 - we'll see if I get the guts to follow your lead!
Hi Lee. Good explanation and nice job on debugging the stepper motor program. At first, I thought you might need to add a buffer to the switch input to the Pi, to debounce the switching activities. The Pi must already have that type of latch on its inputs. Cool project.
Congrats Lee, always good to keep learning. I’ve not programmed any Raspberry Pi projects, but I’ve done a lot stepper motor projects with Arduino and ESP-32. You were liklely experiencing switch bounce on your limit switch approach. All mechanical switches exhibit contact bounce when activated and because the computer is looking at the inputs very quickly it can see these contact bounces and confuse the code. It is common practice to “debounce” the inputs to deal with this. I’m sure there are examples of Pi code out there to help. The nice thing about your final solution is you don’t have to worry about it. In the Arduino world there are libraries (subroutines) that you can download for all types of applications. There is one that basically performs a linear acceleration (and Deceleration) on the step pulses to keep from causing the lost steps you experienced. There may be similiar utilities for the Raspberry. I’ve got the same surface grinder that I am currently restoring and thinking of doing the same modification. I’d be interested to see how you mounted the stepper motor. It would also be interesting to see if the steps have an adverse affect on the surface finish. Love your channel, keep up the good work. 😊
Very interesting series on this automation! Very glad you took the time to show and explain in detail the code and the rationales for the various changes you made. Also it wouldn't surprise me if the combined weight of the table and mag chuck exceeds 100 lbs, perhaps significantly..
Most dro encoders use differential signalling on twisted pairs (eg RS422 for logic) coupled with appropriate sheilding to eliminate the interference issue. 24V logic levels with low value pullups when required is often used in industrial controls.
This design, Doesn't look like your going to get any strange pulling on the table like the original setup. Love it, Id like to copy this a bit if it works out.
Instead of using fixed values for the sleep functions, I suggest that you use variables. This would allow you to gradually ramp up and down the pulse rate near the end points, and provide better control of acceleration. The value of the sleep variable should be altered in relation to the pulse count. In regards to the problems that you were having with I/O control, I suspect that you weren't using an optically isolated I/O card. Additionally, VFD's can produce significant EMI. Filters should be used on all wiring connected to the VFD, e.g. ferrite cores. Even without the limit switches, EMI can cause erratic and unpredictable problems with your Raspberry Pi. Shielded wiring should be used for connections to the I/O card and, depending upon the card, you may need pull-up resistors. I prefer running pins hi and bringing them to ground with the external switches. This arrangement tends to negate the effects of EMI.
Is your Harig a ballway unit? With the cable driven ballway, if you run it to the end of travel, you can actually force the wheel to keep going & the cable will slip on the drum underneath the table. It actually walks across the drum as the table traverses. The fact that you slowed it down, lets the table reverse without the shock & then start up in the opposite direction without slippage. You can tighten cable until it doesn't slip & then it binds & breaks the cable. (A master grinder taught me this so I wouldn't break mine). Just my experience.
Umm Lee, maybe I'm not visualizing this right, but... If you turned your stops around, it would be the spring pins in the way of the adjustment screws. Couldn't you just push the pin in and hold the un-sprung side to make adjustments?
Obviously there can be considerable overlap these days. Fabrication and machining can present opportunities for using automation. Hence projects like this are, for many of us, perfectly within scope. And if you're not interested, it's pretty easy to just move on to another video..
Since you've come this far, why not add a ramping function so that acceleration and deceleration are not instantaneous and are set to occur over a defined number of motor steps? The current approach looks (and sounds) 'jerky' because you increase/decrease steps/unit time in a single increment rather than a short series of increases or decreases.
Lee, glad you got the bugs sorted out on the stepper motor. I finished automating my Boyar Schultz 6-12 about a year ago. Like one of the other commentors I had not done any programing since Fortran IV. I decided to use an Arduino because they are about $17 and have enough capability for this kind of project even though it was a big learning curve to program it. I originally thought about using a stepper motor for the X axis but I have a collection of gear motors and went with one of them. I used limit switches with long levers to account for the enertia overtravel. This also allows for a little more than 12 inches of travel which allowed me to regrind my chuck. The switches are each adjustable in the slot and a bumper is fixed in the middle. I did use a stepper motor to control the Y axis though. And I have switches on my control panel to make a 1/4, 1/2 or a full turn. I can also stop the X axis and quickly reverse the Y direction to start another cycle. Since you have all that computing power I'm guessing you will automate the Y axis as well. Good job with the videos.
Glad you got it sorted Lee. I would still be tempted to put more steps into the acceleration and deceleration stages. Some capacitors and inductors should fix the problem with interference. All the best from UK.
Outstanding! I haven't done any programming in 40 plus years (and it was Fortran) but I understood the logic you were describing. I also have a Harig Super 612 - we'll see if I get the guts to follow your lead!
I am in awe of your skills. Thanks for the explanation.
I bet you enjoyed the project. Thanks for the video keep on keeping on.
Hi Lee. Good explanation and nice job on debugging the stepper motor program. At first, I thought you might need to add a buffer to the switch input to the Pi, to debounce the switching activities. The Pi must already have that type of latch on its inputs. Cool project.
Quite interesting. For me, writing code is fun. Have not done it in quite some time. Thanks for the video.
Congrats Lee, always good to keep learning. I’ve not programmed any Raspberry Pi projects, but I’ve done a lot stepper motor projects with Arduino and ESP-32. You were liklely experiencing switch bounce on your limit switch approach. All mechanical switches exhibit contact bounce when activated and because the computer is looking at the inputs very quickly it can see these contact bounces and confuse the code. It is common practice to “debounce” the inputs to deal with this. I’m sure there are examples of Pi code out there to help. The nice thing about your final solution is you don’t have to worry about it.
In the Arduino world there are libraries (subroutines) that you can download for all types of applications. There is one that basically performs a linear acceleration (and Deceleration) on the step pulses to keep from causing the lost steps you experienced. There may be similiar utilities for the Raspberry.
I’ve got the same surface grinder that I am currently restoring and thinking of doing the same modification. I’d be interested to see how you mounted the stepper motor. It would also be interesting to see if the steps have an adverse affect on the surface finish. Love your channel, keep up the good work. 😊
Thanks for sharing great info. We all learn from mistakes. This looks like it could be used for a couple other projects.
Very interesting series on this automation! Very glad you took the time to show and explain in detail the code and the rationales for the various changes you made. Also it wouldn't surprise me if the combined weight of the table and mag chuck exceeds 100 lbs, perhaps significantly..
External 'spikes' go from low to high, rarely from high to low. You should try pull up resistors and have the PI look for a low.
Most dro encoders use differential signalling on twisted pairs (eg RS422 for logic) coupled with appropriate sheilding to eliminate the interference issue. 24V logic levels with low value pullups when required is often used in industrial controls.
This design, Doesn't look like your going to get any strange pulling on the table like the original setup. Love it, Id like to copy this a bit if it works out.
Very interesting video, Lee. Do you plan to add control to the cross feed axis as well? Thanks for the great explanations.
Instead of using fixed values for the sleep functions, I suggest that you use variables. This would allow you to gradually ramp up and down the pulse rate near the end points, and provide better control of acceleration. The value of the sleep variable should be altered in relation to the pulse count.
In regards to the problems that you were having with I/O control, I suspect that you weren't using an optically isolated I/O card. Additionally, VFD's can produce significant EMI. Filters should be used on all wiring connected to the VFD, e.g. ferrite cores. Even without the limit switches, EMI can cause erratic and unpredictable problems with your Raspberry Pi. Shielded wiring should be used for connections to the I/O card and, depending upon the card, you may need pull-up resistors. I prefer running pins hi and bringing them to ground with the external switches. This arrangement tends to negate the effects of EMI.
Is your Harig a ballway unit? With the cable driven ballway, if you run it to the end of travel, you can actually force the wheel to keep going & the cable will slip on the drum underneath the table. It actually walks across the drum as the table traverses. The fact that you slowed it down, lets the table reverse without the shock & then start up in the opposite direction without slippage. You can tighten cable until it doesn't slip & then it binds & breaks the cable. (A master grinder taught me this so I wouldn't break mine). Just my experience.
Umm Lee, maybe I'm not visualizing this right, but... If you turned your stops around, it would be the spring pins in the way of the adjustment screws. Couldn't you just push the pin in and hold the un-sprung side to make adjustments?
You may want to add a “bounce” command for the switches. Maybe?
Do you have pull up resistors on the switch inputs?
Did you have your oil pump running when you did these tests?
The usual solution to gthe missing steps issue is to use a trapezoidal velocity profile limiting the maximum acceleration.
What programming language are you using?
Python
👍🏻
Thought this was fabrication and nachining channel not a computer one.
Obviously there can be considerable overlap these days. Fabrication and machining can present opportunities for using automation. Hence projects like this are, for many of us, perfectly within scope. And if you're not interested, it's pretty easy to just move on to another video..
Since you've come this far, why not add a ramping function so that acceleration and deceleration are not instantaneous and are set to occur over a defined number of motor steps? The current approach looks (and sounds) 'jerky' because you increase/decrease steps/unit time in a single increment rather than a short series of increases or decreases.