On 9/8/2013 3:42 PM, John Prentice (FS) wrote: > > For new inputs, I need to work through Brandon's stuff on my system. The > para: > > We'll use X-Max, the limit switch closest to the PWM outputs at the edge of > the BeBoPr. According to the BeBoPr manual, the BeagleBone black manual > (BBB_SRM.pdf pg 80), and tracing the board traces, the X-max input switch is > pin 32 on connector 8 and gpio0.11. > > has me puzzled. I cannot find the BeBoPr manual anywhere on CircuitCo and > have not got one (or a Bridge) to trace tracks :-( The .dts file suggests > Brandon's numbers are non-Bridge and X-max will be P8-9 (gpio2.5)
There is a manual...I'll send it off-list. There is also a pinout chart (which is IMHO even more helpful) as part of the Bridge board github project: https://github.com/modmaker/BeBoPr-Bridge/blob/master/BBB-P8-P9-signals.pdf ...also, check out the wiki pages on the BeBoPr github project, there's a lot of good info there too: https://github.com/modmaker/BeBoPr/wiki/BeBoPr-Bridge > Finally a detailed question: I notice on the 'scope that the DIR lines have > random looking waveforms (around 500 Hz - but different patterns on each > axis) after a keyboard jog has stopped. An axis DIR goes quiet (at LO) after > a G-code move of the axis. Is this behaviour intentional? If not might it > hide a bug on Setup/Hold times of the DIR line - I ask as in another life I > have been bitten by the small, but very nasty to find, loss of position > errors that invalid timing can produce on some stepper drivers? It's not a bug, it's caused by the fact that the PRU is an actual independent timebase and not an exact integer fraction of the servo thread (as happens with software step-gen). What you're seeing is the position 'hunt' around the desired set point as the servo thread attempts to zero out the error but the real-world effects like IRQ latency, jitter, and the fact that LinuxCNC is calculating new servo commands based on the theoretical ideal that it sampled the position instantly and without jitter at the start of the servo period, and takes exactly zero time to calculate the new commanded stepper velocity. All the applicable setup and hold times are still being honored, the commanded step rate is just oscillating between very small values on either side of zero. The 500 Hz rate comes from the servo thread, which is running at 1 mS (the sign tends to invert each pass through the servo thread). Feel free to write some squelch code to get rid of this if you want, but it's not really any different than the minor "hunting" that goes on with "real" servo motors and encoders when at rest, so I haven't worried about it. -- Charles Steinkuehler char...@steinkuehler.net
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
_______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
