I did a little reading on the BBB's PRU and that looks great for Motion control projects with it's ability to perform tasks at very low latency. I would be interested to find out if it has full access to using the eQEP module while maintaining low latency. That looks to be just what I need, but I am wondering if it would be a bit over my head since I have no experience with the BBB and PRU programming.
As far as the counters go, I agree that may be a better solution. I assume they would be able to count up and down when direction is changed without losing count, but would the operator be able to change the value of the stroke's upper or lower limit on the fly without losing position? This is a bit new to me. I also find some nice IC's from sold by US digital they may help with this task: http://www.usdigital.com/products/interfaces/ics http://cdn.usdigital.com/assets/general/LS7366R.pdf While this is somewhat of a simple task (not simple for me I guess), it is part of a larger project I am working on. I am retrofitting (for the second time now) a Moore G18 CNC Jig grinding machine. I did a partial retrofit about 6 years ago with using Mach3 motion control software which made the machine a hybrid of the new control and the old 1982 GE control. This time I am using Mach4 software and trying to eliminate the old control completely. The Mach4 software is doing a good job of controlling the X&Y axis Motion (via external PMDX-424 Motion controller) but it doesn't seem like a good setup for this particular task due to latency. The software has an internal PLC loop that runs every 50ms which creates overshoot of the set limits. This is not a big deal because we can set hard stops, the problem is that the latency seems inconsistent and I am getting odd behavior such as changing direction halfway through a stroke as seen in this video on the 3rd or 4th stroke: https://www.youtube.com/watch?v=L82Gi7fmf28&feature=youtu.be What ever my end solution is, The operator needs the ability to change the upper or lower stroke limit quickly and easily on the fly. The PLC loop is working great for that, it just isn't very responsive or consistent. It looks like there are a lot of different ways to approach this, I am just trying to figure out which would be the simplest method to integrate with the existing motion control software. On Saturday, September 10, 2016 at 9:26:07 PM UTC-4, Dennis Lee Bieber wrote: > > On Sat, 10 Sep 2016 15:04:23 -0700 (PDT), beezerlm > <[email protected] <javascript:>> declaimed the following: > > > > > I have a fairly simple motion control project I was planning on > using > >an Arduino for, but my understanding is that the arduino's 16Mhz clock > >won't keep up with my encoder pulses. I will need to process a max of > >10,000 pulses per second. The project is to control 1 reciprocating > >pneumatic cylinder and to simply monitor the position and change > direction > >at a programmable in/out position. Is this within the capabilities of > the > >BBB? > > Rather fast for a motion encoder... I think my Kenwood > transceivers > only produce 1000 pulses per rotation (well, maybe twice that to account > for direction), and spinning that dial faster than 1 rotation per second > is > difficult. > > Using the /sys filesystem access is highly unlikely to keep up. > Memory > mapping the GPIO block might, or writing code for the PRUs (200MHz -- an > input loop using 100 instructions is still around 2MHz vs 10kHz) > > > OTOH: you may be looking at the matter from the wrong side. > > If you need to catch just a position to command some valves... > Perhaps > all you need is a simple hardware counter using the pulse stream as an > input. Full counter range scaled to the full encoder range, trigger set > for > the specific count at the position to activate. Hardware counter is > probably much faster than a software loop. Getting to the counter from > plain Arduino may take some experimenting (I've not looked for a preset > library function) > https://sites.google.com/site/qeewiki/books/avr-guide/counter-atmega328 > -> > CTC mode on counter 1 (16-bit) might be the type of operation you need. > > The BBB may have something similar, but a quick Google didn't > blind me > with anything obvious. Granted, to date the most ambitious thing I've done > is to prove that a DHT-11 humidity/temp sensor can not be read from Python > using the /sys filesystem access, nor from a C program using that mode > either. [Oh... And running the old HINT benchmark -- which, contrary to > the > authors' expectations, didn't really scale well over 20 years: had to cut > the RUNTM parameter from 1.0 seconds to 0.001 seconds, and still got a > warning that the 16-bit integer benchmark was too fast for precision] > > -- > Wulfraed Dennis Lee Bieber AF6VN > [email protected] <javascript:> HTTP://wlfraed.home.netcom.com/ > > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/e1bb6539-ad55-42b4-ba5f-5554c7f3e050%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
