On Sunday 26 January 2014 13:14:29 Charles Steinkuehler did opine: > I'm working on adding software encoder support to the BeagleBone PRU > code. Counting up/down is easy, but I'm wondering how to deal with the > index pulses. Both the Mesa VHDL code and the existing software encoder > component have quite a variety of options, and I'm wondering if it is > necessary to support them all (more options = longer code = lower > operating frequency). > > If you use encoders on your machine, what options do you have set for > the HAL component, and (if you know) what is the maximum pulse frequency > for your machine?
I do, but not on a BB yet. I am using a 50 slot optical disc, A/B/X, with ATM about a 2000 rpm max spindle speed. With the older motor & gearing it was 2500 revs tops and still had considerable headroom. Currently that calculates to 150 microseconds per slot edge, with a 23 u- sec base thread. So my sample rates theoretically have a more than sufficient time to do their work. Where 100x or more accurate knowledge would be required to move a joint precisely than the 2.4 degrees I get, and the number of joints to track is some multiple of 3, or even 9, I can easily see a missed count situation arising since my safety factor for one, the spindle, is only 6. But at more normal, say 600 rpm turning speeds, there isn't any excuse to miss a count, ever. That data then could be used to infer the maximum velocity that a joint could be expected to move w/o errors in tracking it in real time. In the case of the BBB, maybe its time to set an output pin true as the encoder module is entered, and clear it before that final return, and develop some timing information that would give us a better handle on our estimates of just how much processing time is actually used by hal out of each base-thread incarnation, ditto the TP and servo-thread? That information would certainly be enlightening. Even just having hal set the flag pin going in, and clearing it when it falls back to idle, which I have to assume in some cases won't be a spin in place, but to finish an unfinished servo or TP thread incarnation. The hal method would be far simpler, and by tossing a # in front of a modules addf, an individual modules execution time can be deduced. Its more complex than that of course in terms of editing the hal file, but still something that needs to be done. We might find that the BBB really doesn't have the computational iron to do the job. While I'm happier than that famous pig with my pair of atoms, I have also found that it does have some real limits in an all software situation. Where there are multiple joints per axis, that strikes me as a very strong argument in favor of hardware solutions that are hopefully 100 to 1000x faster than software unless call a surveyor to set stakes speeds are usable for that job. Since the machine needs to bill at a profit to justify even bidding on the job, I cannot imagine a situation where those limited speeds would be justifiable. Either build state of the art, or stay home like I do. Cheers, Gene -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> NOTICE: Will pay 100 USD for an HP-4815A defective but complete probe assembly. When in doubt, tell the truth. -- Mark Twain A pen in the hand of this president is far more dangerous than 200 million guns in the hands of law-abiding citizens. ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
