It is quite correct to latch the data, before reading out in byte chunks, so no roll over occurs in the hi byte going from 00FF to 0100 for instance, if there is a count pulse during reading . I forgot about that part.
j. On Sat, Mar 2, 2013 at 8:57 PM, Klemen Dovrtel <[email protected]>wrote: > I see, if i understand this correctly, i should add a two-stage > synchronizer to latch the data from QuadA/B before sampling with counter > logic? > > Ok, thank you for the suggestions, i will try to add some filters, as > suggested also by Jan de Kruyf. > > Regards, Klemen > > > > > > ________________________________ > From: Peter C. Wallace <[email protected]> > To: Klemen Dovrtel <[email protected]>; Enhanced Machine > Controller (EMC) <[email protected]> > Sent: Saturday, March 2, 2013 7:14 PM > Subject: Re: [Emc-users] fpga epp data transfer - strange behaviour > > On Sat, 2 Mar 2013, Klemen Dovrtel wrote: > > > Date: Sat, 2 Mar 2013 09:38:34 -0800 (PST) > > From: Klemen Dovrtel <[email protected]> > > To: "Enhanced Machine Controller (EMC)" <[email protected] > > > > Subject: Re: [Emc-users] fpga epp data transfer - strange behaviour > > > > I think this can not be the reason, this would not trigger glitches only > > while decreasing the encoder value. My epp data transfer is started with > > address write which triggers the sampling and latching of encoder > position > > value and all other signals values. The following data read/write are > then > > dealing only with latched values which can not change during the data > > transfer. > > > > > > Redards, Klemen > > > OK thats good > > There is also a mistake in the counter logic related to sampling external > asynchronous signals (QuadA and QuadB) in multiple places (this will cause > occasional wrong states when an input is changing whan sampled) > > But if you have big transient errors, I would look at the EPP interface. In > our EPP interface we required digital filters on control signals as the > signals from the parallel port (especially with a long cable) are quite > slow > and dirty relative to the FPGAs clock speeds. > > > > > > > > > ________________________________ > > From: Peter C. Wallace <[email protected]> > > To: Enhanced Machine Controller (EMC) <[email protected]> > > Sent: Saturday, March 2, 2013 4:45 PM > > Subject: Re: [Emc-users] fpga epp data transfer - strange behaviour > > > > On Fri, 1 Mar 2013, Klemen Dovrtel wrote: > > > >> Date: Fri, 1 Mar 2013 23:23:48 -0800 (PST) > >> From: Klemen Dovrtel <[email protected]> > >> To: "Enhanced Machine Controller (EMC)" < > [email protected]> > >> Subject: [Emc-users] fpga epp data transfer - strange behaviour > >> > >> Hello everybody, > > > > I am using fpga to monitor the incremental encoder and transfer the axis > > absolute position to pc using parallel port and epp communication. When > I run > > the Axis GUI I am getting some strange following errors. I found out that > > occasionally i get some bad axis position data transfer from the fpga. > But > > what is very strange that this happens only when the axis moves in > negative > > direction and never when it moves positive direction or stays still > (please > > see the image attached)). So i thought there must be some bug in pfga > encoder, > > not in epp communication, but i have no idea what could possibly be > wrong - > > the code is very simple (i pasted it below). > > > > I increase the servo-thread period, but the result was the same. I also > tried > > to locate a certain position of axis when the data is bad, and i could > not do > > this - it seems this is happening randomly. > > > > Does anybody have some idea where to look for the error? > > > > Regards, > > Klemen > > > > My first guess is that you are not sampling the 32 bit count atomically, > That > > is, with the EPP transfers you are reading the count as 4 individual > bytes so > > you must latch all 32 bits of the count at the beginning of the 4 byte > > transfer so that you dont have scrambled data in your 32 bit count if the > > count happens to change when reading. > > > > > > > > Peter Wallace > > Mesa Electronics > > > > (\__/) > > (='.'=) This is Bunny. Copy and paste bunny into your > > (")_(") signature to help him gain world domination. > > > > > > > ------------------------------------------------------------------------------ > > Everyone hates slow websites. So do we. > > Make your web apps faster with AppDynamics > > Download AppDynamics Lite for free today: > > http://p.sf.net/sfu/appdyn_d2d_feb > > _______________________________________________ > > Emc-users mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > ------------------------------------------------------------------------------ > > Everyone hates slow websites. So do we. > > Make your web apps faster with AppDynamics > > Download AppDynamics Lite for free today: > > http://p.sf.net/sfu/appdyn_d2d_feb > > _______________________________________________ > > Emc-users mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > Peter Wallace > Mesa Electronics > > (\__/) > (='.'=) This is Bunny. Copy and paste bunny into your > (")_(") signature to help him gain world domination. > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > Emc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-users > ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
