[rfrenzl]

I've done my reading here and I don't know if there is a reasonable answer or not. My question/issue is:

I want to do threading on my lathe (so what's new).
I have an index already set up on the spindle and it works fine.
I have used the Sherline sample configuration that is packaged with EMC2 and modified it to work with my steppers and other equipment.
I was successful in getting things to work with EMC2 2.2.2 but not with 2.2.5, but neither using a single pulse for speed and index.

What I am after is the correct HAL configuration to use a single input line for a spindle index AND spindle speed for synchronize motion (i.e. threading).

If someone out there has done such a thing, a copy of their HAL and INI files will be greatly appreciated. I can read through them and determine what I need to change so the supplier does not need to do anything other than supply the files.

I do have a couple of used encoders available but they seem to have issues in dropping pulses now and then. The result is that the spindle and slide movement are erratic and not necessary correct. A single pulse per revolution would simplify things greatly, both in construction of the mechanics to read the spindle and in software settings. MACH3 does this just fine but I have been using EMC2 for a number of years and like it very much (plus it still runs my mill). The encoders have 2000ppr and 1250ppr which means a pretty high throughput for 300+ rpm on the spindle. I can make a index wheel and add optical sensors but that requires designing and and adding it to the lathe. I'm trying not to do too much redesign/rebuild of the lathe so simple is good.

Thank you in advance for any help you can provide.
Ron

[samco]

1ppr is very new to emc. You would have to get the latest developement version (trunk).

instructions here for getting trunk
http://wiki.linuxcnc.org/cgi-bin/emc...o_compile_emc2

after that you could 'man encoder' from the trunk environment

You would be in effect beta testing it (we can always use testers).

if you want to - I would get on irc tonight and ask your question. The guy who added the functionallity might be there. (jmkasunich) although others may be able to help.

http://www.linuxcnc.org/component/op...emid,8/lang,en

otherwise - asking on the email list would be a good idea also.

https://lists.sourceforge.net/lists/listinfo/emc-users

sam

[acondit]

Sam,

I hadn't even seen anything about this. Where was it discussed?

I think it is about time, but I may still finish my encoder setup.

Alan

[rfrenzl]

1ppr is very new to emc. You would have to get the latest development version (trunk).
...

You would be in effect beta testing it (we can always use testers).

...
sam

Thank you for the information, Sam. I had thought I'd seen a few emails from the EMC Users group, but did'n take notice as I did not need it until now. I'll take a look at the new code and see what's changed. I have lots of new optical sensors sitting around so will also look at milling a timing wheel and putting it on the lathe. I had one of the encoders mounted but it was just too inconsistent to do much. It did work nice when I manually turned the spindle as it did not need to try and look ahead very far. At 300 rpm, the encoder just was not stable.

I'll continue to play with this and if I get anywhere, I'll try to post back to the Users Group.

Ron

[jmkasunich]

Some sample config files for 1ppr threading can be found here.

http://jmkasunich.com/pics/tormach/

These were used during testing of the one-ppr encoder software, so they have both a real encoder and a 1ppr encoder (using the index pulse of the real one). I wanted to be able to compare the results from the two different ways of measuring spindle speed.

One PPR threading will always be less accurate than multi-ppr threading, because if the spindle slows down under the load of the cut, the control won't know about it until a full revolution later. With a regular encoder, the control can react much sooner, before any significant error builds up.

That said, the actual amount of error will depend on the spindle and the cut. If you take light cuts on a spindle that has some guts, you will be fine with 1ppr.

[rfrenzl]

Some sample config files for 1ppr threading can be found here.

http://jmkasunich.com/pics/tormach/

These were used during testing of the one-ppr encoder software, so they have both a real encoder and a 1ppr encoder (using the index pulse of the real one). I wanted to be able to compare the results from the two different ways of measuring spindle speed.

One PPR threading will always be less accurate than multi-ppr threading, because if the spindle slows down under the load of the cut, the control won't know about it until a full revolution later. With a regular encoder, the control can react much sooner, before any significant error builds up.

That said, the actual amount of error will depend on the spindle and the cut. If you take light cuts on a spindle that has some guts, you will be fine with 1ppr.

Thank you very much for the information. I am very much aware of the disadvantages of the 1ppr signal but I want to see if it will work like I want before going through the cost, time, and effort of adding the extra pulses. If I can find the right stock in my metal bin, I can cut an encoder wheel and use it with what I already have. I just finished putting the step motor on my rotary table so can make the wheel much easier than before.

Like many on this forum, I like to experiment and this was something I want to learn a bit more about.

Again, thanks for the help and files. I'll let folks know how it works out. I also have a 2hp DC motor to add to the lathe and the controller I use has very good torque control for constant rpm. I modified EMC2 to use a frequency to voltage circuit to drive the spindle motor so expect to have a good CNC capable machine. If I get a wild hair, I'll use feedback so that I can dynamically manage the motor. Since the test config looks to be for a Tormach, I will assume it already has a similar config for this feedback. Just more stuff to learn and play with.

Thank you,
Ron

[acondit]

Some sample config files for 1ppr threading can be found here.

http://jmkasunich.com/pics/tormach/

These were used during testing of the one-ppr encoder software, so they have both a real encoder and a 1ppr encoder (using the index pulse of the real one). I wanted to be able to compare the results from the two different ways of measuring spindle speed.

One PPR threading will always be less accurate than multi-ppr threading, because if the spindle slows down under the load of the cut, the control won't know about it until a full revolution later. With a regular encoder, the control can react much sooner, before any significant error builds up.

That said, the actual amount of error will depend on the spindle and the cut. If you take light cuts on a spindle that has some guts, you will be fine with 1ppr.

John,

Is 1ppr capability in 2.2.6? Or does it still have to be compiled from cvs?

Alan

[jmkasunich]

Is 1ppr capability in 2.2.6? Or does it still have to be compiled from cvs?

It is in CVS only. The policy is that bugfixes go into the current release, but not new features. The #1 rule with a release series (like 2.2.x) is to not break existing working configurations.

We sometimes add a new feature if the implementation is such that it can't break anything. For example, a completely new HAL module - if nobody was using that module before, adding it won't break things for people who still aren't using it.

But in this case, the new feature is part of the existing encoder counter module, so we didn't put it in the 2.2.x series.

Regards,

John Kasunich

[Ryobiguy]

I've used EMC just for it's HAL system and UI - I wrote a lathe feed/threading program as a HAL module to simply replace the need for change-gears (ie, not exactly "CNC" since no G-code.) So, I've never used or explored EMC as an actual machine controller, I've just used some of it's supporting software.

If I recall, the encoder module takes the A/B and index signal and generates a float(ing point number) for EMC to use for both position and velocity. Is this all that EMC needs as an output from the encoder module?
That would explain why 1 PPR is a special case, because it's no longer an "encoder" (as we know them: quadrature w/ index), it's just a non-quadrature encoder with n pulse(s) per rev.

Why not add a new non-quadrature encoder module? If debouncing does not need to be integrated (ie, don't need it, or just run through the standard debounce HAL module,) then it would be trivial to write a non-quadrature pulse encoder module. And, it wouldn't affect existing users of the encoder module, it terms of both bugs, and overhead from making it a flexible do-all module.

-Matt

[jmkasunich]

That would explain why 1 PPR is a special case, because it's no longer an "encoder" (as we know them: quadrature w/ index), it's just a non-quadrature encoder with n pulse(s) per rev.

EMC's encoder module already has "counter mode" in which it counts edges on the phase A input and ignores the phase B input. What is new is the "interpolated position output" that can estimate where the shaft is between pulses.

Why not add a new non-quadrature encoder module?

Because then we wind up with two modules which have a lot of duplicated code. Sooner or later, a bugfix will be applied to one and not the other, or something like that.

If there is a lot of interest in this feature for the 2.2.x branch, then maybe after a careful review we might put it into 2.2.7. I think the code is written in such a way that if you don't use the interpolated position output nothing else changes.

Regards,

John Kasunich

[Ryobiguy]

I see, it's the interpolation that's the special thing, that makes perfect sense now. It doesn't tell you where it's last position is, it tells you where it thinks it is, which is fundamentally different and why it's a newer feature.

My first attempt at the manual lathe HAL module used the encoder and stepgen modules, and didn't have good results since there was no interpolation and not enough resolution on the encoder. I saw the encoder position jumping, and the stepgen with it's discrete moves (based on encoder jumping) was lagging. So then I rewrote it to integrate debouncing, encoder interpolation, and a token-bucket step output. Now it's accurate and much more smooth.

BTW, is it weird that I saw stepgen overshooting? It happened because the control of stepgen is all in the servo thread; the high speed thread generating the step signal didn't shut off the frequency when it reached the proper number of steps because the step count info wasn't passed down to it, just the Hz. It reached the position and passed it before the next run of the servo thread, and had to reverse back to the commanded position.

-Matt

[acondit]

If there is a lot of interest in this feature for the 2.2.x branch, then maybe after a careful review we might put it into 2.2.7. I think the code is written in such a way that if you don't use the interpolated position output nothing else changes.

Regards,

John Kasunich

John,

That sounds good to me, but I may have my ABZ encoder working by that time.

Alan