New firmware for printing directly from the Raspberry Pi's GPIO pins

I got my Mini Kossel up and running, and the electronics (A4988 stepper drivers, fan, hotend, etc) are controlled directly from the Raspberry Pi's GPIOs - no arduino or RAMPS, etc.

Here's a demo video: http://youtu.be/g4UD5MRas3E

And here's a link to the open source firmware: https://github.com/Wallacoloo/printipi/

As it stands, it's mostly a proof-of-concept; a Raspberry Pi may be capable of doing the same tasks typically handled by a dedicated microcontroller. It's not quite there in terms of step rate, but give this time.

That is great work. Do you have a real time OS running?

---

ConceptFORGE
Wally, GUS Simpson, LISA Simpson, THOR Simpson, Sextupteron, CoreXZ

Rather than a real time OS, I'm first going to try to use the memory streaming abilities ("Direct Memory Access", abbreviated "DMA") that the Raspberry Pi uses for transferring data between the cpu and its peripherals (like USB and Ethernet) in real time. It basically just copies a buffer of memory from one place to another at a (mostly) constant rate, regardless of what else the CPU is doing. In this case, the memory will be streamed from a buffer inside my program, which will be updated every few milliseconds, into the section of memory that controls the I/O pins.

This could potentially guarantee timing to the same, or even better degree, as a real time OS while also using less CPU. Initial testing looks promising, but if this doesn't work out then I'll likely take the route of writing a kernel module in order to handle precise timing instead.

That sounds promising. I will be interested to know what is the max stable step rate.

---

ConceptFORGE
Wally, GUS Simpson, LISA Simpson, THOR Simpson, Sextupteron, CoreXZ

This is really cool. Have you thought of using a Beaglebone Black? The PRUs would probably come in handy.

Nice proof of concept.


A Raspi B+ won't be able to do it but a BBB PRU just might. Neither the Rasp Pi or the BBB have been quite up to the task of being a dedicated slicer/controller in that they work but aren't near as quick as a standalone host. Where they work well is as a controller only using OctoPrint. As we see the embedded space mature boards like this will get more and more powerful. The nearest term thing I can see is the Arduino Pro where the AVR can still be used in addition to an ARM. That opens up many more possibilities to bridge the gap until the hardware and software are small enough and capable enough to encompass an all in one solution with the performance of a stand alone host and printer driver board combo.

I wasn't overly excited about this at first, but when I think about it, there seem to be a lot of RepRaps who's build cost is around $700 to $800, by knocking out the dedicated controller board, that takes out about $100 of it... I've heard from people that $500 is kind of a 'magic price' for the middle class to start adopting a new technology. Are there any printers that can use this to get comfortably below the $500 mark?

I seem to remember the Morgan being estimated almost exactly at $500 to build, but I'm not sure.

$200 is the comfortable bottom price of all the parts. After markup, $500 is a good lowend retail price for a stripped down machine. The RPi will just replace one thing with another thing of about the same cost. The benefit is that the RPi can also do all the things a computer can do.

---

ConceptFORGE
Wally, GUS Simpson, LISA Simpson, THOR Simpson, Sextupteron, CoreXZ

This is a great advance wallacoloo.

Please, let me know the schema to connect stepper drivers, hotend, etc. with RPi.
I have Printipi and octoprint installed.

Thanks

jesussiero,

I'm working on replacing the board containing stepper drivers, etc with a RAMPS-fd to make this less DIY, but for now, here's how the connections work:

Currently, lines 130-153 of Kossel example deal with the IO mappings. In general, each stepper needs to have its STEP and DIR pins connected to any GPIO on the Raspberry Pi. You can optionally wire the ENABLE pin of any of the steppers into a GPIO pin too. My setup has the 4 enable pins all share 1 GPIO.

For the hotend, you need a transistor and I believe you'll want the heating resistor wired from the transistor's emitter to ground, the transistor's base tied to your power source (eg 12 volts), and the collector connected to a GPIO pin. The fan can be wired the same way.

For the endstop, simply connect a 3.3v source to one end of the switch, and the other end of the switch should be connected to a resistor (between 1000 ohms and 50000 ohms) with that resistor then wired to a GPIO pin. The resistor is to prevent accidental shorts.

The thermistor is a bit odd, because the raspberry pi has no ADC. So I'm using an RC circuit, where I charge a capacitor and measure the time it takes to discharge through the thermistor. The circuit should be constructed like Figure 1 from this document (Note: I called their R1 "Ra"). Your Ra should be at least 300 ohms, but you probably don't want it higher than 1000 ohms, or else you won't be able to sense high temperatures. I'm using a 2.2 uF capacitor for C, but anything at or above 0.1 uF works fine. Larger capacitors give you more precision, but decreases the frequency with which you can measure when at a low temperature (e.g. < 50 C).

Once you have everything wired up, you have to tell Printipi which GPIO pins to use. This wiki page may help with the pin numberings. You should be able to work off of kosselpi.h and just edit the pin configurations. For example, if you have your A tower stepper motor with its STEP signal connected to GPIO pin 7, and the DIR signal connected to GPIO pin 8, then you would change this line:

A4988|RpiIoPin|mitpi::V2_GPIO_P1_22>, RpiIoPin|mitpi::V2_GPIO_P1_23>, _StepperEn>, //A tower

to

 A4988|RpiIoPin|mitpi::V2_GPIO_P1_07>, RpiIoPin|mitpi::V2_GPIO_P1_08>, _StepperEn>, //A tower

(replace | with a less-than sign - the forum won't let me type those). Pins are defined like this:

RpiIoPin|mitpi::V2_GPIO_P1_18, IoLow, mitpi::GPIOPULL_DOWN>

where the second two parameters are optional. The first parameter specifies the location of the pin on the raspberry pi board. The second parameter indicates the default value it should be set to when operating in an output mode, and the third specifies if the pin should internally be tied to a HIGH or LOW value when no other logic signal is present (useful, for example, to make an endstop automatically trigger if the connection is faulty). If you see something like InvertedPin|...>, then that means that all the logic-levels for that pin are inverted - if the pin is at 0V, then that should be read as HIGH, instead of LOW, and setting the pin to a high output should entail putting it at 0 volts instead of the supply.

Note that the pin numbers refer to the physical location of the pin, which is described on that elinux.org page (where it uses the notation "Pin XX" or "P1-XX" instead of GPIO XX) - top-left pin is pin #1, and bottom-right pin is pin #26 (or #40 if you have a model B+).

You'll need to also define some values for your thermistor. In kosselpi.h, there is a chunk of code that looks like:

#define THERM_RA 665
#define THERM_CAP_PICO 2200000
#define VCC_mV 3300
#define THERM_IN_THRESH_mV 1600
#define THERM_T0 25
#define THERM_R0 100000
#define THERM_BETA 3950

You shouldn't have to mess with VCC_mV or THERM_IN_THRESH_mV, but THERM_RA should be updated with the value of the resistor you used for Ra in your thermistor circuit, THERM_CAP_PICO reflects the value of the capacitor in that circuit, in pico-farads (2200000 pF = 2.2 uF), THERM_T0 and THERM_R0 and THERM_BETA should be specified on the product page from where you bought the thermistor, or its packaging. If for some reason you can only find the beta value, you can find T0 and R0 by measuring the ambient temperature and set that to T0 (or assume 25 C), and then measuring the resistance of the thermistor and set that to R0.

Finally, for calibrating, you'll want to locate and edit this chunk of code in kosselpi.h:

#define R1000 111000
#define L1000 221000
#define H1000 467450
#define BUILDRAD1000 85000
#define STEPS_M 6265*8
#define STEPS_M_EXT 30000*16

R1000 refers to the distance between the center of your build plate and the base of your tower in micro-meters. L1000 refers to the length or your rods connecting your end-effector to the carriages in micro-meters. H1000 reflects the height of your endstops above the build-plate in micro-meters (it is assumed your endstops are leveled). BUILDRAD1000 reflects the radius of your actual buildplate, in micro-meters. STEPS_M is the number of *microsteps* that are required to raise one of your carriages by 1 meter, and STEPS_M_EXT is the number of extruder microsteps that result in 1 meter of filament being pushed through your hotend.

Now to actually build the firmware, all you should have to do is navigate to the source directory and type `make MACHINE=rpi::KosselPi`. Then navigate to the build directory and type `sudo ./printipi` and then interact with your printer with g-codes (or you can use the Octoprint setup detailed on the Printipi github page). Note that you'll have to rebuild the project any time you edit the code - it doesn't automatically pick up changes or anything fancy like that.

I apologize that the process is a bit complex. I'll try to simplify and document it in the coming months.

Please don't leave your printer unattended if you're using Printipi - this is experimental software and I don't want to be responsible for house-fires or broken printers.

Best of luck & feel free to contact me if you need assistance.

Edit: The devel version of kosselpi.h has updated documentation that might be useful to reference.

Edited 1 time(s). Last edit at 11/14/2014 12:37AM by wallacoloo.

I spotted your project a few weeks ago and it looks very interesting, but I wonder why you have implemented the whole system from scratch, you could have created a driver and avoided dupilcating the TP and kinematics if you used linuxcnc.

I am very uncertain if there is any point in implemtenting anything on the raspberry pi as I have done a fair amount of surveys of developers that have interest in computer motion control and have not had any favourable interest, most people seem to think the arduino is a better system.

I think the beaglebone could be a better platform and I have started looking at getting machinekit working on that, but not got enough detail to think about buying a development board.

There are a huge number of minus points for the raspberry pi as I have been told that Repraps need 5volt tolerant controllers and all the work has been done already but is not suitable for reprap.

I did originally think the raspberry pi could have benefits as the vc4 gpu could be used for some of the openCV analysis required for future developments, but I have found that without step rates above 100kHz the exercise would be pointless and unfortunately once higher order kinematics and vision processing are factored in, the step rates possible drop rapidly with more than 9 axes. Also I was finding problems when running more than 6 thermistor pid loops, how many analog inputs can your system use?

Have you done any further work that could speed step generation as this is the main problem that people have found and maybe if someone cracks that problem then using the pi would be possible?

Edited 1 time(s). Last edit at 12/08/2014 06:25PM by mung.

Repraps do not need 5V tolerant controllers, in fact the more modern controller electronics (e,g, Duet electronics, or Arduino Due + RAMPS-FD) are 3.3V. That said, I am not sure that the RPi is an ideal solution, for example because it lacks ADCs.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42
Repraps do not need 5V tolerant controllers, in fact the more modern controller electronics (e,g, Duet electronics, or Arduino Due + RAMPS-FD) are 3.3V. That said, I am not sure that the RPi is an ideal solution, for example because it lacks ADCs.

I really do not want to tell you that its wrong but there are a large number of very very reprap users that have discussed this previously e.g. [forums.reprap.org]

I have been running linuxcnc on the rasperry pi since the summer of 2012 and have checked this forum on a number of occasions and been informed that there is no possibility it would work with reprap.

I know the problems with ADC as the linuxcnc ADC could only sample at 4MHz with 12bit res and had a latency buffer of 500us which is unworkable for reprap, I have not tried the method used by this standalone firmware system using capacitors maybe that could change things but I doubt it.

I think think we are both in agreement that raspberry pi will have problems with future developments, as I said getting step rates above 100kHz for more than 9axes means that the opengl gui becomes unresponsive and when running python plugins and multiple differntial PID loops from ADC that link into print speed feedback algorithms there is insufficient processing available unless the work is offloaded to the vpu.

Also cost is another aspect that is important to reprap and the overall cost of running a system with raspberry pi is higher, I actually looked into the cheapest possible systems, and it looked like $200 total cost for motors and controllers, and this is way above what other people could make a similar system for(edit some people could get the kit for $50 here [forums.reprap.org] ).

I suppose the pi does give a cheap networking connection and opengl live plot display, but that could probably be handled by cheaper systems just as well and avoid the poor licencing and closed source that the pi is based on.

People like keithsloan, and shadowram who I have been told work for the beagleboard developers have said the raspberry pi will never work and also the beaglebone is not ideal, unfortunately nothing is ideal unless you develop a system from the ground up for the specific reprap purpose. I have heard beagle will be releasing a new board soon that could be a better platform as it has pcie ports and 2GHz quad core, maybe when that is released.

I am still at the waiting stage to see if anyone else has ideas how to get higher step rates then I would be able to make a decision what to use as a controller.

Edited 1 time(s). Last edit at 12/09/2014 08:33AM by mung.

Quote
mung

Quote
dc42
Repraps do not need 5V tolerant controllers, in fact the more modern controller electronics (e,g, Duet electronics, or Arduino Due + RAMPS-FD) are 3.3V. That said, I am not sure that the RPi is an ideal solution, for example because it lacks ADCs.

I really do not want to tell you that its wrong but there are a large number of very very reprap users that have discussed this previously e.g. [forums.reprap.org].

No, I am not wrong. If you read that thread, you will find that a lot of the posts agree that that you can use 3.3V electronics. There are already 3.3V controllers being used to control 3D printers, such as the Duet.

The problem comes when you want to connect 3.3V electronics and 5V electronics together. For example, a standard 5V RAMPS board will not work with a 3.3V Arduino Due. Hence there is a separate 3.3V RAMPS-FD board. Similarly, a 5V LCD display controller board will not work with 3.3V electronics. Neither will a SevenSwitch work reliably with 3.3V electronics.

So using an RPi or other 3.3V microcontroller board is fine, provided that the stepper drivers and any other electronics you need to add to it to control your printer accept 3.3V signal levels at its inputs, and any signals from external electronics that you feed into your RPi use 3.3V signal levels (or you can use a couple of resistors to reduce the 5V signal levels to 3.3V). Stepper driver modules may be compatible with 3.3V signal levels, but high-current MOSFET switches (to drive the extruder heater and heated bed) generally need 5V unless they have been designed for 3.3V.

As for processing power, you really do not need anything like a 2.2GHz quad core processor to drive a 3D printer. There is nothing wrong with having excess processing power if it comes free, but it shouldn't be the determining factor. OTOH the 8-bit Atmega processors are rather short of power, and while it is still possible to use them for controlling 3D printers, the lack of processing power makes the firmware more difficult to write.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Hi mung,

The step rate used on this implementation is 250 kHz for each individual axis. That is, if you are running 9 axes, you can still make 250k steps per second on each one. It uses DMA (a hardware peripheral that is logically separated from the CPU) to do the step control so that it uses literally 0 cpu time. If you're careful to limit network/sd access, it's possible to push 400 kHz.

I avoided LinuxCNC because it looked intimidating, and I wanted to create a solution which wasn't intimidating. I know, I could probably have gotten LinuxCNC to work in a few days, but a simple userland program that works out-of-the-box on any Linux system is easier for newcomers. Furthermore, I wanted a non-GPL solution. I did heavily consider using aprinter, but its configuration system is an absolute mess, among other things, and I think it also required a gcc version that wasn't supported on the Raspberry Pi at the time. In hindsight, I probably should have just contributed fixes for the bits of aprinter that I didn't like, but I underestimated the complexity of starting from scratch.

Of course you can use 3.3V electronics. Ramps-FD is compatible with either 3.3V OR 5V (and will even automatically detect the desired voltage based upon an Arduino's IOREF pin) and it costs $20 from Geeetech. Raspberry Pi Model A+ costs $20. That's pretty comparable to the common Arduino + RAMPS combo. Additionally, my solution is aimed specifically to people who want to network their 3d printers. Currently, those people are taking their Arduino + RAMPS and connecting it to a networked Raspberry Pi via a serial interface. If the Raspberry Pi is capable of directly driving the motors, etc, then why not ditch the unnecessary Arduino?

Yes, I admit that the Pi is not the ideal solution. I have focused on making my software as generic as possible. I can compile and even run the software out of the box on any machine that has a C++11 compiler (gcc-4.6+), with the limitation that all IO operations are dummy operations. It does not even need to be running an operating system, so it can still be run on bare metal if you're targeting an MCU where the compiler will include the proper startup sequence for you. Fixing the dummy IO operations is as simple as populating a few files under src/drivers/xxx that are automatically detected by the build system. The goal was that as more appropriate boards surface, adding support for them should be a breeze and shouldn't require a fork of the firmware.

Lastly, I hear you saying "So and so says it can't be done" when there is direct proof in front of you that it IS being done (ie a video of both the Raspberry Pi 3d printing, and using 3.3v with stepper drivers & electronics). I don't even know how to respond to this. There is SO much misinformation in these forums propagated through this kind of "so-and-so said" logic.

Edited 3 time(s). Last edit at 12/11/2014 04:47PM by wallacoloo.

Hi,
I'm new here. I'm collecting info to build a diy cnc router using actual technology and i'm very interested in your project wallacoloo. I'm evaluating use of a board from odroid team (http://www.hardkernel.com/main/main.php). I was looking for odroid-u3 @ 65€, but i just noticed che newcomer odroid-c1, a 35€ board that definitively beats rpi.
What do u think about these products? There is compatibility with your software?
Thanks in advance

neverEnough,

You could get that device working, but you would have to implement hardwareinterface.h for the specific architecture (the Raspberry Pi implementation, for reference). If you're a competent coder and willing to devote a few days to the task, it's certainly doable. Given that it's a quad-core system, it's probably possible to claim one of those cores exclusively for your application, in which case step timing becomes much simpler since you don't have to worry about being preempted by the operating system.

Personally, I would recommend that you wait until the firmware matures a bit before trying to add support for another platform. Things are changing pretty rapidly right now. Also, according to hardkernel's website, the processor documentation won't be available until mid-January ("Amlogics S805 data sheet will be available in the middle of January 2015"), and I'm not sure how you could determine the procedure to control the GPIOs without that documentation.

hey wallacoloo,
thanks for your reply.
I'm totally new to cnc and makers world, i'm just an old linux user with some C++ experience (not related to hardware topic).
I've got a personal long term project and the first part requires getting some experience by building a cnc router from scratch (and *maybe* later convert it to a 3d printer, not mandatory). Delta design sounds interesting for that new tool in my garage (that's the concretization of first stage), but later probably i will require a different shape and a compact electronical hardware.
Printipi idea is exactly what i'm looking for a software, no limits on the controller side (when considering a higher board than rpi) and maybe less electronic magics when adding functional specs. Plus the pros by a direct link to IOT world (remote managing, smartphone links, eventually more sensors available detached to the Big Platform).

I won't wait odroid-c1 specs release to start buy and early tests, odroid-u3 is a mature platform with a nice optional shield ( [hardkernel.com] ) with schematics ( [hardkernel.com] ). Unsure if 16 gpio are enough for a complete mini kossel, i still got to build my first robot and understand all the pieces.
There is already at least one working example with odroid-u3 and shield:
U3 based Quad-Rotor ( [forum.odroid.com] )

Quote

we use the Odroid U3 to control a quad-rotor (no microcontroller-based flight control, just plain Linux control code).
As a Linux distribution on the ODROID we use Gentoo, and of course our quadrotor natively compiles all of its software (kernel, userspace)

Those unwillig to explore this approach in machines are just binded to the past, that's the future (even if their arguments may sound reasonable).

I've peeked into printipi but i must go further.
Since this is reprap forum, have u got/planned an other place to stay in touch with people? A mailing list perhaps?

neverEnough,

16 gpios is cutting it really close for even a stripped-down 3d printer. I don't know much about CNC machine details, but the minimum you'll want for a 3d printer is step+direction lines for 4 stepper motors (each axis + extruder), 1 pin for a fan directed near your hotend, 1 pin for powering the hotend + 1 (preferably analog) pin for reading the hotend temperature + 3 endstops (1 for each axis). That alone brings you to 14 gpios, and then you're limited in regards to adding a bed-probe, heated bed, a second extruder, or the ability to activate/deactivate the stepper motors. 16 gpios is by no means impossible - it just depends on what features you're looking for.

In regards to a mailing list, I set up a public google group for general discussions related to Printipi.

Hope your project goes well!

Quote
wallacoloo
Hi mung,

The step rate used on this implementation is 250 kHz for each individual axis. That is, if you are running 9 axes, you can still make 250k steps per second on each one. It uses DMA (a hardware peripheral that is logically separated from the CPU) to do the step control so that it uses literally 0 cpu time. If you're careful to limit network/sd access, it's possible to push 400 kHz.

I avoided LinuxCNC because it looked intimidating, and I wanted to create a solution which wasn't intimidating. I know, I could probably have gotten LinuxCNC to work in a few days, but a simple userland program that works out-of-the-box on any Linux system is easier for newcomers. Furthermore, I wanted a non-GPL solution. I did heavily consider using aprinter, but its configuration system is an absolute mess, among other things, and I think it also required a gcc version that wasn't supported on the Raspberry Pi at the time. In hindsight, I probably should have just contributed fixes for the bits of aprinter that I didn't like, but I underestimated the complexity of starting from scratch.

Of course you can use 3.3V electronics. Ramps-FD is compatible with either 3.3V OR 5V (and will even automatically detect the desired voltage based upon an Arduino's IOREF pin) and it costs $20 from Geeetech. Raspberry Pi Model A+ costs $20. That's pretty comparable to the common Arduino + RAMPS combo. Additionally, my solution is aimed specifically to people who want to network their 3d printers. Currently, those people are taking their Arduino + RAMPS and connecting it to a networked Raspberry Pi via a serial interface. If the Raspberry Pi is capable of directly driving the motors, etc, then why not ditch the unnecessary Arduino?

Yes, I admit that the Pi is not the ideal solution. I have focused on making my software as generic as possible. I can compile and even run the software out of the box on any machine that has a C++11 compiler (gcc-4.6+), with the limitation that all IO operations are dummy operations. It does not even need to be running an operating system, so it can still be run on bare metal if you're targeting an MCU where the compiler will include the proper startup sequence for you. Fixing the dummy IO operations is as simple as populating a few files under src/drivers/xxx that are automatically detected by the build system. The goal was that as more appropriate boards surface, adding support for them should be a breeze and shouldn't require a fork of the firmware.

Lastly, I hear you saying "So and so says it can't be done" when there is direct proof in front of you that it IS being done (ie a video of both the Raspberry Pi 3d printing, and using 3.3v with stepper drivers & electronics). I don't even know how to respond to this. There is SO much misinformation in these forums propagated through this kind of "so-and-so said" logic.

Thanks for the reply wallacoloo, very interesting thoughts and some I agree and some disagree, I think you have done some excellent work but not sure it is 100% working, have you done any large scale tests on the system?

I sort of agree and disagree with you about direct proof, just because you have a video showing motors moving does not mean that the motors will run perfectly without lost steps over a long varying workload.

I have had the pi running stepper motors from linuxcnc for about 3 years, but there is a big difference between running motors with zero lost steps or timing offsets and having something that does not. As far as I am aware timing accuracy is very important to stepper torque, minute mistiming at highspeed can mean lost steps and misalignment and a ruined print.

I have been running DMA drivers with linuxcnc for over 18months and it seems to print out all the tests with no problems, but I would not like to trust the system with full testing and analysis of the low level signals. I have had many people saying that it will never work, but I do not like to argue without good quality empirical test data, and have no way of verifying the system as I do not have the equipment. If you think others are just propagating misinformation then you must disprove them by producting quality experimental data. I have had many people quoting technical manuals and text books, and I never read any of them because I have learned the engineering and physics already at university, I do not want to start giving you references to read that would be pointless as I can see you obviously know the subject well, and motor mechanics is actually of little relevance to a software and timing problem.

I suppose what I am saying is I would like to see some quality signal analysis tests of the system over a few hours with different programs running on the pi to give stress tests as I know there are some very strange things going on in the pi firmware that could effect timing.

I have not really looked closely at your code but am assuming that you are using interupts to set timout when a gpio change should occur which is slightly different to the system I was using for linuxcnc, seems you use a lot less control blocks per pwm switch interval as I had to use 7 blocks per time division in order to circumvent some of the vc4 timing problems. You are right about networking and SD access but I think there are also other factors that can come into play over much longer time scales. There are solutions but they require more processing and slow the system in other ways.

Also as far as 3.3volt/5volt you are pushing specs outside ratings, and this is okay as a hack but there is no way you can put out a commercial product on something that does not meet specs it would fraudulent, and I have previously been taken to task by the admin for suggesting people cut corners to save money, who is then responsible if someone burns down their house?

As I said I dislike bothering to argue with people unless I have tested proof, I prefer to let them continue to know they are right, and as the admin of this site seem to remove any posts where I disagree with others I do not think it worth going any further.

As I said you have done good work with the driver, and I will definitly be following the progress incase it suggests useful optimizations that could be put into the linuxcnc dma driver, but I am still not sure it is possible to get more than 10k steps per second with less than 0.1us error from the pi.

I would love to see some test data.

I am also thinking that this post may well be deleted by the admin as they seem to have some grudge against me, I am not really bothered by admins behaviour as reprap does not really have much of interest for me, I have probably seen less than 10 interesting developments from reprap (your firmware being one of those ). I normally give away my ideas but guess this site does not want anything from me, I suppose there is no loss for either parties. The world keeps on spinning until it stops.

Anyways keep on keeping on, with what ever keeps you occupied away from the human condition.

Quote
mung
Also as far as 3.3volt/5volt you are pushing specs outside ratings

Mung, if you are going to make accusations like that, you need to be precise. What specs do you believe wallacoloo is pushing outside ratings?

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42

Quote
mung
Also as far as 3.3volt/5volt you are pushing specs outside ratings

Mung, if you are going to make accusations like that, you need to be precise. What specs do you believe wallacoloo is pushing outside ratings?

I am not making any accusations, I also do not have time to go over previous discussions and very long and detailed investigations into the subject, there is a huge amount of documentation on the subject please read it and learn, also try discussing the subject with user 'shadowram' they have huge knowledge of the subject and is a lead researcher into logic control. I do not want to flood you with useless information and a long reading list but if you check and read the thread [forums.reprap.org] and contact each of the users that posted for a more indepth conversation of the matters involved you will find out the true details. If you speak to the users involved you will discover there was actually alot of further discussion behind the scenes as it was felt best not to go into too much detail on a public forum.

I am sure you realise that obviously everyone thinks they are correct, only an insane person would argue a point they know to be incorrect, but unfortunately at some point we all discover we are wrong in certain contexts and when given cetain data on which to base our views.

I am not sure if this is due to an inventive step and non-obviousness, but if you look carefully and discuss this with the knowledgable people on this site you will realise your error. I am stating common well founded knowledge from this site that has been reached by consensus amoung the users of this site. I initially thought as you did, but I think you need to look deeper into your demands, I am not stating anything other that general consensus, it is up to YOU to state with supporting data your proof and reasons with precision. Sloppy questions and statements without consensus or data will get you nowhere.

Mung, most of the posters on these forums don't have a good knowledge of electronics. Unfortunately, a very few of them choose to display their ignorance by posting incorrect information. Unlike those people, designing electronics is something I do for a living. Going over past posts only going to tell me how ignorant a small number of the posters are, or that you have misinterpreted what they are saying - which I suspect is a large part of the problem. Consensus means nothing unless the people reaching that consensus know what they are talking about.

However, I did look at the thread you linked to, I don't see any consensus there. What I do see is a number of posts saying that you can use 3.3V electronics. I also see a post saying that you should not power a Pololu stepper driver from a 5V logic supply and then drive it with 3.3V logic signal - which is correct.

There is nothing magical about the voltage levels "5V" and "3,3V". What matters is that when the output of a digital device A is fed into another digital device B, the signal level is in the range that B can accept without (a) being damaged or (b) possibly misinterpreting the logic level. So it's all down to what devices you connect together, and how you connect them together.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42
Mung, most of the posters on these forums don't have a good knowledge of electronics. Unfortunately, a very few of them choose to display their ignorance by posting incorrect information. Unlike those people, designing electronics is something I do for a living. Going over past posts only going to tell me how ignorant a small number of the posters are, or that you have misinterpreted what they are saying - which I suspect is a large part of the problem. Consensus means nothing unless the people reaching that consensus know what they are talking about.

However, I did look at the thread you linked to, I don't see any consensus there. What I do see is a number of posts saying that you can use 3.3V electronics. I also see a post saying that you should not power a Pololu stepper driver from a 5V logic supply and then drive it with 3.3V logic signal - which is correct.

There is nothing magical about the voltage levels "5V" and "3,3V". What matters is that when the output of a digital device A is fed into another digital device B, the signal level is in the range that B can accept without (a) being damaged or (b) possibly misinterpreting the logic level. So it's all down to what devices you connect together, and how you connect them together.

I feel you are being very negative towards the users of this forum calling forum users ignorant is not going to win you any friends on this forum, there are tens of thousands of developers on this forum all advancing the reprap project at an exceptional pace. You seem to think that your own personal opinion is absolute fact? I did not misinterpret anything in the threads, I am just offering them as an example of what you need to know if you are going to use this forum. You have shown no proof of what you are saying, so why should I take your word over that of anyone else that uses this forum?

Also as far as I am aware you are not the developer of the rpi reprap firmware so how would you know anything about what works and what does not?

I think you are wrong about saying 'nothing magical' there are very important factors in electronic design to do with voltage drops across diode junctions and interjuction capacitance all linked in with doping factors in silicon. As an electrical engineer I would think you would understand the effect capacitance has on switching speed.


As I said you need to provide proof, show me some data plots showing switching speeds voltage risetimes/drops and delays etc etc etc then we will have something to discuss.

I think you do not realise what this forum is about, you should not be here to argue a point that may well be irrellevant just to feel superior to those you feel are ignorant, you should be here to learn and help others understand, you are not prooving anything or educating anyone by making statements without well explained and easily understandable proof.

Calling forum users ignorant without trying to help them is not the way forward, please try discussing this with shadowram and some of the other better forum users these are people who have done great work for reprap and people that I really trust and admire, they will help you understand this stuff if you try asking for help. I think you should not be here trying to proove your superiority and telling others how to do things, this is all about experimentation and learning not about elitism.

Just for clarity (unfortunately forums are fast paced chat like communications and errors or poorly phrased statements are given as time is of essence), I should say my prior posting statements about 'very strange things going on in the pi firmware' refer to the closed source vc4 boot configuration 'blob' provided with the pi, not meaning the wallamooloo firmware for reprap control.

Mung, I will happily discuss the finer points of electronic circuit design with other professional electronic engineers, but I certainly don't need to prove anything to you. As far as I am concerned, this correspondence is closed. I remain willing to discuss compatibility issues between particular 5V and/or 3.3V devices.

PS - no I do not use a RPi to control a 3D printer, however one of my 3D printers uses 3.3V electronics, and I am converting my other one to use 3.3V electronics too. But as you yourself pointed out, it is not just a case of what has been made to work by one individual, it is a case of what works and runs everything within the tolerances of the individual components. This isn't just a problem with 3.3V electronics, there is at least one open source design for 5V 3D printer electronics that runs some of the components out of spec.

Edited 4 time(s). Last edit at 12/20/2014 04:49AM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

PPS - mung, you appear to put a lot of weight on posts by ShadowRam in that thread. What he is actually says in one post is "...With this general information, we can figure out if you can use a Rasberry Pi as a replacement for an Arduino." and in a subsequent post he gives the answer No. If the question is narrowed to be "... we can figure out if you can use a Rasberry Pi as a replacement for a 5V Arduino", then the answer is indeed No, because a 5V Arduino would of course be connected to 5V printer electronics e.g. RAMPS 1.4. So as I suspected, part of the problem is your misunderstanding of what has actually been said - not helped by ShadowRam not taking account of the existence of 3.3V Arduinos and 3.3V printer electronics boards in his replies.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42
Mung, I will happily discuss the finer points of electronic circuit design with other professional electronic engineers, but I certainly don't need to prove anything to you. As far as I am concerned, this correspondence is closed. I remain willing to discuss compatibility issues between particular 5V and/or 3.3V devices.

PS - no I do not use a RPi to control a 3D printer, however one of my 3D printers uses 3.3V electronics, and I am converting my other one to use 3.3V electronics too. But as you yourself pointed out, it is not just a case of what has been made to work by one individual, it is a case of what works and runs everything within the tolerances of the individual components. This isn't just a problem with 3.3V electronics, there is at least one open source design for 5V 3D printer electronics that runs some of the components out of spec.

I am not sure I should reply as I worry you may find my answer annoying but I will give one last try to show you how we must solve these problems.

I am saddened by your reply as you seem to prefer being closed to being open, a closed mind will get you nowhere except where you have been before, this site is an open forum, for opening up the future without imposed barriers. I am most saddened because you seem to be a person that wants to help and offer advice, yet you close yourself off from self improvement. Guiding involves picking up on cues and gently proposing ideas in a way that others can hear, humans are individuals, they don't all think like you do dc42. This site is full of great people, that will go out of their way to try and help others, but you seem to missing the whole point of this site. We are not here to discuss some fact that can easily be looked up in a component datasheet or simulated in a design system.

We are here to further the cause of reprap and create a new and better world, and that mean an inclusive world, all humans are equal and they deserve an equal voice here, you cannot go around insulting peoples beliefs and education simply to make yourself seem superior to others. I could easlity quote scripture to you and the good foundations that all should be given, 'in the beginning was the word' this is the foundation, words and communication are the only way forward for humanity, ignoring other peoples voice will lead to the end. You may not understand the reality which we are all born into but reality is based on communication and you must never close correspondence, everything changes and oneday you maybe need to return, how if you have closed your route?

Now I will not quote your PPS but you obviously have not contacted 'shadowram' or you would have been enlightened by now, not all masters give simple answers and they often give people the path to follow rather than showing the destination, you cannot not understand until to have walked the path, an answer is only a dry empty shell that remains in memory after the riches that are experienced while on the journey.

There are many great masters on this site and most are never recognised by the casual passer by, you need to dig deeper for the great insights and the glory of knowledge that they can show you, and making fuzzy statements and shallow enquirys will not lead to enlightenment.

I am but a simple follower on their road and I have slowly come to realise their great insights, as little as a year ago I was angry like you are, only thinking of exactitudes and proving my own personal opinions in the hope of self glorification, I was always battling the tide and trying to push others to my own closed minded dogmas that had been instilled by closed education.

I wish you will oneday become one of those great masters dc24 as I wish the same for myself, until then we will both have to keep learning and discovering and enjoying the true nature of reality.

Quote
mung
I am not sure I should reply as I worry you may find my answer annoying...

Right on.

Mung, from what I can see you have ignored posts by several different users saying that you can drive a printer with 3.3V electronics and/or that they are doing so. Instead you are focussed on one post by ShadowRam in which he says this:

Quote

GPIO voltage levels are 3.3 V and are not 5 V tolerant. There is no over-voltage protection on the board

NOPE, you won't be able to use a Pi's GPIO without a ton of extra external electronics.

That's a serious disappointment that the Pi can't even handle 5V logic.

It is blindingly obvious from his "not 5V tolerant" and "can't even handle 5V logic" that the problem he is considering is connecting the RPi to 5V printer electronics. He obviously didn't consider using 3.3V printer electronics instead. Maybe when he wrote that post 19 months ago, the only readily-available 3D printer electronics were 5V boards such as RAMPS. If you don't consider this sufficiently obvious, then it is you who needs to contact ShadowRam and ask him for clarification. btw there must be thousands of 3D printers out there using 5V electronics - ask RepRapPro, who have been shipping the Ormerod with 3.3V electronics for over a year (and the first 500 sold out in a few weeks).

Quote
mung
I wish you will oneday become one of those great masters dc24 as I wish the same for myself...

If you hop over to the Ormerod forum and make enquiries there, I think you will find that I am already considered one of those "great masters" in respect of electronics and firmware. But I still have a lot to learn about printer mechanics.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42
Repraps do not need 5V tolerant controllers, in fact the more modern controller electronics (e,g, Duet electronics, or Arduino Due + RAMPS-FD) are 3.3V. That said, I am not sure that the RPi is an ideal solution, for example because it lacks ADCs.

I've spent time looking through the ramps schematic... This point seems to be correct


[www.pololu.com]

The datasheet says the stepper drives are 3.3V tolerant...

As you can see by the schematic for the drive modules...

The Vdd pin goes right into the semiconductor...

Endstops all use Vcc logic...
I2C is fine... as a logic "high" is pulled to com
Reset and AUX pins will all be 3.3V obviously (Although RPI wont have enough IO to fill all those)

So just apply 3.3V to Vcc and the shield should work fine... as all the semiconductors will be powered with with 3.3V ... your pi is 3.3V ... everyone is happy...


But that's not the point of my post...

"The Raspberry Pi has no user-accessible analog to digital (A/D) converters, meaning that it's slightly more complicated to read analog sensors, like thermistors and force-sensitive resistors (FSRs). Since both of these act as resistors, this limitation is bypassed by using an RC circuit - a capacitor of known capacitance is charged to its capacity, and the time it takes to discharge through the resistor is measured."

How well is this working? it's a very interesting concept ... is this bogging down the processor at all? running a super fast timer during CAP discharge? what's the sample rate? Have you considered using an I2C ADC as RPI supports I2C naturally (sometimes will a little tweaking)

I'm sure some of my questions have been answered by your documentation, I'm going to dig into it a little bit later... I had a similar idea using a RPI and dedicated hardware to achieve something like this.

Quote
MachineHum
"The Raspberry Pi has no user-accessible analog to digital (A/D) converters, meaning that it's slightly more complicated to read analog sensors, like thermistors and force-sensitive resistors (FSRs). Since both of these act as resistors, this limitation is bypassed by using an RC circuit - a capacitor of known capacitance is charged to its capacity, and the time it takes to discharge through the resistor is measured."

How well is this working? it's a very interesting concept ... is this bogging down the processor at all? running a super fast timer during CAP discharge? what's the sample rate? Have you considered using an I2C ADC as RPI supports I2C naturally (sometimes will a little tweaking)

Thanks for your interest, MachineHum.

I'd say the current RC thermistor implementation is acceptable. There are two versions at the moment - one in the master branch, and a revised circuit for running on ramps-fd in the devel branch. The one in the master branch produces very reproducible readings, but requires a lot of manual calibration to get it tuned right. One of the reasons for this is that the voltage at which an input switches from being read as LOW to HIGH is quite variable from pin to pin. Also, the nature of the RC circuit makes it such that the time taken to read the temperature at 20 C is something like 3 orders of magnitude longer than the time it takes at 200 C for a typical thermistor.

To solve those issues, the new version (which should get pushed to master in a few days) places a fixed resistor in parallel with the thermistor, so as to limit the time it takes to measure low temperatures. It is also able to logically disconnect the thermistor from the circuit and then measure some parameters at startup (namely the pin's input threshold voltage), which saves a good deal of calibration effort.

As far as processor usage goes, it's not quite that straightforward. In the devel implementation, a single read using the component values found in the ramps-fd thermistor circuit (10 uF capacitor and 4.7k parallel resistance) will take 1 mS - 10 mS, based on the temperature, and is measured using a 1 MHz hardware timer. I think I have the sample rate set to 1 Hz right now from the legacy RC circuit, which could be naively translated to between 0.1% and 1% of cpu usage. The routine is non-blocking though, so it's still doing other stuff during this time and only checking the RC circuit every 2-3 uS or so. I think it could be run at 10 Hz quite easily and in the future I might make the frequency scale with temperature (so as to make cpu usage constant). I'm not sure what the typical value for hotend feedback frequency is in the 3d printer world though. The Pi does support falling-edge and rising-edge detection, which could give theoretically better resolution and near 0 cpu usage if anyone wants to implement it, but this gets into the land of kernel modules and I don't think the improvements would actually be noticeable.

Yes, I have considered using an external ADC. I initially avoided this because I wanted to be able to connect the Pi directly to a ramps-fd board with no external components, and I also thought that I2C and SPI code would be more complicated to write than it actually turns out to be. Somebody else who's using Printipi has implemented support for an I2C thermistor, and I plan to merge his changes sometime in the next month.