Remote Pendant Acting Erraticly

Hello All,

We use the Mesa 7I73 pendant Interface with knock off ebay bought MPG pendants, and have never really had any issues with them or there working with linux. Last week the operator came up to me and said the pendant quit working. After investigation I found the following, jogging in the negative direction on both axes (X and Z) on our lathe, it would stop jogging randomly for no reason, with inches to spare before hitting my "soft Limits". Using the keyboard, the machine would jog just fine throughout the full extent of what is programmed for the limits. I started the "show hal config" utility and looked at my encoder counts and enable signals and the pendant was showing to be working just fine with the enables going on and off with the pressing of the enable button, and the encoder counting up and down based on how I was turning the mpg.

Totally lost,,,,,

I completely shut down linux, re-started and it, and it worked fine after that.

Any Thoughts,,

Rick

If the 7I73 hal pins were working and you got no SSerial
interface faults I don't actually think this is 7I73 related.

If you have an old enough 7I73 (firmware older than V14)
you might update the 7I73s firmware as sserial remote firmware
older than V14 has a bug that can be triggered by a series of more than 16 faults

www.mesanet.com/software/parallel/sserial.zip

(though I would not expect that this is your issue if you don't get _many_ sserial error popups)

Hello Peter,

How long has this updated firmware version been available?

I do actually get smart serial errors randomly on the machines but, I'm trying to address one fire at a time on the machines.

Thanks

Rick

The V14 firmware has been available about 6 months
If you do have random mart serial errors it probably
means that there is a noise issue that needs to be addressed.

perhaps by re-routing serial cables away from power cables,
perhaps by looking at possible grounding issues

What errors do you have and on what cards?

I think I have figured out what is going on with my MPG,

Every time the encoder.N.counts pin reaches 21475 counts, the machine quits jogging. I jogged back and forth past 21475 and when it would count lower than that the machine would start moving again, when it would count higher than that it would stop.

I noticed that when the encoder.N.index-enable pin is set High, it is supposed to reset .counts to zero on the next rising edge input of the Z channel, problem is, the encoder dosen't have a Z channel.

I know I can set .index-enable high, but would it be ok to lie to linux with a bogus Z input, or could I do some kind of hal counter based off the A channel, for every 100 counts set hal counter output high and pulse Z high?


Thanks

Rick

Thats really strange.

I dont think you can clear the jog count without trouble when jogging
since motion would not know about the index.

The count may be clearable when jogging is inactive however.
On the other hand its better to find and fix the bug instead or work around it.

if the encoder counts properly, the trouble must be downstream
in the jogging code. I've never heard of such a thing, though ~215 MPG wheel
spins is a pretty high number.

It might also be a bug in the hal file if you are doing something fancy with the jog count.

In any case this needs further investigation...

Here is the portion of my hal file for the handwheel, it should be a carbon copy of the mpg wiki,


# 7I73 Input signals

net mpg-a encoder.0.phase-A <=== hm2_5i23.0.7i73.0.2.input-08
net mpg-b encoder.0.phase-B <=== hm2_5i23.0.7i73.0.2.input-09

net mpg-x <=== hm2_5i23.0.7i73.0.2.input-16-not
net mpg-z <=== hm2_5i23.0.7i73.0.2.input-17-not
net scale1 <=== hm2_5i23.0.7i73.0.2.input-19-not
net scale2 <=== hm2_5i23.0.7i73.0.2.input-20-not

setp encoder.0.x4-mode 0

setp axis.0.jog-vel-mode 1
setp axis.2.jog-vel-mode 1

setp mux4.0.in0 0.0001
setp mux4.0.in1 0.00001
setp mux4.0.in2 0.000001
#setp mux4.0.in3 0.0001

net mpg-scale <= mux4.0.out
net mpg-scale => axis.0.jog-scale
net mpg-scale => axis.2.jog-scale

setp ilowpass.0.gain 0.009
setp ilowpass.0.scale 100

net encoder-counts <=== encoder.0.counts
net encoder-counts ===> ilowpass.0.in
net smoothed-encoder-counts <=== ilowpass.0.out
net smoothed-encoder-counts ===> axis.0.jog-counts
net smoothed-encoder-counts ===> axis.2.jog-counts

net x-jog-enable <=== axis.0.jog-enable
net z-jog-enable <=== axis.2.jog-enable
net scale1 <=== mux4.0.sel0
net scale2 <=== mux4.0.sel1




I told the operator to turn the machine off at the end his shift every day to reset the counter to Zero for now until I come up with a solution.


Rick

It does seem to be a bug in the jogging code
Here is some discussion on the developers IRC channel:

psha.org.ru/irc/%23emc-devel/2014-03-25.html

(scroll to the bottom)

There is one fairly odd thing about your hal code:

You are not using the built in 7I73 encoders but using software encoders instead
that is I would expect you to use

hm2_5i23.0.7i73.0.2.enc0 and
hm2_5i23.0.7i73.0.2.enc1

as the jog count sources

and not use a slower software encoder
(not that this is related to the jogging problem in any way)

Can you watch

ilowpass.0.out

and see if it sticks beyond the 21475 encoder count point

just to try an narrow down where the problem is located

Yes the ilowpass.0.out value stopped when the .counts value hit 21475, its value was 2146999999.

This makes sense "<jepler> should be fine until jog counts get into the billions" then.



Rick



I just looked at my hal file and realized that my ilowpass scale is set at 100000, making the output go just north of 2.1 billion counts.

Regardless I need to make it reset after they make there manual moves with the handwheel, as referenced in the irc, it would probably eventually happen anyway if they kept jogging towards the part after running a program, which we do a lot of.