[LZ1TWB]

Hi Henrik ,

If you can really achieve only 13Khz I think you may be having some problem with your drive or the encoder/motor. I is much lower that I have made /and I think I've not made that much /.

And when I say 75KHz I mean encoder steps. With a 25KHz mach3 kernel it means that my M parameter is something like 3 or 4. I tend not to push the computer more than 21-22Khz as it seemes to have problems as slower screen updates and such latency stuff /Driver watchdog triggers also when I got as high as 25Khz/. My CNC PC is PentiumII 733 128 RAM, driving simple steppers so far 3 axis with no problems.

Have you tried to change the board? Or the motor with different encoder? I have experienced some other problems with electronics and found it very useful if there is another equipment to be able to change and therefore compare the results.

Todor

[H.O]

Irfan,
Thank you! If you run 3200mm/min at 400steps/mm you are stepping at 21.3kHz which is close to twice what I'm getting - that's a lot better but still not good at all.... I'll need to have another look at my computer, turn off the auto negotiation on the network card etc.

Todor,
Yeah, I'm not ruling out anything but since I CAN step it at 65kHz with the signal generator I'm having a bit of a problem seeing it be the drive (electronics) or encoder. Your 21-22kHz seems to match Irfan's numbers pretty good. I'll swap back the encoder to my 3600lines one and see what numbers I'll get with that one.

I really need to be able to step it at atleast ~35-40kHz (with M set to 1) or preferably ~70-80kHz (with M set to 0). Even if I can get 20kHz it's way to slow....

Yes, a 733MHz for Mach3 is a bit on the slow side, I've heard about people running on 500Mhz but I can imagine the GUI gets a bit slow....

Thanks guys!

[LZ1TWB]

** Do you have the M-setting in the UHU set to anything other than 0?

yup M is zero - not tried anything else.

Irfan is using M=0 which means that encoder frequency is equal to input frequency. In my case M=3 which leads to 4 times the input frequecy, for example 20x4=80Khz. So I think I've managed 80Khz not 20. Just a thought to make sure we don't mess up the numbers here.

Anyway what type of signal generator are you using /I missed that/ - desktop function generator, simple 555 type or smth else?

Thanks,

Todor

[H.O]

Todor,
The signal generator is a desktop type - not a very advanced one but it's OK.

We have to separate the encoder frequency and the step-input frequency here or we won't get anywhere..... The problem doesn't seem to come from the encoder frequency at all but from the step frequency. (Or rather the jitter the in the pulse-stream)

I can get ~13kHz with Mach3, 65kHz with signal generator
Irfan can reach ~21kHz with Mach3
You've reached ~21kHz with Mach3

Only reason I asked Irfan about his M-setting was to calculate what step-frequency he was running.

The UHU manual/FAQ/website states that you should be able to reach 100kHz in "any case" but that step frequencies as high as 300kHz have been achived under optimal conditions. (Depenading on the M-setting, recalc-interval etc etc)

If 100kHz should be possible in all cases how come none of us have been able to get above ~21kHz?

Even if the jitter is as bad as it possibly CAN get with Mach3 set to 25kHz pulse frequency there's still 40uS between pulses when the UHU clearly should be able to "see" them if there was as little as 10uS between them.....

Anyway, have to run now, will try to switch encoders and have another look at the computer tonight.

Thanks!
/Henrik.

[LZ1TWB]

So here are the results from my latest test I did this morning. I used my home PC as it is much faster than the previous mentioned - Dual core athlon 2.2GHz, 2GB RAM;
/assuming my encoder is 1024steps/round x4=4096 and 10mm pitch screw/

(1)
Mach3 set to 100Khz
M parameter = 0
409.6 steps/mm
F11000mm/min

This speed is equal to an output frequency of 75093 Hz comming from the parallel port. No problem at this point. I cannot move higher as the Driver watchdog triggers and takes mach3 into a reset condition. The PC is not made for cnc use with all the stuff that has to be turned off so maybe that's the cause.

(2)
Mach3 set to 75Khz
M parameter = 0
409.6 steps/mm
F10000mm/min > f=68226 Hz, No problems

(3)
Mach3 set to 75Khz
M parameter = 1
204.8 steps/mm
F15000mm/min > f=51200 Hz /par. port/ ; f=102400 Hz/encoder/,No problems
Single errors triger above F16000 which is f=109226 Hz/encoder/

I almost got to the end of the motor speed with this voltage having some errors. Motor is 2000rpm max.

(4)
Mach3 set to 25Khz
M parameter = 4
81.92 steps/mm
F15000mm/min > f=51200 Hz /par. port/ ; f=102400 Hz/encoder/,No problems
Errors come above F16000 which says it makes no difference if I use mach3 at 100Khz with M=0 or 1 and if I use it at 25Khz with M=4. The results are all the same - I get stuck at around 100Khz.

This is for now that I have done here.

Todor

EDIT: I forgot to mention but I am using the old board design. Since we are discussing processor power here I thought it makes no difference.

[H.O]

Thank you very much Todor!

Your test prooves that the processor is capable of handling Mach3's pulse-stream at 75kHz, which is way more than what I'm getting.

My computer is also a dualcore 2.2Ghz with 2GB RAM so it should be on par with what you have. Mine, on the other hand, does not have any extras on it so it should be performing better than what it is.

** My tests with the signal generator shows that the HP-UHU drive, the UHU-chip and my motor/encoder is capable of speeds at or above 65kHz step-frequency.

** Your tests shows that the processor itself, when driven by Mach3, is capable of 75kHz step-frequency or more.

** The above prooves that it's not a general problem with Mach3's pulsestream but rather something with MY computer/Mach3 setup. I'll keep on digging.....

Again, a sincere thank you for doing the tests!

/Henrik.

[krazatchu]

I briefly scanned the thread so perhaps someone has already mentioned this...

As it runs fine from the signal generator, the problem seems to be either the parallel cable, the pc, XP, or mach 3....

From my own experience, I 'm guessing it's a combination of XP and Mach3...
I had jitter problems until I turned off ACPI...

Anyhow, have you setup the pc as per the Mach3 optimization guide?
http://www.cnczone.com/forums/showpo...64&postcount=1
There might be other version of this around, this one looks similar to the checklist I used...

Most importantly, Step 6 ...
Hope that helps!

[H.O]

Hi,
I agree - it has to be a computer/software thing. Todors tests prooves that the chip is capable of handling Mach3's pulse stream and since I can't match his results by a long shot the problem must be my setup.

The strange thing is that Mach3's drivertest application shows excellent timing results but obviously it's not as good as it could be. This computer has an onboard graphics card which is generaly advised not to use but again, since the drivertest app shows good results I've thought it worked OK - may not be the case....

AND this IS the second computer I've tried the last one was a much slower laptop but I got basicly the same results from that one.

Thanks!

[H.O]

Sorry guys, I know this is getting old fast but I feel I'm at ends of what to do here....

I switched computers again, this time to the one that's running my small mill. It's been running the stepper motors thru G210's at 4500mm/min with 500steps/mm without problems for years - that's 37.5kHz.

Swapped in the HP-UHU, still pulsing at 37.5kHz and after running a minute or two long program of G0 moves back and forth I had 15 false counts.... I then swapped motors to the one with the 3600lines encoder, loaded the second set of parameters in the HP-UHU and tried again. No difference....still massive amounts of invalid transistions.

I've now tried three different computers, with and without the C11 breakoutboard, two motors and two different encoders. I've tried with both long and short encodercable, shielded and twisted pair, shield connected to GND in the DB15-connector only - and there only. It just won't run reliably at any speed what so ever.....

Todor, would you mind giving me your complete UHU parameter list? I know the PID paramters won't do me much good but the recalc-interval and the a few others might be interesting. Also, do you have your encoder cable shielded, if so where is the shield connected?

Thanks!
/Henrik.

[krazatchu]

Hi...

Did you disable ACPI?
If it's not disabled, XP will want to slow down the CPU when it's not being used so much... This introduces jitter...

Follow these instructions to disable ACPI...

1. Right Click My Computer and select Properties
2. Click Hardware tab.
3. Click Device Manager Button in the middle.
4. Double click "Computer".
5. Right click on Standard ACPI PC and choose Update Driver.
6. Choose "Install the software from a Specific Location (Advanced)"
7. Click Next.
8. Choose "Don't search. I will choose driver to install."
9. Click Next.
10. Choose "Standard PC" from the listing.
11. Click Next.
12. Click OK.

Now reboot... and try it...

[rokag3]

hello,
i think that we should look at this simple experience
launch uhu monitor
send with mach a sequence
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
we have a nice platform for experiment
but this is the proof that despite a good encoder uhu can be in trouble

meanwhile it will be interisting to get the same info from the other controller
it is very trendy to, if the result are no good to do not give the info at all or break the thermometer !!!
here at least we have the info and we should not exagerate the consequence on large encoder

[H.O]

Hi,
Just tried disabling the ACPI on two of the three computers. On the first one it made no difference, got 31 "O-counts" where I previosuly got 15, lowered the velocity so the effective step-frequency was 25kHz and got 21 "O-counts". This is on the machine that's been running my Geckos at 37.5kHz for years (with ACPI still ON)

(The number of O-counts on the different runs isn't really important, doing two runs of the same program at the same speed may end up with 10 O-counts the first time and 25 the second)


Then I tried the second computer, the dual core one that's supposed to end up running the machine if I ever get to it.... ;-) Switched to Standard PC and rebooted and now I'm stuck with it asking for a driver and no way to tell it where to look since neither mouse, keyboard or touchscreen is working....


Rokag3,
As I've stated before I have never used the A-option during these tests. I always run my test-program and then I ask it for the status of the O-parameter by typing 'O' and press enter. I'm using HyperTerminal as the cosole so the A-option wouldn't do anything for me even if I wanted to right now.

Thanks guys, and sorry for the frustration!

/Henrik.

[LZ1TWB]

These are my PID settings, pretty much the default values that came firstly. Only the P,H,I are changed.

Yesterday I tested recently assembled board, and what you think - OMG, errors occur at even low speeds, and they are connected more to the processes of acceleration/decceleration rather than speed itself. I am really pissed and don't know what to do.

The schematic has some different components from the other board but they are as the original shematic. It is the old board that has some differences from the schematic but it behaves better .

Maybe IRFP150N's work better on my setup than the 260N which are now put, I don't know.

The other changed thing is the RC network at the output if that would be a problem. Other components are pretty much the same.

I start to doubt that I can make 4 working controllers to drive the machine at nice speed.

Todor

[contactirfu]

H iTodor,

why such a high value of E, you should be able to do it within 100. and what does X mean "speed?

I have a value of 300 for x and still it works well at 3200mm/min, I think I should try changing that to get better speed.

sorry for the off topic post!

RGDS
Irfan.

[kreutz]

.......The schematic has some different components from the other board but they are as the original shematic. It is the old board that has some differences from the schematic but it behaves better .
....................

Todor

Todor;

Are you using HP UHU boards or original UHU?

Thanks,

Kreutz.

[H.O]

Todor,

Please confirm that the old test you did was with the "older, standard" UHU board and these new tests are with the new "HP-UHU board".

Please also confirm that all other components of the system (power supply, motor, encoder, computer etc) are the same. Basicly the ONLY difference between the previous test where you got to 75kHz with Mach3 and these new tests where you're seeing the same thing as I do is the drive itself.



Irfan,
The X-value is a speed limit when the drive is commanded to move with the G-command. It's not used with Step/Dir acording to the manuel. Never the less the manual states that it should be set to 5000 when using Step/Dir. Mine is still at 300, I'll try changing it by I doubt it has any effect on the problem at hand.


Kreutz,
I'm glad you're following this! Let's wait for Todor to confirm or correct and we can go from there. I hate to say it but I'm glad I'm not alone on this anymore.....

/Henrik.

[LZ1TWB]

Hi all,

No, when I say the "older" board I mean the one I have assembled some time ago. Both boards are with the OLD schematic, I am not using the HP version.

Todor

EDIT:

H iTodor,

why such a high value of E, you should be able to do it within 100. and what does X mean "speed?

I have a value of 300 for x and still it works well at 3200mm/min, I think I should try changing that to get better speed.

E = 1024 which is 1/4 of round of the motor. Even with that value I cannot hit the STOP button in mach /when travelling at high speed/ because the drive resets, leaving the motor free spin. This has been discussed some time before and Kreutz said it is connected to the firmware and obviously cannot be changed.

This is something bad when using limit switches that triger MACH3 and when it stops the pulses, the motor cannot catch the position and resets, leaving the iron into the wall. Well, it depends on how far are the limit switches, but I believe noone wants to loose axis travel for this.

Todor

[H.O]

Todor,
Sorry for the mixup.... So, both boards you've tested are the same hardware-revision/version then? Did you use the same motor/encoder, the same PID settings, same computer, same settings in Mach3 and the same cables etc?


I've spent several more hours today trying different settings, swapping computers, connecting/disconnecting breakoutboard etc etc but it WILL NOT run with Mach3 on any of the three computers I have.

I made a simple G-code program that run the motor 250 revs forward and then 250 revs backwards. This program was run 5 times in a row at different velocity and acceleration settings. The O-count was recorded and reset between each run.

The results can be seen in the attached .pdf.

What's strange is that it 'almost' works at a velocity of 400 (13.3kHz step-frequency) where I've "only" got 1 false count in a total of 15 runs but above OR below (!) 400 it's getting a lot worse.

Basicly this proves that my system, for whatever reason, is completely unreliable at any speed. Again, I'm not ruling out anything and I'm not "blaming" anything but to me it seems as if the UHU and Mach3 isn't very compatible.

The HP-UHU works with the signal-generator so I can't "blame" that. Mach3 works just fine on my other machine, happily running steppers at 37.5kHz so I can't blame THAT computer or THAT version of Mach3 - they simply will not behave together.

[contactirfu]

does then a device like smooth stepper make them (UHU and Mach) compatible?

I thought that when a Opto isolated BOB is used the signal got by the UHU are copies from the parallel port and not exactly the ones which come out of the same.

hmmmm very interesting!

with so many people using mach and UHU ..........................

[H.O]

with so many people using mach and UHU ........

Yeah, I thought that too but there doesn't seem to be that many here.....

The reason I tried with the breakout board is that it "boosts" the signal-level a bit. My LPT-port output 3.3V when high and that can be problematic for some drives that are desinged to operate on 5V logic. This, however, doesn't seem to be a problem for the HP-UHU, it seems to work the same on 5V and 3.3V levels at the step and dir inputs.

Since running it with the signal generator works but running it with Mach3 doesn't it "must" be the jitter on the pulse-stream generated by Mach3. Again, for software generated pulsestreams Mach3's is considered quite good. The smoothstepper takes over the pulsegenerating from the PC's CPU and produces a pulse-stream with less jitter.

Does it make them compatible? I'm not sure......I'm not sure of anything anymore.....

/Henrik.