I wish someone would fix spindle sync so it works for everyone and not just me
we have a dozen people saying what they think must be wrong with it, who probably haven't even looked at the code
and of course we hear that mach can [magically, I guess] do rigid tapping with 1ppr
>> and of course we hear that mach can [magically, I guess] do rigid tapping with 1ppr
That would have to be magic as they never claimed to be able to do rigid tapping. Heck even Mach3 threading is not right..
From that scope screen it looks like the correction has a bug in it. But it is working for you? What is your encoder count again - pretty high?
I just put a 200 ppr encoder on my lathe and I may try to run threading with it later this week. I had a 1024 encoder on it - too fine for PPort sampling.
yes the problem is with granularity in the spindle feedback
mine works really great
for threading (non reversing) you can count an encoder twice as fast by using counter mode
How often is the correction routine run - every servo loop - 1 ms?
the change I made recently should make it much better
yes every servo loop
the problem with low count encoders is that for many servo cycles in a row it will see NO change in the spindle position
then all of a sudden, there's a huge jump when an encoder line finally goes by
I need to make sure to put that in counter mode then as there is no way I'm going to do tapping with this big spindle motor
So it is winding up
well it thinks the spindle has stopped - it tries to stop Z (at Z's max acceleration)
Integrating an error that really doesn't exist
then many cycles later, the spindle position jumps way ahead...
you can see why it doesn't settle
I get it...
if your encoder gives many counts per servo cycle, so the spindle appears to be moving smoothly, it works great
that's why using the interpolated position mode helps
So can the update be delayed until the next encoder pulse is seen?
IE, don't correct until the leading edge of the next pulse
adding delays seems to always make stuff worse
good feedback is the real answer IMO
So the results are the same with the hostmot driver as with the PPort driver also?? no difference
Is all of the threading sync code in that one file that you patched?
yes pretty much all the motion planning is there
driver/interface doesn't matter except some allow you to have higher resolution encoders
when people have trouble with this, they turn the spindle down slower - that makes it worse, not better, when you think about the problem I described (spindle "stops" for even longer)
the slower your machine is (crappy underpowered steppers) the slower the acceleration, the slower you have to run the spindle to thread, the worse it gets
it's a big swirl of badness
my lathe is fast and accelerates fast and has good quality feedback - no wonder it works for me
the oscillation in the latest screenshot is not due to low encoder resolution
what was that url?
(this screenshot) http://mah.priv.at/gallery2/main.php?g2_view=core.DownloadItem&g2_itemId=70522
I need to figure out GIT anyway I guess. I'll try and pull that file down - I think from that patch I can find that chunk of code. Perhaps I can figure something out there.
So it looks like the Z speed is being altered between the encoder pulses - correct? Since the encoder pulses are further apart with a coarse encoder it slows the Z thinking that the spindle has stopped.
Shouldn't the spindle speed be assumed to be constant unless it is updated via a new encoder pulse being sense??
I'm guessing that's the incorrect initial velocity problem - which I fixed (ish)
Dave911: EMC doesn't know anything about speed, it deals with spindle position
Dave911: fwiw, that's what the interpolated encoder output does
I have no idea why he has f-error there
he's got more than one problem maybe
Is the F error following error?? I didn't quite understand what he was showing.
his following error is proportional to his velocity command
that ferror behavior is what you'd expect if you have only P in your PID loop - but that has nothing to do with the threading issue
I agree it is unrelated
(no clue about the cause)
do we know what code he's running when he got this?
OK, so I guess I mean shouldn't the change in position per servo cycle ( velocity) be considered constant between encoder position updates on the spindle?
Or is that what interpolated encoder position is??
Dave911: that is what interpolated position is
the normal position output of the encoder counter advances in discrete steps whenever 1 (or more) encoder pulses has arrived
So wouldn't interpolated encoder position improve this situation?
yes, and it does
the interpolated output advances on every servo period, even when a pulse hasn't arrived, based on the spacing of the last two pulses (and some other fiddling)
OK, I missed that. I thought in the message thread a while back that using interpolated was not recommended - perhaps Steve Blackmore told me that off the list - I'm not sure..
Interpolated is NOT suitable for axis feedback - you don't close a position loop on X, Y, or Z using interpolated
but when you are slaving one or more axes to a master, interpolated IS recommended for the master
note that the hardware encoder counters do not have this option - but with them you can use a suitable encoder so it's not needed
depending on the hardware, it is quite possible to provide interpolated position even for hardware based counters
pick an encoder so you get at least a couple dozen edges per servo cycle at tapping/threading speed and you will be fine
specifically, those which capture a timestamp with each encoder edge
jmkasunich: right, timestamps
you also don't use position-interpolated for rigid tapping, since it has to reverse
yeah I doubt it does reversal perfectly enough
I asked for the HAL files he used to generate that screenshot, but I think he's in Germany, so it may be tomorrow before we see them
The guy on the email list did not indicate if he was using interpolated encoder position or not.
SWPadnos: you can still use position-interpolated for tapping
I thought you pointed out that there's an expected 2-count jump at reversal
since interpolated "keeps going", but then the real feedback says "whoah there, we've gon the other way"
it isn't perfect during a reversal, but it is never off by more than one encoder count (maybe 2).... if your counts are so coarse that 2 counts will cause a problem, then you REALLY need a finer encoder
tapping DOES need a finer encoder, there is simply no way around that
yeah, the expectation that speed will be somewhat constant goes out the window for tapping, I think
so you need better feedback
argh, half hour and my post hasn't showed up yet
So can you use interpolated encoder position and use the counter mode at the same time ??
I think so
it was written so you could do 1-PPR threading
so you'd use counter mode, connect the one pulse to both PHASE-A and intdex, and tap
yeah, not tap
I'm not going to do rigid tapping, the spindle is way too big to reverse for a tap..
not that someone won't try it
yes, interp-pos has nothing to do with count mode
Dave911: I tap on a 2hp and 7.5hp spindle - is yours much bigger?
even taking a few turns to reverse is fine
tapping MUST be in quadrature mode so it can sense reversal, and it MUST have reasonable resolution.... the discussion on the list isn't about tapping and that just muddies the water
I guess there is really no reason why I couldn't tap with it, there is just a lot of mass to brake stop and reverse..
just need a BIG braking resistor...
or tell the spindle to stop about 1" before the end of the cut ;)
yeah, or just go slow
I don't think the spindle drive has an external braking resistor come to think of it.. But you are right telling it to stop an inch before I run out of tap would do the trick ;-)
Actually it goes slow really well, it is a very smooth at low speeds.
What is a "reasonable" resolution? The 200 PPR I put on resolves to 800 positions per rev. in quad mode. That seems pretty high to me.
like I said earlier, shoot for dozens of edges per servo cycle at threading speed
that knocks your granularity way down into don't-care territory
So like you were saying before this really sounds like a granularity problem. If you have 1 or 2 encoder edges per servo cycle - that is a huge difference..
the percentage difference between 25 and 26 counts is very small compared to the difference between 0 and 1
so unless I know your servo cycle speed and your desired threading rpm, I can't give you an encoder spec
I see what you mean... But does such drastic action have to take place that often - ie is the loop gain not way too high then??
and if I did, I wouldn't anyway, because you can do the math :-)
Dave911: it's responsive because the same algorithm is used for tapping. you can't have any delay for tapping because you can't lag behind in position.
I bet it could be smoothed a lot for people who don't tap.
a constant .005 behind where you want to be while threading - who cares
Yep, I can see why it would have to be very tight for tapping.
while tapping - that's .010 difference between "going in" and "going out" which is pretty bad
Yep, if I could never tap with my lathe I'd be ok with that. Realistically I'd probably put a tapping head in the turret and forget about it. No spindle reversals etc. I'm trying to set it up with a bar feeder to make lots of parts.. at least that is the immediate plans. My plan was to go with the PPort interface and then later go with a 5i20 board but perhaps my plan was flawed! ...
with a 20000 base thread and 1000000 servo cycle, you can easily get dozens of edges per servo cycle (but at a limited range of speeds)
on a machine with low accel, I bet you could do 500Hz servo cycle and improve it even more
I can see that. I have several things to try out.
cradek: Is that patch that was discussed on the email list part of the GIT"trunk" now? (I think I said that right?)
the one on trunk is similar
kept the part where the initial velocity match is done, did not keep the smoothing which I think might hurt tapping
So you tweaked it a little further than the patch he had?
Well thanks! I'm going to print off this conversation and put it with my threading notes, pull down the source code and study that file where you patched it. Get to my lathe and try it out.
Unfortunately the lathe is about an hour away so it may be a few days before I get to it. Sounds like more will happen before then with Haberler's testing.
Haberler ... the guy in Germany who brought this up again.
ok, good luck and report back
maybe configurable smoothing is what we want, so people can thread ok with terrible feedback and tap well with excellent feedback
(that kind of makes me want to hurl though)
>>>(that kind of makes me want to hurl though)
You'll get over that feeling when people stop complaining that the threading routine doesn't work when _______ ;-)
>>so people can thread ok with terrible feedback
I'm used to the Mach3 world where the standard is 1 ppr for threading. So 200 ppr is rocket science compared with Mach's 1ppr standard.
Of course threading doesn't work with Mach3 but that's another story.. :-(
Making one more thing configurable does add complexity.
I'll report back. Thanks!
I saw threads cut by mach3 on a small crappy lathe at cnc workshop 2 years ago - as you would expect, they were crappy and wavy ("drunken"?)
EMC does ok on my sherline with good feedback (1024 line)
but even my little sherline is pretty fast and can accelerate nicely - it's a little servo hackup
low mass helps
I don't have any crappy underpowered machines to test :-/
you could reduce the current limit on your HNC
I ain't soldering no more resistors on that damn thing
here I am thinking they use pots for that
it was hard enough to make it work right - making it work wrong would probably be worse
wait wait - replace those drives with Geckos!
>>crappy underpowered machines .....
You aren't looking for them hard enough. They are easy to find.. ;-)
good idea - I bet the geckos would love the 204800 counts/inch feedback
and software stepgen would be good enough, right?
sure, as long as you don't go faster than 1 IPS or so
(for the geckos)
EMC: 03cmorley 07master * raa9e11d00a37 10/src/emc/usr_intf/pncconf/ (pncconf.glade pncconf.py): Jog button mpg work
EMC: 03cmorley 07master * redb603981bf0 10/src/emc/usr_intf/pncconf/pncconf.py: Clean up hal file output, Change to stepper settings
EMC: 03seb 07master * ref35c86acf71 10/configs/hm2-servo/ (9 files): Fix homing in the hm2-servo config.
BJT-Work is now known as JT-Work
Dave911_ is now known as Dave911
EMC: 03cradek 07random_toolchange * r8a20888daf91 10/ (46 files in 20 dirs): Merge branch 'master' into random_toolchange
does anyone know how to put a license statement in a glade file?
bonus points if glade doesn't puke on it
you could add an xml comment, but glade is almost certain to discard it when it writes out the file
you could put it in the text of a widget in a non-shown window
yeah that's not optimal...
a survey of glade files on my system doesn't turn up any that embed license information
I found a place to cram it in
MainWindow / Accessibility / Name / Comments for translators
(whatever that is)
EMC: 03seb 07master * r82040654265c 10/configs/hm2-servo/ (10 files): better description of this config, and better comments inside
EMC: 03cradek 07master * rbe07d9c303d9 10/src/emc/usr_intf/touchy/ (emc_interface.py touchy.glade touchy.py): add override limits
EMC: 03cradek 07master * r76026acb28c2 10/ (9 files in 3 dirs): initial import of touchy, the touchscreen gui
EMC: 03cradek 07master * rad67a2fd7204 10/src/emc/usr_intf/touchy/ (touchy.glade touchy.py): give up on using images, for now
EMC: 03cradek 07master * r1ad59cc2e007 10/src/emc/usr_intf/touchy/design.notes: design notes
EMC: 03cradek 07master * r29558c1312d5 10/src/emc/usr_intf/touchy/emc_interface.py: show tlo in relative dro
EMC: 03cradek 07master * re489870230e0 10/src/emc/usr_intf/touchy/ (design.notes emc_interface.py touchy.glade touchy.py): some status stuff
EMC: 03cradek 07master * rfc0ecb2c2e79 10/src/emc/usr_intf/touchy/ (emc_interface.py touchy.glade touchy.py): prepped tool display
EMC: 03cradek 07master * rfd7a7d87d1e5 10/ (configs/sim/touchy.ini src/emc/usr_intf/touchy/touchy.glade): start auto mode
EMC: 03cradek 07master * r4f7f19b8c294 10/src/emc/usr_intf/touchy/ (touchy.glade touchy.py): file chooser widgets, sort of
EMC: 03cradek 07master * r503143b3ce80 10/src/emc/usr_intf/touchy/ (Submakefile touchy.glade touchy.py): filechooser events
EMC: 03cradek 07master * r5551892bcd51 10/src/emc/usr_intf/touchy/filechooser.py: file chooser working
EMC: 03cradek 07master * r36ff017a881d 10/src/emc/usr_intf/touchy/touchy.py: oops, fix it to run again
EMC: 03cradek 07master * r22e839909839 10/ (2 files in 2 dirs): fix highlighting of loaded file
EMC: 03cradek 07master * r258cd683254d 10/src/emc/usr_intf/touchy/touchy.glade: screen whitespace fix
EMC: 03cradek 07master * rf00c886247de 10/src/emc/usr_intf/touchy/ (design.notes emc_interface.py touchy.glade touchy.py): manual controls
EMC: 03cradek 07master * r1bfd0eee10dc 10/src/emc/usr_intf/touchy/design.notes: update design doc with things that are done
EMC: 03cradek 07master * r3e02fe79f4fa 10/src/emc/usr_intf/touchy/filechooser.py: read in the file, probably badly
EMC: 03cradek 07master * rd36bc0289855 10/src/emc/usr_intf/touchy/touchy.py: visual tweaks, and load touchy.hal to hook up the controls
EMC: 03cradek 07master * rf0dc61b0563e 10/src/emc/usr_intf/touchy/ (filechooser.py touchy.glade touchy.py): filechooser reload
EMC: 03cradek 07master * r1cde4ce33972 10/configs/sim/touchy.hal: need this for it to run now
EMC: 03cradek 07master * r95df2d637beb 10/src/emc/usr_intf/touchy/ (hal_interface.py touchy.py): better handling of the Jogging button's status
EMC: 03cradek 07master * rfff3fc498157 10/src/emc/usr_intf/touchy/ (emc_interface.py mdi.py touchy.glade touchy.py): dro commanded/actual, mdi T, gui part of dro inch/mm
EMC: 03cradek 07master * raee8b52ac8ca 10/src/emc/usr_intf/touchy/ (emc_interface.py hal_interface.py touchy.py): some support for continuous jog
EMC: 03cradek 07master * r6875126eec85 10/src/emc/usr_intf/touchy/ (emc_interface.py hal_interface.py): quill up
EMC: 03cradek 07master * r92c54d75e60e 10/src/emc/usr_intf/touchy/ (emc_interface.py hal_interface.py touchy.py): wheel changes fo/so/mv and messages are sent
EMC: 03cradek 07master * rf3fcff4eb2d5 10/src/emc/usr_intf/touchy/emc_interface.py: make the initial jog velocity agree with the screen
EMC: 03cradek 07master * re5f1eef16744 10/src/emc/usr_intf/touchy/touchy.py: This somehow doesn't unset the font. (?)
EMC: 03cradek 07master * r87308a131442 10/src/emc/usr_intf/touchy/ (emc_interface.py mdi.py touchy.glade touchy.py): Touch off, using new G10 modes
EMC: 03cradek 07master * r9ba064eafd75 10/src/emc/usr_intf/touchy/ (emc_interface.py hal_interface.py): run/stop/step/resume
EMC: 03cradek 07master * r916b39c81865 10/src/emc/usr_intf/ (4 files in 2 dirs): visual tweaks and make quill-up work better
EMC: 03cradek 07master * r95d2030002c8 10/src/emc/usr_intf/touchy/ (emc_interface.py touchy.glade touchy.py): allow single-block from stopped state, I think
EMC: 03cradek 07master * re8191d2c01dc 10/src/emc/usr_intf/touchy/emc_interface.py: do quill-up in terms of manual mode, not mdi
EMC: 03cradek 07master * rf9db489a25d2 10/src/emc/usr_intf/touchy/ (Submakefile filechooser.py listing.py touchy.glade touchy.py): program listing, doesn't do much yet
EMC: 03cradek 07master * r1069b29464d5 10/src/emc/usr_intf/touchy/ (touchy.glade touchy.py): more lines of listing, and a configurable font
EMC: 03cradek 07master * r733a972f7660 10/src/emc/usr_intf/touchy/ (emc_interface.py hal_interface.py touchy.glade touchy.py): use cycle start button for mdi as well
EMC: 03cradek 07master * rcad7cb32dea5 10/src/emc/usr_intf/touchy/touchy.glade: use table instead of vbox when there are many items
EMC: 03cradek 07master * r9f9e3e3914b6 10/src/emc/usr_intf/touchy/touchy.py: simplification?
EMC: 03cradek 07master * r36559103cfc1 10/src/emc/usr_intf/touchy/touchy.py: looks better if the headings are in the control font
EMC: 03cradek 07master * r7523b84cacbf 10/src/emc/usr_intf/touchy/ (Submakefile preferences.py touchy.py): save font preferences, yay
EMC: 03cradek 07master * rc45055cdd5ba 10/src/emc/usr_intf/touchy/ (emc_interface.py listing.py touchy.py): show the running gcode program
EMC: 03cradek 07master * rd77391bac665 10/src/emc/usr_intf/touchy/ (emc_interface.py touchy.py): save dro prefs and honor inch/mm now
EMC: 03cradek 07master * ree8eacd241cf 10/src/emc/usr_intf/touchy/ (emc_interface.py listing.py): better handling of cycle start
EMC: 03cradek 07master * recadf97d24a2 10/src/emc/usr_intf/touchy/touchy.glade: new buttons for restart points
EMC: 03cradek 07master * r90936dc698d4 10/src/emc/usr_intf/touchy/ (emc_interface.py listing.py touchy.glade touchy.py): rfl support and coordinate system rotation
EMC: 03cradek 07master * r1f4ed2e0f4c8 10/src/emc/usr_intf/touchy/listing.py: handle listing of very short programs
EMC: 03cradek 07master * r1f786f204300 10/src/emc/usr_intf/touchy/listing.py: N search for start points
EMC: 03cradek 07master * r91609e761aec 10/src/emc/usr_intf/touchy/ (emc_interface.py touchy.glade touchy.py): add reload tool table button
EMC: 03cradek 07master * r7ec78c274c5b 10/src/emc/usr_intf/touchy/design.notes: update notes
EMC: 03cradek 07master * r09c7119dc2be 10/src/emc/usr_intf/touchy/ (emc_interface.py mdi.py touchy.py): touch off should change the active system
EMC: 03cradek 07master * r69bf7f7eb780 10/src/emc/usr_intf/touchy/ (hal_interface.py touchy.py): disable the jogging button at more right times
EMC: 03cradek 07master * r7552c2f7fc1b 10/src/emc/usr_intf/touchy/ (design.notes emc_interface.py touchy.glade touchy.py): add tlo display to status screen
EMC: 03cradek 07master * r97e7dd56fe77 10/src/emc/usr_intf/touchy/ (design.notes emc_interface.py touchy.glade touchy.py): blockdel, opstop
EMC: 03cradek 07master * re33392b7c435 10/src/emc/usr_intf/touchy/ (emc_interface.py touchy.py): abort button clears the error
EMC: 03cradek 07master * r687042724a1c 10/configs/sim/touchy.ini: ini cleanup
EMC: 03cradek 07master * rc5797ba3754e 10/src/emc/usr_intf/touchy/design.notes: Explanation, design goals, and very basic docs
EMC: 03cradek 07master * rbba7b6017d86 10/src/emc/usr_intf/touchy/touchy.hal.example: Example hal file that connects touchy's HAL stuff
Nice work chris!
he's been very busy for the last five minutes
cradek: do you have a external cycle start? (how to you run mdi commands?)
yes when you're happy with what's shown in the mdi window, you poke cycle start
ok - (stupid question - there isn
isn't one on the screen? (cycle start)
a little info here: http://git.linuxcnc.org/gitweb?p=emc2.git;a=blob;f=src/emc/usr_intf/touchy/design.notes;h=bc54c3965e220247d350799dec381ce58caa3cc9;hb=bba7b6017d86ca89a74f556fa22f46dbd6b5e6ab
nope, you need an actual button
obviously docs are needed - I didn't write them yet
ok - Just making sure I wasn't doing somehting stupid
It only took a second to figure out how to enter commands - pretty cool :)
yay I'm glad to hear that. handling mdi was the hardest/funnest part of it
it really works great on a touch screen
skunkworks_: halcmd setp touchy.cycle-start 1; sleep .2; halcmd setp touchy.cycle-start 0
the computer I use to test is a tablet pc - I should get the touch screen working :)
heh - that was easy enough ;)
heh - that is pretty cool
also gives a nice error display at the bottom (cannot do g1 move without feedrate)
When I first looked at it I was wondering - how the heck do you enter the I,J,P....
for a good time see if you can figure out how to enter G0 G53 Z0 - that's a very unusual case - you NEED two G words on the same line - there is no other case where it matters
I'm looking for a (small) python program that can read the current position and set a target position (using EMC). Should I start with axis.py or is there an easier way?
maybe try mdi.py in the source, installed as /usr/bin/mdi ?
I'm not sure what you mean by "set a target position"; do you mean jog, or issue an mdi?
I have a little PID loop... I could send an mdi or a jog
I guess a jog is fine, I can let EMC deal with the speed issues
probably have to read the axis source to send a jog
to me a (g53) g0 mdi might be more sensible and easy to do
That's sounds good. My program would a) import emc stuff, b) read the current position, c) get a a new posiiton from the outside world and d) send a g0 command... then goto b).
So I should hack axis.py if I want to get it done ASAP?
did you look at mdi.py yet?
no, but its sounds like what I want. thanks...
cradek: heh - nice. G53 gives you an extra G :)
jepler: thanks, mdi is what I was looking for.
EMC: 03cradek 07master * rcf373a09b34a 10/src/emc/usr_intf/touchy/design.notes: add obvious note for sake of completeness
EMC: 03cradek 07random_toolchange * r286910510f26 10/ (26 files in 5 dirs): Merge branch 'master' into random_toolchange
EMC: 03cradek 07random_toolchange * r3654c98e1eb3 10/src/emc/usr_intf/touchy/emc_interface.py: show prepped tool, not prepped pocket
git seriously kicks ass
that is all
cradek: cool stuff
gotta try it out tomorrow ;)
sure is hungry in here
heh 'Like "git", "touchy" is named after its author.'
to avoid discussion #239 of threading and encoders - I've written up a bit for the wiki to explain what's going on if the issue comes up again, see http://mah.priv.at/tmp/sm.txt
it's my current perception - I'd appreciate some cursory bullshit detection by more clueful folks than me before I put it on the wiki
dont blame me, I'm just an MBA ;-)
cradek: impressive. :)
cradek: while a program is running in auto - you can click on other files and they will load... but you go back to the running program - it still follows it. Is it meant to be able to preview a file while cutting?
heh - never mind, - it loads the program at and keeps it and doesn't allow you to navigate thru it.