On Thursday 12 January 2017 00:27:15 Peter C. Wallace wrote: > On Wed, 11 Jan 2017, Gene Heskett wrote: > > Date: Wed, 11 Jan 2017 23:11:51 -0500 > > From: Gene Heskett <ghesk...@shentel.net> > > Reply-To: "Enhanced Machine Controller (EMC)" > > <emc-users@lists.sourceforge.net> > > To: emc-users@lists.sourceforge.net > > Subject: Re: [Emc-users] Two questions. > > > > On Wednesday 11 January 2017 22:37:46 Peter C. Wallace wrote: > >> On Wed, 11 Jan 2017, Gene Heskett wrote: > >>> Date: Wed, 11 Jan 2017 21:50:19 -0500 > >>> From: Gene Heskett <ghesk...@shentel.net> > >>> Reply-To: "Enhanced Machine Controller (EMC)" > >>> <emc-users@lists.sourceforge.net> > >>> To: emc-users@lists.sourceforge.net > >>> Subject: Re: [Emc-users] Two questions. > >>> > >>> On Wednesday 11 January 2017 13:34:50 Peter C. Wallace wrote: > >>>> On Wed, 11 Jan 2017, Jon Elson wrote: > >>>>> Date: Wed, 11 Jan 2017 10:36:18 -0600 > >>>>> From: Jon Elson <el...@pico-systems.com> > >>>>> Reply-To: "Enhanced Machine Controller (EMC)" > >>>>> <emc-users@lists.sourceforge.net> > >>>>> To: "Enhanced Machine Controller (EMC)" > >>>>> <emc-users@lists.sourceforge.net> Subject: Re: [Emc-users] Two > >>>>> questions. > >>>>> > >>>>> On 01/10/2017 10:45 PM, Gene Heskett wrote: > >>>>>> On Tuesday 10 January 2017 23:02:28 Jon Elson wrote: > >>>>>>> On 01/10/2017 08:39 PM, Gene Heskett wrote: > >>>>>>>> But if I hook up the halscope, the apparent quadrature error > >>>>>>>> is worthless due to the 1KHz servo-loop timing limiting the > >>>>>>>> bandwidth. > >>>>>>> > >>>>>>> Well, that's why we use hardware encoder counters, as > >>>>>>> sampling the quadrature at 1 KHz just isn't fast enough. > >>>>>>> > >>>>>>> Jon > >>>>>> > >>>>>> Plz elucidate Jon. Something has got to be better than this. > >>>>>> See the pix I posted with the last reply to Peter & the list. > >>>>>> The top, white trace in the halscope screen is the quadrature > >>>>>> noise, easily 10x the timing wibbles I see on the hitachi's > >>>>>> screen. > >>>>> > >>>>> If you are looking at the quadrature signals at a 1 KHz > >>>>> sampling rate, then unless the encoder is moving quite > >>>>> slowly, the sampling will be too coarse. That screen shot > >>>>> is kind of small (you can take just a single window as the > >>>>> screenshot, by the way) but it looks like the duty cycle of > >>>>> the encoders is not 50%. That may well be aliasing, as the > >>>>> quadrature signals seem to be moving much too close to 1000 > >>>>> Hz. You'd get much better results below 100 Hz. Or, with > >>>>> Mesa hardware, you can sample these with the base thread. > >>>>> > >>>>> I can't comment on the velocity output from the Mesa, as I > >>>>> don't know their gear (or driver). But, the scale is 2/div, > >>>>> meaning the scaled velocity output is jumping around 2 user > >>>>> units up and down at a KHz rate. Clearly, not good. > >>>>> > >>>>> Jon > >>>> > >>>> The velocity output is calculated by using the number of counts > >>>> divided by the time between the counts (time measured via a 1 MHz > >>>> timestamp). If you have less than 2 counts per servo period the > >>>> velocity estimation accuracy depends heavily the quadrature > >>>> phase/symmetry since the edge spacing entirely determines the > >>>> estimated velocity at this speed range. > >>>> > >>>> I suspect what Genes plot shows is that he has significant > >>>> quadrature phase/symmetry errors at the FPGA inputs. > >>>> > >>>> > >>>> Again here is a velocity plot of a accurate 100 Hz quadrature > >>>> signal: > >>>> > >>>> http://freeby.mesanet.com/100_Hz_quadrature_velocity.png > >>> > >>> I've not played with the stepgen type 2 yet, but I have adjusted > >>> the quadrature a few thousandths and reduced it by about 1/3rd. > >>> Thats helpfull as I can filter to smooth a tach dial once I have > >>> defeated the noise. > >>> > >>> But I have another concern. I have had to do a full powerdown > >>> reset to clear a watchdog bite. The original config was I think > >>> intended to clear it by re-enabling the machine, but I could > >>> nolinuxcnct, so I disconnected > >> > >> that > >> > >>> reset in the hal file I started with as the logic was self > >>> feeding, locking out the ability to reset the disabled machine. > >>> And I couldn't even do it from the halconfig as it claimed another > >>> signal was driving it when I tried to setp that pin. > >>> > >>> Do you, Peter, have a logic diagram I can re-construct for that, > >>> that actually works? > >> > >> You need to restart linuxcnc to clear a watchdog bite > >> > >>>> Peter Wallace > >>>> Mesa Electronics > > > > That didn't work, I have since had to do full power downs with at > > least 15 seconds off time. 5 or 6 times now. > > That probably means the watchdog bite is not the issue but a symptom > of some kind of system crash.
Which is a puzzle. Despite standing there looking at the "watchdog has bit" message, only the power led is lit. I have it running fairly noise free today, and had no such problems. However it appears that I may have blown the #0 stepgen, as data is going in, its enabled, but nothing is coming out of other either pin 1-1 (step) or pin 1-3 (dir). So I added another one in the config, and will re-configure the hal file to use it for the X axis. Where I'm working on the back side of this is just a hair crowded, and more than 10 times my clothing has rubbed on the 2" of blue styro glued to the inside of the garage door, giving be a weak, just enough to make me aware of it shock when I touched the machine for the first time after walking around to the back of it. I had the current to the Z motor set pretty high, and I know just enough about how microstepping works to know that the current mapping per microstep needs to be mapped to move the motor nearly the same per micro-step. But the mapping in the DM860 doesn't match this motor's map, a 1600oz 4 wire, by a huge error, so I am hearing 4 very quiet steps followed by 4 huge steps. I am reducing the motors current everytime its powered down, and its getting smoother and quieter as I reduce it, which is promising. So far I haven't hurt its top speed, which seems to be something north of 120 IPM, about 100 IPM faster than this same motor & DM860 driver could move the head on the G0704. Its timing belt coupled, 30 teeth on the motor, 40 teeth on the Z screw. But its too long a job to fix the hal file, and fit another block connector to connect the driver wires to stepgen #2 yet tonight. That crimper for those teeny pins I am gradually getting the hang of as there isn't a load a pin, then insert the wire, and finish the crimp position. But I've managed to do the last 5 or 6 without having to redo them. Provided I don't miss roll call, there's always tomorrow. :) Thanks all. 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) Genes Web page <http://geneslinuxbox.net:6309/gene> ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
