i responded to your git issue. the probe routines are correct, your issue is your machine setup. many new folks get things a bit twisted as they view motion from the perspective of the table when whats actually happening is motion relative to the spindle.

gantry machines (head moves around) DOES actually follow expect cartesian motion because the spindle is what is moving in all 3 axes. however when you have a machine where the table moves, everything is opposite to the motion of the table because the spindle is still in the x and y axis. so we are moving the work and not the spindle.

in a traditional mill where the table is what moves:

table moving rearward = Y minus
table moving forward = Y plus
table move right = X minus
table moving left = X plus

because the spindle motion relative to the work is what is moving.

Z axis is also tricky. on a knee mill it is also opposite, where the knee moves up it is Z minus

on a VMC, Head Moving up is Z plus, Head moving down is Z minu. this is because the tool is actually moving with expected cartesian coordinate system.

Hope this helps!

Here is a problem. The arms will catch the drive motor, no matter which way I rotate it. I probably have to lengthen the arms of the 'center piece' that holds the extruder. Mounting the extruder drive farther away from the nozzle is not an option. Unfortunately the filament path is not centered to the extruder.

The plan is to have multiple extruders living inside the upper part of the 3D printer, with some method of automatically swapping extruder heads. The nozzle is attached to the extruder head, the high frequency induction heater is attached to the 'center piece'.

There will be spring contacts between the motor and the 'center piece', to make the motor's and thermocouple's electrical connection.

I might use strong magnets to hold the extruder to the 'center piece'.

The linear carriage blocks will have the gearbelt sandwitched between the carriage block and the arm bracket, teeth out. The return path for the belt is between the arms. HDT5M x 20mm wide gearbelt not shown.

I bought a 4 axis ethercat stepper kit (reference) , now I need to find a use for it. Decided it will be a 3D printer that will (hopefully) do what mine already can't.

It will be enclosed and heated, build plate will also be heated. The three delta motors will be up on top outside the heated enclosure, driving the carriages up and down via gear belts.

The door will be something like polycarbonate. Two thirds of the sides will be sheet metal heavy enough so it doesn't sound like a tin can. One third of the sides will be the clear door spanning most of the distance between two corner posts.

The linear rails are 2000mm long, I might try 2pc 1000mm to make the full length.

The frame as shown is incomplete... The three corner posts are 2" steel square tube.

Yes, that makes sense. The “jump” after homing and the E87.1 you’re seeing are consistent with that temporary desync between the drive’s internal motion and LinuxCNC’s commanded position. During CiA-402 internal homing the drive is effectively moving on its own, so unless pos_cmd is kept in sync with pos_fb (or LinuxCNC is otherwise decoupled from the loop), you can get that kind of discontinuity when control is handed back. So your observation fits well with what rodw described about the need to resynchronize after homing.

On a side note (and not to derail the thread): I might eventually pick up a used EtherCAT drive/motor myself to learn and test this in practice. I saw your configuration in another post and got curious—what made you choose EtherCAT for your setup specifically? From the outside it looks powerful but also relatively costly and a bit of work to get everything “dialed in”, so I’d be interested in your reasoning.

While using probe basic I have found for outside corners probe selection.  I have to select all opposite corners except the center in the 3x3 (tic tac toe looking ) matrix.  Everything appears to be working correctly just have to invert.  I have checked all of my accesses and all seems to be fine except the probing function of probe basic. Anyone else experience this or have any thoughts?

Thank in advance,
D
 

OK that looks like exponential runaway which is an indication that the
feedback loop is backwards (positive rather than the desired negative feedback)

If the encoder feedback is in the correct direction, the fix is to change the sign
of the PWM scale value:

[JOINT_0]
TYPE = LINEAR
HOME = 0.0
FERROR = 10
MIN_FERROR = 5.0
MAX_VELOCITY = 200.0
MAX_ACCELERATION = 1250.0
P = 1
I = 0
D = 0
FF0 = 0
FF1 = 0
FF2 = 0

BIAS = -0.0105
############-0.0105 vorher Bias
DEADBAND = 0
MAX_OUTPUT = 10
ENCODER_SCALE = -4000
OUTPUT_SCALE = -10
OUTPUT_MIN_LIMIT = -10.0
OUTPUT_MAX_LIMIT = 10.0

ah yes you have a slightly older version i did notice that after an edit and resolved it already, if you are apt installed a simple sudo apt update sudo apt upgrade will install the latest fixes, no need to reinstall everything.

Any conversational subroutine, such as Turning. I enter the parameters, and when I press the Turning button, nothing happens.

I always use the screen in full-screen mode, but if you look at the image I uploaded, the bottom part is cut off. This doesn’t happen in Probe Basic Mill.

Tomorrow I’m going to uninstall and reinstall the latest version and replace the files again.

glad you got it sorted out!!

what subroutines?

for reference i just installed the latest version on my test pc clean and everything is working as expected in all of the sims. which tells me the build is good. so this is likely a configuration error. but i would want some verification in the sims from you before we discount an installation error.

as for the screen size mode, probe basic is designed to be run full screen only to take advantage of every square mm or screen space for machine use. that will not change in the main branch as that is how i use my machines in their dedicated form and how i setup PB to be used. you could modify it but that will mean you are on your own or will have to remodify things any time you run an update.

In simulation mode, the screen looks the same, the subroutines don’t work, and I honestly haven’t tried the movement with the arrow keys.

Hallo,
und danke für die Antwort, es geht langsam aber stetig, ich habe jetzt als nächstes Problem das ich nicht weiß ob die Standardkonfiguration der Firmware nach dem Laden nicht bereits alle Variablen für alle Achsen plus Ein/Ausgänge enthält.
Meine Frage dazu ist, wenn die Achsen plus E/A im NVEM bereits vorhanden sind aber in der HAL nicht definiert, ist das ein Problem? Mir fehlt noch ein wenig das Verständnis zwischen der Firmware des NVEM und der HAL.
Ich wollte als nächsten Schritt einmal die Notauskette testen, daher wäre es interessant ob es da schon etwas konfiguriertes gibt.

Gruß
Mario