On 1/1/2014 9:24 AM, Bas de Bruijn wrote: > Hi, > > I got my Delta Type printer moving with the Machinekit image from Charles and > compiled with the lineardeltakins from Jeff Epler. Thank you guys for the > wonderful work, Also a big thanks to Michael and Bas for getting me up to > speed. I’m not yet ready to compile the ubc3+ja4 branch, but that’s just a > matter of time now that I’m plunging more and more into Linux and LinuxCNC. > > Here’s little video of my printer writing “LinuxCNC" on a piece of paper. > http://youtu.be/G2oQGTJH4Vc > > Now as I’m going froward I want to correctly set up my stepper motors. I > checked the step time, step space, direction and hold. I’m wondering if my > calculations are right regarding the setup of the stepping. > > When powering the motors in LinuxCNC I get the messages "stepgen.0/1/2.maxvel > is too big for current step timing & position-scale, clipping to max > possible". > Sometimes I get a joint following error. So I did some reading on the > LinuxCNC wike > > Am I going in the right direction if I calculate: > STEPLEN + STEPSPACE (each 1000ns for my stepsticks acc. > http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Latency-Test) = 2us > SCALE = 64 steps per mm (16x micro stepping) > STEPGEN_MAX_VEL = 2us with 64 steps per mm thus gives (1/2us)/64 = 7812.5 > > and that means my MAX_VELOCITY can never be higher than STEPGEN_MAX_VEL?
The default PRU task period is 10 uS, so the maximum step rate is 20 uS (10 uS high and 10 uS low). The 1000 nS times for STEPLEN and STEPSPACE are *MINIMUM* times, the actual time taken will be the smallest integer number of PRU task periods that is at least as long as each timeout. > When I run latency-test I get approx 60.000 ns jitter. But these are for > software stepping, and the PRU on beagle bone takes care of the stepping if i > read correctly. > > Now reading http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Following_Error where do > I set the BASE_PERIOD. > Is that the SERVO_PERIOD in the .ini file? The PRU task period is set using the pru_period= parameter when loading the module (default is 10,000 nS or 10 uS if not specified). If you want to reduce this value, make sure you leave enough overhead for the worst-case timing path through the PRU code. You can monitor the PRU active and idle time using the pru_busy_pin (defaults to enabled on PRU direct output 0). The PRU busy pin *MUST* be a PRU direct I/O, and you have to setup pin muxing to send the PRU bit to the I/O pin. By default the LCD/HDMI signals is using the PRU I/O bit 0, so you either need to move this signal to another pin, disable (or override) the HDMI pin multiplexing for PRU I/O 0, or just shorten the PRU task period and hope for the best (not recommended). -- Charles Steinkuehler [email protected]
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
