7i77 testers wanted

I always appreciate and try to take care of precaution notes. This was my stupidity to did things in hurry. Even I didn't try to check with multimeter. Or try to put a switch between circuit as drive supplier also suggested me. hopefully I will do better next time.

I am really thankful to all the kind people helping me here.

I'm back again with a couple more questions -

I've set up my spindle control and it seems to run correctly from AXIS after a little massaging of the scaling numbers (it appears that the analog input of my VFD wants a max voltage of 1.5 to get 60 Hz which for some reason works with a scale of about 6.4 - however I'm not sure what AXIS' default spindle speed is supposed to be when you leave spindle at 100% and press the CW rotation button). When I tell it to run in reverse, it correctly sets the spindle CCW pin but the PWM pin output stays at 0. I've seen this discussed here www.linuxcnc.org/index.php/english/compo...57&catid=38&start=18 with a workaround but I see at the end of the thread that you updated PNCConf (or was it stepConf?) to fix it. I wanted to see whether I should proceed with the workaround or if there's a cleaner way of fixing this behavior.

I'm also having trouble getting my servomotors to run in AXIS. I'm able to run them in the open loop test dialog in PNCConf but whenever I try to jog them in AXIS I get no motion whatsoever and a following error. The ".. Amplifier Enable" pins, which I have connected to X/Y/Z-release relays on my end, are not being activated when I try to jog in AXIS like they are in the open loop test. 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. I would appreciate suggestions on this issue but the question I imagine is more answerable is "Why aren't the X Amplifier Enable.. etc pins being activated when I jog in AXIS?"

I also would like to figure out how to get my multi-axis MPG encoder to work. I don't think it does at the moment despite being set up in PNCConf; I don't see any activity when I rotate it but maybe I need to press a button in AXIS to get it to run. Getting the linear axes running is the more important issue at this point though.

Any pointers are appreciated.

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:

maxvdh wrote:

workaround but I see at the end of the thread that you updated PNCConf (or was it stepConf?) to fix it. I wanted to see whether I should proceed with the workaround or if there's a cleaner way of fixing this behavior.

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.

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:

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.

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:

I also would like to figure out how to get my multi-axis MPG encoder to work.

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.

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.

PCW wrote:

"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

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.

A few observations:

1. Why are you not using the drive enable outputs of the 7I77? That is their intended purpose. They have the advantage that they are "floating" switches so can be used with active high and active low enables. They have the additional advantage that they can use a separate supply so you can use them with enable inputs that have a different voltage requirement than the field I/O (which is normally 12 or 24VDC)

2. HM2 encoder "Counter mode" which is an up/down count mode
as opposed to the normal reversable quadrature mode is not suitable
for MPGs so this should be set false

andypugh wrote:

maxvdh wrote:

net estop-out hm2_5i25.0.7i77.0.0.output-00
net xenable hm2_5i25.0.7i77.0.0.output-03

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)

Thanks a lot for the references. I wasn't aware that xenable wasn't a LinuxCNC function. That said, xenable is netted to axis.0.amp-enable-out later in the HAL file. Maybe I should take a look at that signal to see what it's doing.


andypugh wrote:

net jog-incr-a => jogincr.sel0
net jog-incr-b => jogincr.sel1
net jog-incr-c => jogincr.sel2
net jog-incr-d => jogincr.sel3

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.

I have no jog speed selector switch or buttons so that's probably the problem. I'd just like to be able to set a fixed jog speed for the joysticks I have and use the MPG in velocity mode.