optical limit switch

[Paul567]

Has anybody successfully integrated an optical switch as a home limit and been able to use the Find Reference vi to Find Home 100% of the time?

We have integrated an optical switch and are noticing that 3% (aka not good enough) of the time the motor keeps moving (at its decreased velocity) after it reaches home.

We have configured the find reference home routine (in MAX) to have an REVERSE initial search direction, a REVERSE approach direction and to stop at the FORWARD edge. When this works, it works. When it doesn't work, it keeps going in the FORWARD direction.

We have tried changing the find reference home routine to use REVERSE initial search direction, FORWARD approach direction and to stop on the FORWARD edge and notice that when it messes up it keeps going in the REVERSE direction.

Does anyone have any ideas?

[Jochen]

Paul,

could you please provide some more information?

1. What type of motion control board are you using?
2. Are you using a UMI for signal connection? Which one?
3. Could you please provide a data sheet of your optical switch?
4. Is there a correlation between failure probabilty and search velocity? Does it work more reliably if you reduce the speed?

Thanks,

Jochen

[Paul567]

It is a PCI-7334 Motion Controller, we integrate it with a UMI-7764, the optical switch is an EE-SX771 (http://www.ia.omron.com/data_pdf/data_sheet/ee-sx77_87_dsheet_csm484.pdf) and it is set to trigger active low.

I've tested the switch in MAX, the switch does get triggered correctly.

I haven't tried lowering the speed with this switch and I wont be able to until tomorrow. Just to make note though, I believe the switch does get triggered, it's just the homing process to detect the correct edge is messing up. When it keeps on going it does so at a slower speed as it would if it were trying to locate the edge.

I was playing around with it a little more and couldn't reproduce the problem after 110 find references. This was under the configuration of Reverse Initial Search, Forward Approch Direction, Forward Edge and with a -5 Step Offset. The last time I tried to test our system I didn't apply any offset and got an error once out of every 30 or so times.

While it's great that I didn't reproduce the problem I still don't know why the offset helped or even if it did or not (I might have just gotten lucky).

Thanks for your response Jochen.

[Jochen]

Paul,

thank you for the additional information. Maybe the source of your problem is the impedance of your optical sensor. There is a chance, that your optical switch doesn't pull down the voltage of the switchinput to a level that is low enough to be reliably detected as LOW (please refer to this thread for further information). If there is additionally some amount of noise on the signal lines of your sensor, you might see the described behavior.

Switching to a slower velocity is an expected part of the find reference move sequence, but if you can't detect the switch signal reliably, unexpected behavior may occurr. With 'reliable detection' I'm not only referring to static detection (which, according to your statements, is working) but also to dynamic effects during the state transitions, e. g. noisy signals around the switching threshold.

Jochen

[Buechsenschuetz]

I do not think that the output impedance of the sensor is the culprit. The data sheet mentions a low voltage output level of max. 0.4V, this should drive the input of the NI controller to a logical LOW state. Anyhow we usually use additional Schmitt trigger circuitry (such as 74LS14 inverters or 74LS245 buffers) for better noise rejection. In any case, proper grounding is always essential, the GND of the sensor output should be connected as directly as possible to the GND pin(s) of the motion controller. 

[Buechsenschuetz]

PS. My answer refers to the NPN output version of the sensor which should be chosen for applications with TTL compatible inputs. PNP outputs are rather used to in SPS/PLC environments.

[Paul567]

Thanks for all the feedback.

The switch is an NPN type switch.

Buechsenshuetz: I've noticed on another post (http://forums.ni.com/ni/board/message?board.id=240&requireLogin=False&thread.id=2524), you mention that the +5Vdc of the 7344 is not designed to be a power supply. Does that mean that by connecting the voltage supply of my switch to the +5Vdc output on my UMI is an incorrect thing to do?

Hopefully later today I will be putting a scope on the output of the optical switch and see just how noisy it is.

Message Edited by Paul567 on 08-06-2009 09:18 AM

[Buechsenschuetz]

The +5VDC terminal of the UMI box (or the NI controllers) should not be used to supply external circuitry (since the current supplied is not very high) but the few mA consumed by a limit switch should not cause any problems. The GND terminal of your limit switch should be connected to GND of the NI controller for a proper supply voltage return path. 

[Jochen]

Just a brief comment:

Buechsenschuetz is right, that the +5 V DC of the 7344 shouldn't be used as a power supply for external devices. The main purpose of this output is to be able to monitor if the PC is turned on or off. In contrast the + 5 V DC output for each individual axis on the UMI is connected to the power supply of the UMI, which is independent from the 7344. So these outputs are definitely designed to power encoders and other external devices.

Jochen