Raspberry Pi based 4 axis controller
Posted by mrwolfe
|
Re: Raspberry Pi based 4 axis controller October 03, 2015 08:21PM |
Quote
mrvn
Hi,
I'm toying with the idea of building a 3D printer that has a graphical display for more options on what to display, networking to avoid the hassle with usb sticks or sd cards, live video so I can watch the printing while I'm cooking in the kitchen and maybe include the slicer. A Raspberry Pi might provide all that.
The Pi has the capacity to do USB, LAN, HDMI, camera, LCD and web interface, as well as WiFi, and Bluetooth with additional hardware, but from experience it's very slow for slicing.
Quote
mrvn
Quote
mrwolfe
Extra pins are an issue because the GPIO only has 21 pins plus SPI (which can be 5 GPIO pins or SPI but not both) and ID (which can't be used for anything except the device ID rom). Extra dIscretes can be added via an expansion board. Again, everything can be added but the size and cost goes up.
How many pins do you use so far? I see the need for at least:
4 X Axis: X_STEP_PIN X_DIR_PIN X_ENABLE_PIN X_MIN_PIN
4 Y Axis: Y_STEP_PIN Y_DIR_PIN Y_ENABLE_PIN Y_MIN_PIN
4 Z Axis: Z_STEP_PIN Z_DIR_PIN Z_ENABLE_PIN Z_MIN_PIN
3 E Axis: E_STEP_PIN E_DIR_PIN E_ENABLE_PIN
2 Extruder: HEATER_PIN TEMP_PIN (analog)
=
17 Pins
That would leave 4 + SPI or 9 pins free. If all ENABLE pins are connected together that would save 3 pins. Adding MAX_PIN for each axis would use 3 more pins.
The current list is:
X, Y, Z, E motors: 8 pins plus 1 for enable (my initial design had 3 pins per motor)
Bed, Fan, Extruder : 3 pins
Endstops: 6 pins
Interrupt Tick: 1 pin
Spare: 2 pins (so, yes, a 5th motor channel is possible)
Not sure whether the interrupt tick will be necessary. The idea is to use a 10ms (or whatever) pulse generated by an on board circuit as an RTC interrupt (The Pi has no RTC). It may be possible to impliment this in software, expecially for a bare metal implimentation which could dedicate one of the system timers to it.
Quote
mrvn
With 4 pins there isn't enough space for a second extruder. Unless some pins could be reused or multiplexed. Ideas:
- Only one extruder is used at a time
shared E_STEP_PIN and E_DIR_PIN and tristate E_ENABLE_PIN (0 = left, 1 = right, float = off)- Z Axis movement is done only inbetween layers (when extruders aren't used)
shared E/Z_STEP_PIN and E/Z_DIR_PIN, 2 pins E1/E2/Z select
Not bad ideas. There are 2 spare pins ATM that could be used as select lines. Taking this idea to its logical conclusion, you could multiplex all of the motor control lines e.g Common Step, Direction, plus 7 enable lines for 7 motor channels. Only problem is that only one motor can be driven at a time. Another possibility is to have seperate X and Y channels with all the others multiplexed i.e
XDir, XStep, XYEn
YDir, YStep
CDir, CStep, EN1, EN2, EN3, EN4 (assuming the 2 spares are used as well)
Of course, squeezing all of this into a small space is challenging.
I have also started thinking about a version that uses SPI to talk to all of the drivers. That would free up a lot of GPIO pins, allow an almost unlimited number of output channels and possibly make the whole thing simpler - everyhting is done via SPI except the limit switches.
Quote
mrvn
Support for 2 extruders and heated plate with the extruders multiplexed by a tristate pin would come to a total of 21 pins by my count.
And how do you handle the analog TEMP_PINs? Unlike an Arduino the Raspberry Pi has only digital inputs. I assume you have some 8 channel AD converter chip?
Yep, I have am MCP3008 connected to the SPI port. Because it's an 8 channel A/D (I COULD have used the 4 channel MCP3004, they are about the same price) I have 4 thermocouple channels and 4 extra analog input channels. The required sample rate is not high, and the extra channels add a bit of versatility.
Quote
mrvn
Quote
mrwolfe
I've just remembered the OTHER reason that I kept the board size down. I cut the board down and did quite a bit of squeezing because if it gets any bigger it goes into the next size range and gets more expensive.
The prices I have for etching boards have 50mm x 50mm and 100mm x 100mm price classes (50mm x 100mm costs the same). Your board is 100mm x 70mm. So there would be room for an extra 30mm width at no price.
Seeed studio, I presume?
Quote
mrvn
Quote
mrwolfe
Oh, BTW, I could really use some help with the software. Anyone out there have any experience writing kernel mode drivers in a realtime linux environment?
I might be interested in writing a linux driver for the board or go one step lower and work bare-metal. Obviously it would help to have a board to play with. Do you have a spare board or could you provide schematics, layouts and parts list? Will your board be GPL like the RAMPS?
I'm planning to go mostly GPL, although I'm also hoping to make a little money from it as I'm currently unemployed (It's a problem when you're an Aerospace engineer in a city where there is no Aerospace industry left), I have some prototype boards and I can sent you one if you're willing to help.
At this stage, I think a RT kernel module to handle the stepgen and I/O would be the thing to aim for. Once the kernelspace side is in place the userspace side is open for all to play with. I'm thinking along the lines of a kernel module with the highest priority that just takes step commands from a buffer and outputs them to the port with minimal translation. The conversion from GCode to step commands could be done in userspace (with RT priority) as long as the buffer is big enough.
Quote
mrvn
As for the $50 price have you seen [www.banggood.com] ? Would be cheaper to connect that to a Raspberry Pi via USB and use that as display + network controller and slicer. But half the fun is in building this yourself.
Yes, RAMPS stuff is getting cheaper all the time. I was looking at Photon Elephant a while ago, but they seem to have dissapeared into a hole somewhere. Photon Elephant was also WAAAAY too expensive, as well as being big. One of the reasons for going the way I have is to keep the whole thing in a neat, compact package that can be used as a network connected 3D printer, a robot, or anything else that you can think of.
Connecting a RAMPS to a Pi via USB is certainly cheap (already done that), but I kind of like the idea of a single unit instead of having cables all over the place. As for the price, I'm pretty confident I can get it down to about the same as that RAMPS kit, but I'll need to do it in volume to get there.
|
Re: Raspberry Pi based 4 axis controller October 10, 2015 02:14PM |
... sure! - this was a simple first test with the Arduino IDE and "analogWrite()", so could be highly optimized with a more hardware specific code 
here is the used test-code - some of the functionality is only there to simulate load, the serial output is for some sort of logging while testing:
Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]
Call for the project "garbage-free seas" - [reprap.org]
here is the used test-code - some of the functionality is only there to simulate load, the serial output is for some sort of logging while testing:
myFile = SD.open("datalog.txt");
if (myFile) {
Serial.println("datalog.txt:");
// read from the file until there's nothing else in it:
char SDbyte = 0;
starttime = millis();
while (myFile.available()) {
linenumber += 1;
SDbyte = myFile.read();
if (buttonPin){
//analogWrite(analogOutPin, SDbyte);
analogWrite(A0, SDbyte);
//digitalWrite(ledPin, HIGH);
//digitalWrite(ledPin, LOW);
//analogWrite(A1, 255);
//analogWrite(A1, 0);
if (SDbyte<255){
ttime = millis() - starttime;
Serial.print(linenumber);
Serial.print(": ");
Serial.print(SDbyte, DEC); //HEX);
Serial.print(" - ");
Serial.print(ttime/1000);
Serial.write("\n");
}
}
}
// close the file:
myFile.close();
Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]
Call for the project "garbage-free seas" - [reprap.org]
Sorry, only registered users may post in this forum.