Matthew Glenn Shaver wrote: >On Mon, 2007-01-01 at 01:10 -0600, Jon Elson wrote: > > > >>I don't understand all the ramifications of this, but it seems some >>changes to EMC2 >>at some point changed the way homing to an encoder index pulse worked, >>and so >>it appears that you need that update if you want to use the axis index >>pulses to refine >>the home position. I am going to be investigating this over the next >>week or so to >>make sure homing to the index mark really works. >> >> > >I recently upgraded a STG driven CNC mill from EMC1 to EMC2. Homing on >an index pulse didn't work for me. I ended up setting the "home on index >pulse" parameters for all three axes to "NO" in the .ini file. Luckily a >precision home position wasn't critical to my client, but it is a loose >end... > > I think you need some hal commands to link axis.n.index-enable to the right pin of the stg driver so the encoder counter clears on the index pulse. That's what Chris Radek seems to think is now needed. I'm not sure this is going to work as the encoder position is going to have a big discontinuity at the index pulse. I will find out this afternoon, I need to redo the FPGA one more time to make the PPMC match the way the other boards work.
>Also, the estop control logic is slightly different in EMC2, not >necessarily wrong, but different. In EMC1 the ESTOP state would change >to ESTOP RESET only after pressing F1 and setting the "estop write" bit. >In EMC2 you go to ESTOP RESET as soon as "estop sense" is OK (the estop >chain is all continuous). In EMC1 the F1 key would toggle "estop write", >in EMC2 you have to break the estop chain to get from MACHINE ON to >ESTOP. Like I said not wrong, just different. > > > I had a problem with EMC2 going automatically from "estop reset" back to "machine on" when the external fault condition was cleared. Definitely not a safety feature! I fixed it with the hal components estop-latch, inverter and latch. See http://jelinux.pico-systems.com/codes/univpwm/univpwm_io.hal to see how I did it. This has an estop latch in the hardware, so I just had to make the software latch follow the hardware one. Note that the order the RT processes of these components are scheduled are critical, so that there is a one cycle delay between reading the hardware state and writing to it. >Finally I've found that keyboard jogging in tkemc is jerky. Starting a >jog move seems OK, but upon releasing the key the axis jerks to a stop >rather than smoothly decelerating. > > Hmm, I'm also using tkemc as I mucked up Axis on one of my computers and haven't fixed it yet. I was jogging up to 50 IPM yesterday, and I clearly saw on the scope matching accel and decel ramps. I do keep the accel pretty low to keep my weak servo motors and amps from hitting the current limit. If the following error accumulates during the constant-velocity part of the ramp, it may overshoot and then slam to a stop. Jon ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
