Advanced Search

Hi,

Setting up Probe Basic 0.6.6 on a 4-axis gantry machine (MPCNC with a fixed rotary B axis mounted at the end of the Y travel).

Configuration:
- LinuxCNC 2.9.8
- Mesa 7I76E (Ethernet)
- trivkins coordinates=XXYYZB, 6 joints
- B axis is a rotary chuck, fixed position at Y=700mm

What works:
DRO displays all 4 axes correctly using DRO_DISPLAY = XYZAB (A axis is unused but present — there is no XYZB option available).

What does not work:
The backplot renders the toolpath as 3-axis only — B axis rotation is not applied when building the path. For wrapped rotary applications (tube machining) the toolpath preview is not meaningful.

Also, machine bounds are not displayed in the 4-axis config, while they display correctly in the 3-axis config on the same machine.

Are there any plans to support wrapped rotary backplot rendering in Probe Basic / qtpyvcp?

3 axis configuration - mpcnc_probebasic.ini
4 axis configuration - probebasic_4b.ini

Hallo Zusammen ! Da bin ich mal wieder mit einem oder besser mehreren Problemen... Mittlerweile weiß ich nicht mehr weiter. Meine Fräse spinnt ja des öfteren,da habe ich mich schon daran gewöhnt,einfach am nächsten Tag wieder Versuchen ,dann ging es meistens wieder. Fehlermeldungen wie" Radius to end of arc differs from Radius to start und ähnliches bin ich ja schon gewöhnt. Da half oft einfach einen anderen G Code zu Laden,Starten und gleich wieder Stoppen,dann den Ursprünglichen Code wieder Laden und dann ging es . Jetzt Kommt aber die Fehlermeldung,dass die Fehlermeldung" Bewegung Linear in Zeile 19 würde Anschlag der Achse 1 Überschreiten! Das Dumme ist nur,dass das Werkstück 40mm Durchmesser hat und ich nach jeder Seite 250mm Weg über habe. Jeden Start quittiert die Maschine mit einem sofortigen Stopp. Ich habe für das Werkstück 2 G Codes,einmal für eine 3,17mm Fräser und einmal für einen 2mm Fräser zum Schlichten. Der G Code für den 3,17mm Fräser läuft ohne Probleme,der für den 2mm Fräser nicht. Ich habe schon ein neues Setup Probiert,für jeden Arbeitsschritt einen eigen G-Code erstellt,alles ohne Erfolg. Meine Steuerung ist eine Mesa 7i76e ,an allen Achsen Closed Loop.  Das Nonplusultra wäre jemand im Raum Laa an der Thaya in Niederösterreich,der sich das mal in Natura gegen Bezahlung natürlich anschauen könnte. Ich bin mit meinem Latein Mittlerweile am Ende. Ein neues Bedienpult neuem Steuerrechner(I 5) steht auch schon in den Startlöchern,da bin ich auch noch am Tüfteln wegen Werkzeuglängen vermessung und Antastfunktion ect. G-Code häng ich mal an,vielleicht findet wer den Fehler,ich werde nicht daraus Schlau. Mit Dank im Voraus !

Unless you changed the firmware, I doubt that that's the issue.
 (all cards are tested and shipped with standard firmware)

You think it's worth it to give it another shot with flashing another firmware before returning it or do you advice against that?

The hal and ini file look sane so I would guess its some kind of hardware issue.
 So the card should be returned for evaluation
 

I tried on a Raspberry Pi 4 with image "image_2026-01-21-raspios-lcnc-2.9.8-trixie-arm64"
and on a Laptop with image "linuxcnc_2.9.8-amd64.hybrid"
and unfortunately i get the same results on both, with the simplest configs i can do, even in the test/tune tab in pnc wizard it acts the same way, Sorry guys i may be missing something really basic here, do you think it might be the firmware?

config name "GG" made on the laptop

Files attached

Can you make a new very simple config and test again?

Very weird symptoms...

Probably should be returned for evaluation

As last check on the software side, can you post you hal/ini files?

I measured again

from +5V to DIR+ = 5.13V and drops to exactly 5V when jogging in the negative direction


from +5V to DIR- is always at 0V That's for all channels on TB2 1, 2 and 3

Do you think i got a faulty board, Sorry this is getting so frustrating

The signals are differential but can be used single ended
That is DIR+ and DIR- should both change voltage when
the direction changes but one should change from 0 to 5V and the
other from 5V to 0 (relative to ground)

Measured differentially, you should always measure either
+5V or -5V across the DIR+,DIR- or STEP+,STEP- pins.

Yeah i checked it in halshow under parameters
step_type is 0

Is it possible that you have the incorrect step mode chosen in your hal file?

(step/dir is mode 0)

Hi everyone,I’m very new to LinuxCNC and Mesa boards, so I might be missing something basic here, but I’ve been stuck on this for a while and could really use some guidance.I’m working with a Mesa 7I76EU and setting up stepgens in LinuxCNC. When I use TB3 (channel 4), everything works perfectly. The motor moves in both directions, the direction signal changes correctly, and I can clearly see step pulses on the oscilloscope.The issue is with TB2 (channels 0–3). No matter which channel I use, I don’t get proper behavior. At first, measuring to ground made it seem like there was no voltage at all, which confused me. Then I realized these are differential outputs and started measuring across the pairs instead.On TB2, I can see step pulses across STEP+ and STEP− (about 5V differential), so the channel is definitely active. But the DIR signal (DIR+ to DIR−) stays constant at about 5V and does not change when I reverse direction. Also, the step pulses only show up when jogging in one direction, not both.In HALShow, the stepgen for that channel looks active. Enable is true, velocity command changes sign when I jog forward and backward, and position feedback and counts are updating. So from LinuxCNC’s side, it looks like the commands are being generated correctlyWhat’s confusing me is that TB3 works perfectly under the same setup, but TB2 behaves like this. At this point I’m not sure if this is something I’m misunderstanding about configuration or differential signals, or if it could be a partial hardware issue affecting only TB2.Has anyone run into something like this before? Any suggestions on what I should check next would really help.Thanks a lot

There was a problem with the limits and the estop on the input pins. I got that all figured out and now the machine is working and homing. I just now have to get it all tuned up. Thanks again for all your help.

The hardware spindle enable can never get set:

net spindle-output => hm2_7i76e.0.7i76.0.0.spinout
net spindle-enable => hm2_7i76e.0.7i76.0.0.spinena << hardware spindle enable
net spindle-ccw => hm2_7i76e.0.7i76.0.0.spindir

# ---setup spindle control signals---

net spindle-vel-cmd-rps <= spindle.0.speed-out-rps
net spindle-vel-cmd-rps-abs <= spindle.0.speed-out-rps-abs
net spindle-vel-cmd-rpm <= spindle.0.speed-out
#net spindle-vel-cmd-rpm-abs <= spindle.0.speed-out-abs
#net spindle-enable <= spindle.0.on << but the signal is not driven

One possibility is to change:
net pdnt.spindle.is-on whb.halui.spindle.is-on spindle.0.on

To
net spindle-enable whb.halui.spindle.is-on

and uncomment this line:

#net spindle-enable <= spindle.0.on