Acorn & PC Division of Tasks

[cnckeith]

if it makes you feel any better so you can sleep... we have over 10,000 CNC control units running with the same system that Acorn uses with no loss of valuable material. The CNC job processing techniques and methods Centroid has developed were not done lightly, many many man hours over the course of many years have gone into the system that is currently being used on the OAK, Allin1DC and now Acorn CNC controllers. Our original controls the Big Stepper, CNC3, and CNC4 units from the 80's and early 90's used the job processing method you describe. The limitation of those and other systems that use such techniques have been overcome and improved upon by what we use today. Try it , you'll like it.)

[mikes]

Keith, you make a good point, and I am glad everyone is so open to answer my questions, so thank you.

If you have time I would be very interested to understand the kind of limitations that were encountered, and how the new architecture resolves those.

I suspect this impacts some of the higher end and niche functionality of CNC machinery, so maybe it is over my head.

[tblough]

The Acorn is designed for much more than a little 3D printer where if something bad happens you loose a little plastic. The Acorn can control big iron where a mishap can cause ten of thousands of dollars worth of damage, lost fingers, and significant lost revenue. The PC is the user interface. A machinist need to know feed rate and spindle speed and may need to adjust both as the cut progresses. The backplot lets the machinist know the how far along the program is, and the screen displays information on tool changes and lets the operator adjust the tool information to compensate for tool wear.

Subtractive machining is a lot more involved at the machine than additive manufacturing where all of the heavy lifting is done during pre-processing. Despite the price, this is not a Rambo or a Smoothie controller board. This is a professional level control.

[mikes]

The Acorn is designed for much more than a little 3D printer where if something bad happens you loose a little plastic. The Acorn can control big iron where a mishap can cause ten of thousands of dollars worth of damage, lost fingers, and significant lost revenue. The PC is the user interface. A machinist need to know feed rate and spindle speed and may need to adjust both as the cut progresses. The backplot lets the machinist know the how far along the program is, and the screen displays information on tool changes and lets the operator adjust the tool information to compensate for tool wear.

Subtractive machining is a lot more involved at the machine than additive manufacturing where all of the heavy lifting is done during pre-processing. Despite the price, this is not a Rambo or a Smoothie controller board. This is a professional level control.

I am sure Acorn and CNC12 do the job well. I agree that there is way more MMI and support for all things CNC. It absolutely looks to be a polished and professional DIY option, and that may be enough for most. I was just trying to go a level deeper. I was asking about a fundamental design element to the solution. None of what you have stated, and only minimuly what the Centroid team has stated, explains the need for tight coupling of the PC and controller. Estops and the like are outside this discussion as they should be hardwired, and trump anything the control system does. Having a tight coupling for the real-time job processing between the PC and controller is adding a link in the chain (another potential failure point) that I propose may not be needed. Oh course, you want to have near real-time info about the job, and where needed intervene with manual control, but none of that requires the PC to be doing real-time processing of the job's data (g-code) or buffering. Preprocessing maybe, but not real time. I fully agree that the link (for monitoring and manual control) should be up at all time and monitored for failure, but should a failure (possibly temporary) in that link cause a job failure? I realize it was stated that it may recover, the job may finish, it all depends. Can someone point me to where in the manual it explains how to recover a job that fails in this way? I am really asking not making definitive statements here. I am the newbe simply asking, why is it done this way. I am hoping someone can provide a use case to why this is needed and how it is better than what I have proposed.

Regarding big iron, well I don't think the MCU cares if it is moving a print head or 500# table, the calculations for vectors, speed, etc. are not much different (I propose). The results can be very different, but remember it all comes down to driving a set of steppers/servos and spindle of some nature. Can someone provide some insight, and not try to justify with its bigger and heavier, or it is working in 10,000 shope so it must be good. Maybe this is proprietary and Centroid does not want to share, ok but I have not heard that. Maybe I need to acquire more knowledge in CNC controls before this becomes obvious, as it appears to be for others.

Please please..., if any of this is coming across as smug or know it all, it is absolutely not intended. I am just a newbie sticking up for a thought, a question, that I don't think has been satisfactorily answered.

[RayL]

The "why" is very far from simple, and, in many cases, requires a detailed understanding of exactly HOW trajectory planning works, and the complex algorithms required to implement it properly. The size and performance of the machine makes a HUGE difference. You seem to believe that the G-code is a complete description of What the machine has to do. In fact, the g-code is just the starting point, and often a highly idealized one at that. Real machines, operating in the really world have to deal with all kinds of things that the g-code does not describe, and there are countless compromises that have to be made in translating the g-code into what the machine actually does. The higher the machine performance, the higher the machine precision, the more complex the job becomes. Comparing the Acorn to a 3D printer controller is like comparing a Toyota Corolla to a Bugatti Veyron. They are both cars, they both go down the road, but in VERY different ways. A 3D printer is, inherently, a very low-precision, low performance machine. How many 3D printers can maintain 0.0002" accuracy and run over 1000 IPM? A 0.002" error on a 3D printer won't even be noticed. A 0.0002" error on a commercial mill can produce very expensive scrap metal. The calculations required to get 0.0002" accuracy are an order of magnitude more complex, or more, than those required to run a 3D printer. So, your base assumption that they both doing the same job is just very wrong. Read up on trajectory planning algorithms. They are very complex, constantly evolving, and the subject of constant on-going research and development.

Regards,
Ray L.

[mikes]

Very interesting, thank you for sharing! As I said, maybe I just need to increase my limited knowledge. You point about precision is curious. I appreciate that super high precision machines are not comparable to a DIY 3D printer, but it is not uncommon to have 3D printers with .03mm of resolution, that’s .001". At that tolerance, you can machine automotive parts like cams. I thought that tolerances had more to do with the hardware. That is, things like the ball screws, rigidity of the components, backlash, etc. I guess you are saying that assuming your hardware can support .0002" tolerances. The controller must do its part for that precision? So, what makes a tool path trajectory more complicated for a high tolerance system compared to a low or medium tolerance system? I was assuming that the 32bit floating point arithmetic operations possible on a MCU would be exactly the same on a 3D printer as a high precision CNC. I agree that as precision is reduces, simplifications and possibly shortcuts can be applied to make things faster, but I don't know that that is being done in most cases for 3D printing.

Effectively what you are saying is that all things equal (hardware tolerances), a Smoothieware (for example) controlled CNC would not be capable of producing the same results (regarding precision) as the Acorn, and that to achieve its higher precision, the Acorn must employ real-time data processing on both the PC and MCU. Is that correct?

Regarding G-code, well clearly there is tons that needs to be done to convert those instructions into movements on the machine, including acceleration, deceleration, optimization of the tool path, etc. However, these are needed in 3D printing as well. I think you discount 3D printing level of complexity when calculating tool path. If you were ever to see a delta based printer in action, I think you would marvel at its dance and the arithmetic complexity needed to calculate its trajectory.

It sounds like you are quite knowledgeable in this area. Do you have any books, websites, or references you recommend for deeper knowledge? Is it not possible to give one moderately detailed example of why the PC is needed? I think others may be interested, if only for a moment.

Again, thank you for responding to my question.

[RayL]

The moving parts of 3D printers are always VERY light, which means they react quickly, and there are minor issues with vibrations affecting, in any material way, the result. With mills, the moving parts can be VERY heavy. Even many smaller mills have tables weighing several hundred pounds, and can have several hundred pounds of fixtures and workpieces mounted on them. A poor toolpath can result in poor surface finish, due to the intertia of the system. So, smooth motion is critical. As I said, the g-code is an idealized goal. The software has to do everything it can to take the g-code and convert it into a SMOOTH path the machine can execute. Complex toolpaths often CANNOT be smoothly executed exactly by the toolpath, due to physical factors, and the vagaries of g-code. For example, I doubt very much that many, if any, 3D printer controllers even bother trying to convert many small linear segments into smooth curves as the Centroid software does. If they do, I can guarantee they don't do it nearly as well. There are compromises to be made when going around corners, where it is easy to get slightly off-path, unless the tool is slowed down by a lot. I guarantee you the Centroid will create a far faster, smoother, more accurate path than any 3D printer controller, which will give you a FAR more accurate part, with FAR better surface finish, FAR faster, and with FAR longer tool life.

As I said, go spend some time studying how trajectory planning REALLY works, rather than speculating based on little real knowledge, and you'll see it is a FAR more complex task than you envision, and the higher the speed, and the higher the precision required, the harder it gets. A Centroid control on a 3D printer would be pretty much a waste of money. A 3D printer controller running a precision mill would be a complete waste of a good mill. That is a fact.

Embedded controllers are getting close to being able to compete with PC based controls in terms of computational capability, but I don't think they're there just yet. While many embedded controllers do have some, very limited floating point capability (often nothing more than a hardware integer multiplier, NOT true floating point hardware), it is not even remotely in the same league as the floating point co-processor in even the cheapest modern PC. Again, go learn what's actually in there, and compare specs. There is no contest.

Regards,
Ray L.

[ScotY]

This is an interesting discussion. I’m not totally following it but I can say it’s interesting reading. I’d like to learn more about this kind of thing, just for the sake of understanding the concepts but I am far too busy and lazy to go searching the web for info.

[mikes]

Ray,

I am sorry, but I am not so sure that because it is heavier, it is harder. The consequences for getting it wrong are potentially much worse. Having more inertia either due to speed or mass is absolutely a factor in the calculations, but even a light tool head must decelerate before changing directions and all that needs to be calculated. I am not sure about the smoothing aspects of the tool path, I know there is some in Smoothieware, but maybe they are far more extensive in Acorn and CNC12.

What about mills that are self contained and don't have the support of a PC? Does the embedded processor for them have bigtime FPU support? Are the end results of CNC machines from yesterday inferior to those of today, or are they just as good, and it is about speed and efficiency? Keep in mind that we are talking about at most a four axis solution.

I wish I had the time and resources to do a head-to-head comparison of the Acorn and other solutions, and see what the real results are. I think if the Acorn beat the pants off Mach4 and the like then it would be a great marketing tool and bring a bunch of converts. I am not sure I would see much difference in the end product given the tolerances and kind of machines the Acorn is marketed to. Would you put an Acorn of a machine capable of .0002 tolerances? Maybe in the future when time and money are no object

For me the sweet spot for the Acorn is the UI.

I will try to do more research, and respond then. The little investigating I have done thus far does show that this can be very computationally expensive stuff, and in fact the next big hurdle to speeding the generation of tool paths is parallelization of the problem set. Based on Centroid's single threaded specs for the PC, I suspect they have yet to fully crack that nut (at least for this line of controllers). It was stated that much of the algorithms were designed to run on the processors of the past, that in many cases they are still sequentially processed in a single thread. So, maybe that is partly the answer to my question. If parallel processing were employed, this could potentially be much faster. I was reading about this in a scholarly paper from Clemson University. Here is the link in case you are interested: https://tigerprints.clemson.edu/cgi/vie ... sertations

I look forward to conversing more, once I have a greater understanding. Thanks again.

[RayL]

The little investigating I have done thus far does show that this can be very computationally expensive stuff, and in fact the next big hurdle to speeding the generation of tool paths is parallelization of the problem set. Based on Centroid's single threaded specs for the PC, I suspect they have yet to fully crack that nut (at least for this line of controllers). It was stated that much of the algorithms were designed to run on the processors of the past, that in many cases they are still sequentially processed in a single thread. So, maybe that is partly the answer to my question. If parallel processing were employed, this could potentially be much faster. I was reading about this in a scholarly paper from Clemson University. Here is the link in case you are interested: https://tigerprints.clemson.edu/cgi/vie ... sertations

You do realize that paper deals with toolpath creation - i.e. going from geometry to g-code, NOT executing the g-code. Toolpath creation is a COMPLETELY different can of worms, but one that is reasonably amenable to parallel processing, as the toolpaths for different parts of the work can be generated reasonably, often totally, independently. For many reasons, actually EXECUTING g-code is not nearly as amenable to parallel processing, as it is inherently a somewhat more serial process, because what happens in each step is often dependent on what happened in previous steps.

Regards,
Ray L.