Advanced Search

Trying to get analog jogging working on gmoccapy, linuxcnc 2.9.3 with mesa card.
Have followed a few separate threads and have com up with the following .starting with just the x-axis. The analog out from the mesa is approx 0 to 5v

 loadrt mux2 names=mux2_x,mux2_y,mux2_z
addf mux2_x servo-thread
addf mux2_y servo-thread
addf mux2_z servo-thread

loadrt and2 names=and-jog
addf and-jog servo-thread

loadrt deadzone names=deadzone-x
addf deadzone-x servo-thread

loadrt scale names=scale.x
addf scale.x servo-thread

setp scale.x.offset -1.00
setp scale.x.gain .416
net x-scale <= hm2_7i76e.0.7i76.0.0.analogin0 => scale.x.in
net gate-x-scale <= scale.x.out => mux2_x.in1 
net x-is-homed <= halui.joint.0.is-homed

net machine-is-on <= halui.machine.is-on => and-jog.in0
net x-is-homed => and-jog.in1 
net jog-allowed <= and-jog.out => mux2_x.sel

setp deadzone-x.threshold 0.1
net mux-x mux2_x.out => deadzone-x.in

net jog-x-analog deadzone-x.out => halui.joint.0.analog halui.axis.x.analog
setp halui.mode.manual 1
setp halui.joint.0.select 1

Am getting halui.joint.0.analog going from +1 to -1 ok and seems to be gated correctly if I unhome X.
Was getting
error: command [EMC_JOG_STOP] cannot be executed until the machine is out of E-Stop and turned on
when I didn't have the gating correct so it appears to be getting through to some extent 

I also seem to have a problem with deadzone as configured above. It is letting through values like .006 when threshold is .1. If I change it to .2 it seems to behave better.

But get no movement. Jogging using gmoccapy still works

You can also just add ~220 ohm series resistors in the PWM lines

The main hazard is ground differences/HF noise causing negative
input voltages with unlimited current. a series resistor will protect against
this.

Yes I'll take care to put a BOB betwen P3 and the hardware until I grab a specific card from mesa store

Thanks a lot, have a good day

Firmware for a 7I76EU with a 7I85 on P2 and 2 PWMgens on P3

Note that since P3 pins are unbuffered/unprotected it's best to add
a say 100 to 220 Ohm series resistor to pins connected to the rest of the system
(or use a cheap parallel port breakout card)

 
 

yes exactly please

So 7I76EU firmware for a 7I85 on P2  and 2 PWMgens on P3 is what you want?

I got the 7I85

But I had to buy the S version... My mistake

I'll be fine if the P3 with 1 or 2 pwm and all the others P3 ports as IO if possible ?

I'm not clear on what daughter card
you have: 7I85 or 7I85S ?

I can make firmware for either.

ok I found this firmware corresponding to my card 7I85
forum.linuxcnc.org/27-driver-boards/5823...76eu-7i85-pwm#341493

I should buy the 7I85S

Hi Peter,

I need custom firmware for my amazing 7i76EU with:

- 7i76 daughter for router 5 axes + 0-10V vfd (currently working with 7i76eu_7i76x1_7i85sx1d.bin)
- 7i85 (1 serial, 2 encoder, 4 stepgen) on P1 (currently working with 7i76eu_7i76x1_7i85sx1d.bin)  
- 1 or 2 PWM generator on P3 for 20kHz laser control and idealy the rest as I/O port

Can you create such firmware combining all these ? Do you need more info ?

Board IP: 192.168.1.121

Thanks! 

Just to close this topic down, having found the enthusiasm to strip the machine down...

So, it looks like every group of 8 inputs is routed through it's own octal analogue mux, with each input circuit comprised a current limiting resistor, a pull-down resistor (essentially a voltage divider) and a capacitor snubber.

That only one input is at fault suggests either the mux (LV4051), or the RC network on each pin, or the pin itself. I've examined under magnification all joints, and reflowed them all, and the problem remains. Therefore I conclude the most probable fault is on the mux, most likely due to user (my) mishandling,

At this stage, remapping the input to an otherwise unused input closes this problem - tested and proven. I thank you all for your earlier replies.

Yes, coupling of inputs often means a missing ground.

Note the the field I/O is completely isolated from the
logic (5V side)

Kind of where my thoughts where - to the periphery of the board the wiring is correct - I've strapped field-V to the inputs (input KEFG connector). What you've described I can believe with a broken track/open circuit component on the board.

Seems like interference from missing/wrong wiring/not connected grounding, or disconnect of the negative field power.

Context: An old Boxford 160 lathe adaptation, using the (fabulous) Mesa 7i76e card (integrated FPGA/2-port/massive break-out of I/O/Steppers etc). Started too many years ago and been through various incarnations, LinuxCNC uplifts etc. Never really used in anger, but more for learning about LinuxCNC, in between juggling work, the wife and various cats. Now that I'm retired I can start to concentrate a little. A long winded way to say I think it used to work but now...

Somewhere along the way something has happened. I have push button controls for jog x+/x- and z+/z-, with the jog speed controlled by an analogue pot, From memory, this all worked. Then retirement hits and I get more time to play. The behaviour now somewhat peculiar. X+/- work as expected. Z+/- are more erratic. Turns out, through HAL-Show/Scope that I have z+ on 7i76e.0.input-08 and z- on 7i76.0.input-09.

If I activate (field voltage to input) input-08, the resulting waveform on halscope shows an erratic 0/1 value for the duration of the field voltage being applied. Once field voltage is removed then the signal on halscope reverts to a steady 0.

If I apply field voltage to input-09, then input-9 is shown high on halscope and input-8 reverts to the erratic 1/0 value whilst the voltage is applied to input-09. Removing voltage from input-09 and both input8/9 on halscope revert to 0.

The observation on halscope describes perfectly the observation on the machine - traverse in the Z axis is erratic to the point of occasional reverses of direction and/or stuttering of the jog.

Particularly as my fuddled brain thinks that when I last played with this this all worked, I'm thinking this is likely to be a hardware issue on the 7i76e card. I've quickly belled-out all other inputs and they appear to work as expected. This does mean I can re-wire to use an otherwise unused input, but this irks me.

Has anyone experienced anything like this before?, and is there a solution (e.g. a different bit-file for the FPGA?)

The nature of this is peculiar to my mind, that this is likely tied not so much to a IP fragment of the FPGA, but more likely individual hardware between the terminals on the board and a FPGA port pin. Particularly as the input-8 looks to be in someway coupled to input-9 I'm inclined to get the associated pins under the microscope and reflow the joints, but that's a job for another day. This post just to understand if anyone has witnessed similar and found a solution?

Regards,

Mike