You aren't wrong :tired:Quote:
Originally Posted by peteeng
Printable View
You aren't wrong :tired:Quote:
Originally Posted by peteeng
After several weeks of slow/no progress (because life is like that), the welding on the base truss is finally complete:
Attachment 480382
Attachment 480384
Attachment 480386
Although it is very stiff, it also has very low damping. Rings like a bell. On the plus side, the lowest resonant mode is above 100Hz, somewhere around 120Hz or so. We're thinking about sand in the two main tubes to add a bit of damping.
Next steps - we took measurements for correcting the straightness of the master rail - details in another post soon. While I'm working on that and the rails are off the base my buddy is planning to get a coat of paint on it.
Looking for opinions for the long axis drive method. Rack and pinion or ballscrew with rotating nuts? Ballscrews would be a few hundred dollars more. Haven't done the detailed design yet to estimate which is more work. Ballscrew only needs supported at the ends rather than along its whole length, which is an advantage, but the rotating nut mechanism is probably more machining than the gearbox mount for rack and pinion.
Hi JMK - Good progress. Light structures and slender structures vibrate. Just because they vibrate when you strike them does not mean they will vibrate in service. Many of these vibs will not affect the performance of the machine just means the machine will sing its own song. I would not second guess these and fill with sand or anything until the machine is in service. If vibration is an issue solve it then. Light machines have many acoustic vibs that don't affect the cut. A lot of vibs come from the motors so use damp materials for the mounts.
R&P vs rotating nut RN: RN is more complex but due to a preloaded nut no backlash. R&P will have some backlash. Have you done the numbers on std stationary nut? Since you are on the economy side of the equation I think you will find R&P is your answer. Plus its less complex. If you build your own RN it may not turn out how you expected. Peter
Good advice. Should still be able to add sand later.Quote:
Originally Posted by peteeng
Looking at 2.8 or 2.9 meter long screws, so rotating screw would probably run into whip problems. I haven't done the math yet to see what critical speed would be.Quote:
Originally Posted by peteeng
I have built a rotating nut before, for a quill drive on a 3-in-1 lathe/mill/drill. In that case, the rotating nut was mounted to the machine head, and the non-rotating (but translating) screw was attached to the quill using a banjo, see below. In that case the reason was clearance and travel, not whip...
Attachment 480396
Rack & Pinion candidate: https://www.ebay.com/itm/294594387439 (two sets needed) with a 10:1 planetary gearbox between stepper and pinion
Ballscrew candidate: https://www.ebay.com/itm/143428535452 (contains two screws and nuts) with a roughly 2:1 belt reduction from stepper to nut
Attachment 480484
Chevy Engine Orange
Very Cool!! Peter
It's been quite a while since I posted an update on this build. We've made a lot of progress (but also had a lot of delays). One big delay: the shop we are building in is part of Ingenuity Cleveland's collaboration space. They have a big festival every September. We spent June thru September getting ready for the festival, and for the last half of September and first week of October the entire shop was forklifted away into storage. But things are moving again. Going to try to get this thread caught up, but it will take several posts.
Back in May we had completed the main truss frame but needed to make adjustments so that the linear rails would be straight. We had a plan for the adjustments (the previously mentioned shims and shelves), but needed a reference for straightness. I considered several options:
- Precision level - walking a level step by step. Can only do vertical, would have to set the frame on its side to do the horizontal. Also very time consuming and fussy work.
- Autocollimator - Can do both horizontal and vertical but still a time-consuming and fussy step-by-step process. Hard to come up with a stable mount for the instrument.
- Straightedge - My longest precision straight edge is 48". We needed 118".
- Alignment Telescope - Don't have one of these, and didn't see any inexpensive candidates on ebay.
- Laser - Pro gear is out of reach expensive. Homebrewing something with a laser pointer seems to be limited to about 0.01" accuracy rather than the 0.001" or better that we're aiming for
- Taut wire and traveling microscope - Cheap, relatively simple. Need to compensate for sag, that is just math. Need a traveling microscope, but decided to give it a shot.
I got a couple of cheap ($15 delivered) M12 USB cameras from ebay. Made a 3D printed housing with an opening in the center for the taut wire. One camera looks at the wire from the top, the other from the side. Opposite both cameras is a piece of white translucent plastic as a background, backlit with bright green LEDs to minimize the impact of stray light. The wire shows up as a very dark line across a very light background, which makes image processing pretty straightforward.
Attachment 487968Attachment 487970
I wrote some Python software using openCV to find the pixel location of the wire in each row of pixels, then average all the rows to get a displayed value with sub-pixel resolution. The code (including the scaling factor) is on another computer, but it is something better than 0.001" per pixel.
For the first pass, we just held the camera against the rail mounting pads and took a reading at each pad.
Attachment 487972
As expected, the rail mounting tubes were far from straight. Something like 0.050"-0.075" of total curvature. I had to re-make some of the shims because my originals weren't thick enough. But we used the first pass data to roughly machine the shims and shelves, then mounted the rails. For the next round we mounted the camera assembly on one of the carriages and slid it along the rail taking a measurement at each mounting pad. That data is on my other computer; I'll make another post once I dig it up.
Hi JMK - very good gadget, This is quite marketable. Been looking for something like this for a long time. Peter
Not interested in marketing, but I'd be happy to share the 3D model for the camera housing (the photo is actually the first version, I've revised it a bit) and the Python software. Could dig it up this weekend.Quote:
Originally Posted by peteeng
(Edit)
Actually, the camera housing is in the cloud at OnShape, so here you go:
https://cad.onshape.com/documents/c4...1a0827a7beed2f
That is a read-only link but it's a public document, you can make a copy and then generate STL or whatever for free.
Here is the camera I used: https://www.ebay.com/itm/324450174888
Thanks for sharing the model!
Here is the python source code to calculate the wire centerline from the camera images. It is a single file 209 lines long (the first 50 lines are comments and instructions). I don't see a way to attach a text file to a post, so I'm just going to paste it below. If this is breaking a rule let me know and point me in the direction of a better way. Usage instructions are embedded in the code. To run it, make sure you have python installed, open IDLE (the Python IDE), then open the file and run from within the IDLE.
When you run it you will get one window for each camera. Each window shows the wire as dark on a light background. The calculated centerline is shown as a fine red line and the overall value is displayed in the lower left in pixels and inches (or mm, it is based on a scale factor that you supply). The title bar of each window shows the camera channel number (assigned by the operating system) and the axis (X, Y, etc). The windows are live; if you push the wire you will see it move and the numbers change on the fly. Below is a screenshot from when we were testing our master rail. The IDLE window is on the left (with blue text), the two camera windows are stacked on the right.
Attachment 488090
Code:# tautwire.py
#
# Copyright 2022, John Kasunich
#
# This program is free software: you can redistribute it and/or
# modify it under the terms of the GNU General Public License as
# published by the Free Software Foundation, either version 3 of
# the License, or (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# DESCRIPTION:
#
# This program uses cheap webcams to look at a taut wire straight
# line reference and calculates where the center of the wire is
# relative to the cameras.
#
# Tested on windows 7 running Python 3.7, might need tweaked for
# a different OS or Python version.
#
# Must have OpenCV-Python installed (this is a one-time operation)
# Type "pip install opencv-python" on the command line to install
#
# It was developed and tested using these cameras:
# https://www.ebay.com/itm/324450174888
# but will probably work with others if you tweak things
#
# I mounted the cameras in this 3D printed housing:
# https://cad.onshape.com/documents/c4...d73439c1815c3c
# but anything that holds the cameras steady and provides
# an evenly illuminated background should work
#
# HOW TO USE:
#
# edit this file as noted below to select cameras, axes, scale, and filename
# look for "EDITME" in the file
#
# run the program and see the camera views on-screen
#
# push the wire lightly in each direction to see which camera responds
# and confirm that the scale factors (including their sign, +/-) make sense
#
# once running you can simply read the wire shift from the screen, or
# hit 'p' to print the current values to the CSV file
# hit 'r' to reset the sample number in the CSV file to zero
# and print a new header line - useful for doing multiple runs
# hit 'q' to quit
# ---------- program starts here ----------------------------
# import the packages we will need
# in this case the key ones are opencv (for image processing)
# and tkinter for display
#import os
#import sys
import tkinter as tk
from tkinter import ttk
from tkinter import messagebox
#pip install opencv-python to get this
import cv2 as cv
from collections import namedtuple
# a function to put a window in the foreground
def focus(self):
# make the window open in the foreground
self.lift()
self.attributes('-topmost',True)
self.after_idle(root.attributes,'-topmost',False)
# and active
self.after_idle(root.focus_force)
# datatype for channel info
ChannelDef = namedtuple("ChannelDef", "channel axis scale")
channels = []
# EDITME
# define the camera channels you want to use
# windows seems to assign the channel numbers somewhat arbitrarily,
# it may depend on what order you plugged in the cameras
# edit the "channels.append" lines below as needed for your system
# first item (number) is the camera channel number, will need to trial-and-error it
# second item (string) is the axis ID for display and CSV file
# third item (number) is the scale factor in inches (or mm) per pixel
channels.append(ChannelDef(3, "X", -0.000378))
channels.append(ChannelDef(2, "Y", 0.000355))
# EDITME
# change this filename if you want
# each run appends data to the end of the file
# rename the file (when program is not running) to save for later
# or delete it to start fresh
csvfile = open("camera-data.csv","a")
csvfile.write("program start\n");
# open the camera devices
Camera = namedtuple("Camera","cap index window axis scale")
cameras = []
for chan in channels:
camera = Camera(cv.VideoCapture(chan.channel, cv.CAP_DSHOW), chan.channel, "camera "+str(chan.channel)+":"+chan.axis, chan.axis, chan.scale)
if not camera.cap.isOpened():
print("cannot open camera "+str(chan))
else:
cameras.append(camera);
print("camera "+str(chan)+" opened")
print("fps: "+str(camera.cap.get(cv.CAP_PROP_FPS)))
camera.cap.set(cv.CAP_PROP_FPS,10)
print("fps: "+str(camera.cap.get(cv.CAP_PROP_FPS)))
print("axis: "+camera.axis)
print("scale: "+str(camera.scale))
print ("all cameras opened")
# camera setup complete
values = {}
samplenum = 0; #forces print of header to csv file
# this loop runs until the user hits 'q', processing one
# frame each time
while len(cameras) > 0:
# Capture frame-by-frame
for camera in cameras:
ret, frame = camera.cap.read()
# if frame is read correctly ret is True
if ret:
# Our operations on the frame come here
# split into blue/green/red channels
b,g,r = cv.split(frame)
# these cv.imshow() lines display intermediate results for debugging
# leave them commented out unless you really need them
#cv.imshow("red",r)
#cv.imshow("green",g)
#cv.imshow("blue",b)
# blurring the image a bit allows for sub-pixel resolution
# this uses the green channel since I have green backlights
blur = cv.GaussianBlur(g,(7,7),0)
#cv.imshow("blur",blur)
# apply threshold to make a pure black and white image
ret, bw = cv.threshold(blur,127,255,cv.THRESH_BINARY_INV+cv.THRESH_OTSU)
# cv.imshow("b/w",bw)
sum = 0
count = 0
# compute the center in each horizontal row of pixels
# read opencv docs if you want to understand the altorithm below
for y in range(0,478):
slice = bw[y:y+1, 0:639]
M = cv.moments(slice)
if M["m00"] > 0:
center = int(M["m10"]/M["m00"])
# paint one red pixel at the centerline
# looking at the red line lets you see if it is doing something stupid
frame.itemset((y, center, 0),0)
frame.itemset((y, center, 1),0)
frame.itemset((y, center, 2),255)
sum = sum + center
count = count + 1
if count > 0:
# calculate the overall centerlne
center = sum / count
offset = (center-320.0)*camera.scale
values[camera.axis] = offset
center = round(center,1)
offset = round(offset,4)
# paint the results in the corner of the image
frame = cv.putText(frame, str(center), (20,400),cv.FONT_HERSHEY_SIMPLEX,2,(0,0,255),thickness=4)
frame = cv.putText(frame, str(offset), (20,460),cv.FONT_HERSHEY_SIMPLEX,2,(0,0,255),thickness=4)
# Display the resulting frame
cv.imshow(camera.window, frame)
else:
print("Can't read from camera "+str(camera.index))
break
# the rest of this handles the CSV file
if samplenum <= 0:
#print header line
csvfile.write("Sample")
for axis in values.keys():
csvfile.write(","+axis)
csvfile.write("\n")
print("Sample", end="")
for axis in values.keys():
print(","+axis, end="")
print()
samplenum = 1
keypressed = cv.waitKey(1)
if keypressed == ord('r'):
# reset command
samplenum = 0
if keypressed == ord('p'):
# print command
csvfile.write(str(samplenum))
for value in values.values():
csvfile.write(","+str(value))
csvfile.write("\n")
print(str(samplenum), end="")
for value in values.values():
print(","+str(value), end="")
print()
samplenum = samplenum + 1
if keypressed == ord('q'):
print("shutting down")
break
# When everything done, release the capture
for camera in cameras:
camera.cap.release()
csvfile.write("shutting down\n")
csvfile.close()
cv.destroyAllWindows()
print("done")
Hi JMK - You can attach as word file or zip any file. If you use the advanced menu (below right side of box) you can add txt files... Peter
Using the "code" option seems to have worked nicely. You can scroll thru the code, indentation is preserved, and you can copy/paste it out of here and into a file for use.Quote:
Originally Posted by peteeng
Getting back to our specific machine...
The left rail (as seen from the front of the machine) is the master rail. As mentioned before, the first pass measurements were made by just holding the camera housing against the rail mounts. The result was a deviation of about +/-0.023" (+/-0.6mm) vertically and +0.110" (+2.8mm) horizontally. The graph below shows the initial measurements.
Attachment 488092
After processing the data and rough-machining the shims and shelves, we installed the rail and mounted the camera housing on one of the carriages.
Attachment 488094
The mounts at each end are adjustable in two axes so that the wire can be centered in the camera at either end of the rail.
Attachment 488096
The wire is 0.016" piano wire from McMaster Carr. We hung a 35 pound barbell weight from it so we would have a known tension for the sag calculation.
Attachment 488098
We wanted to check repeatability so this time we made two passes down the rail. On the first pass, we recorded the position every fourth rail mounting hole (four holes = 320mm = 12.6"), where our rail mounts are located. On the second pass, we recorded the position at every hole (every 80mm). The graph below plots the second pass as a solid line, and the first pass as diamond markers. The diamonds line up very well with the solid line, showing that the system is repeatable. Note that the vertical scale on this graph is 10 times more sensitive than the previous graph at 0.001" per division; the rough machined shims and shelves dramatically reduced the error in the rail.
Attachment 488100
Using the second set of measurements we took the shims and shelves back out and tweaked them a bit. Reassembled and measured one more time. Results below, still at 0.001" per division. We still have a couple of "bumps" in the vertical dimension, at the 320mm and 1920mm rail supports. Once the machine is closer to finished we will probably re-do these measurements one more time and tweak a bit but we're calling it good enough for now. This is a wood router, not a precision milling machine.
Attachment 488102
With the master rail "good enough", it was time to move on to the secondary rail. For that rail, the goal is not just "straight", but instead "parallel to the master rail". So we didn't use the camera and taut wire. Instead we cobbled together a rather janky arrangement of measuring equipment.
We started with a temporary "gantry", just a length of steel tube attached to the car on the master rail. It stretched across the table and was supported on the far end by a long vertical bolt that bears on the top edge of the slave car. We added a dial indicator mounted near the bolt and also bearing on the car. With my precision level (0.00025" per foot) on top of the gantry, we can use the long bolt to level the gantry and the indicator to take a reading. Then move both cars down the axis a bit, re-level the gantry, and take another reading. As long as the gantry is kept level, the indicator gives the vertical error directly.
Attachment 488104
For the horizontal error things are even simpler. We just attached an indicator to the end of the gantry with its probe bearing on the outside face of the car. If the rails move further apart the indicator reads higher.
Attachment 488106
The first pass readings showed about 0.060" of vertical deviation and 0.080" of horizontal. As before, we rough machined the shims and shelves accordingly and reinstalled the rail, then took another set of readings. With the exception of one point that is 0.005" high, we are within +/- 0.003" or better of parallel. We want better, but the jury-rigged measurement system isn't rigid enough for more accurate work. We're going to re-visit these measurements once the real gantry and carriages are in place. We'll unbolt one end of the gantry and use an indicator to measure the in/out movement, while the level checks the vertical. The graph below shows "before" (dashed) and "after" (solid) data.
Attachment 488108
Janky or not as long as it works!