On 07/19/2020 03:59 PM, Matthew Herd wrote:
Hi all,
I made my first attempt at using spindle synchronized motion for a rigid
tapping operation on my Bridgeport BOSS mill today and it didn’t go as planned.
It has a spindle encoder and a Pico USC board. I can use the spindle to read
encoder counts and spindle position (I already use PYVCP to show me spindle
speed). However, G33.1 produces unusual results and doesn’t seem to work
properly. It appears that the down feed works properly, but the spindle either
never reverses or reverses very slowly and the synchronized motion on retract
doesn’t appear to reliably track the spindle motion. In several tests, it
either retracts while still turning clockwise, appears to retract faster than
the counter-clockwise speed would allow, or just doesn’t retract at all.
According to the g code reference page, motion.spindle-at-speed and
encoder.n.phase-Z must be connected in HAL. I don’t have spindle-at-speed
hooked up, but am using rigid tapping sample HAL from Pico Systems, with the
encoder connected to motion.spindle-revs.
encoder.n.phase-Z does not exist on the Pico boards. Z
(index) cannot be seen directly, it can only be detected by
index-enable going from true to false, and the encoder
position count going to zero.
Wow. First, make sure that the value fed to scale the
spindle encoder is correct. It should be equal to the
number of quadrature counts/rev of the spindle (4X the
number of "lines" on the encoder). It should look something
like this:
setp ppmc.0.encoder.03.scale 6912
The connection to LinuxCNC looks like this on my system :
net spindle-pos ppmc.0.encoder.03.position spindle.0.revs
The names might have been changed in newer versions.
You should look at ppmc.0.encoder.03.velocity with Halscope
(or even Halmeter) to make sure this signal is properly
registering the spindle rotation. With the correct scaling
factor, velocity should equal 60 at 3600 RPM (60
revs/second) and ppmc.0.encoder.03.position should count up
at 60 counts/second.
If the velocity shows negative when the spindle is running
"forward" then change the arithmetic sign of the encoder
scale to a minus number. The velocity should show an
opposite sign when the spindle direction is reversed, and
the position should count in the opposite direction. If
not, something is quite wrong with the encoder or how it is
connected.
I attempted to troubleshoot using this references:
https://forum.linuxcnc.org/27-driver-boards/26275-spindle-encoder-on-pico-usc
<https://forum.linuxcnc.org/27-driver-boards/26275-spindle-encoder-on-pico-usc>
I ran a halcmd sets on the spindle index enable and it reset counts to zero
immediately. spindle index enable remained false and fiddling with halscope
wasn’t ever successful in showing a change from false to true while playing
with G33 commands, etc. I’m not sure what to try next.
the correct connection is :
net spindle-index-en ppmc.0.encoder.03.index-enable
spindle.0.index-enable
All of the above examples assume USC channel # 3 is used for
the spindle, if different change the .03. to
whatever is needed.
The spindle index is only enabled once at the beginning of
the spindle synchronized move.
I think the trajectory planner sets it true, and when the
PPMC hardware detects a rising edge on the index input, it
clears index-enable, and zeroes the position count. So, one
part of the system sets this bit true, and the ppmc driver
sets it false.
In general, if the index is not working, LinuxCNC should
hang forever waiting for index-enable to go false. But,
maybe if it is not hooked up at all, the behavior is different.
Jon
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
