[neilw20]

When an edge generates an interrupt, ideally at the SAME TIME as the interrupt, BOTH A and B need to be read.
If the interrupt routine is reading A and or B AFTER the interrupt, it is possible the data may have already changed, so the wrong logic state is processed.
A good way to achieve this and get rid of the latency problem is to read the A and B bit on the same port and have each transition generate the the interrupt.
There are a lot of low end CPU's that can't do this. You can only tell it which pin will be the interrupt pin. We need more than one interrupt pin for proper operation.
Externally you can latch the state with a flip-flop to overcome the latency problem, but if you are going to spend money on extra parts to overcome the problem, you might just as well use a better (more expensive) CPU.

There are quadrature chips that do all the fancy timing stuff up to frequencies, that would require a Pentium, so the chip keep count and the CPU just examines the count and direction from the chip as required.

Bottom line. Can the CPU hack the pace. That's why the error signal is required. The CPU might be off in the weeds when it is needed.

[H.O]

Neil,
The drive and the processor is what it is - it's not changeable, not at the moment anyway. There may be a processor upgrade in the future but right now it is what it is.

With over 4000 UHU-chips sold and Mach3 being as popular as it is I'm having a hard time seeing that I should be the first to realize it doesn't work above 15-20kHz.....

Kreutz,
(Mixing in comments to your PM here)
U3 is 74HC14 and I've already increased the pulsewidth in Mach3 to 5uS. Doing that made it slightly better but I can't go above 600rpm (20kHz) without losing position.

I'll make some more experiments today, the goal is to have 2500counts per rev, and have the multiplier setting set to 1 in the UHU, with my gearing and screws that'll give me 500steps/mm at ~42kHz. If all else fails I'll try a "pulse-stretcher" flip-flop with around 10uS. But, with that route, if the jitter is large I may end up missing step-pulses instead....aarghh....

Please, can't anybody else report what you're getting!?

Thanks,
/Henrik.

[neilw20]

Henrik,

You really don't want to close up the overlap time.
Does this card use 4013 flip flop or some other counter chips.
A generic 4013 requires clock rise time better than 15uS as do quite a few counter chips. This is a trap because if the designer used schmit trigger input counters his design would work.
Phillips HEF4xxx parts have no rise time limits. Most generic parts quite often have.
If the clock inputs are not buffered into a CMOS counter chip the rise time usually has to be less than 15uS. This is because internally the flip flop uses the property of a transmission gate, namely remembering the last data state during the clock transition. The small capacitor storing this state loses it's charge and hence the logic can become corrupted. It is also temperature dependent.

[vroemm]

With over 4000 UHU-chips sold and Mach3 being as popular as it is I'm having a hard time seeing that I should be the first to realize it doesn't work above 15-20kHz.....

The UHU community talks about a lot.
But somethings are not talked about, as far as i have read.
Like the accuracy of their cnc router, 1 mm, 0.1 mm or 0.01 mm ?
Which is important.
I rarely have read about it.

Have you read messages mentioning the actual step speeds others have reached ?
If not, maybe everybody uses the lower step speeds ?

Vroemm.

[H.O]

Hi Guys,
The computer is running Mach3 and Mach3 only (well of course there's other processes running but nothing "extra", no antivirus etc). The LPT-port is the onboard one, I don't have a PCI-card right now but I doubt it'll make any difference. Running the Mach3's DriverTest application shows that the system stability is "excellent" - even att 100kHz kernal frequency, please see the attached screendump.

Scoping the step-signals reveals that there's jitter on the pulsestream for sure, the higher kernal-frequency I select the better it gets - as can be expected. If I set the step-pulse width to 3 in Mach3 I get roughly 10uS wide pulses but even with the kernal frequency set to 100kHz I can not go above 600rpm (20kHz step-frequency). (I know it wouldn't work with 10uS wide pulses at 100kHz step-rate but I can't reach that speed anyway so....)

Normally, if a step pulse is to be sent during "this" interrupt Mach3 sets the output, then go and do some other housekeeping and then resets the output at the end of the same interrupt. This produces narrow(ish) pulses on the step-line. But there's also a mode available where the step-pulse doesn't get reset untill the next interrupt, thus producing much wider pulses (and effectively reducing the max step frequency by 50%). I've tried this mode too to no avail, so building a flip-flop circuit that stretches the pulses probably won't make any difference.

Regarding what speed others get - I don't know....that's pretty much why I started this thread. There are some confliting number floating around, everything from 100kHz to over 300kHz on the UHU-website, then someone stating they never could reach beyond 75kHz.

Obviously the problem IS the jitter since it works fine with the signal generator, I'm just a bit dissapointed that it just won't work with Mach3 without spending more money on a Smoothstepper or simmilar device :-(

Thanks!
/Henrik.

[vroemm]

The apparent problem could be also un-related to encoder noise, but more related to noise/jitter at the Step input.

There is a way to measure the jitter.
At startup the free version of turbocnc on msdos shows a screen with on it a text something like:

"On this computer Jitter approaches 10% at xxxxx Hz."

On my old amd 7934 500 Mhz computer it shows 16500 Hz.
I do not know if this is a reliable or useful number.
You could try it, and see if you get a higher step rate when turbocnc shows a higher frequency.

Are there differences in the quality of the parallel port ?
Maybe a different parallel port card gives less jitter ?

Do you have other programs running ?
Maybe without knowing it ?
Other programs demand some cpu time.
Which could increase jitter.

Can other PCI, ISA, USB or other cards increase jitter ?
Like the presence of a soundcard ?

Vroemm.

[rokag3]

hello,
ok here some info
with step multiplier m=7
so 8 time the number of steps send
with an encoder at 2048 points
freq of sending=9374 hz
so 9374/256=36.617 rev per seconde
36.617*2048=74991 hz speed of sampling of the encoder
at this speed overrun 0
rpm:2197rpm
BUT
if you use uhu monitor with A option
and you make ?
you win 4 or 5 overrun
(if the motor is running)
so just switch off A option
and type O <carriage return>
you will have the value of the overrun.
this seems not perturbate uhu
i am going to see how much i can go above 75 khz
after that i will change the value of the encoder to 1024
the motor run at 200 V

[vroemm]

with step multiplier m=7
so 8 time the number of steps send
with an encoder at 2048 points
freq of sending=9374 hz
so 9374/256=36.617 rev per seconde
36.617*2048=74991 hz speed of sampling of the encoder
at this speed overrun 0

Do i understand this correctly ?
Does this mean the encoder circuit is not the problem, because this test shows it can go up to 75Khz ?

The step signal goes via a optocoupler.
What if you put a 75 Khz step signal on the UHU.
And measure the step signal after the optocoupler, on the UHU chip, with the osciloscope ?
To see the quality of the signal, in time and voltage.
Preferably with a digital oscilloscope then you can record lots of steps to see the effect jitter has on each step pulse.

Vroemm.

[H.O]

Hi guys,

he's getting 8000 mm/min of a 1000ppr encoder, think multiplier is set to 4

Thanks Irfan, and how many steps/mm?
You see, right now I don't really care how fast the machine is moving I want to know how fast he "steps" the motor. Say for example that his machine moves 4mm for each rev of the motor, there's 4000cpr/rev and the multiplier set to 4 so basicly 250steps/mm if he's getting 8000mm/min he's doing ~33.3kHz which is way more than I can succesfully get. If the encoder is 250lines (so it's 1000cpr on 4X mode) then the stepfrequency is only ~8.3kHz which is more in line what I can get.


It seems pretty obvious now that this is due to the jitter on the pulse-stream coming from Mach3. Let's say you have the kernal frequency set to 25kHz in Mach3, now you want to step at 12.5kHz - easy - one step every second interrupt. Step-skip-step-skip-step-skip and so on

But what if you want to step at 10kHz? You can't step every 2.5 interrupts so what happends is something like. Step-skip-skip-step-skip-step-skip-step-skip-skip-step and so on. Over time the average frequency is 10kHz but as you can imagine the step-pulses aren't evenly spaced anymore.

This you can't avoid when generating step-pulses in software and Mach3's pulse-stream is conciddered quite good actually so I'm quite surprised that it doesn't work better that what it is. And it's therefor I'd like to know what results others are seeing.

Vroemm,

Do i understand this correctly ?
Does this mean the encoder circuit is not the problem, because this test shows it can go up to 75Khz ?

Yes and no, it seems. I've successfully run my setup up to ~65kHz step-frequency with the multiplier set to 0 (the motor doesn't like going faster than that...). I've run it for over 10 minutes and didn't have a single false transistion - feeding the step-input from a signal generator. However, when using Mach3 to feed the step-pulses I can't get over 13kHz before getting false transitions. Right now I don't see any other reason than the jitter.

[LZ1TWB]

Hello Henrik,

This is something new and very interesting that I read about the step pulse jitter comming from the PC. I have never thought that problems could lead to that place of the schematic at all. I have never tried feeding the UHU from generator but is something i will definetily do as I am also interested in findind the solution of the problem.

As for my setup I have said dome time before, I have got up to about 95Khz but limited it do about 75 as I do not get a single error. I have to be sure that when the machine works it doesn't make mistakes. I cannot sit all the time with another computer switching COM ports from one drive to another to make sure I am on position. Just not the right thing to do.

Maybe there could be some schematic buffering the step signals from the PC and making them somehow more steady. I dont know.

I thought the drive works out the step pulses and it doesn't matter when they come in the time. Maybe it is not like that.

Thanks,

Todor

[H.O]

Hi Todor,
Yeah, this is really bad news for me. Considering Mach3 being what it is I'm really bummed that it doesn't work better than what it is. As I said before there IS jitter for sure but only problem I've had with in the past (with other drives) is that the motors may sound a little bit different or, in the case of steppers, they can't be run as fast is with a steady pulsestream.

It's strange because if feeding it 65kHz (or even 95kHz in your case) from a signal generator there's a pulse coming in every 15uS and it doesn't miss anything. But using Mach3 at 25kHz kernel frequency the closest two pulses can ever be to each other is 40uS and it still doesn't work.....

About the buffering, I did try the PLL-circuit that usually sits in a G210 step-motor drive and it made it a bit better but not usable. I haven't ruled anything yet but every test I've done point to the problem coming from jitter in the pulsestream.

What you say about constantly watching the machine, worrying about if it's doing what is should is spot on. It has to be reliable or it simply will not work....

I thought the drive works out the step pulses and it doesn't matter when they come in the time. Maybe it is not like that

I thought that too, to some extent atleast... the more I think about it the more strange it is when you consider what I wrote above. That is why I'd really like to know what others are experiencing....

This is a major show-stopper for me right now and I feel a bit lonely..... ;-/

[rokag3]

i have manage to go at 12000 hz
but then i have overrun sometime and it seems that the motor do not go that fast
2812 rpm
surprising since the max speed is suposed to be 4000
i will change the value of the encoder and i tell you

[H.O]

Hi,
Thank you VERY much for doing these tests.

Are you using Mach3?

So, in your first test you got to ~9kHz stepfrequency and in the second test ~12kHz so far this matches my 13.5kHz I initially got although I have managed to get to around 20kHz but it's not completely reliable at that speed.

If you don't mind trying one more thing could please set the Multiplier to 0 and see what kind of speed you can get.

I've never used the "online-thing" in the UHU, I always que it for an answer.

Again, thank you, I really appreciate it!

/Henrik.

[contactirfu]

HI,

if you watch the below video it goes over 5000mm / min thats like 220IPM, amazing our machines cant do that!

www.youtube.com/v/j2pRCX8kfpA&hl

[H.O]

Thanks Irfan,

Could you please give me some more details about that setup then:

Encoder resolution?
How many steps/mm is Mach3 set to?
Is the multiplier in the UHU set to anything other than 0?

I have no problem making my motor spin at ~2000rpm, the problem is that the UHU-chip loses track of where it is because it misses either step-pulses or encoder transitions. Now, in your video, I see that the indicator on the Z-axis returns to zero at the end but have you checked the O-parameter in the UHU on all three axes after a run like that? Does it read zero?

Thanks!
/Henrik.

[contactirfu]

OOPS henrik, jut picked it out of youtube, I have asked the same Q to the person who has posted the video.

RGDS
Irfan

[contactirfu]

also if you see the video carefully (at the end) you will see the UHU settings he has.

he's getting 8000 mm/min of a 1000ppr encoder, think multiplier is set to 4

[kreutz]

Henrik;

Have you tried with a different PC? Or the same PC driven by a (free) DOS/Linux based CNC program (for testing only)? It is a little bit odd that nobody complained before about this issue...

About PC optimization:

Did you try stopping the networking/remote access/firewall/print spooler/cryptographic/ related services on your PC? I assume that no anti-virus or PC fix/monitoring software is running (Norton/iolo/etc).
What amount of RAM? What is the virtual memory size?
Do you use a fixed size swap-file, or is it Windows controlled?
Is the higher priority assigned to foreground processes or background processes?
What type LPT port is assigned on the BIOS?
Have you tried a different LPT port (PCI card)?

Regards,

Kreutz.

[contactirfu]

Hi henrik ,

U are not alone, though I tried to get the O parameters tested at different speeds today, I sort of was confused.

here is my story.

today after setting up the delay switch i set of putting together both the X and Y to their paces and here is what I discover, at around 4000mm/sec and 45KHz there were around 8 O's and then as I wnet on reducing the speed I had to settele down of 3200mm/sec. thats real bad. Also considering the fact that the place where i have my workshop located has a night time voltage of 195 to 200 volts on each phase I had to derate my speeds to 3200mm/min and then there were no O values anymore.

thats what I could make out today. If it is a possibility for increased speed and reliability with smooth stepper then I would in all case go for it sooner or later!

let me know if you want me to do more tests and let me know how bcos I also don't have a oscilloscope.

Thats it from me today.

RGDS
Irfan

[H.O]

Hi guys,

Kreutz,
I agree it's odd, that's why I'd like to know what others are getting.....Perhaps they simply haven't used speeds above ~13kHz with Mach3 or never actually checked the O-parameter, or it's simply a problem with my setup, I don't know...... Odd, yes....frustrating, yes.....

This is the second PC that I've tried with, the first was a laptop and this one is a purpose built machine, dual core Athlon CPU at 2.2GHz, 2GB RAM and it boots from CF-card so the swap-file is turned off. Only other software installed is AcrobatReader and CUBLOC studio but none of those have any services running at startup. There's no antivirus, no printer-drivers, no firewall software or anything else running except the touch screen driver.

Mach3's drivertest program shows "excellent" stabillity even at 100kHz kernel frequency as can be seen in an earlier posted screen-shot.

Right now I don't know what mode the onboard LPT-port is set to as I haven't touched that part of the BIOS, I'll check it though. I have not yet tried with a another LPT-card but I guess I could order one just for the heck of it.

I have yet to try disabling the network card, thanks for remindning me of that.


Irfan,
Thank you for doing those tests! Let's see if I got this correct....

** You have the kernel speed in Mach3 set to 45kHz, correct?
** You have the axis velocity set to 3200mm/min, correct?
** If you raise it above 3200 you start to get false transitions acording the O-parameter?

Questions:
** Do you have the M-setting in the UHU set to anything other than 0?
** How many steps/mm do you have Mach3 set to?

Thanks guys!