stepper motors glitching

[routercnc]

Hi Lee,

I did some more testing last night, and got the PC spec.

Processor AMD Athlon XP 2600
RAM 1.5Gb
Graphics card FX5200 128MB ram (i.e. not built-in)
MB Asus A7N8X Deluxe Gold
Windows XP SP3

A few years old, but plenty good enough!

Checked the output of the Parallel port directly and still got glitches on the scope.

Then disabled the PCI parallel port and got clean pulses from the main port! Quickly hooked up the steppers and got clean runs - for about 20 seconds, then the glitches came back. The allegro chips all got quite warm on the drivers, even though the current is limited to 1A. System3 is an all in one board, and for these tests it is out in the open. Shouldn't be overheating surely? Thinking about heatsinks and direct fans on chips to see if this helps (case has general exit fan).

I might need to remove AVG to see if that helps, but the chip heating needs to be checked out a bit more first.

Thanks
Barry

[John S]

Try this.

http://www.codeproject.com/KB/system...cAnalyzer.aspx

and check the BIOS is set to EPP

[routercnc]

Hi irving2008,

Looks like I did not create an ISO. Am reading about those so I can try again.

John,
Downloaded the analyser and tried it briefly. The graphical output showed some red pulses, but they were all in a block. I need to play with that a bit more, but my Wife is getting upset with the amount of hours (days!) I'm putting into this.

Started again with a clean install this morning, following the Mach3 windows optimisation steps. Disabled everything on the list (sound, gone back to classic, switched off auto updates etc.etc.). Switched to 'standard PC' in hardware.
Still glitches.

In BIOS have disabled: game port, midi port, AC97 audio controller, onboard lan (nvidia), onboard lan (3com) 1394, serial port1, serial port2
Parallel port is set to: 378/IRQ7
Still glitches.

Then went through all the parallel port options in BIOS: ECP+EPP DMA3, EPP, ECP DMA1, ECP DMA3, SPP, ECP+EPP.
Still glitches.

Then in Mach3 traversed at various speeds (since I noticed that 1500mm/min did not glitch since this fresh install). Noticed that: 50,300,500,700 mm/min all glitched. 1200 mm/minute occasionally glitched. 1500mm/min never glitches, nor does 2500mm/min. 3500mm/minute makes the motor sound unhappy (but not glitching). Cutting at 1500mm/minute is not possible, so this is not a solution but may point to the answer.

I hooked up the scope to the system3 boards whilst it was running, onto pin3 and earth. At 1500mm/min (when there is no glitching), the scope does not give a steady spacing between pulses and is very inconsistant. I can no longer rely on the scope and need to use the motors as a glitch guide.

I'm beginning to think there is a fault with the MB (or parallel port). Even used on ebay this spec of board (ASUS A7N8X) still is quite expensive. What MB are people successfully using Mach3 with?

Thanks for your patience !!
Barry

[routercnc]

Update,

Installed ISO recorder into windows xp, and created a proper boot disc for Ubuntu and EMC2. Installed this onto a reformatted second HDD. I ran the latency test and got max jitter servo thread of 6983, and max jitter base thread of 7541. These are similar to the results in the EMC2 manual, so assume are OK.

I then ran EMC2 using the 'stepper mm' profile. Unfortunately this also glitched the motors!

I then tried the profile which sends the stepper pulses to the speaker (nice feature). This also glitched. I attempted to record this into another computer using 'windows sound recorder', so I could post this and do some analysis on it, but got the windows error about not enough memory. Microsoft say this is a problem on machines with more than 2GB (this other machine has 4GB), but do not offer a fix.

Anyway, later today I switched on the CNC PC and tried Linux again, but system will not get past POST with 'NTLDR is missing' error. Tried lots of things but can't get past this. PC obviously thinks there is a problem with the boot or root directory of the Linux HDD.

Went back to Windows XP and added a PCI parallel port, added the driver, and configured Mach3 to this port. Motor rotated, but still glitched. Glitches are still happening at <900mm/min or so, but not >1500mm/min. This test probably means the built-in parallel port is OK.

So in summary:
Fresh install XP, optimised computer (all drivers updated, standard PC, minimal hardware enabled etc.): this helped and glitches only occur <1500mm/min
Brand new replacement driver system3 board from Roy - glitches
Mach3 using PCI parallel port (Moschip) instead of built in port - glitches

Fresh install on reformatted HDD of Linux and EMC2 - glitches
Linux and EMC2 output to speaker - glitches

This all suggests it is the motherboard (ASUS A7N8X Deluxe Gold), or MB chipset. I would welcome information on successful MB & chipset combinations which work with Mach3 (or EMC2), what are other people using?

Also, been reading about smoothstepper. Since this takes the timing away from the PC, do you think this would help?

Thanks
Barry

[irving2008]

Update,

Installed ISO recorder into windows xp, and created a proper boot disc for Ubuntu and EMC2. Installed this onto a reformatted second HDD. I ran the latency test and got max jitter servo thread of 6983, and max jitter base thread of 7541. These are similar to the results in the EMC2 manual, so assume are OK....

Anyway, later today I switched on the CNC PC and tried Linux again, but system will not get past POST with 'NTLDR is missing' error. Tried lots of things but can't get past this. PC obviously thinks there is a problem with the boot or root directory of the Linux HDD.

Barry

NTLDR missing is a Windows boot error, means that the PC has a Windows master boot sector trying to find NTLDR on the disc... suggests your dual boot setup is not right, or corrupted

[irving2008]

Definitely sounds like there might be a heat issue.

A useful trick from my 'making the design work on the manufacturing line' days... Pop to maplins, get a can of freeze spray (or B&Q pipe repair freezer) - its a bit pricy (£14 B&Q) but you only use tiny amounts. direct the spray onto hot parts one at a time, small bursts, till you find which component reacts. A temperature probe (Maplins £19.99) is also useful. Obviously adding a fan would help but sometimes replacing a part with a better rated part is a more effective answer, or adding localised heatsinks. Classic examples of poor design are the lack of heatsinks on voltage regulators so they flip in and out of thermal limiting - doesnt stop the circuit working but causes odd side effects as the regulator current limits and the 5v supply rail drops out of spec for a millisecond or so.

[routercnc]

Hi Irving2008,

I was beginning to think that this was a heat issue, but went back in the garage after work today and the reading direct from the parallel port was full of glitches again. I'm getting very confused by what seems to be perhaps multiple contributing factors.

Started disabling every other port and piece of hardware I could, and disabling AVG at startup, removed printer driver, and still got glitches on the port.

Only encouraging thing from this is that I've managed to ''hold" scope readings on the screen to work out the pulse spacing. Sorry I'm struggling to get these as a good photo (there is no output on the scope either), but I think the following will give you the numbers you need. These are the Mach3 settings, and theoretical pulse spacing:
INPUT
320 steps / min (calibration: stepper per rev, 1/8 microsteps, 5mm pitch)
1500 mm / minute traverse rate (my jog speed)

THEORETICAL OUTPUT
= 480,000 steps / min
= 8000 steps / second
= 8000 Hz
= 125 microseconds between pulses

Comparing this to a typical scope reading shows several pulses spaced at 125 microseconds, then a spacing of about 187 microseconds, followed by more at 125 microseconds. This 187 microseconds is probably:
125 + (125/2) which is 187.5

This means there are several normal pulses, followed by a gap of 1.5 times the correct pulse rate. This is odd, I was expecting missing pulses rather than a mis-timed output. It is more of a jump than a missing pulse. Does this give anyone any more ideas?

Thanks for your continued support and ideas . . .
Barry

Re-read your post, and thought I'd add a bit about the system 3 board and the heat. There are transistors with metal plates which I think are the regulators (see photo in post above). These do get quite hot to the touch within perhaps a minute or two, hotter than the allegro chips. I had considered heat sinks on these, but with the glitches on the parallel port that area of investigation will have to wait. Good suggestions about the cooling spray etc, thanks.

[Robin Hewitt]

Comparing this to a typical scope reading shows several pulses spaced at 125 microseconds, then a spacing of about 187 microseconds, followed by more at 125 microseconds.

A quick explain might be called for, if you already know all this someone else might find it useful.

Windows time slices the processor, that's how it can run several programs at the same time. A Windows programme is actually a whole mess of unconnected programmes all working to a common purpose.

For example: You ask Windows to put a button on the screen, a resource. You the ask Windows to allocate the button to you, and come to you should someone press it. Your button might require part of the screen to redraw but your button can only invalidate that part of the screen. Nothing happens until Windows asks you redrawing program to refresh that part of the screen.

Without time slicing the machine nothing works.

MACH has to assume that other programs do not create appreciable delays. If they do you get glitches. That is why you you want to crock everything possible apart from MACH.

AVG 9 has a bad habit of creeping across your disk checking files. I know this because I had a corrupt sector on my disk, if I tried to read it Windows crashed. It took about half an hour for AVG to find it running it's background scan and then POW, dead machine.

Go through your Start up and crock anything you can get away with.

[mel_earp]

Robins explanation is fine as a basic understanding, but as in any field it can and does go much deeper than this. I am sure that Robin is using the term "time slicing" in an informal manner, but the original time slicing based operating systems used fixed and then variable time slices which could not be interrupted. This is no longer true for Windows and it doesn't time slice in the strict meaning of the term. Also made more complicated with the advent of multi-processor chips. But Windows doesn't, and this is the problem, have much in the way of mechanisms to guarantee that processes that need it, get the resources in a timely manner. This is what I meant when I said that Windows is not a real time operating system, and it is never likely to be so because, apart from it being too hard, there is no commercial reason why Microsoft should make it so.

A real time operating system would know that certain Mach processes were time critical and would do all that is possible to give them the resources as soon as they needed them. Windows makes a bad job of this. The time taken to do this is called latency and this is one of the things the Mach (and EMC) test programs try to measure.

EMC will generally be better at this because it is based on a version of Linux with real time extensions - not fully real time from the ground up, but not bad.

If the source of this problem is the software (not yet proven) then the only hope is as Robin says, kill everything that is not essential for Mach. That includes AVG, any additional hardware drivers... I think it unlikely that a network driver could cause this, but it is known that some network drivers can spend time looking for an UNPLUGGED cable. So if you have a network driver try both situations, with the cable being plugged in as the preferred option. The best way would be a clean Windows install. Some software packages are notorious for not quite uninstalling themselves. So, if you have installed anything else and uninstalled it, you have to consider a Windows clean install and clean means ask for the disk to be formatted along the way. A Windows install over an existing copy won't necessarily get rid of the rubbish. The install process might just pick up stuff from the old installation.

(BTW - I used to design real time software)

[irving2008]

(BTW - I used to design real time software)

You and me both :)

Of course there are true real-time extensions for Windows, as well as the embedded Windows with RTX, but the licencing costs of those makes it unlikely to get into hobby-level software. There was an OpenSource RTX sometime back, but it seems to have died off....