Welcome to LinuxCNC.org

maxvdh wrote:Pncconf has an almost impossible job with the rate at which Mesa bring out new hardware and the variety of machine tools out there. So, it is likely to be quite common to need to hand-edit the configuration files a little after Pnccconf has done the bulk of the work.

It sounds like your amp-enable signals are either not wired, or are wired with the wrong sense.

You can track this down using various tools built in to LinuxCNC / AXIS.

The first place to look is in the AXIS menu machine->show HAL configuration. This brings up a tool which lets you look at the internal "wiring" of HAL. It is important to note that there are two tabs, and only the "WATCH" tab shows live data, the other tab shows a snapshot from when you clicked the pin name.
First, a bit of research. Have a look in the generated HAL file and see what signal names are associated with amp-enable, and which GPIO pins they are linked to. (if any).
Then open machine->show HAL config and have a look at the available pins and signals. (you should recognise the signals from the HAL file, a "signal" is the first string after a "net" command, or a newsig.).
You can select the pins and signals in the showconfig "Watch" window and see if they change in the expected way when you press F2 or click the Machine On button.
I suspect that the problem might be that the 7i77 has pwm-enable pins that are not being connected by pncconf. The 7i77 is a bit of a clever card, and it declares its own pin names.
Again, you should be able to see if the switch states and encoder position are finding their way in to HAL, and then it is a case of making sure that they go to the correct places.

I don't expect this to be a full answer, but it should get us started.

A quick observation is that if you get a following error, with a standard (and safe) HAL file, the drive enables will be instantly dropped (this may not be the case in the open loop test).

If you have not tuned the drives this is expected at this point

"Now the complication is that there must be some intricacy of my Bridgeport control circuitry/servo amplifiers because if I jumper a logic high signal to a release relay, I hear a progressively louder buzzing noise for about 2 seconds until the main contactor trips out completely. This is pretty bizarre. I can't find any differences between what is on and off when I successfully run the open loop test and when I try to jog in AXIS except the release relay drive signal being low."


This sounds like the closed loop gain is too high. That is when you run a real test (not open loop) your servos are oscillating. If the drive enables are controlled by LinuxCNC the drives will be disabled as soon as you get a joint following error

I would set your PID parameters to something really low to start (say 1 for P and 0 for I,D,FF1,FF2), and as Andy suggested increase your following error limits so it does not immediately fault when the drives are enabled

Thanks for all the responses. I'll try to address everything that's been mentioned.



andypugh wrote:
Physically they have certainly been wired but it's possible something is mis-wired in the HAL file. I believe the relevant lines are -

"# external output signals


# --- ESTOP-OUT ---
net estop-out hm2_5i25.0.7i77.0.0.output-00

# --- MACHINE-IS-ENABLED ---
net machine-is-enabled hm2_5i25.0.7i77.0.0.output-01

# --- FORCE-PIN-TRUE (this is connected to an "auto" relay which seems to want to be on for motion" ---
setp hm2_5i25.0.7i77.0.0.output-02 true

# --- XENABLE ---
net xenable hm2_5i25.0.7i77.0.0.output-03

# --- YENABLE ---
net yenable hm2_5i25.0.7i77.0.0.output-04

# --- ZENABLE ---
net zenable hm2_5i25.0.7i77.0.0.output-05"

andypugh wrote:
I've used the watch tool and the HAL scope to monitor the xenable signal and the hm2_5i25.0.7i77.0.0.output-03 pin when I turn the machine on and when I press the jog button in AXIS and at no point do I see either of them change state. I would think they should. Even if they needed to be inverted for some reason, I would have expected a change of state.

andypugh wrote:
The encoder count for the MPG comes in fine in HAL meter but I guess it must not be properly connected to AXIS. I would think I needed to activate something to toggle MPG control but I haven't seen any button in the software and I don't have any hardware button to activate it.

"# ---jogwheel signals to mesa encoder - shared MPG---

net joint-selected-count <= hm2_5i25.0.encoder.05.count
setp hm2_5i25.0.encoder.05.filter true
setp hm2_5i25.0.encoder.05.counter-mode true

# ---mpg signals---

# for axis x MPG
setp axis.0.jog-vel-mode 0
net selected-jog-incr => axis.0.jog-scale
net joint-select-a => axis.0.jog-enable
net joint-selected-count => axis.0.jog-counts

# for axis y MPG
setp axis.1.jog-vel-mode 0
net selected-jog-incr => axis.1.jog-scale
net joint-select-b => axis.1.jog-enable
net joint-selected-count => axis.1.jog-counts

# for axis z MPG
setp axis.2.jog-vel-mode 0
net selected-jog-incr => axis.2.jog-scale
net joint-select-c => axis.2.jog-enable
net joint-selected-count => axis.2.jog-counts

# for axis a MPG
setp axis.3.jog-vel-mode 0
net selected-jog-incr => axis.3.jog-scale
net joint-select-d => axis.3.jog-enable
net joint-selected-count => axis.3.jog-counts

# connect selectable mpg jog increments

net jog-incr-a => jogincr.sel0
net jog-incr-b => jogincr.sel1
net jog-incr-c => jogincr.sel2
net jog-incr-d => jogincr.sel3
net selected-jog-incr <= jogincr.out-f
setp jogincr.debounce-time 0.200000
setp jogincr.use-graycode False
setp jogincr.suppress-no-input False
setp jogincr.in00 0.000000
setp jogincr.in01 0.000100
setp jogincr.in02 0.000500
setp jogincr.in03 0.001000
setp jogincr.in04 0.005000
setp jogincr.in05 0.010000
setp jogincr.in06 0.050000
setp jogincr.in07 0.100000
setp jogincr.in08 0.000000
setp jogincr.in09 0.000000
setp jogincr.in10 0.000000
setp jogincr.in11 0.000000
setp jogincr.in12 0.000000
setp jogincr.in13 0.000000
setp jogincr.in14 0.000000
setp jogincr.in15 0.000000"

I think I made some progress with one of the below suggestions so please let me know what you think.

maxvdh wrote:
Well, these are half of it, defining signals and where they need to go to. What I don't see in the lines you have pasted is where the signals come from.
I would rather expect to see, for example
net estop-out halui.estop.is-activated
because estop-out is just a signal name, and it has no meaning to LinuxCNC. halui.estop.is-activated, however, is an output pin driven by LinuxCNC.
The same is true for xenable, I would expect it to be netted to axis.0.amp-enable-out

(Yes, i do know most of these pin names off by heart, but they are all listed in the docs for example:
www.linuxcnc.org/docview/html/gui/halui.html
www.linuxcnc.org/docview/html/man/man9/motion.9.html
Knowing where to look for each one is a bit more difficult)


Here we have the reverse problem, I don't see where jog-incr-a etc are driven from. I would expect them to be wired to gpio and from there to the jog-speed selector switch.

PCW wrote:
This seems likely. I've been using FERROR=5 and MIN_FERROR=0.5 to allow myself some leeway. I cranked the gains down to where you suggested and when I manually activate the X release relay I don't get oscillation but I seem to get positive feedback. Monitoring the analog output signal to the X servo amplifier, I see an initial voltage of about 1e-14V. As soon as I activate the servo amplifier, that voltage slowly climbs to ~-0.5V at which point I get a joint 0 following error. I attached a picture of HAL scope monitoring this behavior. I wasn't able to capture the whole event in one pass but I got a joint error right after the period you can see here.

Perhaps that means that I have either an encoder or servo drive signal inverted. I set them correctly in the open loop test in PNCConf but I know that doesn't necessarily mean that they're being handled correctly now.