Problem with 'Find Center'

[3e8tech]

Hi all,

I have an intermittent problem that I am trying to address with Find Reference-Center on a 10 inch motion control linear stepper axis with endpoint limit switches (no feedback).  For most of the axes I have worked with, find center executes without incident 100% of the time.  For some reason, with the axis in question, the find center operation terminates abnormally with the axis at either one endpoint or the other (but not at center).

I added wait reference, and even did a read reference status to try to ensure proper completion of the operation, but to no avail, the axis still sometimes terminates abnormally with reference status indicating 'center found'.

My guess is that since both limit switches share a ground, that there is some signaling glitch making both limit switches appear to transition when at only one endpoint, with center being right there at the endpoint, but I don't have good scope equipment to verify.

I'm wondering if there is a way to verify the distance between endpoints and the absolute position of the axis relative to the endpoints.  This way I can ensure that they are in an appropriate range.

Also, any other good ideas as to what might cause (and fix) such an issue?

Thanks,

-James

[The_Chancenator]

Hi,

Could you please provide some more information about the software and hardware that you are using?

Thanks, 

[3e8tech]

Environment: LV 8.2 & Motion

Controller: PCI-7350

Current Drive: 7602/7604

Update to problem:

I was able to make the system find the center consistenly by doing the following:

Inserting the 'find center' call into a loop where only an error or a 'reference found=true' polling will exit the loop.  In other words, the software will redo the 'find center' unless it completes the find reference operation.  At first, when I did this, whenever the axis would stop at the first limit switch, reference found would be false and so the loop would call 'find center' again.  But, if it stalled on the second limit switch, the reference found would be true even though the stage would not be at the center.  This is where the problem lies because my software thinks the axis is at center, but it is in fact at the second limit switch=> not cool!

THEN, I discovered that if I slowed the Axis down to 1/2 speed, then when it stopped on the second limit switch, reference found would be false, and so my loop would intitiate another 'find center' operation.  So, even though the user has to wait through a second find center operation, at least when it exits the loop, the axis is AT CENTER.

So now, whenever find center does not execute properly, my program does it again until it does function properly.  And this fix is acceptable for my program.  However, I know that it could be even better in that the find center operation could just work properly every single time.  I tried slowing the axis WAY down, but I still get occasional failures of find center.  What could cause (and possibly fix) something like this?

[The_Chancenator]

Hi,

Have you tried using a "check reference" in your sequence?  This VI is meant to check the status of a search sequence and respond with a "Finding Reference" and "Found Reference".  Also, I would try using a Read Reference to read both the forward and reverse limits, and then starting the home search.  If you do this, what kind of behavior do you see?  

If this does not help, then how fast are you moving?  And, do you see the same behavior in Measurement & Automation Explorer?

Please post back if you need more assistance and I'll be happy to help you out. 

[3e8tech]

Yes, Marti, I did ultimately find "check reference", and it did help fix the problem when the motion axis hit the first limit switch.  But now it sometimes gets stuck on the second switch, and "check referece" returns the appropriate boolean indicating reference has been properly found.  I tweaked the speed to minimize occurrences of this problem (1 in 5 times or so), and gave my end user a button to perform the find reference again should the need arise.  But this is really embarrassing, cause my client is paying for this work.  This is really not acceptable.

So I had other problems to iron out, but I am now training my end user on my software.  The software is great.  Nice and professional, EXCEPT for this issue.  End user found it right away!  So I had to solve it quick.

I had more time to think about it since then, and had also found some passive scope probes in the area that would fit an HP Infinium scope that was laying around.  I hooked the probes to both the forward and return limit switches at the NI MID7604/7602 and grounded them there as well.  Then I watched what was going on while I performed the find center operation.

The first thing I noticed was that there was about 5 V of noise on these digital limit switch signal lines!  Clearly the controller is getting false edges back from all this noise!  The spikes ran from 0 to 5 volts, just like the signal does.  The signal is logic low, so it sits at 5 V mostly, and you can see two dips, one when the stage hits the first limit switch, and a second when it finds it the second time. 

The second thing I noticed was that the system did not get stuck at the limit switches when the probes were attached.  Hmmmm...  That REALLY is interesting. 

So I grabbed some capacitors to lowpass filter the return limit switch lines as they enter the NI MID 7604/7602.  I set the 3dB point for less than 1 MHz, and was sure the put these on each line. 

Whaddya know!  Problem solved!

So what causes the noise?  Well, this is the third thing that I noticed.  The cable attached from the 7604/7602 to the stepper motor is an NI cable.  I don't have the part number in front of me, but the lines are unshielded, and I think it may be a DB-9 on the motor end (again not sure cause I'm at home now).  The length is 1 - 2 meters, and the noise is coupling from the motor lines.  I have the 7604/7602 configured for 1 amp max via dip switches, and I need this due to torque problems I used to have (no longer though).   So even when the moror is still, there are still signals going to it.  I guess these hold the motor in place.  You can see the noise change depending on what motor is doing at the time.  I watched the scope and how the noise changes during a find center operation, and it was just very clear that this was coupling from the motor pins to the limit switch lines.  Now I only have 1 ground, and it goes to both limit switches, but as I understand things this is an accepted NI configuration, yes?

Maybe you have a shielded cable for this?  If not, I can try to find you part numbers if you wanna reproduce this at NI.  Having worked at NI myself a few years ago, I know the management there appreciates finding bugs/problems, especially when it can be remedied for current products, and maybe offer new features on future products (software selectable digital input filtering on motion control products?/a new cable option if it does not exist already?)

Anyhow, thanks for helping me and offering suggestions. 

-James

[The_Chancenator]

Hi James,

I'm glad that you were able to track this down.  Your hardware configuration and groundings sound correct. 

If you give me the cable number we can hunt down a shielded type cable for you. 

[Buechsenschuetz]

Of course a stepper motor needs some current even if it is not moving, since stepper motors are not latching in position by themselves. Also, the outputs of most motor drivers are pulse-width modulated, i.e. there is no permanent DC current but the current is divided into small portions on the time axis. (The current is controlled by making these pulses wider or smaller, the inertia of the motor integrates the pulses into a DC signal.) These pulses can generate a lot of noise in the environment. You should always use separate cables for motor current and feedback signals. At least the motor current cable shoud be shielded. You usually can use the same GND line for all position switches but you should avoid multiple earth connections. -  We have one system where we have to use the same cable for motor current and feedback signals. We have RC filters on the position switch inputs on our control system (not a NI system in this case). During prototyping, we had problems with erratic signals on the position switch lines - I had used a wrong capacitor which looked identical. You can use rather big C values on the inputs since usually detecting the position switches does not need to be very fast, we are using a combo of 120 ohms and 100NF. 

[3e8tech]

You know, this is absolutely the right response.  DIdn't even realize this one cause I'm new to the stepper motor world, and motion altogether.  The motor signals need to be separated from those digital signals.  Of course!

Let me explain how I managed to get them all in one cable:  You see, I am working with a five axis system used to position a device under test.  This one has two cables per axis, and the signals are split as you suggest.  My requirements specify multiple measurement genres, so I kept having to switch in new equipment for measuring.  Each time I switch equipment, I have to go through about a half-hour alignment process.  What a pain!

So I noticed that I had three axis drivers left (5/8 were used) and I found two 10 inch linear motion control stages, although they had no wires attached.  So I personally cooked up a couple of cables out of an NI 9-pin cablle.  I did not realize that the stepper wires needed to be separated from the sensor wires.  So I didn't do this. 

Well, these two new axes worked OK, and did do a nice job of automatically moving the equipment around, but they didn't zero very well, and you know the rest of the story.

So it sounds like the easiest fix is to simply rewire the cables.  I'll try this tomorrow.  Thanks a million!!!

-James

[Buechsenschuetz]

To reduce EMI from the motor cable(s) you should consider using ferrit cores around the cables. When we took our system to an EMI lab we found that there was a lot of EMI generated by the motor cable (close to the limit). First we placed a ferrite core near the output of the driver, since we thought that the noise was generated by the driver circuit. Almost no changes. But EMI decreased drastically when we placed the core near the motor, probably it was rather generated by the back EMF of the motor. - This might not apply in each and every case but sometimes ferrite cores are great to reduce EMI, especially when using shielded cables where the shield might carry some signal and/or drive current (which of course should be avoided by design but sometimes it happens anyway). Only way to reduce EMI coming from a shield is using ferrite cores.