Bridgeport Retrofit - keyboard input delays noted

I would vote for solution #1, fixing it within Linuxcnc. In my case, my overrides come in via a pot on a game controller, via usb. Its a floating point, originating from a pot. People can handle the overrides in many fashions and a bit of noise is to be expected. I recall someone said the override HALUI inputs are 8 bit, that means one could have 256 steps in their override function. Putting a bit of noise rejection within Linuxcnc would lower that a bit but 256 is far more than normally required. Fixing it within Linuxcnc leaves all the various hardware choices for overrides available to the user without having to try and mask this problem in HAL somehow.

I think Mark using pots is something common and to be expected in the future. Ditto for usb gamepads employing pots.

There was a education here, I never considered the noise spikes as dither, but A to D converters do indeed dither one or two bits normally. No doubt that is what Marks HALSCOPE paste shows.

You should not have more than a LSB or so of noise from a clean input
If you have more noise than this is would make sure you have the correct ground
for the input:

(TB2 pin 8, _not_ logic ground)

(this still will need treatment to avoid dithering the FRO)

Thanks again for the comments andypugh. Of the 3 solutions that you suggest, my vote is obviously Option 1 but since i have no control over that and I am a realist, that one is not really an option for immediate use. Option 2 is probably above my pay grade. I can barely use the components available. I can't see me creating such a component. Option 3. I could swap out my simple pots for encoders (i suppose that is the way things are going these days. ie. volume control on my car radio. where has the time gone.) I haven't looked at this in depth but I assume that will use up 2 of the 6 encoder inputs available. I am using 3 now for axis control, plan one for spindle feedback and have hopes of a trunnion with servos using 2 more. You can see that I don't have 2 more available. Another board perhaps to use digital fro and sro instead of pots?

Is it possible to use unused field i/o input pins instead of encoder inputs if I were to swap pots for simple encoders?

Since FRO/SRO doesn't require high accuracy (just reliability) it seems a bit like using an air compressor, hose, electrical cable and a nail gun and then try to figure how to only partial drive the nails when all i want to do is tap in 2 nails and hang my coat and hat up in the shop. Seems like the hammer is the right tool.

The 4th option is to see what I can do with the existing HAL components to further mask the effects of dither.

The last one is to ignore it. I have been able to pretty well mask the original problem. No need to process a constantly changing FRO/SRO signal. No delays noted. Just a little dither once in a while. It seems that I headed down an intriguing technical path but....

Thanks PCW. I do have a question regarding the correct logic/signal ground. I have the field (24v and TB2-4&8 ) supply tied across 2 10K pots. The wipers of the 2 pots go to the 7i77 analog inputs TB8 1&2. The ground for this is TB2-8. Is that correct? Is there better option?

Thanks again all for the assistance. I hope someone else is able to use the information in this thread to their advantage.

Mark

Your pots are connected correctly (I just wanted to make sure that the 9V battery test was connected that way as well)
The 7I77 field inputs are filtered but have a fairly fast time constant so shielded cable may be required to get the lowest noise.

Note that as Andy mentioned, you will always have some dither in analog inputs, (your "spikes" represent 2 LSBs of noise)
Some encoders dither as well if their optical sensors have no hysteresis.

So in any case you may need something to help eliminate the dither (A hysteresis component?)

If you want to use encoders for FRO/SRO you can use field inputs 16,17,18,19 and 7I77 software mode 3
to support 2 MPG type encoders (5V signaling)

PCW, yes, the neg term of the battery was tied to the field gnd. If I understand correctly, cheap encoders may still exhibit dither and thus require the same processing that my pots do.

andypugh, thanks for the code. As usual, this looks pretty simple on the surface. Wonder what educational experiences I'll enjoy researching and implementing (and perhaps modifying) the code in your sample "backlash" component. I guess its why we do this though. Option 2 here we come..... Who knows? For grins, I may just experiment with simple encoders too.

Mark

I looked at those and found they don't ship to north america. I'll search around when I get some more free time.....