sinking INP #7 from a different power source?

[CRM]

I'm working on the last kink of interfacing a Haas 5C indexer to my ALLIN1DC system. I've run into a potential snag. The Haas indexer has a really nice connection cable terminated at the machine/control box end with a 17 pin Amphenol connector, the other end has 4 different Molex connectors (fully potted to prevent coolant ingress to the cable) for servo motor, encoder, home switch & (unused on 5C indexers) brake.
It turns out that the home switch is a NPN type, NO, 3-wire prox switch. The bad part is that, as wired in OEM form, it gets +5vdc from the same pin at the control box/machine end as the +5vdc for the encoder. The signal (load) and 0vdc are on their own pins.

My ALLIN1DC inputs are configured for 24vdc, sinking. Can I sink the +5vdc being supplied from the encoder input into INP7 (my rotary axis "home" signal)? My gut instinct says no. If, by chance I can, would the 0vdc go back to the common of the encoder input? Or where?

If, as I suspect, that cannot be done, I will have to separate the home prox switch power from the encoder power...and the only way I can think to do that is utilize one of the brake pins to carry the power for the prox switch...which ruins the chance to "plug-n-play" any other Haas DC brushed indexer; and will require special instruction if I ever have to send the indexer for service.

How would I correctly wire a NPN prox switch to INP7 (sinking) in that case? Would the +vdc lead go to the "common" terminal for that input group, the 0vdc go to the -vdc of the power supply and the signal (load) wire go to INP7?

[cncsnw]

If you have +24VDC wired to your input bank common, I would call those "sourcing" inputs. The input sources current; the sensor wired to the input sinks current.

If you have 0VDC wired to your input bank common, I would call those "sinking inputs. The switch or sensor sources current; the input terminals sinks it to 0V.

An NPN sensor provides a path to 0V ("ground") when active. That will only work with sourcing inputs, as defined above. As long as the sensor is connected to a 0V supply that is connected to (is the same as) the 0V side of the 24V supply you wired to the PLC input, then it should correctly activate the PLC input. Since your 5VDC encoder supply and your 24VDC inputs supply are probably both coming from PS1 (the RQ-65D supply for the Allin1DC unit), they share the same 0V terminal.

You might reasonably be concerned about feeding +24VDC from the PLC input into a sensor, which might in turn connect it to the +5V line when inactive. In my experience, proximity sensors do not do that. If you wanted an extra measure of protection anyway -- and you can break into that part of the circuit -- you could insert a diode between the +5V source and the +V connection to the proximity sensor.

If the proximity sensor is made to operate on 5VDC, then you should connect only +5VDC to its +V terminal (typically the brown wire).

[CRM]

Thank you, CNCSNW. I do stand corrected. My +24VDC is indeed wired to the input bank common, and I am using the RQ-65D as you said. I really appreciate you helping a machinist with just enough knowledge of electronics to be dangerous get this indexer interfaced.
The prox switch doesn't use the typical Brown, Black & Blue wires I see on all the circuit examples I see. It uses Red, Black & Blue. But by tracing all the pins and referring to the schematic I had uploaded in the other forum post I determined the functions to be Red = +5VDC (same pin as the encoder +5VDC), Black = 0VDC, and Blue = load. (I don't have my notes in front of me, I might have Black and Blue functions mixed up)
So, if I understand correctly what you are telling me, I can bring the Black wire to the 0VDC of the power supply (I have a terminal strip for multiple circuits) and the Blue wire to INP #7, correct? I would be able to cut the Red lead to the prox switch and solder a diode inline, covered in heat shrink, but I am comfortable with omitting this based on your experience.

[CRM]

EDIT:
CNCSNW, I wanted to wait until I could get home to check my manual before I replied. How you identify "sourcing" vs. "sinking" inputs regarding the Allin1 is opposite the way Centroid explains them in Centroid_allin1DC_Install_Manual.pdf rev 8-9-16 in section 5.2, page 35:
* Sourcing Connecting the inputs to power is sourcing. The negative lead of the power supply must be connected to common...(then refers to example in Figure 5.2.3)
* Sinking By connecting the inputs to ground is sinking. The positive lead of the power supply must be connected to common...(same figure referenced)
Hence, my confusion.
I really don't care which nomenclature is right, I just want my wiring to be right. I know I have my power supply +VDC connected to the common for the input bank I will be using for the home signal. I will wire as I already described (I checked my notes, Blue is indeed the signal and Black is 0VDC) Your guidance agrees with with what I read in multiple other texts and videos regarding NPN being correct with how I have my inputs configured, and I can wrap my head around the explanation you gave regarding the power supply having the same common relative to the two different voltage level outputs. It's just that I hesitated because I am NOT confident I fully understand why what I am doing is correct, compounded with a prox switch that decided not to follow common wire color conventions.
I did find a suitable diode and WILL install it for good measure.

UPDATE: The wiring advice worked perfectly! Thank you! I can observe IMP #7 change state on the I/O screen as the spindle passes the home mark on the indexer--big relief to know the hardware is all compatible and working. Now I have some serious motor parameters and tuning to figure out...

[cncsnw]

Regarding "sourcing" and "sinking", it is important to be clear which side of the circuit you are talking about.

Sourcing devices connect to sinking PLC inputs. Sinking devices connect to sourcing PLC inputs. Similarly, if you are using solid-state PLC outputs, then sourcing outputs control sinking devices; and sinking outputs control sourcing devices.

There is a pretty clear description here:
https://cdn.automationdirect.com/static ... source.pdf

Regarding the prox sensor: is there a jam nut on the other end of it, locking it in place? Good to know that you can replace it if needed.

[CRM]

There might be a jam nut behind, but I would have to disassemble the spindle to find out...So that remains a mystery as long as it is working now.
I did see the explanation you linked to from Automation Direct, which helped fuel my confusion because the terminology seemed to conflict with the Centroid manual. And the more I thought about it, the more scrambled it got in my brain.

One thing with the wiring is bugging me though: I was so sure that the motor wiring observed correct polarity thru the cable, disconnect plug, and finally to the terminals on the DC1. While testing the encoder, I had to swap pins for one channel, because according to the ALLIN1 manual, the encoder should count UP when facing (what I interpreted was) the OUTPUT end of the motor being spun CCW. Did I interpret that wrong? Because when I finally hooked motor power to the DC1 and attempted to move under servo power, I got a runaway condition I recognized as the motor turning the opposite direction the control is expecting, resulting in a encoder position error fault. I swapped the motor +VDC and -VDC wires on the servo amp terminals and could now jog the axis (but not getting nearly the movement amount I should for the amount of handwheel input, but that's a different problem...motor config parameters most likely).
Does that mean I was viewing the wrong end of the motor and that I SHOULD NOT have swapped those pins on encoder channel "A"? My OCD prevents me from leaving a red motor lead connected to the minus terminal on the drive, and a black lead connected to the positive terminal, so before I de-solder the splices for both motor power wires and swap them at the connector, I want to know if I fix both problems (and make motor direction agree with encoder count direction) by simply putting the A channel encoder pins back to the positions indicated in the Haas schematic and restoring the correct color coding at the drive output terminals.

I also noted that turning the handwheel clockwise (+), the spindle of the indexer rotates Clockwise when viewed looking at the spindle face (while the motor power leads are swapped). That is correct, right? That would make APPARENT tool motion counterclockwise around the workpiece periphery. If that is INCORRECT, it is fixed by changing axis reversal from "N" to "Y" on the motor parameters screen, correct?

[cncsnw]

If you want to be able to swap the motor power leads back, then you could indeed swap the encoder polarity at the same time.

It does not really matter which motor direction is positive and which is negative. All that matters is that the encoder feedback match the outgoing power: positive output current should cause motor rotation that results in positive-going encoder counts, and vice versa.

Once you have it moving under control, then you can set the "Direction Reversed" setting on the Machine Configuration -> Motor Parameters table so that the rotary table rotates in the desired direction when given a positive-direction movement command.

Once you have it moving under control and in the right direction, you can set the encoder counts/rev and motor revs/unit (it will say revs/inch, but in this case it is really revs/degree) as needed so that the rotary table moves the distance it is told to move.

Once all that is done, you can set the Max Rate on the Machine Configuration -> Jog Parameters table to reflect what the table is capable of (typically somewhere between 3000 and 7000 degrees/minute); and set the Slow Jog and Fast Jog speeds -- also in degrees/minute -- to suit your personal preferences.

Then you can look at Machine Parameter 41 and decide how much you want the rotary table to move when you crank the MPG handwheel on its various increments.