Dead in the water on 7i92 config

A while back I was wondering how this 5V tolerance worked and I found this Application-Note:
www.pericom.com/assets/App-Note-Files/AN001.pdf

See the section:
Conversion Between 5V and 3V Logic

When 5V and 3V logic devices need to communicate with each other, since many of the 3V ICs are not 5V Tolerant, there is a need to provide level shift/translation functions. Pericom's bus switches are widely used to provide these functions.

andypugh wrote:

I think you are over-thinking this.

Thousands of Mesa cards are running in 5V logic systems. Including three of mine.

Before things get any more heated, someone should perhaps mention that PCW is the Mesa board designer.

Ah I did not know that... I would have edited myself a bit for that. But I'm not sure what changes. I do think it's a great product, but it doesn't have a 5v compatibility that meets spec, even as an OC it can't ever meet spec.

Not meeting spec doesn't mean the system's guaranteed to fail, but that it's not guaranteed to work. Even if we put the pins into OC mode on the 882's 5v opto inputs, it's not a 5v OC system and isn't guaranteed to work under all conditions of speed/temp/etc. In fact it looks like it's risking exposing the Spartan6 pin to an out-of-spec voltage. A bus switch was confused with a level shifter.

Not that this is the end of the world, it's a nice part- exceptional, in fact. But this one thing is a glaring error, and anyone designing a system around it should know that. A 3.3v to 5v level shifter is less than $0.10/channel.

Yes it does meet spec, please read the Pericom application note carefully (or the TI, NXP or Analog Devices equivalents )

BTW most bidirectional level translators _ARE_ bus switches they are just named differently

Well, back to the current matter at hand- any idea why the axis A is behaving this way? When I'm in Joint mode and Home it, it doesn't zero there. It takes the axis off blindly in one direction (probably not a 7i92-specific issue). But that's still declared LINEAR and no special homing instructions. It's copied verbatim from the sections for the X axis in .hal and .ini and only the relevant numbers were changed from 0 to 3 to make it the 4th axis. I made sure I didn't change the numbers which are fixed at 0 regardless of which axis it is.

andypugh wrote:

dannym wrote:

Well, back to the current matter at hand- any idea why the axis A is behaving this way? When I'm in Joint mode and Home it, it doesn't zero there. It takes the axis off blindly in one direction .

If the motor points in a different direction to its partner then _something_ needs to be different to make it run in the opposite direction.

I would expect the [AXIS_3]SCALE to be the same as [AXIS_0]SCALE but negative.

The directions of all those motors is arbitrary- the motor phases were done with the same-color wire and I just made sure no wiring crossed from one phase to another, but I didn't enforce a consistency of phase A1/2 vs B1/2 being the same across motors. So direction is arbitrary. Actually IIRC all 3 of the motors came up unfortunate and had to be inverted. For that, I used "invert output" on the DIR pin, that's ok right? I didn't know about setting SCALE negative. As it stands, the A axis is one which is NOT inverted.


It's not that it's in the wrong direction at all. It's that the other joints just zero in place when I hit Home, but this one just starts jogging off in one direction blindly and I can't stop it, I have to toggle the e-stop. It's not homed after that either, nothing can home it, so I can't move it with MDI.

If I was actually using gantrykins or trivkins, that would obviously be where the problem it coming from. But it's not, that isn't tied in yet.

andypugh wrote:

Is it part of the homing sequence?
Does it have homing switches?
Which stepgen is it connected to?
Which axis is the stepgen connected to?

(edit: I know you posted a config earlier, but I can't open RAR files here)

.hal and .ini files were already uploaded in an earlier post.

No homing sequence yet, nor homing sequence. Its own stepgen.

andypugh wrote:

Actually, it turns out that 7-zip will open rar files if you ask nicely.

The problem is that you have configured for an A-axis. ie, everything is set up to move the 4th motor in response the G-code "A" word.

If your A axis is a 4th Axis then this is correct. (probably).

However, if I have kept my threads straight (something I struggle with, trying to support several forum questions at a time) then this is a gantry machine with only XYZ axes.

There are probably two things wrong:

1) in this HAL code

# position command and feedback
net emcmot.03.pos-cmd axis.3.motor-pos-cmd => pid.3.command
net emcmot.03.vel-cmd axis.3.joint-vel-cmd => pid.3.command-deriv
net motor.03.pos-fb <= hm2_[HOSTMOT2](BOARD).0.stepgen.03.position-fb axis.3.motor-pos-fb pid.3.feedback
net motor.03.command pid.3.output hm2_[HOSTMOT2](BOARD).0.stepgen.03.velocity-cmd

all references to axis.3..... need to be axis.0.... so that the 4th motor moves in response to the X-comands from G-code.
However axis.0.motor-pos-fb is already connected in the X-axis section, so just delete that from this section.

2) It is possible that the PID control setup for the 4th axis is wrong, though as the PID has no way to tell which way a motor is actually turning this is less likely than I thought it was when I started typing this sentence.

1. Hardcoding axis 3 to be equal to 0 wouldn't make sense, then the gantry racking can't ever be calibrated. That's my understanding. So I was planning to use gantrykins, ultimately. Having the axis work in joint mode would be a precursor to that- even if the 4th axis made it lock-step to X, I don't see what use that is, it's not going to ever be run like that.

2. Yeah it's clearly got its own PID coded there- if it didn't, the axis wouldn't run. It'd throw "following error" immediately.

Could the "A" label be screwing it up? I used that for now because the G540 used the "A" label. It's listed as "TYPE = LINEAR" in the .ini file so I was under the impression that it'll be treated as a "normal" axis. And it's my understanding that in Joint mode, an axis's relation to the overall geometry isn't relevant, it's just a scalar position.