Advanced Search

No RGB for now, but soon, and putting that tempered glass on!

PCW wrote:

Typically this is done by by connecting the MPG count to all axis
and selectively enabling jogging on the desired axis
 

Thanks for that. I'm almost there.....

I have two rotary switches, each switch has 2 outputs driving inputs on a MESA card as 00,01,10,11

Switch #1 is used to select MPG increment 0, 0.0001", 0.001", 0.01"  I'm using a MUX4 to control that. No problem with this.

Switch#2 is for selection of where the MPG ticks   ( net encoder-counts  <= hm2_7i96s.0.inm.00.enc1-count ),gets routed, so to either:
X, Z, C (Compound), or N(None), so....
axis.x.jog-counts
axis.z.jog-counts
anglejog.counts-in
or to nowhere when position N is selected

I now have the rotary switch working for: none, X or Z by simply enabling jogging for X or Z as required. For Compound action I can simply enable both X and Z when in compound mode.

Final hurdle is that I have two S32 source signals:
   1) The MPG signal called (encoder-counts), for non-compound moves. Configured and working as net encoder-counts => axis.x.jog-counts
   2) The modified by anglejog MPG signal for compound moves called (angle_x). I can't simply configure as net angle-x => axis.x.jog-counts

 HAL does not allow two sources to drive one output pin. I'm guessing that mux_generic might be the best solution, to allow choosing the source signal for axis.x.jog-counts?

Assuming mux_generic is the best solution, I need a little help configuring mux_generic:
  - I assume I would add it to the servo-thread?   loadrt mux_generic config="??????"
  - the other pins are a bit fuzzy, looks like I need to specify:
     mux-gen.00.in-s32
     mux-gen.00.out-s32
    
I'm not sure how to:
a)  assign encoder-counts and angle_x to the two inputs of the multiplexer?
b)  route the output of the multiplexer to axis.x.jog-counts?
c)  define the control bit that will select the desired input?

   Your help is appreciated.

I put an old working backup of the ini and hal files just in case. Same outcome. The x and y encoders do read fine when moved by hand.

If you did not change anything in the hal/ini files, this points to a hardware failure of some kind.

Do the encoders still read the axis position if you move them by hand?