Can't configure Mesa 7i92

I did exactly as stated on the GitHub site:

In the source directory, install dependency and build:

sudo apt-get install libpci-dev
make

Would that still be a problem?

OK, I did that and Mesaflash works, ip=10.10.10.10!

Now when running with that 7i92.hal, I get:

./hm2-pidstepper.hal:42: Can't find module 'hm2_eth' in /usr/realtime-3.4-9-rtai-686-pae/modules/linuxcnc
5124

I added "loadrt hm2_eth board_ip=10.10.10.10", no difference.

Are you running uspace realtime? For ethernet connected devices you need to run the rt_preempt realtime kernel and uspace (not rtai).

linuxcnc.org/docs/devel/html/getting-sta..._installing_linuxcnc

sam

OK, I thought that was the basic problem, those instructions solved that.

Now I'm trying to figure out the HAL file. So I tried that "7i92step.zip" file and LinuxCNC DOES start without error, however, jogging the axes has no effect.

I tried adding "loadrt hm2_eth board_ip=10.10.10.10" but it just generated an error about duplicate things, so I figured it's already communicating and doesn't need that line. I did try launching LinuxCNC without the 7i92 powered up and got an error so I know LinuxCNC is finding it when it boots without an error when the 7i92 DOES have power.

What's the "pidstepper.hal" part? Is the PID for the spindle? i don't know how you'd have a PID on a stepper. I have a Hitachi X200 VFD and it'll need to control the spindle via Modbus, but that's later, and won't involve the 7i92.

Alright, it may be because I'm on the dual inline receptacle, not the DB25. So I went to reconfigure it- I looked through the .ini file, .hal file, .bitfile and I don't see where pins are associated with axes anywhere. What gives??

Is there a guide to building these HAL configs on the 7i92? I clearly don't know the first thing.

You need to use the DB25 connector for that example file since it has the proper stepgens ( 0 though 3 ) connected
The proper cable is the same male-male DB25 cable that you would use to connect a G540 to a parallel port


PID is used as part of the stepgen velocity control loop in the sample config.


The G540 config has a fifth stepgen on the DB25 (stepgen 4). This is intended for use as a charge
pump signal generator. There is a G540 thread in the forum that discusses how this chargepump
is setup in the hal file.


The linuxcnc hal manual gives the basic information on hal file syntax. If you need to know pin
or parameter names, launching the sample config and then in a terminal window, typing:

halcmd show pin
or
halcmd show param

will list all the pins and parameters respectively

Since the pin/parameter lists may be pretty large, redirecting the output to a file may be more useful:

halcmd show pin > pins.txt
or
halcmd show param > params.txt

Now these files can be use as copy/paste donor files when editing your hal/ini files
so you don't have to guess at exact pin/parameter names.

OK, how do I set it up to use the dual inline receptacle? I can make up a temp parallel cable on the DB25 but for space reasons it'll need to be the dual inline.

Is the "PID" nature of this file going to be a problem? I don't have any feedback, and I don't quite understand how a stepper can even be a PID.

Yeah the charge pump signal problem showed up. I really question the reasoning behind the charge pump- it's not really a good idea because my Z-axis will drop if the drives are shut down. The idea that the controller would go crazy and generate Steps... but NOT generate the Charge Pump due to error... doesn't seem plausible. I mean I DID have a problem on Mach3 where if you hit an arrow and shift in the wrong sequence, it will go crazy and drive the axis into crazytown- but it's still driving out the Charge Pump. Most coding errors which would generate wild stepping commands would likely still generate the Charge Pump.

The reason for the chargepump is that the spindle and machine power are guaranteed
to be off at startup or if the control program or CPU has problems. It is somewhat redundant
but not entirely, I have seen step drives go "wild" when PC/breakout power is removed and the
step output voltage drops close to the input threshold of the drive. At this point the chopping noise
from the drive can couple enough energy into the input to cause a substantial motion.

If the Z axis falls when you have the step drivers powered down,
this is rather an accident waiting to happen. Normally a Z axis brake is
used in this case

The PID is part of the stepgeneration logic, its not really something you need to be concerned about
unless you want to understand how it all works

Probably what you want is a g540r config ( r means reversed ) I have this for a lot of other configs but not the G540
I can make one up sometime next week

OK, made a cable and got some results, but three problems:

1. The axes only move one direction. All 3 will move one direction but do nothing for the other direction. Now if the DIR pin wasn't connected properly, it would move left if you pressed the left or right arrow. But it's moving left for the right arrow and no motion at all for the left arrow, so it's not simply a malfunction on the DIR pin. So confused on this point, because the STEP command should pulse for both left and right arrows.

2. The directions are reversed. Can I fix that in software? Resoldering cables would be very problematic at this point. I just need to selectively change DIR to active-low.

3. The gantry needs second stepper- the 4th axis side- to be driven along with the X. And it really needs to be driven slave but with homing alignment like in Mach3. Google is telling me LinuxCNC has historically had problems doing this.

OK, made a cable and got some results, but three problems:

1. The axes only move one direction. All 3 will move one direction but do nothing for the other direction. Now if the DIR pin wasn't connected properly, it would move left if you pressed the left or right arrow. But it's moving left for the right arrow and no motion at all for the left arrow, so it's not simply a malfunction on the DIR pin. So confused on this point, because the STEP command should pulse for both left and right arrows.

I think the sample hal file uses quadrature instead of step/dir, to change to step/dir change the step_type of each axis to 0

(0 is step/dir output mode read "man hostmot2" in stepgen section for details )

2. The directions are reversed. Can I fix that in software? Resoldering cables would be very problematic at this point. I just need to selectively change DIR to active-low.

Yes, the axis directions can be changed a couple of ways in software but first I would fix the step type and recheck.

3. The gantry needs second stepper- the 4th axis side- to be driven along with the X. And it really needs to be driven slave but with homing alignment like in Mach3. Google is telling me LinuxCNC has historically had problems doing this.

It may be that you need the JAx branch for this. I'm not sure what the current status of slaved axis gantry homing is (do you have 2 X axis home switches?)

What are the ways to reverse stepper direction?

Yes, I have dual X-homing sensors. I'll look up the JAx branch. Google tells me a lot of people have been frustrated because all they can do is hard-link the step generation on both steppers in LinuxCNC and had no way to align the axis, which is very surprising. It's a super-common setup.