> On 5 Apr 2018, at 11:18, Rick Mann <rm...@latencyzero.com> wrote: > > Oops, sent to soon, and forgot the list. > > In addition to the responses below, I meant to add: I don't think what I'm > seeing is overshoot by the PID loop, at least not entirely, because when I'm > not jogging it, it only twiddles the direction output. The step output is > steady without pulses. If it were hunting, I'd imagine it would be issuing > steps as well as direction changes. Check out the other video: > https://www.youtube.com/watch?v=tQkF8TRVVpk > > Thanks! > >> On Apr 5, 2018, at 01:21 , Bas de Bruijn <b...@basdebruijn.com> wrote: >> >> >> >>> On 5 Apr 2018, at 09:50, Rick Mann <rm...@latencyzero.com> wrote: >>> >>> After help from Bas (thank you), I got MachineKit working on a Beaglebone >>> Black and driving a ClearPath stepper. Here's a video: >>> >>> https://www.youtube.com/watch?v=f3kdqH8Miyg >>> >> >> That's a hefty stepper. > > They're really nice servo motors from Teknic. The one in the video is > <https://www.teknic.com/model-info/CPM-SDSK-3421S-RLS/>. The ones I'm using > on my CNC router are a bit smaller. > >> >>> I notice on the oscilloscope (but not visible in the video above) that the >>> step direction output changes when I stop jogging and the servo slows down >>> from the jog speed it was going at. >>> >>> Can anyone tell me why it does this? Is it in an effort to "apply the >>> brakes" to the moving stepper? This is not necessary with the ClearPath >>> servo, which will faithfully the number of steps commanded at the commanded >>> speed (within limits, of course). >> >> This looks like "hunting" from the Pru stepgen. A solution for this is to >> drive the stepgen in velocity mode, and add a PID loop. Have a search thru >> the google group posts about this phenomenon. >> >> This configuration can be an example on how to do this. >> https://github.com/machinekit/machinekit/blob/master/configs/ARM/BeagleBone/Xylotex/Xylotex.hal > > The ClearPath servos have drivers, encoders, and PID loops all contained on > the motor. There is no position feedback from them (only a configurable fault > signal). For this reason, I don't think MachineKit should implement any kind > of PID loop, right? There's no feedback for it to use. It should just > generate pulses for the desired velocity profile and position, and trust the > servo to get there (if it can't, it will assert the fault signal).
This is a pru_generic thingy. Because it can't _exactly_ reach the commanded value, it will change direction all the time. So basically you use a PID component to have position values as input, and give out velocity commands to the pru_generic component/driver (in velocity mode instead of position mode). You don't need the position from your hardware. That's a closed loop system, driven by pulse/dir right? Basically you still have an open loop system though, because any pulse lost between your cape and the motor is not detected. > > In the pru-stepper.hal, there are these lines: > > # position command and feedback > net emcmot.01.pos-cmd <= axis.1.motor-pos-cmd > net emcmot.01.pos-cmd => [PRUCONF](DRIVER).stepgen.01.position-cmd > > net motor.01.pos-fb <= [PRUCONF](DRIVER).stepgen.01.position-fb > net motor.01.pos-fb => axis.1.motor-pos-fb > > I'm guessing "fb" is feedback. Maybe I can remove those to make it open-loop? the axis.1 is the feedback going into the motion component. If you break that you will get following errors. >> One thing to check are the specs of your driver regarding the timing of the >> step and direction signals. >> >> dirsetup dirhold steplen and stepspace. > > I did check these already. Step and dir hold minimum is 1 µs. The only other > minimum time specified is the time between direction change and step, > specified as 25 ns. Is that "dirsetup?" > >> >> These should be at least (but longer would be preferable) as long as the >> specs from your driver. >> >>> For reference, the HAL file <https://pastebin.com/cMTUiW7u>, and the .ini >>> file <https://pastebin.com/eBLxpUh4>. Note I've only adjusted the pin >>> addresses for axis 0 in the HAL, and the path to the PRU binary in the >>> .ini. It's the same as the pru-stepper otherwise. >>> >>> Thanks! >>> >>> -- >>> Rick >>> >>> -- >>> website: http://www.machinekit.io blog: http://blog.machinekit.io github: >>> https://github.com/machinekit >>> --- >>> You received this message because you are subscribed to the Google Groups >>> "Machinekit" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to machinekit+unsubscr...@googlegroups.com. >>> Visit this group at https://groups.google.com/group/machinekit. >>> For more options, visit https://groups.google.com/d/optout. >> >> -- >> website: http://www.machinekit.io blog: http://blog.machinekit.io github: >> https://github.com/machinekit >> --- >> You received this message because you are subscribed to the Google Groups >> "Machinekit" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to machinekit+unsubscr...@googlegroups.com. >> Visit this group at https://groups.google.com/group/machinekit. >> For more options, visit https://groups.google.com/d/optout. > > > -- > Rick Mann > rm...@latencyzero.com > > -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
