Every time I have implemented PID based motor control the PID loop runs on a low-cost microcontroller and then the main computer sends the PID a series of set-points. Micros work well as most of them nowadays have hardware quadrature decoders and can handle over a million lines per second. The $4 Raspberry Pi Pico is at least an order of magnitude faster than needed for this use case. You don't need an FPGA as a $4 micro is already overkill.
That said, LCNC just uses very powerful computers so it should be able to run nested PID loops. If you make velocity (*velocity*, not acceleration or motor current) a function of the position error then the motor wil slow down as it gets closer. There is also likely a good way to use feed forward with just a single PID loop. On Mon, Sep 20, 2021 at 9:05 AM dave engvall <dengv...@charter.net> wrote: > Hi all, > To the best of my knowledge any version of the lcnc pid is in software. > OTOH mesa does offer SOFTDMC which does run in/on mesa fpga products. > However, that breaks the core concept of multiple vendors and real ease > of user modification of the software although there are a few in this group > that could fiddle the code for an fpga. In addition softdmc needs all > the support written to wrap around it; interp, task, etc. Years ago I > head a rumor tht someone had tried to do it and abandoned the effort. If > I recall correctly it does offer something besides trap accel, controls > jerk and runs on a 50 us clock. > The manual is available online. > Dave > > On 9/19/21 5:12 PM, Chris Albertson wrote: > > Is the PID controller running on the PC under LCNC or is this an external > > PID controller you built? > > > > What are the numbers, the loop period, motor speed and numer of encoder > > lines. and so on? > > > > I don't think the fact that there is a worm gear matters. The problem, I > > bet is the large inertia of the system. > > > > Aside from proper tuning of the PID gains you could change the system to > > use a nested or "cascade" PID. THis allows the velocity setpoint to be > > controlled by the position error > > see the section "cascade" in the wiki article > > https://en.wikipedia.org/wiki/PID_controller > > > > I think you want a very fast loop i=for the inner PID. LIkely it > > wouldbe in external hardwarelike a microcontroller or FPGA. (does MESA > do > > the PID algorithm in the FPGA? It should.) > > > > > > > > On Sun, Sep 19, 2021 at 3:39 PM Gene Heskett <ghesk...@shentel.net> > wrote: > > > >> Greetings all; > >> As most of you know, I built a servo from scratch for a BS-1. > >> > >> But I am not at all happy with its performance. > >> It is a motor with a worm output, driving the worm of the bs-1. And it > >> has an A/B quad encoder in it. > >> > >> But I must rather severely limit its run speed because the PID doesn't > >> see the null coming near fast enough to slow it and stop a couple > >> arcseconds early. I can't allow it to use reverse to stop as the motor > >> seems to be a near short circuit then, crowbarring the power supply, > >> causing a 2 to 3 minute dead time for the 450 watt psu to cool, so I > >> must limit its speed to disallow its use of reverse to accomplish the > >> stop. With 2 worms in series the scale for a 360 degree full turn is of > >> coarse huge. If it could be throttled to a gradual stop by anticipating > >> the coming null, I could probably run it 2 to 4x faster for a cruising > >> speed. > >> > >> So my question is, which of the pid inputs would if raised, better > >> anticipate the approaching null, slowing it over the last 5 angular > >> minutes of a turn, ideally to a stop within an arc-second of the command > >> from the gcode? > >> > >> Thanks all. > >> > >> Cheers, Gene Heskett > >> -- > >> "There are four boxes to be used in defense of liberty: > >> soap, ballot, jury, and ammo. Please use in that order." > >> -Ed Howdershelt (Author) > >> If we desire respect for the law, we must first make the law > respectable. > >> - Louis D. Brandeis > >> Genes Web page <http://geneslinuxbox.net:6309/gene> > >> > >> > >> _______________________________________________ > >> Emc-users mailing list > >> Emc-users@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/emc-users > >> > > > > > > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > -- Chris Albertson Redondo Beach, California _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
