Well in the fpga you have the encoder core running at around 100 Mhz, then you are attempting to count the indes pulses going into this HW core with a software cpu running at only 900 Mhz a bare 9 assembler ticks faster ...?
On Saturday, 14 September 2019 21:25:02 UTC+2, justin White wrote: > > Purpose is simply to see that every index input is caught in hal, it's a > test program.....there is no real purpose. > > That being said, I think the test just caught onto something that I didn't > realize might be a problem, that the index output of this particular > encoder may be intermittently broken. I swapped the A-channel of the > encoder into the index input of my board and it is much more reliably > catching that pulse. Sooooo, when I get a chance I'll yank the encoder out > of another machine and see what happens with that......could be a false > alarm. > > On Saturday, September 14, 2019 at 2:48:24 PM UTC-4, Michael Brown wrote: >> >> I would find it easier to follow you line of thought in this bug report >> if you would state the purpose.. >> So why ? >> And what are you trying to achieve ? >> >> On Saturday, 14 September 2019 20:04:42 UTC+2, justin White wrote: >>> >>> Doing a little testing on my hardware I noticed there is an issue with >>> encoder indexes being missed while trying to count them. It's difficult in >>> hal to see the index pin change state on an encoder with reasonable >>> resolution because the change in state is very short. So I added the >>> function in my GUI to count up the encoder index pulses because it's >>> obviously more visible when a number increments up vs trying to catch a >>> small blip in halshow or halcmd. I noticed the index pulses are missed >>> spinning the encoder at anything other than a very slow speed. I'm not >>> really sure what communication method mksocfpga uses between the fpga and >>> the cpu but I figured I'd try running a few non-fp components in a 0.2ms >>> base thread to see if it helped. Didn't really seem to help at all >>> >>> I first tried this by routing the hm2<board>index-input hal pin into the >>> updown component and sending the counts to a hal label in my gui. My first >>> thought is that the state change is too short for the servo-thread to catch >>> at 1ms, so I added the "edge" component to extend the length of the >>> index-input on it's output but that didn't really help. The output of edge >>> obviously only get's extended if it catches the input state change which it >>> does no better than updown. >>> >>> The conclusion I'm drawing is that the RT behavior of the CPU or the >>> communication between the FPGA and CPU cores is too slow for whatever >>> reason, that or there's some issue with the encoder module in mksocfpga's >>> hm2. I'm using 3 channels of a quad differential receiver chip for each >>> encoder input. There is no difference between the index channel and A-B >>> channels hardware wise, and this is the same on 6 identical instances of >>> encoder inputs. The only difference is that hm2 counts the A-B channels in >>> the FPGA while the index is not. I haven't seen any indication of missed >>> counts on the A-B channels counting 4000 edges in quadrature. I've messed >>> with the hm2 encoder sample-frequency too which also did not help. The only >>> thing that helped somewhat is running a 0.5ms servo-thread but it still >>> missed quite a few index's, and this is with me spinning the encoder by >>> hand. >>> >>> I use this same model of encoder on a LinuxCNC machine with a Mesa 7i96 >>> and again on a 7i76e and I've never really seen an index missed on those >>> spindle motors at ~3000rpms. If this isn't an issue with the hm2 encoder >>> module itself I'd expect to see the same issue with a normal GPIO input >>> missing short/fast pulses but I would think that someone else would have >>> noticed that issue by now? >>> >>> Thoughts? >>> >> -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/fd49dc1f-3358-4209-8c6e-ddc39098e81e%40googlegroups.com.
