Electronics and software combination questions

I'm new here so I don't know the personalities yet. Someone earlier praised Bobc's wisdom (I assume it wasn't his mum/girlfriend/wife - depending on his age) so I'm not sure how to take this recent reply.

A few possibilities spring to mind ...

(a) you know how to use GRBL and you can't figure out how I can't?
(b) you think OpenSource is only suitable for people who know how to figure out the GRBL code in an hour or two?
(c) you know all of the OpenSource options and you know that there is nothing suitable for my needs?

Whatever the answer to these options, your last sentence is perfectly aligned with my original post which was a request for links to information that would be helpful to someone writing his own code. Do you have any suggestions?

Thanks

...R

bobc Wrote:
-------------------------------------------------------
> Robin2 Wrote:
> --------------------------------------------------
> -----
> > From reading this introduction to Grbl I figure
> it
> > would be very hard work to figure out what the
> > code is doing. And I don't think there is a
> > comprehensive user manual.
>
> Ok, I think Open Source has nothing to offer you
> then.
>
> You will need to develop your own solution or buy
> something ready made to your requirements.

Robin2 Wrote:
-------------------------------------------------------
> I'm new here so I don't know the personalities
> yet. Someone earlier praised Bobc's wisdom (I
> assume it wasn't his mum/girlfriend/wife -
> depending on his age) so I'm not sure how to take
> this recent reply.
>
> A few possibilities spring to mind ...
>
> (a) you know how to use GRBL and you can't figure
> out how I can't?
> (b) you think OpenSource is only suitable for
> people who know how to figure out the GRBL code in
> an hour or two?
> (c) you know all of the OpenSource options and you
> know that there is nothing suitable for my needs?
>
> Whatever the answer to these options, your last
> sentence is perfectly aligned with my original
> post which was a request for links to information
> that would be helpful to someone writing his own
> code. Do you have any suggestions?

I think what you are looking for, i.e. a guide to writing printer firmware, or even a set of relevant links, simply does not exist. Therefore I was hoping to save you some time on a futile search and explain in advance lack of answers.

What does exist, is firmware source code which is freely available. Studying the source code is the best way to see what the source code does. If you are intending to write some code, then you should be able to read and understand other peoples code. I expect that to take more than a few hours, possibly days or weeks to fully grasp all the nuances, depending on your prior experience.

Robin2 Wrote:
-------------------------------------------------------
> I'm new here so I don't know the personalities
> yet. Someone earlier praised Bobc's wisdom (I
> assume it wasn't his mum/girlfriend/wife -
> depending on his age) so I'm not sure how to take
> this recent reply.


You should take it in the spirit I think he intended, that is to assist you. One great part about open source is that one can "scratch thier own itch", as they say in CatB. That's going to require you to do some (likely most all) of the heavy lifting unless you join a project that is already established. It's good to ask, in fact you should but you aren't always going to get the answers you want or even any answers. Rather than concern yourself with the personalities on the forum or convince others you have a good idea, the best thing to do is go out and make it happen. Get the code, set up a dev environment and have at it.

EDIT: I just read this in one of the previous posts

" It is a myth to think that Open Source software is free. "

The free software movement and open source are related but not necessarily the same. For example there are some licenses that have open source but restrict the use of that source in one way or another. Free means free as in speech, not as in beer. It means you are free to use and deploy the software as you see fit. That is, no restrictions as such are imposed on your use. It's got nothing to do with any monetary cost. It's a myth to people that mistakenly equate no cost source access to free software.

From gnu.org...


A program is free software if the program's users have the four essential freedoms:

The freedom to run the program, for any purpose (freedom 0).
The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
The freedom to redistribute copies so you can help your neighbor (freedom 2).
The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

[www.gnu.org]

Edited 1 time(s). Last edit at 09/08/2013 10:29PM by vegasloki.

Thanks for the clarification Bob, I hadn't got this message from your earlier post.

However, in case there is a difference in your mind, I'm not looking for a guide to writing printer frmware. What I'm hoping to find is a guide to the working principles of 3D printing so that I know what the software must be able to achieve.

It may be that all of the original work on 3D printing was done commercially and secretly and the RepRap forum "reinvented the wheel" by looking at commercial devices and trying to emulate them without the benefit of the underlying principles. However I can't help feeling it probably started in some University and there are publicly available scientific papers if one knew where to look.

My simple Arduino software now seems capable of driving 4 steppers in a coordinated way so the next step (accidental pun) is to write some JRuby code to interpret simple GCode and see can I draw lines with a pencil.

Since you mentioned Grbl earlier, I wonder if you have come across any software similar to slic3r that produces GCode for metal turning on a lathe. Producing GCode for turning is another area where I haven't been able to turn up any information (but that's not really a RepRap issue).

...R

@vegaloski - I was referring to free as in "free of charge" as in Open Source programmers not expecting to be paid for their work and therefore not putting any time constraints on how much time they give to any project or making any assessment of whether that amount of time is justified. (I like Open Source and use Linux all the time - but that doesn't mean it's perfect).

...R

bobc Wrote:

> I think what you are looking for, i.e. a guide to
> writing printer firmware, or even a set of
> relevant links, simply does not exist.

The information you seek is out there, In the time that has been spent replying to this thread some of the research could have been accomplished.

Robin2 Wrote:
-------------------------------------------------------
> However, in case there is a difference in your
> mind, I'm not looking for a guide to writing
> printer frmware. What I'm hoping to find is a
> guide to the working principles of 3D printing so
> that I know what the software must be able to
> achieve.

I really don't see any difference?? But if you prefer, I do not believe a "guide to the working principles of 3D printing so that I know what the software must be able to achieve" exists either.

To be honest, the operating principles are hardly complicated, it does not seem worthy of a university paper. Controlling stepper motors is a well known subject, there are plenty of google references. Other stuff, like parsing Gcode is bread and butter stuff for a programmer, the only reference needed is a GCode spec. Extruding plastic is a question of melting plastic and turning a motor. It is not rocket science!

I don't know why some people think there should be a "secret specification" somewhere that explains everything, there just isn't. Such a belief seems slightly irrational, since by default nothing is documented. A specification is never a necessary requirement, a project can develop by trial and error, and most open source projects do.

I wouldn't claim to be an expert, but I have been working on printer firmware for 2-3 years, so I have practical experience. I've never found it necessary to refer to an overall guide to operating principles. Specific techniques like the Bresenham algorithm are easily found on the web.

It sounds like you are doing exactly what I suggested anyway, which is develop your own software.

I may be missing something, (won't be the first time) but I can not see the problem with GRBL controlling a lathe, maybe if you explained
in simple terms, so a numpty like me could understand what you are trying to achieve.don't get me wrong but it seems you are trying to
re-re-invent the wheel, nothing wrong with making your own tool chain if thats the plan.

---

Random Precision

FWIW, here's documentation about firmware internals: [reprap.org]

And here's the description of the "user interface". It's called G-code: [reprap.org]

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

@Traumflug - thanks for the Teacup link. It's interesting for what it is. But it doesn't explain (for example) why good communications is important or what might happen without it. And No, I'm not asking you to explain here. I'm just using that as an example of the limited audience your comments are aimed at.

@Vegasloki - when I'm not replying here I'm searching, and not finding. It sounds like you know where it is. Can you let me in on the secret?

@Johnrpm - I haven't been able to find any instructions that explain how to wire up Gtbl to a lathe. How do I know if my physical machine is compatible? At least with RepRap there is a predefined set of hardware and I presume there are instructions if you buy a kit.

@Bobc - all the bits you mention are easily handled with a bit of research. But knowing how to make a stepper motor move tells you nothing about where or when it should be moved. It's the difference between knowing how to drive a car and knowing how to use a car to get to the seaside. Presumably there is information somewhere about extrusion rates, layer thicknesses, plastic temperatures etc etc that are important for getting a 3D printer to work. I can get all the technical documentation about a microcontroller in the relevant datasheet. All I'm looking for is the equivalent for 3D printing. (I accept that it may not exist, but if so it seems a very surprising omission).

...R

For the lathe, lets assume you have the gcode from a cam system or hand coded, this is sent to an arduino for example having grbl, teacup, or whatever firmware you prefer, ( which is pre configered to get the best stepper
performance for your machine), the uno outputs step and direction signals to the stepper drive boards, then to the motors.
the arduino acts a bit like mach3 or linuxcnc, but they use the pport of the PC, have a look at linuxcnc it may be what you need for the lathe stuff, not sure if cambam does lathe stuff but worth a look.

I think grbl was reccomended because it is stripped of thermiser, heater stuff and fits on a uno, but other firmware would be good but may need a mega.

EDIT, the pinouts for the firmware will be in config.h or a setup file.
How do I know if my physical machine is compatible? if your lathe has stepper motors, the drive boards will need to handle the current required, and preferably accept step and direction usually ttl," the voltage from a pport", most drive boards are like this
hope this helps.

Edited 2 time(s). Last edit at 09/10/2013 09:43AM by johnrpm.

---

Random Precision

Robin2 Wrote:
-------------------------------------------------------
> @Bobc - all the bits you mention are easily
> handled with a bit of research. But knowing how to
> make a stepper motor move tells you nothing about
> where or when it should be moved. It's the
> difference between knowing how to drive a car and
> knowing how to use a car to get to the seaside.

I don't know if we are two cultures separated by a common language, but "knowing how to drive a car" and "knowing how to drive a car to reach a destination" are the same thing. I can't even think of how you could learn to drive a car without then being able to use it go somewhere.

It's beginning to look like it.

Knowing how to drive a car requires knowing how to use the accelerator, brake, clutch gear shift etc.

Knowing how to get to the seaside requires knowing how to read maps and road signs.

Two completely different skill sets.

...R

bobc Wrote:

> I don't know if we are two cultures separated by a
> common language, but "knowing how to drive a car"
> and "knowing how to drive a car to reach a
> destination" are the same thing. I can't even
> think of how you could learn to drive a car
> without then being able to use it go somewhere.

Robin2 Wrote:
-------------------------------------------------------
> It's beginning to look like it.
>
> Knowing how to drive a car requires knowing how to
> use the accelerator, brake, clutch gear shift etc.
>
> Knowing how to get to the seaside requires knowing
> how to read maps and road signs.
>
> Two completely different skill sets.

I'm sorry, but that is the most ridiculous thing I have ever read!

So you've never known a driver to get lost?
and without simultaneously killing himself or someone else?

...R

bobc Wrote:
>
> I'm sorry, but that is the most ridiculous thing I
> have ever read!

Keep it civil, please.

---

Help improve the RepRap wiki! Just click "Edit" in the top-right corner of the page and start typing. Anyone can edit the wiki!

Robin2,

you're really asking this in the wrong place. While some here may have experience with milling machines and CNC lathes, it's not what we do.

Perhaps here.

We build 3D printers that, with our aid, self-replicate. That is our only goal. Additive lathes have been discussed in the past, but I don't think I've seen any results on that front.

You don't 'wire GRBL up' to anything. It's firmware, not hardware. Adding stepper motors to a lathe for CNC should be trivial. Almost as trivial as wiring the stepper motors up to a microcontroller/shield. You are simply controlling an axis. You will need to properly define that axis in the firmware, but that is all. Controlling a lathe is really a function of the CAM software. An example.

GRBL is just firmware that resides on an arduino uno. Sprinter and Marlin are specialized offshoots of GRBL.

GRBL is used to control stepper motors via g-code, and do some other fun stuff, like turn a spindle on/off, control the spindle direction, turn cooling lubricant on/off and provide some functionality to a pendant. That's about it.

The github repository is here: [github.com]

A guide to configuring GRBL is here: [www.shapeoko.com]

You probably know all this.

We use Marlin/Sprinter/Teacup to interface the PC with the printer via a microcontroller. There are good reasons for doing this as we're not just throwing some axes around like some CNC devices do. We must also monitor and control the temperatures of hotends and heated beds. We also have a need to control fans. Microcontrollers also allow us to run these machines headless by interfacing with LCD displays, rotary encoders, buttons and SD card readers. Then there are accessories, like Z-probes. In short, microcontrollers offer us distinct advantages over the traditional BOB + PC + MACH3/etc. Advantages that can simply be coded into the firmware when a new feature is called for/needed. Thus is the beauty of open source.

Are there issues with communicating via USB? Sure, but nothing insurmountable.

If you want to see how the firmwares work, fork their respective github repositories and have at it. As much as people want it, we cannot hold their hands and walk them through these things. Sometimes it's because some of us don't understand them (me no understand firmware), and sometimes we just don't want to write a dissertation on a well-established part of the tool-chain. If you want to fundamentally understand how something works you'll need to roll up your sleeves and get right in there, preferably elbow-deep. But to truly understand it you need to see it live.

Your best bet for understanding this technology is to actually build a machine. Get the mechanics sorted and then play with the firmware.

And your car/map analogy is exactly backwards. A good driver does his research, reads maps and plots a route long before he ever gets in the car. And it would be nice to know exactly how the mechanics of a car's engine and transmission work, but ultimately does that information help you accomplish your objective in getting from point A to B?

Perhaps what you're looking for is a standard. That is an ugly, four-letter word around here. Accepting the fact that there is no standard is your first step on the path to enlightenment. There is no standard machine. There is no standard tool-path. There is no standard firmware. There is no standard.

There are very good reasons for this.

Every single machine is different.
Every user has different skills and abilities.
Every user has a preferred tool-path.

Once you accept this, that there is no standard, you will see that this is a beautiful thing.

Standards promote ignorance.
Standards stunt growth.
Standards discourage experimentation.
Standards lead to obsolescence.

Finally, maybe you don't understand the tool-chain. This is possible, so I'll outline it.

Step 1 - So you have gotten your hands on a sweet model from someplace out on the interwebs. What do you do with it? Well, we need to take that object and prep it for printing.
Step 2A - Load the model into your favorite skeining/slicing program. There are a variety of tools to do this job (skeinforge/slic3r/cura/kisslicer/etc).
Step 2B - Oops! Your model has a hole (non-manifold)! Better go to cloud.netfabb.com and have them fix it for you. Once you download the fixed model load it into your slicer of choice, specify your settings (which can be a master class in and of itself) and have the program generate the g-code from the model.
Step3 - Hooray! You have some g-code ready to be fed to your 3D printer! But how do it know? Well, you use a g-code sender like repetier host or printrun/pronterface to send the g-code to the arduino. Open this software up.
Step 4 - Prep the printer. This typically means pre-heating the hotend, heated bed, heated chamber, etc. Once you've set the machine up load the g-code file and click print.
Step 5 - Engage in reprap hypnosis watching your machine produce your model.



Step 6 - Finished printing! Hussah! Wait for it to cool before you attempt to retrieve the object of your desire.

Your path the 3D printing Nirvana:
Step 1 - Research.
Step 2 - Ask questions.
Step 3 - Repeat steps 1 and 2 until you're comfortable with what these machines are, what they do, how they work and how to effectively use them
Step 4 - Build a machine.
Step 5 - Ask questions about where you went wrong (you will go wrong somewhere).
Step 6 - Iterate on a variety of topics until you have the machine printing well.
Step 7 - Repeat steps 1 - 6 for your next machine.
Step 8 - Repeat steps 1 - 7 ad infintum

I hope this was useful.

---

- akhlut

Just remember - Iterate, Iterate, Iterate!

[myhomelessmind.blogspot.com]

@ahklut, Thank you very much for taking the trouble to write such a long post, I do appreciate it.

I do realize that stuff about a CNC lathe is out of place here. I just asked that question because someone else looked like he might know something about it.

I like "your path to 3D printing Nirvana" but it seems like I'm stuck at step 2 because I'm not getting answers to the questions that seem relevant to me.

I understand your aversion to "standards" although I suspect you use them many times a day in your everyday life (and couldn't manage without them) - electricity plugs and sockets, electricity voltage, HTML, driving on an agreed side of the road etc etc etc etc.

I realize that using my lathe as a 3D printing platform and as a CNC lathe is very different from the "standard" approach to Reprap. All I've been hoping to find was a description of the principles necessary for 3D printing to work so that I can take them into account in my own system. It's beginning to look as if, while the Reprap crowd are happy for people to copy their equipment and software, they are reluctant to make the underlying secrets public.

And none of the replies I have seen here has presented a convincing argument for interpreting GCode on the Arduino rather than on the PC.

...R

. All I've been hoping to find was a description of the principles necessary for 3D printing to work

if you ever find them let us know.

they are reluctant to make the underlying secrets public.

SSSSSSSSSSHHHHH don't tell everyone you'l let the cat out of the bag.

---

Random Precision

There really is no need for the arduino. You can certainly use a 4-axis BOB and PC to control a reprap. Without the arduino you'll need some extra hardware to make it all work, but nothing is impossible. I know that slic3r can export a MACH3 flavored g-code. Reprap uses the arduino platform because it is cheap, modular and easily procured.

Honestly, there are no secrets. Perhaps the information you seek is buried. Perhaps it does not exist and you may have to create it. Case in point: the Delta printer configuration. The firmware had to be modified to support such a printer. Johann built the machine and modified marlin to support the delta configuration (A,B,C pillars instead of X,Y, Z axes). An additive lathe is no different. The firmware will have to be modified to support such a configuration (X,Z,A).

Maybe these links will help with what you're trying to accomplish.

[forums.reprap.org]
[www.scribd.com]
[fab.cba.mit.edu]

General principle of FDM:

Coordinated positioning and deposition of media via extrusion onto either a substrate or a layer of previously extruded media to produce an object.

Media can include but is not limited to:
Thermoplastics
Polymer liquids
Polymer solids
Super-saturated solutions

That's it in a nutshell.

---

- akhlut

Just remember - Iterate, Iterate, Iterate!

[myhomelessmind.blogspot.com]

Robin2 Wrote:
-------------------------------------------------------
> All I've been
> hoping to find was a description of the principles
> necessary for 3D printing to work so that I can
> take them into account in my own system. It's
> beginning to look as if, while the Reprap crowd
> are happy for people to copy their equipment and
> software, they are reluctant to make the
> underlying secrets public.

I am still genuinely baffled what underlying principles you think there are that are unique to 3D printing which need explaining, and are not general applications of maths, physics etc and common sense.

There are no secrets. RepRap is built on the very opposite of keeping secrets. How could the implementation be openly published without revealing underlying principles? The principles are embodied in the design. Your conclusion is therefore quite illogical.

I like Arduinos. I intend to use an Arduino. The question that remains in my mind is how the work should be divided between the PC and the Arduino. Programs such as Sprinter, Teacup etc seem to use the Arduino to do a lot of work that could be done on a PC. I had been hoping someone who is familiar with those programs would explain the thinking behind the decision to do all that work on the Arduino.

I don't want to print onto a rotating part in a lathe. I just plan to use the three axes of my lathe (I have a small vertical slide) to work the same as the 3 axes of a Reprap machine. I will also have a stationary extruder. I am trying this out because it should be much cheaper than a Reprap machine. It will be a very different machine from a regular Reprap machine and I had hoped that someone would have been able to say "it needs to be able to do this, this and this in order to produce good products".

Thank you for your input.

...R

Robin2 Wrote:
-------------------------------------------------------
> I like Arduinos. I intend to use an Arduino. The
> question that remains in my mind is how the work
> should be divided between the PC and the Arduino.
> Programs such as Sprinter, Teacup etc seem to use
> the Arduino to do a lot of work that could be done
> on a PC. I had been hoping someone who is familiar
> with those programs would explain the thinking
> behind the decision to do all that work on the
> Arduino.

There are a few reasons that I see for using an Ardiuno and using it to process gcode.
First - PC's are not real-time. So you need some sort of buffer between the PC and the motors and sensors. The Arduino does this.
Second - Even if you had a real-time operating system on your PC, it would require a parallel port to output motor control and read sensors. Most modern computers do not have this. A USB-parallel adapter would not work, as USB is not real-time.
Third - Gcode is a compact way of transmitting the movement information. If movements were further derived, such as into step and direction commands, the bandwidth required to transmit those commands would increase dramatically. It would require a more powerful micro controller to act as the buffer, which would defeat the purpose of having the PC do pre-processing.
Fourth - Gcode is readable and portable. It can be human-read and edited, and transfers reasonably well between machines.

---

Help improve the RepRap wiki! Just click "Edit" in the top-right corner of the page and start typing. Anyone can edit the wiki!

Thanks again Cameron.

I understand the importance of the Arduino as a buffer. I learned that the hard way with another (much simpler) project where I thought an FTDI USB to parallel board would behave like a PC parallel port.

I also understand the value of GCode as a compact and convenient standard for code to control machines.

But I am not convinced that these two pieces of information require the GCode to be processed by the Arduino. Ultimately any single line of GCode must be resolved into coordinated moves by the stepper motors. It seems to me quite possible to send a pre-processed (and still compact) instruction to the Arduno which doesn't require any interpretation by the Arduino.

I have been experimenting with sending five pieces of information to the Arduino - the total time for a move (in microseconds) and for each of the 4 motors, the interval (in microseconds) at which it should step. It only takes a few lines of Arduino code to implement that. Turning GCode into that sort of data should be a trivial job for a PC, especially as it doesn't have to do it in real time. Also the PC is much better suited to floating point maths needed to deal with arcs.

What I've been hoping to learn here is if there is a good reason not to do it like that which I haven't yet thought about.

...R

Others who have far more knowledge than I could answer this better, but I would be concerned that relying on timeing alone would lead to
inacuracy, if a step equals a certain distance, then N steps equals a definate value, whereas small errors in timeing could add up, that is if I understand correctly what you propose.

P.S do you not think it would have saved a lot of time asking the above in the first place.

---

Random Precision

Thanks @Johnrpm,

In the concept I have in mind there will always be a precise number of steps in a given number of microseconds so I don't think there is a risk of drift except to the extent that all stepwise processes must reduce floating point values to integers - but that must also happen with Sprinter, Teacup etc.

If this isn't what you had in mind I would appreciate a clarification.

...R

[reprap.org]

---

- akhlut

Just remember - Iterate, Iterate, Iterate!

[myhomelessmind.blogspot.com]

Robin2
What drive board have you got in mind.

---

Random Precision

@Johnrpm, I'm not quite sure what exactly you are asking.

I'm driving my stepper motors with Pololu A4988 boards connected to either an Arduino Uno or Mega. I bought he Mega because I thought I would have to use Sprinter but the code I have written myself will easily fit on an Uno. If I need to use end-stop switches the Uno may run out of pins, but I think I will start with setting the zero position manually and hope the software can keep a correct count of where it is after that.

...R

Robin2
Thanks for the info, the Mega is a safe option, gives more flexibility, maybe a CF card etc, Can you post some of your code, so that I can try to understand it.
notice the word TRY.

---

Random Precision

What stepper motors are you going to use?

---

- akhlut

Just remember - Iterate, Iterate, Iterate!

[myhomelessmind.blogspot.com]