Up to now I workes with the Colorfabb PHA/PLA mix. It's very accurate and thus I found it to be very reliable. (Their shipping options of DHL-Express and UPS are a mess. Both are pure Business2Business courier services and are not fit for delivering to home addresses AT ALL.)
Now I ordered 4 large spools of the new nGen filament to use with mechanical parts.
It's supposed to be even more reliable and that's my primary criteria.
I'm also upgrading my Ultimaker II extended with an Olson block, a set of nozzles and a steel nozzle.
I hope to be able to do thinner layers with larger nozzles (at the same, minimum flow rate) and finer horizontal detail with finer nozzles as well as give copper-fill a try with the steel nozzle.
ABS
I also ordered a front door for the printer to try ABS and Acetone smoothing for non-mechanical parts that require a perfect surface finish.
I'm planning on building a large robot arm using stepper motors.
It shall execute G-Code with absolute, cartesian coordinates.
The job it so assist with some repetitive tasks in the workshop when casting small batches of parts that for quality, material or number can't be 3D printed individually.
As with all my blog postings, I'll keep updating this one.
It documents one, single project in all (public) details and all findings as I progress.
Start Small
To start small, I got myself a laser cut hobby-servo driven robot arm and attached it to an Arduino Uno with my usual LCD+Keypad Shield.
The objective is to get my inverse kinematic calculations right and to see how much can be acomplished with this much simpler setup already.
I also wish to experiment with absolute posistion feedback by attaching and ADC channel of the Arduino to the potentiometers of the hobby servos (maybe using a multiplexer to get all of them).
Hobby Servo issues
So far I identified a number of issues with hobby servos, that I want to document here:
Power supply
Running the Arduino from USB you only have enough power for 1 servo.
Adding a 12V 1.5A power supply for the passive step-down DC-DC-converter of the Arduino Uno is enough for 2 service. Only the 12V supply works for 1 servo only.
The path to go seems to be a 5V supply powering the servos only, pulled to a common ground with the Arduino (so the PWM control signal has the right right voltage level).
If the display gets dark, the servo motion jerky, the software resets of ommits steps, then you are lacking power.
Jerky movement
The default servo.h that comes with the Arduino SDK allows for an integer of 0-90 (degrees).
This isn't a very fine control.
I found in this blog posting that:
It also assumes minimum and maximum PWM timings that are beyond the range of many servos.
You should set minimum and maximum milliseconds in the attach() call and use the servo.writeMicroseconds(int milliseconds) call with 1000-2000 ms. This allows for a much finer control and stays within the allowed range for your servos.
G-Code interpreters
I'm currently evaluating options for g-code interpretation.
What I want is the g-code to contain X,Y,Z coordinates, gripper opened/closed and interpret a number of micro switches as probe inputs or end-stops.
GRBL on an Arduino seems to be a common option but is limited to 3 axis, drives the Arduino at the absolute limit of it's capacity and only has a serial/usb-serial connection.
A Raspberry Pi CNC-Head is a GRBL-running, Arduino-compatible Atmel board as a shield for a Raspberry Pi. For 3 axis maximum this would be a simple solution.
I'd rather go with a Raspberry Pi that can be trontrolled via Ethernet and communicate with other machines to coordinate and integrate. E.g. tell another robot that it has placed an item or be informed that there is one of multiple possible things to be picked up and moved.
I found the L6470 dual-stepper controllers. Simply calling them stepper drivers is wrong because they do their own timing, support microstepping, take end-position, maximum speed, acceleration+decelleration as inputs, support a hard-stop input directly, have a number of safety checks in there,... and work via SPI. Even daisy chained, so multiple axis stay in sync.
(Simple "stepper drivers" just take DIR+STEP input pins.)
Of that that still needs the actual interpreter -part.
I'll have a look at rs274ngc . It seems to be the old base for the EMC g-code interpreter.
My manipulator is a fairly standard gripper design that has been modified to perfectly grip one specific type of container.
Nothing special about it, except that I was too lazy to design proper gears and thus am simply using 3 9g servos opposing each other. Each gets the same signal and each moves one side of the gripper.
These things cost about 1.20eur, so I don't bother with the time to save one.
Y+Z axis (arm)
I'm definately going for an arm-type that always keeps the tool horizontal automatically.
That means less degrees of motion and thus more stiffness. (And less things to worry about.)
I'm also opting for maximum stiffness and am using bearings everywhere, so the arm stays accurate and lasts for a great many moving cycles without any wear and with little resistance.
For the attachment to the stepper motors, I'm thinking of using this:
The arm is not to have a rotational base but slide along a table-edge.
Linear motion systems for >=3m length are hard to find, so I'm thingking about having it drive between 2 aluminium profiles using tracks.
The last update for the Tapatalk forum reader software now needs the ACCESS_COARSE_LOCATION permission. Obviously for reading web-forums there is absolutely no need for this information.
No
Android except CyanogenMod with special privacy settings for this one
app or Android 6 with as-of-yet unknown required settings would even ask
the user. Let alone allow the user to disable location access in the first place.
So almost all users out there will just have their coarse location inquired and handled without even knowing about it, without their consent and with no requirement to provide this information for the functioning of the app whatsoever.
Aparently
it requests the location every time the app starts, a fragment becomes
visible and when the app ends without any visible feature using the
information.
Here is the answer from Tapatalk support:
Thanks for contacting us. Location data is not required, and you have the option to not provide location data.
You
can also change your location permission by going to Settings>Scroll
to bottom to the apps and select Tapatalk>Location. You can change
the setting to Never. (Remark: This only exists in CyanogenMod)
All information collected is non-Personally Identifiable Information.
