Actually this is a better example because I do the exact same thing on this gizmo but in real use. The encoder is driven by a 2" diameter roller and the web driving it is running at 900fpm. That means the roller is spinning at ~1700 RPMs. That machine is using a much more complicated hal file, it counts index pulses (using updown) then triggers the an output on the comparator component. It's the same encoder, a 7i96 and a LinuxCNC PC @ ~2ghz with not great latencies, but it never really misses an index count. That machine runs a fairly huge Python file but all the logic is done in hal.
Point is that all things being equal I probably shouldn't have an issue seeing an index pulse in the same manner at 1/100th the speed at 900MHz. But like I said, I do alot of monkeying around, maybe I damaged this encoder in some way. On Saturday, September 14, 2019 at 5:21:32 PM UTC-4, justin White wrote: > > The "GUI" isn't counting the pulses. As I said/ I'm using the hal > component "updown" which is a RT component as any other. That component > outputs an unsigned integer that I just push to a gladevcp hal label. So > it's being "counted" at the servo thread rate of 1ms or the .5ms that I > briefly tried. I don't do any python coding or anything like that other > than a very simple Python file to load the GUI as you typically would. The > whole GUI is Hal files with a gladevcp interface, all it's doing is > printing the number on the updown count pin. > > The 900MHz CPU in and of itself can't possibly be the issue. The HM2 > encoder core runs at the same speed as it does on any of my Mesa ETH cards, > and being ETH cards it means I use a Preempt-RT kernel on those PCs as > well. An encoder spinning at 3000rpms and not missing a single pulse has > that index pulse state in several orders of magnitude less FPGA cycles than > me sitting here spinning an encoder by hand. A 2GHz x86 CPU with almost > equal latency has far less opportunity to recognize that hm2 pin state than > the Nano does at 900mhz with me spinning it by hand. > > On Saturday, September 14, 2019 at 5:01:39 PM UTC-4, [email protected] wrote: >> >> Sep 14, 2019, 20:04 by [email protected]: >> >> > 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? >> > >> Stupid question, but how exactly are you counting the Z pulses in your >> GUI? Are taking into account the non-RT nature of the GUI? >> >> I don't remember how exactly is the communication done in HostMot2, but I >> remember that you have to "compute" the index signal from A/B registers if >> you were to catch the sampling message (request and response from FPGA >> layer) outside the index occurrence. >> >> Cern. >> > -- 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/6ba00d4d-79e0-45bc-b7cb-0df4cfa5c085%40googlegroups.com.
