Dead in the water on 7i92 config

Nope, already got that figured out. Had the wrong OS version and it just won't even start.

again

what does:

uname -a

print?

have you run a latency test?

BTW here is a 7I92 running from my laptop:

freeby.mesanet.com/7i92laptop.png

using the 7i92step.zips example hal and ini files

freeby.mesanet.com/7i92step.zip

Note that the following error plot has peak errors less than 2u inch
The fact that you got large following errors suggests a basic problem
like running on non-realtime OS or latency issues with the particular
RTOS you are using

Well I'm working off that exact 7i92.zip file.

I set the SERVO_PERIOD and FERROR back to what they were.

I realized I was confusing the units for acceleration I brought from Mach3 (vel is per min in Mach3 so needs to /60- but I also did accel by /60, which is wrong because it was already in seconds).

It "sorta" moves now. OK, realized something SUPER key:

1. If velocity is high (g1 ... f500), it moves fast and sounds nice and smooth!
2. BUT, if velocity is f50, the axis "sputters"/"stutter". It starts to move at a crawl, slows back down, repeats... irregularly. It does NOT make a grinding sound like a motor stall. It doesn't move as far as it was commanded, but the screen DRO says it did.
3. If you specify f5, the motor NEVER moves at all. But the DRO says it's moving. The motor doesn't make a sound!

Reminders:
The driver setup should be fine. G540 on a 48v 8 amp power supply and it runs fine on Mach3 with the Ethernet Smoothstepper plugged in.

I am very familiar with the grinding sound you get if the motor has a wire loose, or steps are badly mistimed. I don't hear any of that. At f50 it seems to be speeding up and slowing down with some controlled ramping of the steps, which doesn't make any sense since it's just a single move.

Now one thing did just come to mind- the Charge Pump switch is really weird on that G540, probably due to having replaced a drive but even Geckodrive had no explanation. The CP has to be enabled with the ESS under Mach3 or it won't come out of reset (that last part seems impossible, it should just run!)- but under LinuxCNC, that CP switch must be disabled or it won't come out of reset. So I've never seen I'd rather that question not be there, but I don't think it can cause this since it's on all the axes and f500 runs just fine.

It does halfway explain the problems in getting it to move before- it doesn't move right at midrange speeds and won't move at all for slow speeds. So with accel set super-low, short moves never got fast enough to make the axis move, and long moves didn't respond at first because the motion was too slow, then gave that irregular stuttering motion the mid-range speed was doing.

Maybe marginal timing at 3.3V (Its already known that the G540 does not meet its published timing specs at 3.3V )
you might try setting the step pulse width to 5 usec (5000 ns in the file)

Ah I think it IS the 3.3v timing. I bumped it way higher, 4000 setup/hold 6000 len/space and it seems to be working consistently! So weird it worked at higher speeds but not lower.

I have an older rev of the G540. It may not be performing the same as later revs.

This is a problem. I was planning to convert to Leadshine AM882 soon- they have optoisolated inputs, but they have an integral resistor inside- you can add more resistance for 12v or 24v inputs, but the internal resistor won't work with <5v. Says 4-5v Vh and 0-0.5v Vl. Well even though they made both + and - of the opto available, I probably can't tie + to 5v and - to the 3.3v out of the 7i92, because that makes for 1.7v Vl and may register as "high". Need a level shifter or pulldown.

The 7I92 can drive 5V signals in open drain mode:

Tie OPTO + to 5V and OPTO- to 7I92 output

In the HAL file, set the "is_opendrain" and "invert_output" parameters
of the GPIO pins used as step and direction outputs to "true"

can you attach your config folder as an attachment ( right click on the folder name and compress )
ledshine drives work fine with mesa cards , as you say connect the + side to 5v and the neg side to the mesa card pin .

Are you sure? The manual seems to say otherwise, but I'm not 100% clear:

The Xilinx FPGAs used on the 7I92 have programmable I/O levels for interfacing
with different logic families. The 7I92 does not support use of the I/O standards that require
input reference voltages. All standard Mesa configurations use LVTTL levels.
Note that even though the 7I92 can tolerate 5V signal inputs, its outputs will not
swing to 5V. The outputs are push pull CMOS that will drive to the output supply rail of
3.3V. This is sufficient for TTL compatibility but may cause problems with some types of
loads. For example when driving an LED that has its anode connected to 5V, in such
devices as OPTO isolators and I/O module rack SSRs, the 3.3V high level may not
completely turn the LED off. To avoid this problem, either drive loads that are ground
referred, Use 3.3V as the VCC for VCC referred loads, or use open drain mode.

Huh, ok, I may have misread this- the wording is very poor, combined with the 5v tolerance section. Open-collector mode always comes with a voltage limit and I thought that was still a 3.3v limit.

Well, it should be consistent with Xilinx Spartan6, since that's the core. The Spartan6 datasheet says those pins are NOT actually 5v tolerant in OC mode. Absolute max DC voltage is 4.10v. That's looking troublesome, because the 882 datasheet says anything over 0.5v drop is above the guaranteed logic-low range. So if the Spartan6 pin is at 4.1v with a 5v supply, that's 0.9v across the input opto so it MIGHT be interpreted as a logical "1".

Open drain mode supports 5V output swings so there will be 0V across the OPTO LED when in the high state

PCW wrote:

Open drain mode supports 5V output swings so there will be 0V across the OPTO LED when in the high state

?? 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.