On Monday 20 July 2020 20:30:59 Matthew Herd wrote: > 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. > Be sure and let us know what you find Matthew.
> > On Jul 20, 2020, at 8:04 PM, Gene Heskett <[email protected]> > > 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 > > [email protected] > > <mailto:[email protected]> > > https://lists.sourceforge.net/lists/listinfo/emc-users > > <https://lists.sourceforge.net/lists/listinfo/emc-users> > > _______________________________________________ > Emc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-users 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> _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
