This is actually pretty easy, the 7i76e comes with 2 mpg inputs and you can have them on the 7i96 as well but you have to give up a couple of pins or a Stepgen.I can't quite remember what. If you ask PCW nicely, I'm sure he will sort out the correct solution.

Once you have that sorted, there is a good example of a MPG using parallel port pins in the docs.  linuxcnc.org/docs/stable/html/examples/mpg.html

But in your case, you can ditch the axis select knob because you will use a dedicated MPG for each axis. Just implement the scale select knob... I have not thought about it but you may be able to use the one scale select for both MPGs. Using digital knobs lets you minimize the number of pins you need for the scale hence the mux4 components.

Glad you made progress.
I think some signals are still not connected, Its too long ago for me to be specific. I seem to remember there was a system Hal file somewhere that hooked up all the signals to where they belong. In your ini file you refer to HALFILE = qtplasmac_comp.hal and I can't see that in your config folder which might be the file I refer to. finding that file and copying it into your config folder might fix it.

But now you are past the ethercat stage, I think you should post in the plasmac section where Phil and Snowgoer the maintainers will see your post, probably link back to this post and attach your config again.

I'll give this format a try and report back.

I don't know what the expected behavior is if you have no X/Y coordinates in your command. IIRC if you want a full circle, you can use the same coordinates as your starting point. Arguably better practice is to split the move up into two half circles.

You can try one of the following to see if it helps:

G02 X0.7812 Y0 I-0.7812 J0

or

G02 X-0.7812 Y0 I-0.7812 J0
G02 X0.7812 Y0 I0.7812 J0

Hi all;

Below is the first few lines of gcode for a circular pocket that I would like to cut on my home built CNC. The move to the first X/Y coordinate works correctly as does the plunge on the Z axis.  However, the machine stalls at this point and will not execute the G02 instruction. I'm guessing that I missed something in my preamble, but haven't a clue what it could be.  If someone can enlighten me I would greatly appreciate it.


G90 G20 G17
M3 S22000
G04 P6.0
F30

G0 Z0.1

G0 X0.7812 Y0
G0 Z-0.25
G02 I-0.7812 J0

Kind Regards,

1. Somewhere in your ini settings kinstype=both lets you jog before homing unless you have 2 motors on an axis
2. Refer to my Ethercat install sticky for the rules to start the ethercat service on startup
3. No idea
4. It may have changed but probe basic requires a 1080p monitor so I could never used it. QT dragon is the same. I had to upgrade to a 1080p monitor.

I'm at a loss to understand what any machine needs moving before homing. Are your home switches set up so they stay triggered to end of travel?

I posted a lot of info on how the remap works and how I use it in this thread: forum.linuxcnc.org/qtvcp/59009-probe-hei...-active-in-versatool

Also, here's my remap ngc file you can look at. It's modified slightly from the original as far as how and where it moves in regard to the "change_position" location and "tool_setter" location, so I wouldn't just drag and drop. But after looking through your ngc file, it looks very weird and doesn't make any sense. IMO, the most important lines to look at are 7, 93, and 99 in my file.

So, I have 4 distinct problems that have come up switching and already working control to probe basic. Hoping some people can help.


1: i cant move the axes before homing. i need to be able to move them into postion and then home. i assume there must be a toggle somewhere for this.

2: the install process wiper out my ethercat driver somehow, and now it wont start on boot. i need to go and do it manually. It seems probe basic installed or updated other things along with itself. I need to un-update them.

3: when i shut off the machine (power button in linuxcnc) i get a lot of limit and joint errors. these were not in the axis setup. I feel like this is related to issue 1.

4: i have a 1680x1050 screen. i and scaling the output to force fit probe basic. this worked ONCE. and then after rebooting probe basic has scaled itself off to the right side and reports a resolution of 2077x1080.

Any help on any of these would be appreciated, thanks!

There are a few minor things that could be improved, of course in qtdragon.

1. The grid in the preview is in inches; it doesn't switch to millimeters when the machine is running in metric mode.

2. The "run time" window freezes when paused, but when resumed, the time is set as if it weren't paused. Shouldn't that be the case?

3. Manually switching between MANUAL MDI and AUTO modes is unnecessary in many cases and sometimes annoying.
For a long time, I've been using the "btn_start_clicked" function without checking if the machine is in the "auto" state. After pressing start, the machine switches to auto mode automatically, and it works very well.
I'd like the "file" button to work similarly.
After pressing "file," switch the machine to manual mode and open files. 

4. The physical keyboard's pause key only works in "auto" mode, so if the program is run from a macro, the machine is in MDI and pause doesn't work.
In the "on_keycall_pause" function, simply remove the appropriate condition.
The "btn_pause_clicked" function probably also needs to be corrected, because if the "spindle lift" button is active, then after resuming work, the spindle starts and lowers, but doesn't continue. In other cases, everything works correctly.

Hello, I have a—Belgian?—Gallic 16 NC lathe. When I acquired it, I removed the control system but left the spindle power unit in place. For the control system, I use Mach3 via two parallel ports, UHU drives, and DC servos. I can also turn in a quasi-conventional manner using two electronic handwheels. The whole setup worked well for years, but it is admittedly outdated. Now I have a fault in the original main power circuit. Although I have an old wiring diagram, the actual wiring is a chaotic mess. I am now considering overhauling the main power circuit to make it organized and installing a more modern control system. However, I need to be able to use the two electronic handwheels, as there are no mechanical ones. Does anyone have experience with a control system that is affordable (the machine is 35 years old and could fail completely at any time), supports two electronic handwheels, and doesn't come with a 1,000-page manual?
In my stock is a Mesa 7I96 Eth, can I use it?
Many thanks for any replies,
Hans

G'day all,

This is a question about Andy's lathe macros. I am getting a slight angle / coordinated facing angle although I set zero angle in the cut parameters. 



Is this finger trouble on my part, or a possible bug?
Cheers,
Mark

First of all thank you for the help
with your tips I managed to get a list of all the I/O pins and managed to test the inputs manually
I also managed to create and edit a qtplasmac config the way you suggested, now I can get it to run

I managed to get these things working:
-QtPlasmaC interface
-motion on all axis when jogging the machine
-external E-stop
-torch break detection switch
-machine enable output turning on a light

but im still having some problems:
- cant get a torch on output signal when I do a torch pulse
- the ohmic probe enable doesn't output any signal
-when I hit cycle start the G code pauses without moving the machine

what are the best ways to debug this situation and what should I be looking for?
all config files in a zip file below

Thank you again 

Hello everyone,
first of all, thanks to Wischi for the touch gesture version of gremlin.py — it works perfectly on my hardware (Melfas LGD AIT touch panel, LinuxCNC 2.9, Gmoccapy).

The only limitation for me was the one HansU already mentioned: with the mouse you can only rotate, dragging/panning does not work in any setting, because motion() returns unconditionally.

I'm attaching a version that is Wischi's file unchanged, with one addition: instead of disabling motion() completely, it now filters events by their source device. Only events that clearly come from a real physical mouse are processed — the event must not be pointer-emulated, the source device must be classified as MOUSE, and the device name must not contain "touch". Everything ambiguous is discarded, so the touch behavior stays exactly as in Wischi's version.

The background: many touch controllers expose a second X input device that does driver-level mouse emulation (mine shows up as "Melfas LGD AIT Touch Controller Mouse" in xinput list). Its events look like genuine pointer events to GTK — no emulation flag set — and those are what caused the original "preview only moves a couple of mm then stops" bug in the legacy motion() path. That's why the filter also checks the device name, not just the emulated flag.

Result on my machine:

Touch: unchanged from Wischi's version — one finger rotates (perspective view), two fingers pan and pinch-zoom
Real mouse: full mouse_btn_mode behavior restored — left rotate, middle drag/pan, right zoom (mode 0), shift+left drag also works
Since motion() is active again, the mouse button mode setting in Gmoccapy works again too
Tested on LinuxCNC 2.9 with Gmoccapy, capacitive multitouch panel. As before: just replace gremlin.py in /usr/lib/python3/dist-packages/ (keep a backup of the original — it gets overwritten on updates).

Changes:
1. Lines 40–50 — header comment (documentation only)
2. Lines 676–699 — new helper function _is_real_mouse_event()
3. Line 700 — motion()