Dead in the water on 7i92 config

Since we're no longer talking about simple configs anymore. Here is how I would handle setting up a double joint driven gantry.
I would hard code both joints to the X-axis as is suggested above, with the addtion of an offset for the slaved side. Home to the limit-switch on the master side, then prob a second switch on the slaved side to calculate the offset for squaring the gantry. Then plug that into the offset component (probably run it through a limit2 as well to prevent following errors)

Well, I figured out the FIRST problem there- somehow the Homing section got uncommented for the A-axis. No idea how that happened, I copied it from the X-axis where it was all commented out.

OK, so I brought in gantrykins as planned and MDI commands DO work. However, when switching from Joint Mode to World Mode, I immediately get errors (I think it was Following Error but I was pretty tired at the time) and none of the axes can be jogged.

andypugh wrote:

I would be tempted to reconfigure in "normal stepper" mode first, ie temporarily remove the PID stuff.
I appreciate that it gives a better result, but it also adds extra scope for error and confusion.
Make a copy of the HAL file. The INI file won't have to change at all.

Then, when you get it working, combine the HAL files into a PID-stepper one.

Tried that on an earlier effort- extracting all that PID stuff (which I am far from fully understanding) just broke things. Even if I got it moving, all additional problems would pretty likely be "well, it might be an actual problem but probably due to the PID being incompletely ripped out and not properly replaced... better bring back the PID instead of messing with it all day trying to figure out what happened". Basically it'll actually add more complexity and questions, even if it ran.

Ah found the problem- it's under the [TRAJ] section, the DEFAULT_ACCELERATION and other items aren't filled in. Apparently this breaks the system (following error)- but ONLY when gantrykins is brought in and you try to jog in World mode.

I have an VFD programmed by RS485, currently running through an RS232-RS485 converter off the PC's serial port. But I'd like very much to simplify the cabling and have the data source off the 7i92's RS422 and convert it to RS485 all inside the control box.

Is that possible? What would it take to get a bitfile which supports that? Would it manifest as another serial port under Linux?

The hostmot2 firmware set has a couple of UART modules,
and we do plan to add modbus support eventually to simplify wiring
and avoid awkward things like USB---> RS-485 adapters
but it will take a while

Well is there any way to make it act like a com port right now?

Well darn it I had the axes moving ok on the G540, then made a breakout for connecting one of the AM882 drives' step/dir to test, set the port's jumper to turn some gnd pins to +V power for the optos, and just got "following error" on all axes. I didn't change anything in .hal or .ini. I can't make any sense of this, it's a stepper drive and there's no feedback signal that it uses. LinuxCNC would be able to "move" the axes around without any drives attached.

I pulled the port power jumper and put it back on the G540 and now get "following error" on that drive too. I'm questioning real hard what changes I might have made to the .hal/.ini but I just didn't.

I am super-frustrated that LinuxCNC just keeps coming down to this nondescript "following error" and no further reporting. It's apparent that any of 100 problems could cause this but there's no clue to work from. Any ideas?

Its most likely that you did change something in the hal or ini files or something else.

There's really nothing that you can change in the external hardware that will cause a
following error and no other errors

If you widen the following error limits and plot the following error, you can see whats going on
and this may provide a clue as to what has changed

Posting your hal and ini files here may also help to diagnose the problem