Thanks all for the input. I don't think I'm presenting the problem quite right, so I'll try to provide more detail, but for those not interested in that the specific technical problem I am hoping to solve is that I have configured a software encoder that does not seem to handle frequencies above about 500Hz. I think it should be able to handle much higher, based on my base period and the rest of the system.
The relevant configuration is like so: the ini file: ... [EMCMOT] EMCMOT = motmod COMM_TIMEOUT = 1.0 COMM_WAIT = 0.010 SERVO_PERIOD = 1000000 ... [HAL] HALUI = halui HALFILE = 3300_mill.hal HALFILE = custom.hal POSTGUI_HALFILE = custom_postgui.hal SHUTDOWN = shutdown.hal ... main hal file: ... loadrt [EMCMOT]EMCMOT base_period_nsec=10000 servo_period_nsec=[EMCMOT]SERVO_PERIOD num_joints=[TRAJ]AXES ... the custom.hal file: source analog-in.hal the analog-in.hal file: #http://linuxcnc.org/docs/devel/html/hal/rtcomps.html#sec:Encoder # hm2_5i23.0.gpio.048.in is the freqeuncy in # load the component loadrt encoder num_chan=1 setp encoder.0.counter-mode true #encoder.0.phase-A net analog-A encoder.0.phase-A <= hm2_5i23.0.gpio.048.in # set the velocity of the encoder for a proper scale setp encoder.0.position-scale 1.0 # set the volicity out to feed the analog input net analog-1 <= encoder.0.velocity # add the component to the thread addf encoder.update-counters base-thread addf encoder.capture-position servo-thread The full config under revision control at: http://code.google.com/p/sector67-sandbox/source/browse/#svn%2Ftrunk%2FProjectSheetCake%2Fconfigs%2F3300-mill%2Fedm I am using a Mesa isolated I/O card, and previously had thought the delay was 7uS, but that was for output. For input the delay can be as high as 25uS, but I think I should still easily be able to read 5kHz (200uS period) with that delay. It acts like it is sampling the encoder at the servo-thread frequency, despite the update-counters function being bound to the base-thread. When I view the configuration from axis, the base-thread does show the encoder.update-counters function bound to it. Sorry for all of the technical details, but I feel I am missing something simple here and so wanted to provide the info I had. Thanks! Scott More technical details follow for those interested: The mill itself is a conversion of an generic 3-axis servo Bridgeport-class knee mill from Anilam 3300 controls to LinuxCNC. We’ve also added a stepper-based 4th rotary axis. We’re using a Mesa 5i23 PCI card with a 7i23TA quad analog servo interface daughter card on the first 50 pin connector for interfacing with the servos and a 7i37TA isolated anything I/O adapter on the third 50 pin connector for integrating estop, limits, servo enable, etc. The second 50-pin connector is not optically isolated and is used to drive the stepper axis amp for the A axis. So the for the Mesa firmware I’ve configured 4 encoders and 4 pwms (three of each used) and 4 stepgens (one used). These are assigned to the first and second connectors respectively.**** ** ** More details here:**** ** ** http://code.google.com/p/sector67-sandbox/wiki/3300MillConversion**** ** ** and here:**** ** ** http://code.google.com/p/sector67-sandbox/wiki/FourthStepperAxis**** ** ** In general both LinuxCNC and the Mesa hardware have worked absolutely great and the mill is completely functional as-is.**** ** ** This is a machine for a hackerspace (sector67.org), and we now have a member interested in doing some plunge EDM. He’s working on the hardware high-voltage DC/fluid side of things and I’m working on the motion control portion, which basically boils down to reading an analog value and determining based on that whether to retreat, stay put or plunge further. I wrote a simple gcode loop that handles that logic, but need to create an interface between the EDM hardware and LinuxCNC that provides the gcode loop enough information to make a movement decision.**** ** ** There are lots of ways of doing that, but my initial thought was to take a relatively low-cost approach and use an Arduino for analog sensing and have that create a frequency pulse. Doing so is fairly trivial on the Arduino.** ** ** ** Given that this is EDM, voltage isolation is paramount. As a result, my hope was to use my isolated I/O daughter card on the third connector, which has ample I/O available as a software-based encoder input and use the velocity from that as the analog value in LinuxCNC. This works for low frequency input, but falls apart much more quickly than I expected at higher frequencies (about 500Hz). I’ll send my configuration later tonight when I have access to it in case I am making a silly mistake there.**** ** ** It seems like my options are basically:**** ** ** **1) **Have the arduino generate a frequency and work out the issues with the software encoder counting. This is my preferred approach, as it will let me add more analog inputs when we eventually want to use this mill for other things like playing with 3d printing with multiple heated head temperatures and a heated bed temperature to measure and who knows what else.**** **2) **Have the arduino generate binary output and use a weighted sum component to get the analog value. This will eat up I/O quickly, but is probably workable as a short term solution.**** **3) **Have the arduino generate a frequency and use a custom Mesa firmware and have it count encoder pulses on-card using the third connector with the isolated I/O daughter card. This is probably technically feasible, but as this machine is collectively maintained by a diverse group of hackers, I want to try and stay on the beaten path as much as possible.** ** ** ** I’d really like to get the software encoder approach working, and feel like I must be missing something simple for it to not be able to handle anything above about 500Hz.**** ** ** Hope that helps clarify the situation,**** ** ** Scott On Thu, Mar 15, 2012 at 11:43 AM, Kirk Wallace <kwall...@wallacecompany.com>wrote: > On Thu, 2012-03-15 at 10:56 -0500, Scott Hasse wrote: > > I'd prefer not to use the mesa encoder primarily because I want to use > > the optical isolation I already have on the 7i37. Additionally with > > the firmware setup I have (4 pwm, 4 encoders, 4 stepgens) and the 3rd > > 50 pin cable for io like estop and limit I only have one Mesa-based > > encoder available with no optical isolation. Ideally I'd like to run > > multiple analog inputs. > > > > Although if I go the weighted sum route I'd be limited by my io as > > well. > > > > It seem I must be doing something wrong with the software encoder > > though, as i think it should easily be keeping up with the frequencies > > I'm sending, > > > > Thanks, > > > > Scott > > Opto-isolators might be considered slow. From my experience, they might > be good to tens of kilohertz to maybe a hundred kilohertz with the the > fast ones setup properly. Data signals generally don't need to be nearly > as fast, so I would tend to isolate the data instead of the analog > signals. > > I wonder... these should be pretty fast: > http://en.wikipedia.org/wiki/Small_form-factor_pluggable_transceiver > > http://www.jameco.com/webapp/wcs/stores/servlet/Product_10001_10001_1552798_-1 > > -- > Kirk Wallace > http://www.wallacecompany.com/machine_shop/ > http://www.wallacecompany.com/E45/index.html > California, USA > > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
