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

[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....

[Robin Hewitt]

My stepper driver runs under DOS

Ancient history maybe, but I have the computer's undivided attention and all it takes is one setvect(0x1c,service); for the timer interrupt to become mine, real time, glitch free.

The only real escape for Windows is to add a slave processor on the end of a cable. The slave can then do all the timing while Windows makes it pretty.

[routercnc]

Thanks for all these suggestions and explanations. AVG is out of there! If this does not work then I had made my mind up last night that it was time for a fresh install. That machine actually has 2 hard drives (the other one is not used but contains the old system that got too clogged up) so I am going to reformat the other one, re-install windows, any vital drivers, then mach3.

Wife is asking when she can have things engraved again, so no pressure then!

By the way, if I were to create an 8KHz square wave (of about 3-5v) and inject it into the system3 parallel port pin 3 and earth, would the stepper rotate or does it need all the other pins to be present (board has a charge pump override)? I have access to lots of signal processing kit at work and could easily do this, or even borrow a signal generator to do it live.

Thanks
Barry

[irving2008]

yes it would, in fact thats exactly how I test my drivers. You may have to patch the enable lines and disable the charge pump but these should be jumpers you can move on the system 3 board, or make a 25way test adaptor from a 25pin male connector and some hookup wire.

[routercnc]

I re-formatted a spare harddisc, installed windows xp, and then added mach3. Same problem with glitches. I'm now open to try anything, so . . .

I downloaded ubuntu-8.04-desktop-emc2-aj13-i386.iso onto another machine, then burnt it onto a disc. However, when I put this disc into the cnc PC with the reformatted harddisc (setting it to boot to CD in BIOS) I get 'Boot from CD :' then 'disc boot failure, insert system disc and press enter'. It does not recognise this as a boot disc. Not being familiar with linux install I don't know how to proceed from here. Any offers?