Welcome! Log In Create A New Profile

Advanced

Functionalities for a complex CNC controller

Posted by Briztou 
Functionalities for a complex CNC controller
October 02, 2017 12:44PM
Hey !!

My name is Raphaël Outhier, and I am a french developper, so before I begin, please excuse my approximative English.

I am a new member of this forum, so let me introduce myself briefly. I am a french engeneering student, in embedded systems. I own a reprap for around two years (an OrdBot Hadron), and I have spent a lot of time improving its performances.

For the last year, I have been working on TRACER, a highly reconfigurable mono-core robot controller, providing multiple modules.

It includes a stepper motor control module, built on the following paradigms (I only listed the main oned) :
- Multi axis support : The controller doesn’t have a pre-defined number of axis. The developer can configure the number of axis, and the appropriate code will be generated at compile time using X-Macro. The only limitation resides on the native type of the micro-controller you are building for (8 steppers for a 8 bit controller, 32 for a 32 bits). The controller can move all axis at the time, drawing each trajectory the developer may have implemented.
- Multi trajectory : The code is made so that any developer can easily implement a trajectory, if he knows a parametric equation for the trajectory. The controller takes the kinetics regulation in charge.
- Adaptative to the machine’s geometry: In opposition to standard controllers like GRBL, who are only focused in Cartesian geometry, TRACER can adapt its kinetics (speed, acceleration, jerk) regulations to any kind of geometry. This includes complex CNCs, or even robot arms. The firmware introduces two types of coordinate systems, the stepper motors system, used to regulate acceleration and jerk, and the control coordinate system ( (X, Y, Z) for example) which is used to express trajectories, and to regulate the speed. The relation between the two coordinate systems (that precisely define the geometry of the machine) is left at the discretion of the developer.
- Multi kinetics regulation algorithm : There are numerous methods to regulate kinetics in a CNC, each offering its own answer to the speed/exactitude compromise : approximative methods will give fast results but will lack of precision, and exact methods may require a lot of processing time. As I didn’t want to restrict the controller’s features, the developer can select the method that will be used.


TRACER also currently includes other cool features, for example the possibility to enable multiple communication interfaces, comprising :
- the standard Gcode Interface ;
- a terminal interface (like proxmark3’s client interface, but embedded in the controller)
- an inter-process interface (non string commands, useful to control the machine directly from software)
(All these interfaces being highly and easily configurable, in macro files).

Moreover, I am also working on a 4 carriages 3D printer that will take advantage of TRACER’s advanced features. Another objective is to build a 3D printer controller over TRACER.

This project’s main objective is to provide the most complete controller / printer, and so I would really like to know what features you think I should include in this project.

They may be entire modules (like a module for tracing trajectories with CC motors), CNC oriented features, 3D printing oriented features, communication oriented features, whatever you think would be useful :-) !! I did my best to write the most short and clear post, but if you want more details, don't hesitate to ask.

Thanks to all of you,

Briztou.

Edited 1 time(s). Last edit at 10/02/2017 12:45PM by Briztou.
VDX
Re: Functionalities for a complex CNC controller
October 02, 2017 02:34PM
Hi Briztou,

welcome to the forum!

In near future I will be in need of a controller+software for a 3- and 5-axis system with a "rotary" tool-head, armed with up to 12 small "tools", which can be selected and moved synchronous with the moving vector.

A ready to use system would be perfect! ... otherwise I'll need much more time for this project ...


Viktor
Re: Functionalities for a complex CNC controller
October 02, 2017 04:57PM
Hi VDX,

Thank you for your reply,

This kind of CNC fits perfectly in the controller's goal. More test are required to verify the speed regulation in non-cartesian systems, but for instance it sounds good.

Nevertheless, the longest part would be to build the software, according to the machine. Do you have plans already?

Thanks,

Briztou.
Re: Functionalities for a complex CNC controller
October 02, 2017 11:44PM
Sounds very interesting.
How many endstops does it control? Two for each stepper would be great, or software controlled virtual endstops.
Does it work with encoders ( closed loop ) too?
Re: Functionalities for a complex CNC controller
October 03, 2017 12:11AM
Sounds like a cool motion control board (mocon).
1. What kind of servo amplifiers or stepper driver boards will be supported?
2. Do I get a hand wheel jog (manual pulse generator)?
3. What micro controllers are compatible? Arduino?
VDX
Re: Functionalities for a complex CNC controller
October 03, 2017 01:55AM
... my plans are only vague at the moment - have to define/develop all the bits'n'bytes by time.

But think to use one of my 3-axis machines with encoders (0,0025mm resolution ... the other has 0,0005mm winking smiley ) and to place a pan+tilt-table (4+5 axis, too with encoders) onto the bed ... the tool-head would then be a rotating axis with absolute position encoder, so no need for "homing".

The tool-selection could be an "offset" on the rotating tool-head ... the tangential moving vector could be calculated from the last to the next position while importing/generating the G-code or "on the fly" before executing to the next move ...


Viktor
Re: Functionalities for a complex CNC controller
October 03, 2017 10:20AM
Quote
VDK
The tool-selection could be an "offset" on the rotating tool-head ... the tangential moving vector could be calculated from the last to the next position while importing/generating the G-code or "on the fly" before executing to the next move ...

What you may need is manipulating an abstraction layer, selecting your command coordinates (x, y, z, etc...) and the carriage you want to move (determining the offset). I'm already setting this up in the code, to ease the control of the 3D printer. I hope it will help!


Quote
o_lampe
Sounds very interesting.
How many endstops does it control? Two for each stepper would be great, or software controlled virtual endstops.
Does it work with encoders ( closed loop ) too?

Hello o_lampe, there are two endstops assignable for each stepper, but the core doesn't use them during the movement for instance. Only the min endstop is used dusing the homing procedure. It is not hard work to make the axis stop when an endstop is hit. I add it to the tasks. Thanks !
Concerning encoders and closed loops, that kind of stuff is not supported for instance. I'm still working on the stepper module, but I plan on making a similar module to control CC motors. I can't promise to do it really soon, because I have a lot of work to do on the printer currently, but I will do it ;-).


Quote
prot0typ1cal
Sounds like a cool motion control board (mocon).
1. What kind of servo amplifiers or stepper driver boards will be supported?
2. Do I get a hand wheel jog (manual pulse generator)?
3. What micro controllers are compatible? Arduino?

Hello prot0typ1cal,

For practical purposes, I started the project with an arduino combined with a RAMPS 1.4, and I'm currently working on a teensy 3.5, still with a (two in fact) RAMPS 1.4.
In fact, I have made the code so that he can be easily adapted to different micro controllers. For each micro controller, there is a couple of h/c files, providing all micro-controller-oriented functions (setup a timer, use a GPIO). The only way the controllers uses the micro controller layer stuff is by calling those functions. It is a bit heavy, but it really eases the portability, and clarifies a little bit the controller, that doesn't require more complexity ;-). So, if you are ready to make your own microcontroller files, you will be able to use it in any micro-controller you want.

Concerning electronics (that's not my greatest domain I confess), I am not focusing on any type of control board. I use RAMPS because there are easy to find, but the software is very flexible. You can configure the pinout easily, and adapt it to the board you use.

What do you mean, by hand wheel jog? A manual control of the machine?

Thank you for your replies :-).

Edited 2 time(s). Last edit at 10/03/2017 10:22AM by Briztou.
Re: Functionalities for a complex CNC controller
October 04, 2017 02:41PM
It is unclear if TRACER is:
hardware electronics
firmware
software

Your mention of RAMPs seems to say
this is firmware on a Mega arduino?

confused smiley
Re: Functionalities for a complex CNC controller
October 05, 2017 07:13AM
Quote
cozmicray
It is unclear if TRACER is:
hardware electronics
firmware
software

Your mention of RAMPs seems to say
this is firmware on a Mega arduino?

confused smiley

Hi cozmicray,

Thank you, I realised that I had employed the wrong word (my english aint perfect :-) )

TRACER is a firmware, with a stepper control module. You could see it as a framework (a core? ). It provides functionnalities, like the advanced control of stepper motors, that the coder may use for its purpose.

As I wanted it to be the most adaptative, I didn't code it for a special chip, or for a special board. To be more precise, when any module must use a chip-specific function, (for example , set a timer interrupt at a specific period), it calls a generic function (set_timer_period and enable_timer_interrupt, for the previous example),. So, if you want the firmware to work on a particular microcontroller, all you have to do is to implement (or have the file that implements) all generic functions, for the micro-controller. Currently, I adapted it to the Arduino Mega, and to the Teensy35.

I mentionned RAMPS, because it is the stepper driver board I'm working with, but again, the software is not made specifically for arduino (and is less and less made for Arduino Mega, as recent modules require a FPU to work ! )

For the story, I'm currently using two RAMPS for testing pusposes, but with a Teensy... The wiring was not a pleasure ;-).

I hope my answer clarified things.

Edited 1 time(s). Last edit at 10/05/2017 07:14AM by Briztou.
Re: Functionalities for a complex CNC controller
October 05, 2017 07:41AM
Why not just buy a Smoothie board?
Re: Functionalities for a complex CNC controller
October 05, 2017 08:07AM
Quote
cwaa
Why not just buy a Smoothie board?

Hi cwaa,

If you just talk about electronics, the first reason I would invoke is the price (I'm a broke student ;-) ), but in addition to this, SmoothieBoard allows the control of (if I'm correct) at most 5 stepper motors, and I currently need 9 for the printer. Moreover, while I'm developping, I need a more flexible board, and RAMPS are sufficient to this :-).

Nevertheless, if I have an occasion to work with one, I'll integrate it with pleasure.

If you talk about the firmware (THE Smoothieware itself :-) ), I wanted a firmware made to deal with any number of axis, and any type of geometry (for ex, robot arms). I saw that SmoothieWare can control up to 6 axis, but I don't think that controling more axis is easy with it.

Briztou.
Re: Functionalities for a complex CNC controller
October 05, 2017 11:03AM
Have you looked at RepRapFirmware? The current build for the Duet WiFi/Ethernet supports up to 12 motors and 9 axes. The firmware could be compiled to support more drives and axes readily, if you have the hardware to support them.

IMO if you really want to control 9 axes, you should forget about trying to do it with 8-bit controllers and firmware.


Delta printer calibration calculator, mini IR Z probe, and colour touch screen control panel: [escher3d.com]

Large delta printer, and other 3D printer blog postings: [miscsolutions.wordpress.com]

Disclosure: I have a financial interest in sales of the Panel Due, Mini IR height sensor, and Duet WiFi/Duet Ethernet [www.duet3d.com].
Re: Functionalities for a complex CNC controller
October 05, 2017 02:17PM
Quote
dc42
Have you looked at RepRapFirmware? The current build for the Duet WiFi/Ethernet supports up to 12 motors and 9 axes. The firmware could be compiled to support more drives and axes readily, if you have the hardware to support them.

Hey dc42 !

Nice ! I didn't know this firmware !

Do you know if he can be adapted to non-cartesian geometry?

Quote
dc42
IMO if you really want to control 9 axes, you should forget about trying to do it with 8-bit controllers and firmware.

Yeah, I totally subscribe, I left the avr8 behind a long time ago, since I needed an FPU for advanced kinetics, and a 32 bits processor to be able to control my 17 axis :-).
Re: Functionalities for a complex CNC controller
October 05, 2017 02:51PM
I'm using a RADDS/Due combination, with dc42's RepRapFirmware fot my CoreXYU printer.
RADDS handles 6 steppers, and with a 3 stepper extension board, can do 9 total.
Plus, the Arduino Due is 32 bit.

About the only kinematic configurations RRF doesn't handle (yet) is a 6 DOF robot arm, and hexapod.(Stewart platform)
Re: Functionalities for a complex CNC controller
October 05, 2017 02:59PM
Nicer !

I'll take a closer look at this firmware, thank you :-)

Briztou.
VDX
Re: Functionalities for a complex CNC controller
October 05, 2017 03:56PM
... would be interesting to check the possibilities - have some of the RADDS and two WLAN+motors expansion modules (older 2 and newer 3 driver sockets) too, so highly interested in working configurations for 5- and 6-axis controllers winking smiley


Viktor
Re: Functionalities for a complex CNC controller
October 06, 2017 06:15AM
Smoothie can control an unlimited number of steppers. 5 on board you can expand that using GIPO pins and stepper drivers.
Re: Functionalities for a complex CNC controller
October 06, 2017 06:40AM
Quote
Briztou
Quote
dc42
Have you looked at RepRapFirmware? The current build for the Duet WiFi/Ethernet supports up to 12 motors and 9 axes. The firmware could be compiled to support more drives and axes readily, if you have the hardware to support them.

Hey dc42 !

Nice ! I didn't know this firmware !

Do you know if he can be adapted to non-cartesian geometry?

You can define new machine kinematics by adding a new class derived from the base Kinematics class. The non-Cartesian geometries supported already are linear delta and serial SCARA, both with optional additional axes. The relevant parts of the code can be found at [github.com].


Delta printer calibration calculator, mini IR Z probe, and colour touch screen control panel: [escher3d.com]

Large delta printer, and other 3D printer blog postings: [miscsolutions.wordpress.com]

Disclosure: I have a financial interest in sales of the Panel Due, Mini IR height sensor, and Duet WiFi/Duet Ethernet [www.duet3d.com].
Re: Functionalities for a complex CNC controller
October 06, 2017 06:42AM
Quote
cwaa
Smoothie can control an unlimited number of steppers.

Which board runs Smoothieware, has an unlimited number of GPIO pins, and an unlimited amount of RAM?

Edited 1 time(s). Last edit at 10/06/2017 06:44AM by dc42.

Delta printer calibration calculator, mini IR Z probe, and colour touch screen control panel: [escher3d.com]

Large delta printer, and other 3D printer blog postings: [miscsolutions.wordpress.com]

Disclosure: I have a financial interest in sales of the Panel Due, Mini IR height sensor, and Duet WiFi/Duet Ethernet [www.duet3d.com].
Re: Functionalities for a complex CNC controller
October 06, 2017 08:14AM
I've always had a suspicion that at some point jumping to LinuxCNC becomes a good choice. It certainly has the ability to perform every task required for 3d printing (plus an endless number of additional features) but I'm not sure if anyone has wrapped them into familiar g-codes yet.
Re: Functionalities for a complex CNC controller
October 08, 2017 12:26PM
As a software engineer myself also with embedded experience I find myself wondering: are you wishing to do all this on your own because of the typical "Oh yeah? I cancdo it better!" common to people writing code to do something that already has other readily available solutions that have been looked at and rejected, or because you don't know what already exists?

The thing is, this domain already has many viable solutions and a large number of them are totally open-source and free-to-use, and, even better, are well-tested, proven, and maintained. I won't say that it's impossible that you could do them better, but unless you have a proven track record that says otherwise, it's unwise to claim otherwise, and expect it to work out as anticipated, without it having a far higher cost than you expected. You state you're a poor student, but what I remember from my distant past is that other than a lack of money, the biggest cost as a poor student is that of time: it makes far more sense to reuse and modify something that's been tested than to reinvent the wheel, possibly badly, and take a very long time to do it.

Software development time/effort estimates are rarely ever close to how long it takes in reality, even with long experience in the problem domain by experienced engineers.

One of the most dangerous potential problems in software development is "Second System Syndrome" which is when people set out to replace an existing application saying "the old thing sucks, it's better to redo it from scratch!" because there's what's visibly documented to the outside in documentation, but what the code actually does almost never matches outside documentation perfectly, but it's the mismatches that make the code work "correctly" in spite of what the external documentation would suggest: the only correct documentation of what the application does and should do will always be the code itself (don't depend on code comments as to how, maybe they explain why something was done, but comments can also get out of date) built with the original compiler, as even changing the compiler (due to compiler changes, intended or otherwise, due to bugs or language changes) often results in unintended changes.

The spirit and goal of Reprap is to build off the work of others, and improve upon it and return that work to the community: it's usually better to learn as much as you can from the mistakes of others before you go and make your own mistakes (most of which have already been made by others winking smiley) as it will help you and the tech progress faster and cheaper.
Re: Functionalities for a complex CNC controller
October 08, 2017 01:44PM
Hello JonathanThompson, and thank you for your long reply, that will allow me to clarify my post.

Quote
JonathanThompson
As a software engineer myself also with embedded experience I find myself wondering: are you wishing to do all this on your own because of the typical "Oh yeah? I cancdo it better!" common to people writing code to do something that already has other readily available solutions that have been looked at and rejected, or because you don't know what already exists?

The thing is, this domain already has many viable solutions and a large number of them are totally open-source and free-to-use, and, even better, are well-tested, proven, and maintained. I won't say that it's impossible that you could do them better, but unless you have a proven track record that says otherwise, it's unwise to claim otherwise, and expect it to work out as anticipated, without it having a far higher cost than you expected. You state you're a poor student, but what I remember from my distant past is that other than a lack of money, the biggest cost as a poor student is that of time: it makes far more sense to reuse and modify something that's been tested than to reinvent the wheel, possibly badly, and take a very long time to do it.

For me, this project began as a way to learn C, and to know more about tool machines. I didn't have a great knowledge of existing softwares features, (to be honest I still don't have a great one). Initially a simple 3 dimension controller, I decided to keep developing it, and add new functionalities for two reasons, the knowledge I acquired during development, and the encouraging results I obtained. I didn't lack of time, because this project is the one on which I want to invest my time. The subject passions me, so I don't mind loosing some time for it :-).

Quote
JonathanThompson
One of the most dangerous potential problems in software development is "Second System Syndrome" which is when people set out to replace an existing application saying "the old thing sucks, it's better to redo it from scratch!" because there's what's visibly documented to the outside in documentation, but what the code actually does almost never matches outside documentation perfectly, but it's the mismatches that make the code work "correctly" in spite of what the external documentation would suggest: the only correct documentation of what the application does and should do will always be the code itself (don't depend on code comments as to how, maybe they explain why something was done, but comments can also get out of date) built with the original compiler, as even changing the compiler (due to compiler changes, intended or otherwise, due to bugs or language changes) often results in unintended changes.

The spirit and goal of Reprap is to build off the work of others, and improve upon it and return that work to the community: it's usually better to learn as much as you can from the mistakes of others before you go and make your own mistakes (most of which have already been made by others winking smiley) as it will help you and the tech progress faster and cheaper.

Let me be clear, my intention is (of course) not to replace actual firmwares, and I do not mean to trash-talk any existing firmware on this topic. My approach is more "Hey that would be a nice feature, let's see if I can do it, and if it can help, perfect". I started this project partly for learning, and the features I implement are responding to my particular needs. But if in adding new functionalities, I can help reprappers, who need to control complex machines, then I think my "loss" of time was worth it :-).
Also, as I said upper, I don't have a great knowledge of existing firmwares. As I didn't want to be orientated by other firmwares, I didn't look into their documentations or codes during the coding, neither for formulas, or general methods.

Anyway, this topic is also a great occasion for me to learn more about existing firmwares. If you know one that can regulate steppers and high level kinetics for any type of geometry, adapt to any number of axis, and also be "easily" (without having to spend a week;-) ) adapted to a particular chip, I still am very interested !

Thank you again,

Briztou.

Edited 2 time(s). Last edit at 10/08/2017 01:47PM by Briztou.
Re: Functionalities for a complex CNC controller
October 08, 2017 05:24PM
Quote
Briztou
Hello JonathanThompson, and thank you for your long reply, that will allow me to clarify my post.

Quote
JonathanThompson
As a software engineer myself also with embedded experience I find myself wondering: are you wishing to do all this on your own because of the typical "Oh yeah? I cancdo it better!" common to people writing code to do something that already has other readily available solutions that have been looked at and rejected, or because you don't know what already exists?

The thing is, this domain already has many viable solutions and a large number of them are totally open-source and free-to-use, and, even better, are well-tested, proven, and maintained. I won't say that it's impossible that you could do them better, but unless you have a proven track record that says otherwise, it's unwise to claim otherwise, and expect it to work out as anticipated, without it having a far higher cost than you expected. You state you're a poor student, but what I remember from my distant past is that other than a lack of money, the biggest cost as a poor student is that of time: it makes far more sense to reuse and modify something that's been tested than to reinvent the wheel, possibly badly, and take a very long time to do it.

For me, this project began as a way to learn C, and to know more about tool machines. I didn't have a great knowledge of existing softwares features, (to be honest I still don't have a great one). Initially a simple 3 dimension controller, I decided to keep developing it, and add new functionalities for two reasons, the knowledge I acquired during development, and the encouraging results I obtained. I didn't lack of time, because this project is the one on which I want to invest my time. The subject passions me, so I don't mind loosing some time for it :-).

Quote
JonathanThompson
One of the most dangerous potential problems in software development is "Second System Syndrome" which is when people set out to replace an existing application saying "the old thing sucks, it's better to redo it from scratch!" because there's what's visibly documented to the outside in documentation, but what the code actually does almost never matches outside documentation perfectly, but it's the mismatches that make the code work "correctly" in spite of what the external documentation would suggest: the only correct documentation of what the application does and should do will always be the code itself (don't depend on code comments as to how, maybe they explain why something was done, but comments can also get out of date) built with the original compiler, as even changing the compiler (due to compiler changes, intended or otherwise, due to bugs or language changes) often results in unintended changes.

The spirit and goal of Reprap is to build off the work of others, and improve upon it and return that work to the community: it's usually better to learn as much as you can from the mistakes of others before you go and make your own mistakes (most of which have already been made by others winking smiley) as it will help you and the tech progress faster and cheaper.

Let me be clear, my intention is (of course) not to replace actual firmwares, and I do not mean to trash-talk any existing firmware on this topic. My approach is more "Hey that would be a nice feature, let's see if I can do it, and if it can help, perfect". I started this project partly for learning, and the features I implement are responding to my particular needs. But if in adding new functionalities, I can help reprappers, who need to control complex machines, then I think my "loss" of time was worth it :-).
Also, as I said upper, I don't have a great knowledge of existing firmwares. As I didn't want to be orientated by other firmwares, I didn't look into their documentations or codes during the coding, neither for formulas, or general methods.

Anyway, this topic is also a great occasion for me to learn more about existing firmwares. If you know one that can regulate steppers and high level kinetics for any type of geometry, adapt to any number of axis, and also be "easily" (without having to spend a week;-) ) adapted to a particular chip, I still am very interested !

Thank you again,

Briztou.

Smoothieware is great firmware from all reports I've read.

I see you're in a mode that you'll almost certainly pursue this course of action regardless smiling smiley

I do have concerns regarding safety: C is an absolutely unsafe and unforgiving language you can implement anything in, with top performance, including potentially-fatal bugs that are hard to track down and fix, because of the fact it does not save you from yourself. Working on code that controls hardware that could potentially cause a fire or injury if you get it wrong is an unnecessarily dangerous learning ground for a language.

I don't know what your past development experience is before this, but from what you created this thread with, what is clear is you're using macros extensively, and that has a price in readability and ease-of-use as well as debugging along with it being harder to create decent abstractions to achieve your desired flexibility. I'd suggest instead you move towards a restricted subset of C++ without using exceptions, so you can have more type safety as well as eliminate using macros, combined with making it far easier to create a modular system.

In addition to that, if you aren't already, I'd suggest you look up techniques for creating state machines, and also study (again, if needed) techniques for working with static memory allocation/mangement. What others have mentioned is a truly critical factor for making something portable, even feasible at all on these limited platforms: they have very finite resource limits considering what you need to do with them, and if only for that reason alone, I'd suggest reading through other 3D printing firmware to understand how they work within the constraints for code size and RAM constraints. It's not outside of the realm of possibility and probability that you could create something that otherwise runs fine on a simulator that has enough RAM (simulators are often less limited than the thing they simulate) or you run into that odd corner case where some control sequence requires more resources than your controller has: this can result in a horrible failure mode, with the the worst-case scenario being your code doesn't even detect the failure, and blindly works with corrupted state. Properly designed and implemented, tested state machines are useful towards working with minimal resources(both in executable code size and RAM usage) and being readily tested. Watch your memory usage perfectly and build in code to do a safe failure in every possible place it could fail in such circumstances duecto lack of memory, and do that FIRST. You can always go back and fix mistakes only if your device and you aren't destroyed because they were fatal winking smiley
Sorry, only registered users may post in this forum.

Click here to login