Advanced Search

Excellent news!

Yes, duty cycle is the correct pin.

Is the frequency reasonable and the valid bit set?

It sounds like the EDM output is single ended which means:

1. The EDM duty cycle output should connect to TB2 pin 13 (IDX+)
2. The EDM signal ground should connect to TB2 pin 15 (7I96S ground)
3. The 7I96S IDX input should be jumpered for TTL mode (W1 left)
4. 7I96S IDX- (TB2 pin 14) must be left unconnected

Note the if you connected the inputs to TB2 pins 13 and 14 without a ground
and ran the EDM system you may have damaged the EDM output or
7I96S input.
 

I should have explained more.
point = [wx, wy, wz]
if not self.plotdata or point != self.plotdata[-1]:
self.plotdata.append(point)
This adds a plot point. We would need to change it to also add color.

point = [wx, wy, wz,color]
or maybe better:
self.plotdata.append([point, color])

then later in the file:
#GL.glColor3f(1.0, 0.5, 0.5)

GL.glBegin(GL.GL_LINE_STRIP)
for p,c in self.plotdata:
GL.glColor3f(*c)
GL.glVertex3f(*p)
GL.glEnd()

a few other initialization and clearing details to follow up. but that might work.

Another update.  It seemed that I didn't have the Mesa tied to ground properly.  It is now tied to earth ground (I also tied the shielding into earth ground). The jittering all went away and now the 'hm2_7i96s.0.periodm.00.duty_cycle' is sitting at 0 even when the EDM is running.  Anyone have any ideas? 

Is 'hm2_7i96s.0.periodm.00.duty_cycle' the correct pin?

I have tried various ways to use this code, but so far no results..

I stay away from USB pendants and the like.

Did you find a solution to this problem? Having the same issue
 

Did you find a solution to this problem? Having the same issue

Use the one Rod linked to on his google drive as it handles screen resolutions much much better.

With Linuxcnc is somethings works generally users stick with it. There is still many machines running earlier versions of Linuxcnc on Ubuntu 10 series.

Think of a machine running Linuxcnc the same as an ECU on a pre 2000's car or bike, if it works don't mess with it..........unless you're racing

You can connect TTL level encoders directly to 7C81 I/O pins
_but_ I would at the minimum add say 220 Ohm resistors in series
with each signal to protect the inputs from negative input spikes.
(encoder signals tend to pick up motor drive noise so are fairly hard
on unprotected inputs)

Ha! should have asked about the encoder mode first...

I'll answer with experience of using Aliexpress Omron type encoders www.aliexpress.com/w/wholesale-omron-rotary-encoder.html , which are about less than a tenth of the price of the ones you mentioned, it's nice if you mention parts you can provide a link, saves time trying to search and ensures the correct component is being discussed.

With an optocoupler you will need to ensure the optocoupler is fast enough and the encoder can drive the optocoupler's led hard enough.

If the encoder is true TTL output or open collector output it should be fine.

Personally I've just used simple buffers, 74hc540/541, as I have a couple of tubes of them.

Another option would be to use the differential output of the encoder and connect that to a differential line receiver, such as www.futurlec.com/Linear/26LS32pr.shtml.

The schematics for the 7c81 are available, forum.linuxcnc.org/media/kunena/attachments/481/7c81sch.zip , one of the sheets shows the input circuitry.

No doubt Pete from Mesa will chime in.