Dead in the water on 7i92 config

I'm in pretty serious need of a working .ini and .hal file for a 4-axis CNC router (2x X-axis steppers), without PID. I'm about at the point of giving up on this product here. I believe it's a good product, I believe people have made it work, but without any publicly available actionable info on making it work, it's just a pretty but useless thing. I hate to admit it but all it's done so far is set me back 3 months.

Someone trying to be helpful provided me with a PID-based config but it's very broken and I really think trying to fix that isn't a worthwhile starting point. I've tried to remove the PID, I've broken it further trying to make it work from the PID version, and I only have finite hours to blow on this.

Has pncconf ever been modded to make configs for the 7i92?

There's no problem loading the bitfile, all that got done in the end.

Does anyone have working files they can provide?

first what have you tried ?
what connections are you using etc , it's not a question of making it work , we know they work .
attach your config as you have it , and also provide a list of connections you need , and if you have them already connected to db25 connector , also it would be helpful to know what bit file you have loaded or configured for .


find attached a very quick config done for 7i90 , their may be typo's or whatever you find ...
xyz with an extra tandem y limits , home ,estop . probe . & spindle
edit as you wish , it is NOT a finished product , so will need stepper scale etc , and tuning to suit your system

It's a Geckodrive G540, has the G540 bitfile.

PID is pretty much a necessity for the Ethernet card to have the best Stepgen performance
why would you remove it?

have you tried using

freeby.mesanet.com/7i92step.zip

as a starting point and then posting what errors you have?

Well, got back to that-

All I've got is that, in jogging the axis manually, nothing happens for a moment, then it moves about 1/2" very slow, stops, moves again... a little bit of lag after I stop pressing before the axis stops, but the display keeps showing the numbers changing. I got no idea.

It's a 200 steps/rot motor, on a 10x microstep G540, and a 2 tpi leadscrew. So 4000 steps/in.
I'm used to using 150 ipm, but that's in IPS, so I just went with 2.

[AXIS_2]

TYPE = LINEAR
MAX_VELOCITY = 2
MAX_ACCELERATION = 1
# Set Stepgen max 20% higher than the axis
STEPGEN_MAX_VEL = 2.5
STEPGEN_MAX_ACC = 1.5

BACKLASH = 0.000

SCALE = 4000

Initially it generated "following error" so I changed the FERROR (which I really don't get):

#FERROR = .0002
#MIN_FERROR = .0001
FERROR = 0.1
MIN_FERROR = 0.05

got a message about "clipping" that I looked up and it said it's usually from SERVO_PERIOD being too low:

# Servo task period, in nanoseconds
#SERVO_PERIOD = 1000000
SERVO_PERIOD = 100000

That made the message go away, but this may not have been the right thing to do. From what I read later, systems rarely need anything but the default 1,000,000 value. It did run- but, that got to what I initially described- all sorts of slow, improper motion. Also it eventually threw "joint following error" yet again.

I think I need to know what this PID is doing here. No reference suggested it would be appropriate for an encoderless stepper system. What's it doing with the ethernet card here?

Can you post your modified hal and ini files here?

My guess is that the PID settings are not right

A servo period of 100000 (10 KHz) simply will not work with hm2_eth
if you did not get a real time error message something basic is very wrong

Clipping probably means the step rate is not achievable with your step timings
( but isnt this a pncconf message? I thought you were using the 7i92step example)

Edit: looks like the hal parser checks that max velocity is achievable with the current step settings

2 IPS and 4000 steps per inch is only 8 KHz which means the step length
and/or step space must have been set way too high for a G540. Also without knowing what the limitation in velocity
is caused by, (and what the limit actually is) jogging behaviour is likely to be strange

Also your acceleration setting is _very_ slow, Typically acceleration is at least 5 times the max velocity
setting (200 ms to full speed)

The servo thread rate has no effect on the maximum step rate

Why PID: All linuxCNC step drive systems use feedback to "servo" the actual hardware step count to the
commanded step count. This allows the system to correct for small time base errors between the hardware and CPU clocks and correct for delays caused by the setup and hold time waits on reversals. This feedback can be built into the driver ( for example using the position mode of the step generator) or can be added externally with a PID component. For the Ethernet configurations, the PID scheme is preferable as its more tunable for resistance to jitter and to compensate for the longer read/write times of the Ethernet hardware.

What's the best way to upload, do I need external hosting?

But it's the same file posted here, except with the changes described. SETUP/HOLD/LEN/SPACE aren't changed:

DIRSETUP = 2000
DIRHOLD = 2000
STEPLEN = 2500
STEPSPACE = 2500

Unchanged PID settings, too. I have no way to do a meaningful adjustment to PID without a guide as to how this works. PID outside of a feedback system is sort of a weird hack.

The forum allows you to upload .txt files, so if you rename a copy of the .hal and .ini files to files with .txt extensions
you can post them directly to the forum. Another option is to zip the .hal and.ini files into one archive and post that to the forum

You should not touch the PID settings (though the important parts are very simple)
( and all Linuxcnc hardware stepgen systems are feedback based )

Is it possible you are trying to run this on a non-real time OS?

what does:

print?

have you run a latency test?

Got no motion initially. Now literally all I've done was adjust SCALE, vel/accel, then the FERROR and try to hack the SERVO_PERIOD.

HAL wasn't touched at all.

Is it possible you are trying to run this on a non-real time OS?

what does:

uname -a


print?

have you run a latency test?