[H.O]

So the new processor will handle faster encoders.

Correct, it'll handle higher "encoder count frequency" and higher step frequency.

Let's see if I have the math right. Suppose I want to use a DC servo for my JGRO router project. Assuming I have a 3000 RPM motor with a 500 line encoder in quadrature I get 2000 pulses per rev. At 3000 RPM or 50 RPS I'm going to see 100,000 pulses per second?

Correct, 3000*500*4/60=100kHz. (This should work fine with the original UHU chip)

Now to turn this into a real world application the servo would have a 4:1 set of pulleys ultumately turning a 20T pulley that has a pitch of 0.2" (XL series). That means each revolution moves 4" worth of belt.

With a motor of 3000 RPM and 4:1 reduction the pulley is turning 750 RPM which is moveing 4" * 750 RPM or 3000 IPM?

Correct, 3000rpm/4*4=3000IPM and yes, that's pretty fast! The smallest increment of motion then would be 4"/2000=0.002", usually it's recommended to have at least 5 times higher "encoder resolution" than the intended "machine resolution", so this results in ~0.01" 'machine resolution'. - perhaps not that great.

Yikes! If I reduced the speed to 20:1 then 3000 RPM becomes 150 RPM at the 20T pulley which means 150 * 4" = 600 IPM. That's a decent rapid.

Yep, correct again. And the resolution would increase by a factor of 5 as well, which is good in this case. The maximum frequency is obviously still 100kHz since the motor speed is still 3000rpm and the encoder is on the motor.

Currently for CNC systems then to work with the HP-UHU the encoder should be more like a 200 line encoder? And the standard UHU processor can handle 50,000 steps per second?

The UHU chip is supposed to handle at least 150kHz, under some circumstances up to 250kHz (depending on which document you read). Personally I've never been able to go above 130kHz without "loosing counts" though.

The maximum encoder line count is a function of your desired resolution and desired top speed, as long as the resulting frequency isn't higher than what the chip can handle you'll be fine. A 200line encoder would mean a maximum motor speed of 130kHz/(200*4)*60=9750rpm while a 1000line encoder will give you 130kHz/(1000*4)*60=1950rpm. If that's enough, which it definitely IS in many cases, the original UHU chip will work just fine.

Initially I had some very nice 3600line encoders on my motors (which is how I found the 130kHz top speed) and with those the max speed I could reach was 130kHz/(3600*4)*60=540rpm on a 2000rpm motor. I knew that from the beginning and had calculated with changing the encoders but had I been given the opportunity to use the 3600 line encoders I would have.

/Henrik.

PS. The module offers more than just higher step and encoder frequency capabilities. For example the sliding scale following error limit and the high speed data recorder.

[jcdammeyer]

Correct, 3000rpm/4*4=3000IPM and yes, that's pretty fast! The smallest increment of motion then would be 4"/2000=0.002", usually it's recommended to have at least 5 times higher "encoder resolution" than the intended "machine resolution", so this results in ~0.01" 'machine resolution'. - perhaps not that great.

Hi Henrik,

If the encoder has 500 lines and is operating in quadrature mode, then the motor is seeing 2000 counts per rev. But the 3000 RPM is divided by 4 through the belts before it turns the belt drive resulting in 4" of motion. So isn't it 8000 pulses per 4" and therefore 0.0005" per increment?

I guess if the motor could drive the hardware that fast (sufficient torque at 3000 RPM) then it would be better to go to a 1000 line encoder. Then the system would have 0.00025" resolution with an accuracy of +/- 0.0005". Still not great but for pick and place or solder paste dispensing more than accurate enough. Also for wood or foam routing.

John

[H.O]

Hi,

If the encoder has 500 lines and is operating in quadrature mode, then the motor is seeing 2000 counts per rev. But the 3000 RPM is divided by 4 through the belts before it turns the belt drive resulting in 4" of motion. So isn't it 8000 pulses per 4" and therefore 0.0005" per increment?

Well, of course it is...sorry about that.

The bottom line is that you choose the components best suitable for the job. I'm not trying to "push" anything onto you that you don't need. If you have the UHU chips and they'll do the job then there's no reason to change. If you don't have the UHU chips (but they'll do the job) my module simply provides another option to get the same (or, hopefully better) end result. If you have (or don't have) the UHU chips but you need or like to have one or more of the features this module offers then it can provide that.

/Henrik.

[jcdammeyer]

Hi Henrik,

Didn't mean to suggest you were pushing anything. I as thinking out loud about servo speeds and wondered if what I was suggesting would be pushing the limits of the stock UHU and if what you had designed was targeted at that sort of situation.

I'm still trying to get my head around appropriate ratios and speeds for the CNC router.

Thanks

John

[H.O]

I'm sorry John, I know you didn't.

Like I said, from my experience the UHU chip tops out at ~130kHz, because the web-site said 150kHz easily and ~300kHz under optimal conditions I initially thought that the diferential reciever chip and filters on the HP-board played a part in me only getting 130kHz. But the HP-board has prooved to work nicely at speeds around 1Mhz when used with my module.

To me it sounds like the UHU chips will fit the bill nicely in your case, especially if you already have them on hand. A 4:1 reduction is probably around the highest you can go in one stage with a belt reduction. Your optimal seems to somewhere between 10 and 20:1 so perhaps two stacked 4:1 reductions giving a total of 16:1 driving your 4" circumference pulley could work.

Then you'd have 3000rpm/16*4=750IPM rapids, the maximum step and encoder frequency would be 500*4*3000/60=100kHz which the UHU will handle nicely and the resolution as specified by the encoder alone would be 4/(500*4*16)=0.000125 (32000 steps/inch). A 0.5Nm (70oz-in) continous torque motor would give you 70*16/(4/PI/2))/16=110lbs of force minus losses. Not too shabby depending on the overall effeciency of the drive train. (What's the torque rating of the your motors?)

You could reduce the needed amount of reduction by using a smaller pulley for the actual axis drive but that on the other hand makes for less belt engagement around the pulley, which I think is quite small already. (Not that I know the size and/or requirement of the machine you're building.)

Lots and lots to think about and many variables to play with, as you've noticed.

Thanks!
/Henrik.

(I hope my math is correct this time, I don't guarantee it though....)

[jcdammeyer]

[QUOTE=H.O;791140]A 0.5Nm (70oz-in) continous torque motor would give you 70*16/(4/PI/2))/16=110lbs of force minus losses. Not too shabby depending on the overall effeciency of the drive train. (What's the torque rating of the your motors?)
QUOTE]

Henrik,

As a separate project from CNC on my mill using DC Servo's I also have the need for a small CNC router for cutting plastic and MDF wood. So I'm building up the JGRO router. Work is slow at the moment so every $ I don't spend on something is a dollar earned so to speak which is why I'm building rather than buying.

The Steppers allocated for this project are 280 oz-in motors that on a good day may do 750 RPM. Initial plans are for 10 TPI ACME all thread lead screws but odds are I'll end up changing over to belts. The discussion about this project is what then shifted over to DC Servo's instead of steppers. That's when I started doing the math for encoder lines per rev and maximum input for Uli's UHU ATMEL processor.

Thanks.

John

[LZ1TWB]

Hi all,

Henrik, I ran trough the userguide but did not find the thing I looked for. Have you made a parameter, similar to the error count on the original chip, and how can you make sure it is on position/ or not? Maybe check the actual axis with a dial, or use an external DRO for this. Sorry I may have missed this one.

It seems that you use an additional DIP socket to bring up the board above the surrounding components. I've seen some sockets here with quite long legs. I may need something like that here as the reset capacitor is near and might have a conflict.

Todor

PS: We were performing at a local airshow last weekend, anyone interested in our hobby can see some pics here: http://www.facebook.com/album.php?ai...4&l=1cd566e0b1

[H.O]

Hi Todor,
The UHU-chip, and this is from my understandig as I don't have access to its actual code, works by triggering an interrupt service routine on each edge of the A and B channel signals. The interrupt service routine then "manually" steps the internal position register up or down.

At each quadrature state there are only two valid states that the encoder can transition to, one in each direction. Like this: AB-Ab-ab-aB-AB-Ab-ab-aB and so on. At state 'ab' the next state HAS to be either Ab or aB depending on which direction the encoder is rotating. If the next state detected is anything else then the code knows that it have missed at least one state and increments the "O-count" as an indication of this. Now you may think that if it is at state ab and then detects AB why not just count two "steps"? Because AB is two "counts ahead" in BOTH directions so it can not know if it should count up or down.


This module however does not count the encoder pulses with software. There is a built in 16 bit hardware quadrarute counter in the uC used on the module. The "only" software involved with actually tracking the encoder is to increment or decrement the upper word of the 32bit position register when the 16 bit hardware counter over- or underflows.

You can query the module for the current target position (GT-command) and match this to the expected number determined by the steps/unit and the number of pulses sent out from the CNC system. This will verify that you aren't loosing (or gaining) any step-pulses due to noise or wrong step signal polarity etc.

You can also query the module for the actual position (GP-command). It should match the target position once the motor is stationary. However, this will NOT tell you if the ACTUAL position is wrong due to noise on the encoder lines etc - there's simply know way to determine that software wise. Likewise on the UHU, if noise forces the encoder signals to another state (which at the time happens to be valid) it will not know the difference between the noise and an actual transition of the encoder signals.

If you should find yourself in a position where you think noise on the encoder lines are causing trouble you can activate the internal digital filter of the module (see the Y-setting) and set it to a frequency close to your highest possible encoder frequency + some margin.

To VERIFY that you are on position and no pulses gets lost due to noise or whatever you have to resort to actually measuring the position with a DTI, DRO etc.



As for the IC-socket, yes. On the HP-UHU I had to use one 20-pin IC socket to get the board to clear the USB connector. You could stack a couple of ordinary sockets if you want, or you could mount the "offending" capacitor on the bottom side of the PCB - whatever works.

Sorry for the verbose answer. Let me know if there's anything else!

/Henrik.

[tenmetalman]

H.O.
the module's were here when I got home. they look great My goal is to get a couple of hours in on the project tonight. I turned on the air in my shop (the current outside temp. is 95f. @6:15pm). my plan is to get back up & running with Uli's chip then change over. I'll probably drive you nuts wanting my hand held. Paul

[H.O]

Thanks for letting me know Paul!
That sounds like a good aproach, it'll verify that everything works as expected before trying the module. Please do the initial test with the motor not actually driving anything.

Apart from the fact that module doesn't work with the "UHU specific" terminal, the process of setting it up is pretty much the same. Don't worry about asking questions if you're uncertain but also don't be afraid of simply trying things - that's how you usually find problems ;-)

I'll be here if you need me.
/Henrik.

[kreutz]

Hello Henrik, Paul and John;

Just to let you all know that I am still alive although I haven't had enough free time to keep on visiting the forum and my PM box has been full for a long time. Just came back from Spain where I spent a month on vacation far away from my PC and cell phone.

Best regards,

Kreutz

[jcdammeyer]

Welcome back. I had trouble shedding my cell phone in Greece this spring. Found an internet cafe with low booze prices right by the beach. The family spent it getting wet. I drank beer and surfed with my iPhone.

John Dammeyer

[H.O]

Yes, welocme back Kreutz!
I hope you'll check in now and then, as time allows.

/Henrik.

[tenmetalman]

Kreutz,
Holidays are always too short, glad to know your alive & kicking. I can't keep up with my "stuff" and I'm retired !
best to you & the family. looked at the wife's site not long ago & it was looking great as as always
Paul

[kreutz]

Thanks guys, I am glad you are all OK and still on the CNC wagon... I am planning to come back here more often, it will probably take still a while to start working on my CNC stuff.

My first year's goal was to start a new enterprise and make it profitable; Goal accomplished!. My second year's goal is to keep it profitable (while working less hours a week) having at least as much free time as before so I can enjoy my hobbies.

Best regards,

Kreutz.

[jcdammeyer]

So watcha up to?

John Dammeyer

[kreutz]

So watcha up to?

John Dammeyer

My business is related to the "high end" medical imaging equipment field (X-ray, CT, MRI, Nuclear medicine, PACS, etc) specifically multi-vendor (G.E., Siemens, Philips, etc) equipment sales, technical training (for field engineers) and service.

[tenmetalman]

H.O. & all

with Henrik's help I've been making some progress on my mill. I did have two axis running (X & Y) last week using the uhu chip. I've had a reoccurring problem with poor/no communication between the axes & mach3 and or erratic movement under the terminal program over the life of the project. Henrik gave me some suggestions & using his guidance I got the X & Y axes working well in mach3/uhu chip. I was working in the Z axis & managed to short out the Y drive killing it.....
so after repairing two drives over the weekend I was in the shop today and now have the X & Z axes up and some sort of problem with the Y axis wanting to run away. When I quit to grab a bite to eat I had decided I needed to check my Y encoder cable to see if I've broke a wire or shorted two or more at the drive end (quite a sharp bend there)
I've had the X & Y running using the module and basically just got them rough tuned using the module (before I smoked the Y axis). I had the road runner program running in mach3 and so far what I'm seeing is two significant differences between the uhu & modules. first & what I was hoping for, the module handles 500, 1000 & 2000 count X 4 encoders w/4000rpm servos with no problem, very consistent control . what I wasn't expecting but am pleasantly pleased with is that with the module the servos sound so smooth & as though they are effortlessly going through the motion. when using the uhu chip I thought the servos sounded very good. with the module, the servos have a real different, quiet, free (?) sense about them. I know I'm being very subjective in this post but just wanted to share my experiences so far.
"I'll be back"
Paul

[LZ1TWB]

Hi Paul,

You say motion has different sound, to say better. Is this with the PP or you are using a smooth stepper? I thought once that the irregular sound, going through different speeds was related to mach3's output pulsing and not the drive itself.

Here it makes a lot of difference when using the multiplier option. It gets quite noisy when going to the higher numbers. Of course "0" is the best, but not good for a PP setup with high resolutions.

Todor

[H.O]

Hi Paul,
I'm glad you're on the right track, sorry about the Y-drive though. Like a said in our e-mail conversation I admire your persistance.

What Todor says about the multiplier is true for the new module as well. The higher multiplier setting you use the more the motor will sound as it in reallity are moving in larger "steps" than with a lower multiplier.

Using a higher resolution encoder and then "wasting" that resolution by using the step-multiplier may seem a bit counter productive but in reallity the higher resolution encoder provides more "information" for the servo-loop to work with so it can provide a stiffer control of the motor.

I had a filter routine working earlier that made running with high(ish) step-multilplier settings a lot smoother with the drawback of introducing a slight "lag" to the response but that is not availble in the current firmware.

Regarding the Y-axis, a bad encoder connection can cause runaway, so can a shorted output transistor. Hopefullt it's the former in this case. Let us know how you get on, let me know if there's anything you need.

Thanks for the feedback, I appreciate it!
/Henrik.