Advanced Search

  I ran pnconf wizard and made a configuration for my CNC plasma table. I am able to home and jog my machine for about a minute until I get this error. 
It seems like the ethernet connection is disconnecting on its own somehow. Any ideas on how I could get the ethernet to stay connected so I can use my machine.

Here is the full file

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 wcomp names=plus_x_trigger,minus_x_trigger,plus_y_trigger,minus_y_trigger,plus_z_trigger,minus_z_trigger
addf plus_x_trigger servo-thread
addf minus_x_trigger servo-thread
addf plus_y_trigger servo-thread
addf minus_y_trigger servo-thread
addf plus_z_trigger servo-thread
addf minus_z_trigger servo-thread

# this is the deadzone for each axis to stop drift, also can make bigger to stop x/y axis moves easier without one triggering the other
setp plus_x_trigger.max 0.15
setp minus_x_trigger.min -0.15
setp plus_y_trigger.max 0.15
setp minus_y_trigger.min -0.15
setp plus_z_trigger.max 0.15
setp minus_z_trigger.min -0.15

loadrt lut5 names=jog_x_enable,jog_y_enable,jog_z_enable
addf jog_x_enable servo-thread
setp jog_x_enable.function 0x80
addf jog_y_enable servo-thread
setp jog_y_enable.function 0x80
addf jog_z_enable servo-thread
setp jog_z_enable.function 0x80

loadrt or2 names=or-x-jog,or-y-jog,or-z-jog
addf or-x-jog servo-thread
addf or-y-jog servo-thread
addf or-z-jog servo-thread

loadrt scale names=scale.x,scale.y,scale.z
addf scale.x servo-thread
addf scale.y servo-thread
addf scale.z servo-thread

# mine were 0-4.8v. Assuming a range of -1 to +1. 2/4.8=.416 z was way off balance and cannot see how to adjust so do it in sw
setp scale.x.offset -1.00
setp scale.x.gain .416
setp scale.y.offset -1.00
setp scale.y.gain .416
setp scale.z.offset -0.80
setp scale.z.gain .416

net x-scale <= hm2_7i76e.0.7i76.0.0.analogin0 => scale.x.in
net y-scale <= hm2_7i76e.0.7i76.0.0.analogin1 => scale.y.in
net z-scale <= hm2_7i76e.0.7i76.0.0.analogin2 => scale.z.in

# the mux is used to select 0 or the current value and is implementing the deadband. Cannot let the analog value through otherwise in interferes with jogging from ui
net gate-x-scale <= scale.x.out => plus_x_trigger.in minus_x_trigger.in mux2_x.in1
net gate-y-scale <= scale.y.out => plus_y_trigger.in minus_y_trigger.in mux2_y.in1
net gate-z-scale <= scale.z.out => plus_z_trigger.in minus_z_trigger.in mux2_z.in1

# may not be needed anymore
net x-is-homed <= halui.joint.0.is-homed => jog_x_enable.in-1
net y-is-homed <= halui.joint.1.is-homed => jog_y_enable.in-1
net z-is-homed <= halui.joint.2.is-homed => jog_z_enable.in-1

# only allow jogging if in the jog menu linuxcnc/gmoccapy seemed to complain in any other state
net machine-is-injog <= halui.mode.is-manual => jog_x_enable.in-0 jog_y_enable.in-0 jog_z_enable.in-0

# fixed for all axis multiplied from .15 to 1 from scale above. Change scale is difference needed for each axis
setp halui.axis.jog-speed 600
setp halui.joint.jog-speed 600

# wcomp is used here as deadband. Controls relevant jog plus or minus
net enable-x-jog-plus <= plus_x_trigger.over => halui.axis.x.plus or-x-jog.in0
net enable-x-jog-minus <= minus_x_trigger.under => halui.axis.x.minus or-x-jog.in1
net enable-y-jog-plus <= plus_y_trigger.over => halui.axis.y.plus or-y-jog.in0
net enable-y-jog-minus <= minus_y_trigger.under => halui.axis.y.minus or-y-jog.in1
net enable-z-jog-plus <= plus_z_trigger.over => halui.axis.z.plus or-z-jog.in0
net enable-z-jog-minus <= minus_z_trigger.under => halui.axis.z.minus or-z-jog.in1

# if all 3 conditions are met i.e. not in deadband, is homed and is manual then select mux and route analog value to axis
net jog-x-either <= or-x-jog.out => jog_x_enable.in-2
net enable-x-mux <= jog_x_enable.out => mux2_x.sel
net jog-x-speed <= mux2_x.out => halui.axis.x.analog

net jog-y-either <= or-y-jog.out => jog_y_enable.in-2
net enable-y-mux <= jog_y_enable.out => mux2_y.sel
net jog-y-speed <= mux2_y.out => halui.axis.y.analog

net jog-z-either <= or-z-jog.out => jog_z_enable.in-2
net enable-z-mux <= jog_z_enable.out => mux2_z.sel
net jog-z-speed <= mux2_z.out => halui.axis.z.analog

forum.linuxcnc.org/10-advanced-configura...ning-detailed-how-to

forum.linuxcnc.org/27-driver-boards/3559...ethernet-mesa-boards

Hello all, I have a question about the enable pin on my stepper drivers, I have 4x DM542T stepper drivers from Stepper Online connected to my Mesa 7i76EU. Is it recommended to connect the enable pins to the Mesa, and if so where should they be connected to. Or should I leave them unconnected.

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.