dear Stuart, the benchmark we did was the following : Milling (finishing phase) a brass pocket for watchmaking industry using spiral trajectories in xy plane, vibrations occuring in z direction. 1 mm milling tool, ~40'000 rpm.
Assessment of surface quality by 1) experienced operator (blind test) giving a note from 1 to 10 regarding surface quality (without knowing which CNC, which cutting parameters, etc) 2) microscopical analysis of the piece with Fourier analysis, trying to establish a computable performance indicator regarding surface quality The important point is, that the vibrational behaviour of the machine, AND the acceleration profile from the CNC completely determine the surface quality. This is not yet realized in OpenCN, for the moment only jerk control, wich is already an important point ! best regards, Raoul -----Message d'origine----- De : Stuart Stevenson <[email protected]> Envoyé : lundi, 25 novembre 2019 02:42 À : EMC developers <[email protected]> Objet : Re: [Emc-developers] announcement OpenCN, a new fork of LinuxCNC --> Precalculations Raoul, Paragraph (1) I think it would be necessary to empirically collect the dynamic behavior of each machine component on each machine tool. A productivity improvement by a factor of five seems to be a very large improvement. You can push a tool speed and feed only so much no matter how smooth it moves. What were you measuring to determine a five factor improvement? Paragraph (2) I think the reason all the commercial controls guard their software so close is they are all doing it the same way and don't want to fight proprietary battles. Math is math and there is only 1 best way to calculate something. They may have a few diversionary side tracks inserted to confuse the issue. I did geometric compensation on the 5 axis mill in the video. The kinematic file took a large number of variables and compensated all five axes for geometric inaccuracies such as the center line of the spindle did not pass EXACTLY through the center line of the A axis. Same for the B axis. The A and B axes were not perfect to one another. I collected data with a laser tracker and modified the variables until I saw the motion as shown by the three travel indicators. I am sure I could have tweaked the variables= to minimize needle movement but I believe I was at the all important point of diminishing returns. I reached my goal of the tool tip accurate to within +/-.005 during full travel of all axes. If someone puts a part on that machine requiring closer positioning the part is on the wrong machine. ---------- I like that you are working to improve the capability of LinuxCNC (by association and sharing). I have the algorithms done to implement 5 axis tool diameter compensation. I have not done it as figuring out how to do it in LinuxCNC seems way past my coding skill. After I completed the algorithms I found a paper by Fanuc. It showed their 5 axis cutter diameter compensation concept. It was exactly the same as what I had done. Their paper was produced far earlier than anything I did. It was a published paper and I didn't see any reference to a patent or copyright. It must not be their original work. Probably something so old and obvious I reinvented the wheel. UGH! What are some of the missing features you have identified? thanks Stuart On Sun, Nov 24, 2019 at 11:47 AM Herzog Raoul <[email protected]> wrote: > dear Stuart, > > there were several motivations for starting the OpenCN project : > > 1) We observed that productivity can often be increased compared to > commercial CNC, while maintaining the same geometrical tolerances and > surface quality of the machined piece. In order to do so, you need to > model the dynamical behaviour of the machine (vibrational behaviour). > We did this in a project, and we could achieve a gain of a factor 5 in > productivity compared to a Heidenhain CNC, while maintaining the same > quality of the machined piece. This is the ultimate goal (not yet > realized in OpenCN). > > 2) We observed that commercial CNC (Fanuc, Siemens, Heidenhain, ....) > are black boxes, and the trajectory planning algorithms are closed, > completely impossible for a user to change. > LinuxCNC is open, but the trajectory planning lacks jerk control, and > the C code of this part of LinuxCNC is really poorly documented. > > This was the motivation for starting OpenCN. > > Note that OpenCN is yet in an experimental stage with many features > missing. > We'll continue on academic side, and maybe some of our ideas could be > used to improve LinuxCNC in the future. > > best regards, > > Raoul > > > -----Message d'origine----- > De : Stuart Stevenson <[email protected]> Envoyé : dimanche 24 > novembre 2019 05:36 À : EMC developers > <[email protected]> > Objet : Re: [Emc-developers] announcement OpenCN, a new fork of > LinuxCNC > --> Precalculations > > Raoul, > What did you compare? Why did you start this project? Lead me through > your thought process. > I have the most interest in feedrate modification but if the part > quality can be improved and increase the feed then we have two of the three. > Faster - check > Better - check > Cheaper - ? > Thanks in advance for the education. > Stuart > > On Sat, Nov 23, 2019 at 10:09 AM Herzog Raoul > <[email protected]> > wrote: > > > dear Stuart, > > > > comparative examples between OpenCN and what, LinuxCNC, commercial > > CNC's > ? > > And comparing what, machining time, surface quality ? > > > > Not so easy, but one thing is clear : the jerk control is absolutely > > necessary for a CNC, otherwise for a given quality of the machined > > part you need to lower really a lot feedrate. > > > > best regards, > > > > Raoul > > > > -----Message d'origine----- > > De : Stuart Stevenson <[email protected]> Envoyé : samedi 23 > > novembre > > 2019 16:51 À : EMC developers <[email protected]> > > Objet : Re: [Emc-developers] announcement OpenCN, a new fork of > > LinuxCNC > > --> Precalculations > > > > Would it be possible to post some comparative example > > pictures/videos so I can better understand what you are fixing? > > Thanks > > Stuart > > > > On Sat, Nov 23, 2019, 5:43 AM Herzog Raoul <[email protected]> > > wrote: > > > > > dear Andrew, > > > > > > The RS274 interpreter is still the original, important concepts > > > like HAL, pins etc, are still there. > > > > > > Even with high end drives, you cannot simply stream position data, > > > the reference signals for each drive *must* respect the physical > > > constraints regarding max jerk, max acceleration and max speed ! > > > > > > Important for understanding : there is NOT ANY trajectory planning > > > INSIDE the drive, only feedback loops and feedforward. > > > > > > best regards, > > > > > > Raoul > > > > > > -----Message d'origine----- > > > De : Andrew <[email protected]> > > > Envoyé : samedi 23 novembre 2019 12:24 À : EMC developers > > > <[email protected]> > > > Objet : Re: [Emc-developers] announcement OpenCN, a new fork of > > > LinuxCNC > > > --> Precalculations > > > > > > Just wondering what's left from LinuxCNC there ) With such > > > intelligent servo drives you just have to stream the position data > > > (you made the new TP for that!). > > > Do you use Ethercat I/O too? > > > > > > сб, 23 лист. 2019 о 12:17 Herzog Raoul <[email protected]> пише: > > > > > > > dear Nicklas, > > > > > > > > there is no feedback control loop in OpenCN. > > > > Feedback and Feedforward is only inside the drives. > > > > > > > > We use TSD80E drives from the manufacturer Triamec ( > > > > https://www.triamec.com/de/triamec-servo-drives.html). > > > > The sampling frequency for the PWM, current control loop and > > > > position control loop is 100 kHz ! > > > > The setpoint values coming from EtherCat at a rate of 10 kHz are > > > > fine interpolated in the drive and upsampled to 100 kHz. > > > > > > > > One remark regarding our feedrate planning. > > > > At any time, at least one of the constraints is "active", > > > > meaning that either the max jerk is delivered, or the max > > > > acceleration, or the max > > > speed. > > > > Sometimes this is called "Bangbang", maybe a misleading term > > > > since there are no jumps in acceleration. > > > > Time optimality automatically leads to this "Bangbang" property. > > > > > > > > best regards, > > > > > > > > Raoul > > > > > > > > -----Message d'origine----- > > > > De : N <[email protected]> Envoyé : samedi 23 > > > > novembre > > > > 2019 10:51 À : EMC developers > > > > <[email protected]> > > > > Objet : Re: [Emc-developers] announcement OpenCN, a new fork of > > > > LinuxCNC > > > > --> Precalculations > > > > > > > > > dear Nicklas, > > > > > > > > > > of course, feedforwards are utilized (and well parametrized) > > > > > in the > > > > *drives*, otherwise excessive tracking errors appear. > > > > > > > > > > But this is done in the *drive*, *not* in OpenCN. > > > > > OpenCN calculates physically realizable setpoint values > > > > > (according to > > > > "optimal control theory"). > > > > > > > > Sounds really good. Physical realisable will be movement > > > > calculated with feedforward of maximum and minimum voltage with > > > > a perfect model, sounds simple but to calculate then it is time > > > > to slow down to exactly hit a point running at the limits is > > > > suprisingly hard to get correct for > > > all cases. > > > > > > > > Then there must be some room for the control law. You have gone > > > > further and included unperfect model and dynamics from the > > > > feedback in some way or other? > > > > > > > > > > > > Regards Nicklas Karlsson > > > > > > > > > > > > _______________________________________________ > > > > Emc-developers mailing list > > > > [email protected] > > > > https://lists.sourceforge.net/lists/listinfo/emc-developers > > > > > > > > > > > > _______________________________________________ > > > > Emc-developers mailing list > > > > [email protected] > > > > https://lists.sourceforge.net/lists/listinfo/emc-developers > > > > > > > > > > _______________________________________________ > > > Emc-developers mailing list > > > [email protected] > > > https://lists.sourceforge.net/lists/listinfo/emc-developers > > > > > > _______________________________________________ > > > Emc-developers mailing list > > > [email protected] > > > https://lists.sourceforge.net/lists/listinfo/emc-developers > > > > > > > _______________________________________________ > > Emc-developers mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/emc-developers > > > > _______________________________________________ > > Emc-developers mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/emc-developers > > > > > -- > Addressee is the intended audience. > If you are not the addressee then my consent is not given for you to > read this email furthermore it is my wish you would close this without > saving or reading, and cease and desist from saving or opening my > private correspondence. > Thank you for honoring my wish. > > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers > > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers > -- Addressee is the intended audience. If you are not the addressee then my consent is not given for you to read this email furthermore it is my wish you would close this without saving or reading, and cease and desist from saving or opening my private correspondence. Thank you for honoring my wish. _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
