[Emc-developers] jog wheel problem

[Stuart Stevenson]

Gentlemen,
Setup at Helix (my shop)
Wheezy
Linuxcnc2.7 - git pull and compile this morning
PPMC interface
Jog Wheel - Fanuc type A60-0201-5001 - 100 detents per wheel revolution
Touchy interface with Rapid Over Ride choice added and the MV: label
changed to DRY RUN.

Setup at MPM (my old shop)
Wheezy
Linuxcnc2.7 from the live cd
PPMC interface
Jog Wheel - two different wheels - 100 detents per wheel revolution
Touchy interface as supplied on the live cd.

Moving the machine with the jog wheel doesn't yield the proper movement
amount.

Moving the Helix machine over ride (rapid, feed, spindle and dry run) is
correct.
Moving the MPM machine over ride (feed, spindle and mv) is correct.

There is no machine connected at Helix.
I have the servo error set at .200 for each axis [X,Y,Z] to allow room to
pulse the axis motions.

MPM has the control running the Enshu.

.010 setting per pulse
First detent positive or negative shows motion of .0075.
Subsequent clicks show .0075 or .01 moves each click.
The error is essentially the same but does vary somewhat with minor
differences.
Reverse detents back to zero shows reliably back to 0.0000.
You can watch the position feedback transition through .0025 steps until it
stops counting wherever is stops counting (correct or not correct).

Smaller pulse setting show similar motion errors but the .0010/.0001
display limit masks the exact error amount.

Moving the jog wheel 10 detents rapidly shows .1000 axis movement both
directions. Moving 10 detents rapidly back to zero shows sometimes a
position error of 0.0025 and sometimes no position error.

If this happened only here at Helix I would say nothing and replace my jog
wheel BUT this same scenario is replayed on the Enshu at MPM. MPM has tried
two different jog whThere is no machine connected at Helix.
I have the servo error set at .200 for each axis [X,Y,Z] to allow room to
pulse the axis motions.

eels and both jog wheels yield the same result.

MPM says the machine cuts correctly under cnc control.

Another issue:
Is there a non zero P value for the G64 command as a default?
If so how would I set the default to zero?

thank you for your attention and feedback
Stuart

[Gene Heskett]

Post by Stuart Stevenson
Gentlemen,
Setup at Helix (my shop)
Wheezy
Linuxcnc2.7 - git pull and compile this morning
PPMC interface
Jog Wheel - Fanuc type A60-0201-5001 - 100 detents per wheel
revolution Touchy interface with Rapid Over Ride choice added and the
MV: label changed to DRY RUN.
Setup at MPM (my old shop)
Wheezy
Linuxcnc2.7 from the live cd
PPMC interface
Jog Wheel - two different wheels - 100 detents per wheel revolution
Touchy interface as supplied on the live cd.
Moving the machine with the jog wheel doesn't yield the proper
movement amount.
Moving the Helix machine over ride (rapid, feed, spindle and dry run)
is correct.
Moving the MPM machine over ride (feed, spindle and mv) is correct.
There is no machine connected at Helix.
I have the servo error set at .200 for each axis [X,Y,Z] to allow room
to pulse the axis motions.
MPM has the control running the Enshu.
.010 setting per pulse
First detent positive or negative shows motion of .0075.
Subsequent clicks show .0075 or .01 moves each click.
The error is essentially the same but does vary somewhat with minor
differences.
Reverse detents back to zero shows reliably back to 0.0000.
You can watch the position feedback transition through .0025 steps
until it stops counting wherever is stops counting (correct or not
correct).
Smaller pulse setting show similar motion errors but the .0010/.0001
display limit masks the exact error amount.
Moving the jog wheel 10 detents rapidly shows .1000 axis movement both
directions. Moving 10 detents rapidly back to zero shows sometimes a
position error of 0.0025 and sometimes no position error.
If this happened only here at Helix I would say nothing and replace my
jog wheel BUT this same scenario is replayed on the Enshu at MPM. MPM
has tried two different jog whThere is no machine connected at Helix.
I have the servo error set at .200 for each axis [X,Y,Z] to allow room
to pulse the axis motions.
eels and both jog wheels yield the same result.
MPM says the machine cuts correctly under cnc control.

It has the clues that the jog information isn't being fed into motions
axis.L.jog-value or jog-counts correctly. Checkable with a hal meter.

Perhaps I can explain it as I've applied it to this Sheldon lathe I'm
currently cnc'ing.

I develop, by way of entirely too many hal steps, a jog-value, and a
jog-count. These are independent values. The jog-value is a scaled
according to the size of the step move desired, and can range
from .0001" to .020" over the range of a 0-7 counter. The counter is
decoded by a bitslice to make the 3 address bits for a mux8. Each input
to the mux8 is setp'd to the above value on a 1,2,5 range sequence, like
the gain on a good scope.

This value, however you determine it, is fed to "axis.L.jog-value" where
L is an axis name character.

The next signal to check is "axis.L.jog.counts", which for one click is
an increment of 4 at the encoder out for one "click" at the jog wheel.
So this value is fed to a mult2, with the 2nd input setp'd to .2500000.
The mult2 output of one count per click is then fed into
axis.L.jog-counts. And it moves exactly the amount I've set the
jog.value to be. This is in machine units so I'm dealing in inches. I
have a tally showing that value as part of my axis gui. I drive the 0-6
counter, not by the mult2 output, but by an and2 thats tied to the
encoders A/B pins, so its only true 25% of the time. And I have a 30
second timeout after the release of the jog set pushbutton beside each
wheel that resets the encoder and disables the jog.count back to zero
from whereever it is. If I need more time, I tap the pushbutton for
another 30 seconds.

My biggest problem is that this jog information into the motion module,
doesn't appear to be acceleration constrained by the MAX_ACCEL settings
in the .ini file, so a large jog per step seems to be an instant joint
following error. This on a machine being run by a raspberry pi 3b, with
nary a PID loaded.

Before its all done, I'll need to extract a rockhopper file so that I can
verify that I have the addf's in the correct, everything just falls thru
in one thread execution cycle order. The logic for the jog wheel is
running in a 1/5th servo-thread thread, set by a call to threads,
setting it to 200 hz which I can't quite manage to overrun with my
ancient fingers. Despite all this, the pi appears to loafing, less than
10 to 12% of the cpu is running linuxcnc bits and pieces.

And during the time the wheel is active, I can spin the wheels pretty
fast if the jog-value is only 1 or 2 thou, no miss-queue's of note. I am
still experimenting with reducing the acceleration settings. Maybe
there is one that applies. I have not yet resorted to a lowpass filter
in the jog-counts path, but might have to yet. ATM I am up to my buns in
alligators working on the spindle drive, someone back in the mists of
time installed the pulley on the countershaft reversed left for right
while they were replaceing the spindle drive belts, missing the key, and
expected the set screw to lock it to the shaft. The slippage created a
ton of heat and ate the bore out of the pulley, so I am in the process
of installing a taperlock hub in the pulley to salvage both parts.

Back to this.

Bottom line is that what you feed jog-value controls how far per step if
what you feed jog-count is an increment or decrement of one per detent
felt by your fingers. This to me, seems like the logical way it ought
to work.

FWIW, I finally use the last of those 3 small ball screws you sold me
several years back, its in the crossfeed for this 11x36 Sheldon I am
rebuilding/converting.

I hope this helps you find your scale problem, Stuart, and I thank you
for favors past.

If this is still muddy, I can send my hal file, or even the gui stuff too
if you'd like.

Post by Stuart Stevenson
Is there a non zero P value for the G64 command as a default?
If so how would I set the default to zero?

G64 P0 I think. I've had to do that here a time or 3. Thats not setting
the default, but you can add that to the RS274 init string in the ini
file, which may as well be the default.

Post by Stuart Stevenson
thank you for your attention and feedback
Stuart

Cheers Stuart S., Gene Heskett

[Stuart Stevenson]

Gentlemen,

Thanks Gene - you have given me some things to think about and work on.
I will be working on this today.


another bit or two of information

I have tried a differential mpg with slightly better results but still with
errors.

Has anything changed to cause this as the config files are the same ones
running the machine for years. The only difference is the LinuxCNC version.

Thank you for your attention and comments.
Stuart

[Gene Heskett]

Post by Stuart Stevenson
Gentlemen,
Thanks Gene - you have given me some things to think about and work
on. I will be working on this today.
another bit or two of information
I have tried a differential mpg with slightly better results but still
with errors.
Has anything changed to cause this as the config files are the same
ones running the machine for years. The only difference is the
LinuxCNC version.

That I can't answer Stuart, the raspbarry pi 3b is running Jessie. and
the linuxcnc is the devel branch for 2.8-pre. And its the only machine
I've put wheels on. Mainly the apron on TLM isn't big enough to carry
wheels. For the bigger mill I just carry the keyboard to it, and the
little mill's keyboard shelf is just above and to the right of its table
with a sheet of lexan between them. TLM's keyboard is directly in front
of it, with a sheet of light alu trying to keep swarf out of the
keyboard, poor success though. :) I have a custom molded skin on TLM's
keyboard but it sure makes it hard to type, needing 3x the keypush it
does w/o the cover.

The wheel code is at least half of the hal code for the Sheldon, and I
still have a ways to go because I have yet to mount and configure
homeing switches. And, because of the plumbing across the right side of
the saddle, I'd like to add a z limit if its about to hit the tailstock
& that would bend up the plumbing. 3 pieces of 5/16" bore SS pipe carry
the wiring from the cable chain on the rear, to all the stuff on the new
apron panel. Intended at one time to be used as fuel line on a so-called
stock car, but the neighbor got out of that and gave me the leftovers.
So I intend to fab a bracket to hold a limit switch that will contact
the base of the tailstock in time to save things from a doofus operator,
aka me. :)

In retrospect, I wish we had a counter directly driveable by the a/b
signals from the wheel, but the updown module we have has separate
upcount and downcount inputs, so I had to use a wcomp for direction
detection, which feeds 2 and2's and feeds the on period of the a/b
signals from a 3rd and2 so as to fabricate the separate up and downs
drives. Works well when the button is pushed enabling it with more
and2's, but what a rube goldberg pile of hal code just to do that alone!
But w/o more wires in the cable, impossible to do away with.

As a friend to whom I often quote, this stuff keeps me out of the bars,
and his reply was that I do the craziest stuff to stay out of a bar.

Anyway, check the jog-value to make sure its the right size in machine
units, and the jog-counts to see if its one per felt detent, and it
should Just Work(TM) If not, fix whichever is wrong. With the addf
order being important, make sure the jog-enable isn't out of time so it
misses a pulse on one end or the other. So thats 3 places that could
mess with you. Good luck!

Post by Stuart Stevenson
Thank you for your attention and comments.

Cheers Stuart, Gene Heskett

[Jon Elson]

Post by Stuart Stevenson
Gentlemen,
Setup at Helix (my shop)
Wheezy
Linuxcnc2.7 - git pull and compile this morning
PPMC interface
Jog Wheel - Fanuc type A60-0201-5001 - 100 detents per wheel revolution

John Kasunich gave out some old Fanuc MPGs at a code fest
quite some years ago. There are two pots inside the back
that set the level for the two photosensors. I had to turn
mine all the way up to get reliable signals out of them. I
think the LED in the encoder had faded. It was obvious when
checking the A and B outputs that they were "spotty" and
very far from 50% pulse width. So, you ought to check the A
and B outputs.

The PPMC encoder card, when in single-ended input mode, has
a logic threshold of 2.5 V. If the encoder output has weak
pull-up, it might be helpful to put a 1K Ohm pull-up
resistor to +5V on the A and B lines.

Jon

[Kirk Wallace]

Post by Jon Elson

Post by Stuart Stevenson
Gentlemen,
Setup at Helix (my shop)
Wheezy
Linuxcnc2.7 - git pull and compile this morning
PPMC interface
Jog Wheel - Fanuc type A60-0201-5001 - 100 detents per wheel revolution

John Kasunich gave out some old Fanuc MPGs at a code fest
quite some years ago. There are two pots inside the back
that set the level for the two photosensors. I had to turn
mine all the way up to get reliable signals out of them. I
think the LED in the encoder had faded. It was obvious when
checking the A and B outputs that they were "spotty" and
very far from 50% pulse width. So, you ought to check the A
and B outputs.
The PPMC encoder card, when in single-ended input mode, has
a logic threshold of 2.5 V. If the encoder output has weak
pull-up, it might be helpful to put a 1K Ohm pull-up
resistor to +5V on the A and B lines.
http://www.wallacecompany.com/machine_shop/fanuc_mpg/fanuc_mpg_index.html

I got what I thought was a good deal on three of these. One had very
little detent pressure so I tried to fix it.

It looks like there are a lot of these at a decent price if one shops
around a bit. Watch out for shipping cost though. These have large
wheels, or what I consider normal.
http://www.ebay.com/itm/171287795365
http://www.ebay.com/itm/151583672829

[Stuart Stevenson]

further developments

testing with single and differential mpg yielded similar but slightly
different results

halshow revealed ilowpass losing random counts between in and out

removal of ilowpass yielded much better results but still not perfect

the single mpg was better after removal of ilowpass but still not good

the differential mpg was perfect after removal of ilowpass
the differential mpg was then connected as a single mpg yielding perfect
results

it seems the ilowpass has a problem
it seems the single mpg has a problem
the differential mpg works as a single and as a differential mpg

Does anyone have questions/suggestions regarding the ilowpass?

thanks
Stuart

[Jon Elson]

Post by Stuart Stevenson
further developments
testing with single and differential mpg yielded similar but slightly
different results
halshow revealed ilowpass losing random counts between in and out
removal of ilowpass yielded much better results but still not perfect

VERY interesting. I use ilowpass here, as the servos make
nasty buzzing noises if I don't. And, I frequently count
off clicks on the MPG, and have never noticed it losing
counts. I do have to hold the jog enable button until the
last MPG click has been dribbled out to the axis, or I would
lose some counts on the last click. That takes less than a
second.

Now, I am using ilowpass on a 2.6 install, possibly
something has changed. Also, check that you have ilowpass
addf'ed to the right thread. It ought to be running on
servo-thread. You can compare your hal code to this :
http://pico-systems.com/codes/jebport/pendant.hal

As for the single vs. differential, you could watch
ppmc.0.encoder.xx.count and ilowpass.0.out with halscope or
halmeter. After movement stops, these numbers SHOULD be
identical. If they aren't, that sure indicates where the
problem is. If they ARE identical, then crank the MPG some
exact number of turns at different speeds, and see if the
encoder is not producing as many counts as expected.

If the A and B outputs of the encoder have crosstalk (Seen a
LOT of this when driving long cables) it can screw up the
digital filtering of the encoder counter. So, say, A and B
are both high and the encoder makes a transition to A low,
crosstalk on the cable can cause B to momentarily pulse
low. That is an illegal quadrature state transition (only
one line is supposed to change at a time). The encoder
counter is supposed to reject such transitions and wait for
a valid one. But, if it happens a lot, like at EVERY count,
the filtering can fail. Pull-up resistors might help in
this case by establishing better resting logic levels from
the encoder.

Jon

[andy pugh]

Post by Jon Elson
Now, I am using ilowpass on a 2.6 install, possibly
something has changed.

Nothing has changed since 2014
https://github.com/LinuxCNC/linuxcnc/commits/master/src/hal/components/ilowpass.comp

The whole component is only 2 lines of code:

;;
value += (in - value) * gain;
out = (int)(rtapi_s64)(value * scale);

[Jon Elson]

Post by andy pugh

Post by Jon Elson
Now, I am using ilowpass on a 2.6 install, possibly
something has changed.

Nothing has changed since 2014
https://github.com/LinuxCNC/linuxcnc/commits/master/src/hal/components/ilowpass.comp
;;
value += (in - value) * gain;
out = (int)(rtapi_s64)(value * scale);

Right. Jeff Epler wrote that for me at one of the CNC
Workshops at Roland Freistad's place. It is so SIMPLE, I am
having some trouble seeing how it could be the culprit,
unless maybe given very wrong parameters.

Anyway, comparing the input and output from ilowpass should
confirm that it is (or is not) causing the problem.
I'm thinking there is a combination of a weak encoder output
drive, electrical noise, maybe A<-> B crosstalk and the PPMC
encoder counter is counting somewhat erratically. I think
putting Halmeter on the encoder count output and then
cranking the encoder known distances at varying speeds might
quickly show this is happening. (or not...)

Jon

[Kenneth Lerman]

Up the thread a ways, Gene commented that the MPG generates one count per
detent.

I thought that the encoder in the MPG generates one *cycle* per detent. A
cycle is represents four quadrature edges which means that you get four
counts per cycle. So that's four counts per detent.

There is a complication that there is one count of hysteresis involved
here. So if you turn clockwise and then reverse directions, you might be
off one count from where you started. If you repeatedly go back and forth
though, you should not accumulate more than one count of deadband.

Going back to Stuart's original post where he says that he sees motions of
.0075 or .01 per click, that is what I would expect if there was some back
and forth motion at some of the clicks. Stuart also sees that the error is
not accumulating.

My conclusion is that what Stuart is seeing is an artifact, not an error.

Ken

Kenneth Lerman
55 Main Street
Newtown, CT 06470

Post by andy pugh

Post by andy pugh

Post by Jon Elson
Now, I am using ilowpass on a 2.6 install, possibly
something has changed.

Nothing has changed since 2014
https://github.com/LinuxCNC/linuxcnc/commits/master/src/

hal/components/ilowpass.comp

Post by andy pugh
;;
value += (in - value) * gain;
out = (int)(rtapi_s64)(value * scale);

Right. Jeff Epler wrote that for me at one of the CNC
Workshops at Roland Freistad's place. It is so SIMPLE, I am
having some trouble seeing how it could be the culprit,
unless maybe given very wrong parameters.
Anyway, comparing the input and output from ilowpass should
confirm that it is (or is not) causing the problem.
I'm thinking there is a combination of a weak encoder output
drive, electrical noise, maybe A<-> B crosstalk and the PPMC
encoder counter is counting somewhat erratically. I think
putting Halmeter on the encoder count output and then
cranking the encoder known distances at varying speeds might
quickly show this is happening. (or not...)
Jon
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Gene Heskett]

Post by Kenneth Lerman
Up the thread a ways, Gene commented that the MPG generates one count
per detent.

It does not, the encoder scale is set to 4, so at the encoder out,
one "click" is 4, but later I mult2 that by .2500000, and this is what
is fed to jog-counts.

Post by Kenneth Lerman
I thought that the encoder in the MPG generates one *cycle* per
detent. A cycle is represents four quadrature edges which means that
you get four counts per cycle. So that's four counts per detent.

Correct it seems. Thats exactly why I divide by 4 in the mult2 module

Post by Kenneth Lerman
There is a complication that there is one count of hysteresis involved
here. So if you turn clockwise and then reverse directions, you might
be off one count from where you started. If you repeatedly go back and
forth though, you should not accumulate more than one count of
deadband.

Once I had slowed the MAX_ACCELS to get rid of the joint errors, I find
that I can crank as fast as I can, overrunning the axis motor so it goes
on a bit, but then I can crank it back the other way, and IF I started
at a touched off zero, and the dial on zero when I touched off, and then
crank back and reset the dial to zero, and look at at the dro, it also
says zero, so I am not losing any counts.

But I should point out that for step range setting, due to the input to
our updown counter, I am obtaining the fwd/reverse signal from the
encoders velocity output with a wcomp. But this is only for the step
size adjustment, not the actual step itself.

Another thing I'm doing, is, when the activity timer expires, everything
except the step size, here on this lathe is directly in inches starting
at .0001" on a 1,2,5 sequence, is reset to all balls, so each such timed
interval starts from scratch. This circuit has no hysteresis, and this
reset at timed out may have something to do with that. I'm in hog heaven
with how its working except that each axis has to be moved by some
amount before the dials can move it. Once I have home switches installed
that motion will qualify, but ATM its a PITA because that required
motion destroys the positioning from when it was shut down, and which is
restored on startup. As far as I am concerned, pressing F2 should enable
them just like everything else is. But something else has to move an
axis before the dial can.

My time ATM is spent on the spindle driving pulley, and the G2/G3 is
again eating my days as there seems to be no proper order for it to use
an 0/0 set of moves in relative mode to cut a circle wherever the hell
the code drives it to, and which is to be considered the center of the
counterbore I want to cut. The start to finish error is always 50%
according to the popup during the reload. I'm going to make that a
separate post however.

Post by Kenneth Lerman
Going back to Stuart's original post where he says that he sees
motions of .0075 or .01 per click, that is what I would expect if
there was some back and forth motion at some of the clicks. Stuart
also sees that the error is not accumulating.
My conclusion is that what Stuart is seeing is an artifact, not an error.
Ken
Kenneth Lerman
55 Main Street
Newtown, CT 06470

Post by andy pugh

Post by andy pugh

Post by Jon Elson
Now, I am using ilowpass on a 2.6 install, possibly
something has changed.

Nothing has changed since 2014
https://github.com/LinuxCNC/linuxcnc/commits/master/src/

hal/components/ilowpass.comp

Post by andy pugh
;;
value += (in - value) * gain;
out = (int)(rtapi_s64)(value * scale);

Right. Jeff Epler wrote that for me at one of the CNC
Workshops at Roland Freistad's place. It is so SIMPLE, I am
having some trouble seeing how it could be the culprit,
unless maybe given very wrong parameters.
Anyway, comparing the input and output from ilowpass should
confirm that it is (or is not) causing the problem.
I'm thinking there is a combination of a weak encoder output
drive, electrical noise, maybe A<-> B crosstalk and the PPMC
encoder counter is counting somewhat erratically. I think
putting Halmeter on the encoder count output and then
cranking the encoder known distances at varying speeds might
quickly show this is happening. (or not...)
Jon
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers

----------------------------------------------------------------------
-------- Check out the vibrant tech community on one of the world's
most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers

Cheers, Gene Heskett

[Gene Heskett]

Post by Kenneth Lerman
Up the thread a ways, Gene commented that the MPG generates one count
per detent.
I thought that the encoder in the MPG generates one *cycle* per
detent. A cycle is represents four quadrature edges which means that
you get four counts per cycle. So that's four counts per detent.
There is a complication that there is one count of hysteresis involved
here. So if you turn clockwise and then reverse directions, you might
be off one count from where you started. If you repeatedly go back and
forth though, you should not accumulate more than one count of
deadband.
Going back to Stuart's original post where he says that he sees
motions of .0075 or .01 per click, that is what I would expect if
there was some back and forth motion at some of the clicks. Stuart
also sees that the error is not accumulating.
My conclusion is that what Stuart is seeing is an artifact, not an error.
Ken

I am seeing none of that effect, Kenneth. I bought 3 of those dials,
putting 2 of them on the Sheldons apron, but and have checked all three,
and all three are A=B=0 at rest. I have not been able to trigger such a
1 count anomaly. Nor have I observed a move (as recorded by the screen
DRO) that was not an exact multiple of stepsize-per-click*steps moved.

I would like to have it so the displayed step size was displayed in the
metric or imperial measurement system in use by the display, but I have
not found a way to extract the view displays mode, either in axis or
motion, I find no such pin/signal/parameter available. I wouldn't mind
being able to make the size of the jog change according to the view
mm/inch mode, making this code much more universally usable regardless
of the flag flying over the local real estate. Is there a debug=
setting that would cause this to be exposed?

Am I blind?

Post by Kenneth Lerman
Kenneth Lerman
55 Main Street
Newtown, CT 06470

Post by andy pugh

Post by andy pugh

Post by Jon Elson
Now, I am using ilowpass on a 2.6 install, possibly
something has changed.

Nothing has changed since 2014
https://github.com/LinuxCNC/linuxcnc/commits/master/src/

hal/components/ilowpass.comp

Post by andy pugh
;;
value += (in - value) * gain;
out = (int)(rtapi_s64)(value * scale);

Right. Jeff Epler wrote that for me at one of the CNC
Workshops at Roland Freistad's place. It is so SIMPLE, I am
having some trouble seeing how it could be the culprit,
unless maybe given very wrong parameters.
Anyway, comparing the input and output from ilowpass should
confirm that it is (or is not) causing the problem.
I'm thinking there is a combination of a weak encoder output
drive, electrical noise, maybe A<-> B crosstalk and the PPMC
encoder counter is counting somewhat erratically. I think
putting Halmeter on the encoder count output and then
cranking the encoder known distances at varying speeds might
quickly show this is happening. (or not...)
Jon
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers

----------------------------------------------------------------------
-------- Check out the vibrant tech community on one of the world's
most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers

Cheers, Gene Heskett

[Stuart Stevenson]

Gentlemen,
Having the problem on 4 mpg's (three single and on diff) I am relatively
sure the problem isn't hardware.

Halshow (watch) shows the encoder counts accurate and ilowpass counts are
incorrect I suspect ilowpass.
ilowpass is so simple it is almost impossible to see how it could be
incorrect also it has run correctly on the same machine for years without
problems.

I blame the change that was made and that is the new operating system and
the new LinuxCNC version.

The hal file shows everything running on the servo thread. It is the same
hal file as before.

I moved the ilowpass down the list to right in front of the write statement.

I have the same result.

The initial direction loses a count.

ppmc encoder count moves 4 each detent.
ilowpass moves 3 for the first move and 4 thereafter
motion reversal resyncs the counts until zero is reached
reversing again loses a count again as long as zero has not been passed

results as follows

start machine
encoder count = 0
ilowpass in = 0
ilowpass out = 0

move positive one click
encoder count = 4
ilowpass in = 4
ilowpass out = 3

this relationship is maintained while moving in the same direction for as
far as I moved

upon motion reversal encoder count, ilowpass in, and ilowpass out are the
same until I pass 0

the next click past 0 the count then becomes
encoder count = -4
ilowpass in = -4
ilowpass out = -3

and it maintains this relationship until motion reversal
upon motion reversal the counts are the same again until I go past
zero.

The same but opposite behavior depending on counts being positive or
negative.

all comments/suggestions welcome

thanks
Stuart

[John Kasunich]

try changing line 38 from:

out = (int)(rtapi_s64)(value * scale);

to

out = (int)(rtapi_s64)((value * scale)+0.5);


This looks like a case where the floating point 'value' might be 3.9999999, but the conversion to integer results in 3
Adding 0.5 makes it round to the nearest integer.

Although I bet that will make it worse, not better, for negative input values.

There is an "all integer" way do to the lowpass filter that is immune to the rounding problem, but first step is to confirm that it is indeed a rounding problem.

John

Post by Stuart Stevenson
Gentlemen,
Having the problem on 4 mpg's (three single and on diff) I am relatively
sure the problem isn't hardware.
Halshow (watch) shows the encoder counts accurate and ilowpass counts are
incorrect I suspect ilowpass.
ilowpass is so simple it is almost impossible to see how it could be
incorrect also it has run correctly on the same machine for years without
problems.
I blame the change that was made and that is the new operating system and
the new LinuxCNC version.
The hal file shows everything running on the servo thread. It is the same
hal file as before.
I moved the ilowpass down the list to right in front of the write statement.
I have the same result.
The initial direction loses a count.
ppmc encoder count moves 4 each detent.
ilowpass moves 3 for the first move and 4 thereafter
motion reversal resyncs the counts until zero is reached
reversing again loses a count again as long as zero has not been passed
results as follows
start machine
encoder count = 0
ilowpass in = 0
ilowpass out = 0
move positive one click
encoder count = 4
ilowpass in = 4
ilowpass out = 3
this relationship is maintained while moving in the same direction for as
far as I moved
upon motion reversal encoder count, ilowpass in, and ilowpass out are the
same until I pass 0
the next click past 0 the count then becomes
encoder count = -4
ilowpass in = -4
ilowpass out = -3
and it maintains this relationship until motion reversal
upon motion reversal the counts are the same again until I go past
zero.
The same but opposite behavior depending on counts being positive or
negative.
all comments/suggestions welcome
thanks
Stuart
--
Addressee is the intended audience.
If you are not the addressee then my consent is not given for you to read
this email furthermore it is my wish you would close this without saving or
reading, and cease and desist from saving or opening my private
correspondence.
Thank you for honoring my wish.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Sebastian Kuzminsky]

Post by Stuart Stevenson
results as follows
start machine
encoder count = 0
ilowpass in = 0
ilowpass out = 0
move positive one click
encoder count = 4
ilowpass in = 4
ilowpass out = 3

Is your ilowpass.scale = 1? That's surprising to me. On my machine
(which cradek configured) the scale is 250.

I have 4 encoder edges per MPG detent, so i get 1,000 counts out of
ilowpass per detent. Maybe I have the same off-by-one problem on the
output that you describe, but it's only got a 1/250 part of the effect.
I've never noticed a problem like this, but i've never payed close
attention to the numbers.

I'll try to remember to look at it the next time I power my mill up.

[Jon Elson]

Post by Sebastian Kuzminsky

Post by Stuart Stevenson
results as follows
start machine
encoder count = 0
ilowpass in = 0
ilowpass out = 0
move positive one click
encoder count = 4
ilowpass in = 4
ilowpass out = 3

Is your ilowpass.scale = 1? That's surprising to me. On my machine
(which cradek configured) the scale is 250.

I have this in my system:

setp ilowpass.0.scale 100
setp ilowpass.0.gain .01

Jon