PDA

View Full Version : Troubleshooting a CNC noise problem



Evan
02-04-2008, 04:03 PM
I mentioned in the other thread about CNC noise issues that I had a problem with my machine. I decided to follow it up some more before switching the machine to a more powerful one for Mach 3.

I have already determined that the problem is noise from the computer and not related to the controller. The computer began to show signs of excess noise from the on board parallel port after I removed an extra parallel port card. That should have no effect whatsoever yet that is the only event that coincides with the onset of the noise problem. This am I set out to find out some more. Using a digital oscilloscope program I had a look at the onboard parallel port while under the control of Turbo CNC. The o-scope program takes input from the sound system input and can be connected to the outputs on the parallel port to troubleshoot itself in a sort of diagnostic mode. No special hardware is required except a plug for the parallel port and for the sound input, either line or mic.

It is also necessary to have some way of calibrating the o-scope by feeding a known signal into the sound card. I used a simple AC wall wart feeding a 5K potentiometer with the center tap set to provide 150 millivolts to the o-scope input.

Then I ran some easy tests using TCNC in a DOS box to see what happens on the parallel port. The port was not connected to the control, this is a test of the computer only.The results are very enlightening.

This is a full screen shot of the setup. The two traces are the step and dir lines for the x axis, pins 2 and 3. TCNC isn't doing anything in the shot, just sitting idle with no commands sent. The o-scope shows around 21 to 22 millivolts of noise on the quiescent port pins. That is reasonable and won't present a problem. That reading is after starting TCNC but before using it to send motor commands.

http://vts.bc.ca/pics3/scope1a.jpg


However, it all changes for the extreme worse as soon as TCNC has the focus and some jog commands are sent. Jogging the X axis results in a huge amount of noise related to the step and dir signals being output. These next images show only the noise level, not the DC offset of the logic levels. The measured noise is over .5 volts which is far too much for reliable operation. The motherboard shown no signs of failure such as failing bypass capacitors but this amount of noise is an indicator that the computer is going downhill. It won't take much more and the computer will begin to show problems as well.

http://vts.bc.ca/pics3/scope1b.jpg

http://vts.bc.ca/pics3/scope1c.jpg

http://vts.bc.ca/pics3/scope1d.jpg

This noise is most likely due to a combination of factors. The power supply seems weak as the power monitoring chip reports only 4.89 VDC for the 5vdc supply. It's a cheap motherboard with cheap components. Although none of the capacitors show signs of failure that doesn't mean some of them aren't failing. Failures of a number of bypass capacitors or simply not enough of them will result in this sort of issue. It cannot be reasonably fixed and just means that this computer is not a suitable candidate for controlling a CNC machine.

John Stevenson
02-04-2008, 04:13 PM
Evan,
Be interesting to see this same computer running Mach3 if it's a possible candidate as Mach3 has a built in driver test taht should show up some of these faults you have highlighted.

It may not be up to spec to run Mach thought, I can't remember if you posted the specs at anytime ?

[Edit] forgot to add what O-scope program isit you are using ?

Evan
02-04-2008, 04:40 PM
The computer is a 1000 mhz Duron not suitable to run XP so not good enough for Mach 3. That's ok, I have Mach 3 installed on my file server which is an Athlon XP2500 with a gig of ram and 500 gigs on three drives.

The scope program is Rscope. I don't recall where I got it but it is freeware and free to distribute for free. Accordingly I have put it up so you (and everyone else) may download it. It's only about 260KB, no install required. Just unzip and run. Follow the destructions.

http://www3.telus.net/metalshopborealis/RScope101.zip

John Stevenson
02-04-2008, 06:21 PM
Evan,
Thanks for that.
Do you have an old copy of W2K? that should fit onto a 1000mhz machine.

It would be interesting to see if Mach's driver program matched your scope results.

Only time I have seen another diagnosis result other than the driver test.

.

Evan
02-04-2008, 08:40 PM
That's the sort of thing I did for 23 years John. When I started the machines all had cams, relays and switches. When I finished they had a PC running Unix tucked away behind a door in the back.

[edit]

I'm not going to go to the trouble to put another OS on that machine. The noise problem is a hardware problem and it won't matter what software is used. One of the things I had to do first off was disable the onboard USB hubs because they were causing missed steps even in DOS with TCNC.

darryl
02-04-2008, 09:32 PM
A good test in this case would be to swap in another computer power supply. A lot of the switching regulators I've checked out use the 5 volt output to derive the feedback signal for regulation. The caps in the 5 v output work hard, and even though they are the proper types for the job, they do weaken. Once the feedback signal becomes dirty, I would expect that noise would increase, and regulation will suffer.

Evan
02-04-2008, 09:50 PM
I'll be looking at it further when I find some time. The cool thing is that the scope software will run on the machine you are diagnosing. I can also run it on my laptop but not until I build an optoisolated connection for the audio input. Hmm. A simple local oscillator in the optoisolator would allow a much larger range of frequencies to be examined. It would act as a hetrodyne down convertor.

Sparky_NY
02-05-2008, 07:33 AM
Evan,
Thanks for that.
Do you have an old copy of W2K? that should fit onto a 1000mhz machine.

It would be interesting to see if Mach's driver program matched your scope results.

Only time I have seen another diagnosis result other than the driver test.

.

I am using a 1200mhz machine with mach3 and win2k, very pleased with the performance.

Sparky_NY
02-05-2008, 07:48 AM
A couple thoughts... The scope software is cute but hardly a sub for a real scope. Don't you own a real scope? They are cheap now days, I picked up a tek solid state 100mhz for $50 at a local surplus house, that the normal price. With its internal shielding, sheilded probes etc. I would not be at all surprised to see a real oscope show something far different.

Second, a half volt noise on a 5v nominal signal, although not desireable, I wouldn't think would cause problems. Even with the 5v low, say 4.5, the bottom of the noise is still at 4v which I would expect to be well above the 1/0 threshold of the digital chips.

You may well be getting concerned and attempting to fix something that isn't broke. Mach3 may also cure some issues. I finished up my mill setup and the only issue I ran into was noise on the y axis limit switch lines causing a occasional false trip. A .1 on the line at the breakout cured it instantally. The bridgeport 2j is running like a charm under mach at 100ipm using 860oz steppers and 2:1 timing belt drive.

Evan
02-05-2008, 09:46 AM
Don't you own a real scope?

Sure, three of them. It's a lot easier to haul software to the computer in question and it does the job I need done. They also don't have the features that the software scope has.


Second, a half volt noise on a 5v nominal signal, although not desireable, I wouldn't think would cause problems. Even with the 5v low, say 4.5, the bottom of the noise is still at 4v which I would expect to be well above the 1/0 threshold of the digital chips.

That isn't how it works. TTL is a current sinking logic and it is the low levels that matter when it comes to noise. A low is defined as being below around 1.0 volts to 0.7 volts depending on exact chip family. A high is any value over 2.0 volts. The range in between is indeterminate with the resulting output of a gate being unknown. The traces show a P-P value of a bit over 0.5 volts. When a TTL gate is sinking current it will never be able to pull the output down to zero. It is common for it to run around .3 to .5 volts for a low output. Add to that .5 volts of noise and the gate is now in the indeterminate range.

That P-P value is derived from only a few milliseconds of data. If that noise is superposed on the step and dir signals, which it is, then critical timing is disturbed. This is most important when the edge sensitive step signal input is rising from low to high as that is what the Xylotex driver works on. If the Dir signal is changing too then the noise may cause the step signal to precede the dir signal. This will cause a missed step. It's also very likely that the actual peak noise value is much greater than only 0.5 volts.

There is no guarantee in TTL logic that a low will be anything other than than the maximum of 0.7 to 1.0 volts. This is dependent on the chip family and the fanout from any particular gate. The fanout spec is how many gates a particular output can drive and still maintain a valid low output. It is standard practice to mix logic families in a design. There are many variations of the TTL family with varying fanout specs. In some cases one sub family may only be able to drive a single input of another family and the output will be close to the ceiling when it is sinking current from the input it drives.

This applies doubly to the parallel port outputs since they are only specified as TTL signals. The current source capability of a TTL gate is usually much lower than the sink capability since TTL logic is a current sinking logic. The load imposed by an input is further increased by the use of pullup resistors that are normally used to insure that a high will be present when the input is open or tristated.

The drive capability of any particular parallel port on any randomly selected motherboard will depend on the choice of chips used on that board. The parallel port is an ad hoc specification as it was originally used by Centronics as a proprietary printer port. The actual drive capability can and does vary depending on the chipset.

Keep in mind that the signals I captured were with no other load or even cable on the port. Add a cable and a distant load with a lot of capacitance and the signal quality will be worse, guaranteed.

Look at this trace:

http://vts.bc.ca/pics3/scope1d.jpg

The signals are ringing like crazy when there is a level change. If one rings down at the same time the other rings up and both are changing state then the relative timing may be reversed. As the signal goes from low to high the line begins to ring. That produces the effect of the signal going from a determinate state back to an indeterminate state many times as it is crossing the noise margin.

During the transition of a TTL signal the time spent in the indeterminate state is part of the rise/fall time spec of the output. This is added to the rise time of the input which in this case is very long (relatively) since it is at the end of a long cable with a lot of capacitance and the possibility of crosstalk as well. Ringing in particular is very bad since it will cause high frequency harmonics to be radiated to other wires in the cable bundle.

Ringing also will cause a signal that is supposed to have a certain hold time to not meet that spec because it was busy oscillating from indeterminate to low or high during the transition. This will also cause the input it drives to do the same with the actual effect unknown. The state of a gate with the input in the indeterminate range is also indeterminate. During the transition of any logic signal consideration must be given to the propagation delays along the entire chain of gates to the point where the signal is finally used to produce a logic result.

With the ringing that is present on the port outputs with no load it is most likely that this represents fluctuations in the Vcc caused by level changes in the logic that drives the parallel port registers. This, as I said is most likely related to the amount of bypassing on the motherboard as well as a possible weak power supply. Also, the motherboard may just be a crummy design with poor routing of critical signals.

TGTool
02-05-2008, 10:16 AM
Evan,

Thanks, I'm learning a lot. (Long ways to go on electronics).

Jan

MTNGUN
02-05-2008, 11:30 AM
Thanks for the excellent investigation, Evan.

I've had several boxes that just wouldn't run TCNC well. I was able to solve the problem by switching to another box. Now we can see why.