Dead in the water on 7i92 config

Well, here's where I'm at. X, Y, Z move OK. But I'm having trouble with trivkins linking the A-axis to the X for the gantry. My spindle is a modbus VFD so I don't plan to use PWM or a PID so I commented that out. The .hal file reuses AXIS_0 parameters instead of AXIS_3 because they need to be the identical anyways.

I could select X, Y, Z and Home them to zero where they're at, then MDI around (except the gantry will rack in a couple of inches because only one X motor is working).

Now that I've added A (the second X), selecting A and hitting "Home Axis" doesn't make it zero in place. It starts driving slowly in the + direction, without moving the other motor, and it tries to run forever without any additional user input. So I had to stop it, and it's not Homed, so I can't run MDI commands.

I don't quite get it. The other joints home in place (zero). There's nothing specified to make the A-axis work differently.

The magic of N channel MOSFETs in Common Gate mode

Even though you can drive 5V signals from the 7I92, If you are making a motherboard that
drives external step/dir motor drives, I would buffer the FPGA pins and use differential
step/dir signalling

Well actually I guess I should move to gantrykins- but really I'm not even using trivkins yet. The "A" is just an arbitrary label, right? It doesn't affect functionality. I called it that because that's the G540 channel label.

I figured I needed to verify that it operates like a normal channel before bringing in gantrykins. If the channel's not working right it'll just be too confusing to fix from that context.

Nothing declared it as a rotary axis. In fact it's a literal cut-and-paste of the AXIS_0 config, with the relevant numbers changed to "3". So why would it being Homed in Joint mode make it take off in one direction, unlike the other 3 axes? I can't proceed pairing this with gantrykins until this axis acts like X1 axis.

PCW wrote:

?? how?? The FPGA doesn't and AFAIK there's no external buffering. Kinda important, I need to design the motherboard for all this soon and I need to know if I need to use level shifters.

The magic of N channel MOSFETs in Common Gate mode

Even though you can drive 5V signals from the 7I92, If you are making a motherboard that
drives external step/dir motor drives, I would buffer the FPGA pins and use differential
step/dir signalling

But they don't. Gates in Open Collector (Drain) Mode have 2 limitations- one, the output MOSFET's Vds-max must be observed- you can't use a pullup resistor to 12v, for example, because the drain can't possibly go that high. Second, most parts protect their pins with shunt diodes that forward-bias when the voltage on the pin is greater than Vdd, by like 0.5v or 0.7v. If you exceed that current, you end up sinking current from the pin into Vdd (not GND). Basic ESD protection. So for a 3.3v part, the pin voltage may be limited to 3.8v or 3.9v. More and it sinks current from the pin, even while high. That would still be a problem for optos.

There are some parts with special pins without those shunt diodes- thing is, I don't think the Spartan6 datasheet is saying they removed the shunt diodes.

I guess I should just do level shifters by default. They're not expensive parts, just extra routing and I need to be sure I get the connector pinout right since it's not just a matter of connecting a wire differently, the board's gonna commit the hardware pin to being an output.

Can't use differential signaling. It's illegal to reverse-bias the AM882's input opto, LEDs aren't specified for a lot of reverse-bias tolerance and it's not a well-controlled parameter. Mfgs generally say "just don't".

I dont think you understand the functioning of the bus switches

PCW wrote:

I dont think you understand the functioning of the bus switches

EE here with a whole lot of board-level expertise, including the painful details of how microcontroller pads work. I do. Is there an external bus switch on the board? I don't have the 7i92 with me to check.

7i92 spec is oddly worded, which is why I'd fall back to the Spartan6 spec for how to operate those pins. From that, it's telling me it is NOT safely within spec to operate the AM882's optos as OCM from 5v. They are not guaranteed to turn off. There's a remote chance that it could induce shunt current into Vdd that could be a very serious problem for the Spartan6- not likely, though, but it's looking unsafe.

From the manual:

5V I/O TOLERANCE
The FPGA used on the 7I92 has a 4V absolute maximum input voltage
specification. To allow interfacing with 5V inputs, the 7I92 has bus switches on all I/O pins.
The bus switches work by turning off when the input voltage exceeds a preset threshold.
The 5V I/O tolerance option is the default and should normally be left enabled.

PCW wrote:

From the manual:

5V I/O TOLERANCE
The FPGA used on the 7I92 has a 4V absolute maximum input voltage
specification. To allow interfacing with 5V inputs, the 7I92 has bus switches on all I/O pins.
The bus switches work by turning off when the input voltage exceeds a preset threshold.
The 5V I/O tolerance option is the default and should normally be left enabled.

After analysis of their circuit-

NO. There is no 5v tolerance here, either input OR output, and cannot operate 5v optos in Open Collector Mode. Their board designer made some serious mistakes.

That is NOT a level shifter required for adding 5v tolerance. It is not even a buffer. It is a Pericom 16211AE bus switch. A bus switch is nothing more than a direct electrical connection between the Spartan6 pin and the output. It doesn't buffer or regulate the voltage, it's literally a make/break connection (like a relay) for an entire bus- there's not a defined input/output, just an A and B terminal they tie together. It's got a Output Enable which connects/disconnects all 12 lower bits at once and another OE to disable the upper 12 bits (within one chip, there's two of them). None of that has anything to do with 5v tolerance.

Manual: The bus switches work by turning off when the input voltage exceeds a preset threshold.

There's no way it can do that. It can't detect when a pin exceeds a threshold- and if it did, all it could do is disconnect all 12 IO pins together, rendering the whole port inoperative for input or output.

And I'm looking at the board under a microscope right now. The bus switch just has the capacity to disconnect a bus 12x wires at a time- they don't have the capacity to switch between anything, only disconnect, and could only disconnect a 12-pin bus all together. It can't be "turning off when the input voltage exceeds a preset threshold". That would make the whole board inoperative!

It does add 5 ohms of resistance per ch which is a minor problem for high-speed switching. But there's no way remove that, that's the lowest resistance WITH the OE enabled.

I don't know what it was meant to do. Now it does provide a CLAMP. The 16211AE has shunt protection diodes which will conduct voltages on either the A or B terminal which are significantly above the part's Vcc into Vcc. Which does nothing to resolve the opto problem. Also that shunting doesn't turn on and off with Output Enable. The 5v/3.3v compatibility switch looks like it just switches the OE pin- but that would just disable the whole bus. I don't get it. And it looks like the OE pins are permanently tied to "enable".

If you put the Spartan6 pin on OC mode, it'll just connect to the output pin, and the Spartan6 pin still can't tolerate more than 4v which is a bit out of spec for driving an opto. Adding a switch that will always stay on with a ~5.5v clamp on the IO pin won't change that.

The only thing I could think of is they're switching Vcc from 3.3v to 5v to change the clamping point. But they're wrong if they think that makes it 5v capable. It doesn't change anything on input or output in a functional way.