Good thoughts Jon and Gene, I was thinking the same thing. The count when running the encoder diagnostics keeps resetting to 0. So I will drag out my scope and see what I find. Hopefully a little checking of the grounds plus a braking resistor and I’ll be able to rigid tap. I’ve got a project coming up that involves tapping about a thousand 6-32 holes, hence this experiment. It’d be a real hassle to do it by hand. At any rate, I probably won’t get to it until Wednesday.
> On Jul 20, 2020, at 8:04 PM, Gene Heskett <ghesk...@shentel.net> wrote: > > On Monday 20 July 2020 18:57:03 Jon Elson wrote: > >> On 07/20/2020 05:27 PM, Matthew Herd wrote: >>> Working through Jon’s suggestions, the answers to his questions are >>> as follows. Also, I’m running version 2.7.11 if that helps. No >>> internet in my shop means it gets infrequent updates. >>> >>> Running the universal stepper diagnostics program with the command >>> sudo .univstepdiags 378 bus indicates board 0 is firmware version 3. >>> No board 1 is shown, boards 2 and 4-f are "No Board" and board 3 is >>> "Unknown." >>> >>> Running the command sudo .univstepdiags 378 indexres 3 (from a forum >>> post) gives me +517.00, +517.00, +517.00, and a jittery >>> +0.000/+/-1.000 that seems to increase/decrease (depending on CW/CCW >>> rotation) then go back to zero as fast as I turn the spindle. I can >>> see numbers greater than 1, but they flash back to zero within a >>> fraction of a second and keep jittering. >> >> Yes, that is normal. The position count is being reset to >> zero each time the encoder passes the index position. >> Turning it by hand, you might want to see it count up to >> whatever your quadrature counts/rev is, before it resets. >> If it keeps resetting to zero with just a little rotation, >> then you are getting pulses on the Z channel that is >> resetting the counter in between the index positions. That >> would be a hardware issue with the encoder or encoder wiring. >> >>> The encoder scale on axis 03 is "setp ppmc.0.encoder.03.scale 2048" >>> which is consistent with a 512 CPR encoder in quadrature. That’s >>> what I’ve got installed. >>> >>> the connection to LinuxCNC looks like this: >>> newsig spindle-index-en bit >>> linkps motion.spindle-index-enable => spindle-index-en >>> linksp spindle-index-en => ppmc.0.encoder.03.index-enable >>> >>> AND >>> >>> newsig spindle-pos float >>> linkps ppmc.0.encoder.03.position => spindle-pos >>> linksp spindle-pos => motion.spindle-revs >>> >>> At 3600 RPM (as reported from the encoder) the velocity is 60. At >>> 3600 RPM CCW, the velocity is -60. I don’t readily have a means of >>> verifying actual RPM, but the dial on the vari-speed head seems to >>> read lower than actual RPMs, though I understand this is consistent >>> with a worn varispeed drive. I also confirmed that one revolution >>> appears to correspond to one increase/decrease of the >>> ppmc.0.encoder.03.position as displayed by Hal Meter. I took care >>> to rotate it one revolution as closely as I could manage and the >>> results checked out. >>> >>> Regarding the index, I probed it with a meter and found the position >>> at which it triggers. I can confirm that it should work as it >>> showed 4.64V when at the index position. >>> >>> See below for my HAL files: >>> >>> univstep_motion.hal: https://paste.ubuntu.com/p/h66KJZx3hC/ >>> <https://paste.ubuntu.com/p/h66KJZx3hC/> univstep_io.hal: >>> https://paste.ubuntu.com/p/gMNkMwKDVw/ >>> <https://paste.ubuntu.com/p/gMNkMwKDVw/> univstep_load.hal: >>> https://paste.ubuntu.com/p/d36HgfwZ5Z/ >>> <https://paste.ubuntu.com/p/d36HgfwZ5Z/> univstep_servo.hal: >>> https://paste.ubuntu.com/p/wyb6JPX7ts/ >>> <https://paste.ubuntu.com/p/wyb6JPX7ts/> xhc-hb04.hal: >>> https://paste.ubuntu.com/p/w9mNn8hSdT/ >>> <https://paste.ubuntu.com/p/w9mNn8hSdT/> pycp_panel.hal: >>> https://paste.ubuntu.com/p/dVNwxHWJD2/ >>> <https://paste.ubuntu.com/p/dVNwxHWJD2/> >>> >>> I realize most of these are not likely to be relevant, but I’ve >>> included them anyway. The encoder is connected in the >>> univstep_motion.hal file. >>> >>> Also, re-testing the behavior, I seem to get two different outcomes >>> when I run G33.1. First error behavior is shown here: >>> https://youtu.be/GMspKB5ZkoQ <https://youtu.be/GMspKB5ZkoQ> and the >>> second error behavior is shown here: https://youtu.be/HJBOtFtXF5o >>> <https://youtu.be/HJBOtFtXF5o>. In the first behavior (which >>> appears to be random, but I didn’t restart axis repeatedly to test), >>> the spindle is running before the G33.1 command. It feeds downward >>> past the commanded 0.5" to 0.8125 or so, then stops Z motion while >>> it decelerates. Then it reverses, spins up to speed, and retracts >>> in what appears to be synchronized motion. The second error appears >>> to do the same until it hangs somewhere after reversing. It also >>> won’t respond to MDI commands. I had to go to manual mode and click >>> the spindle stop button to get it to respond. >> >> I have no idea what is causing this. You might set up >> halscope to trigger on the spindle reverse command and show >> Z velocity and spindle encoder position. The G33.1 is >> supposed to follow the encoder count until the command has >> completed. Clearly, it follows it for a while, then stops >> following it, and then in the first video it eventually >> follows it in the reverse direction. >> >> I did not see anything wrong in your hal files. >> >> Jon > > I think I'd drag out one of my 100+ MHZ scopes and look for noise of the > type one might get from lack of a single point ground. And accidental > ground loop from having the far end of a shielded cable grounded as > thats generally a no-no. Even what looks like good shop wiring can get > you in noise trouble. Best is to lift the grounds, one at a time, from > that single bolt in the control box, and check it to see if its still > grounded. If it still shows as grounded, find out where and isolate it, > hook that ground back up to your central bolt and go to the next one > until you have checked them all. > > This is called a "star ground" as it all starts at one bolt and does not > connect to a ground anyplace but that central bolt. > > The static ground in the power service cable should only be connected to > this bolt. That bolt, measured to a good dirt ground, may bounce 100 > kilovolts in a nearby lightning strike, but so will the 5 or 24 volt > stuff also connected to that bolt, and the voltage differential seen > will still be that 5 or 24 volts as far as the electrical stuff is > concerned, and none of it should be damaged by the strike that blew the > 50kw cans fuses out on the pole in the alley. > > Cheers, Gene Heskett > -- > "There are four boxes to be used in defense of liberty: > soap, ballot, jury, and ammo. Please use in that order." > -Ed Howdershelt (Author) > If we desire respect for the law, we must first make the law respectable. > - Louis D. Brandeis > Genes Web page <http://geneslinuxbox.net:6309/gene > <http://geneslinuxbox.net:6309/gene>> > > > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net <mailto:Emc-users@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/emc-users > <https://lists.sourceforge.net/lists/listinfo/emc-users> _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
