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/90c9c4d2-8073-47b0-8bef-27ed125ebb5d%40googlegroups.com.
