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/49efaecf-ff85-47ad-bd49-7b0557a7a62c%40googlegroups.com.
