Advanced Search

Ich habe das jetzt mal so probiert wie Talla83 das gemacht und @CHEROKEE-Laredo auf Seite 1 vorgeschlagen hat, allerdings in stark gekürzter Version, erstmal ohne irgendwelche Kontrollsignale und ohne T0, denn T0 habe ich am Werkzeugrevolver nicht.
In meiner Konfiguration wird auch die Pneumatik nicht geschaltet, weil ich das nicht hinbekomme, im Beispiel werden mit GPIOs die Signale ausgegeben, ich habe aber nur OUTPUTs (7i92TM+7i76+7i85) und so einiges damit versucht, aber es klappt nicht.
Mit der jetzigen Konfiguration und dem Aufruf in MDI von zB. "T1 M6" passiert nichts bzw. der Pfeil von "Aktuelle Datei ausführen" oben in der Leiste bleibt gedrückt. Unten steht auch weiterhin, Kein Werkzeug.

 

Die "toolchange.ngc" sieht so aus:

o<toolchange> sub
#4001=45
M61 Q#4999
o500 if[#<_current_tool> EQ #<_selected_tool>]
    (DEBUG,Tool bereits in Spindel)
o500 elseif [#<_current_tool> NE #<_selected_tool>]
    G0 W[#<_selected_tool> * #4001-#4001]
    M6 G43
    #4999=#5400
o500 endif
o<toolchange> endsub
m2

In der INI-Datei steht:

REMAP= M6 modalgroup=6 ngc=toolchange

In der "linuxcnc.var" wurde der Parameter #4999 eingefügt.

Wenn ich in MDI zB. "G0 W45" ausführe, dann dreht sich der Stepper, das funktioniert problemlos.

Um das Pneumatikventil zu schalten habe ich das hier gemacht:

"revolver_klemmen.ngc"

o<revolver_klemmen> sub
M65 P0            (Ausgang setzen Revolver klemmen)
o<revolver_klemmen> endsub
m2


"revolver_loesen.ngc"

o<revolver_loesen> sub
M64 P0                         (Ausgang setzen Revolver loesen)
o<revolver_loesen> endsub
m2

und in der "custom_postgui.hal":

# --- Werkzeug-Revolver loesen-spannen ---
setp hm2_7i92.0.7i76.0.0.output-00 true
net   wkz-rev-pneumatik  hm2_7i92.0.7i76.0.0.output-00  <= motion.digital-out-00

Warum funktioniert überhaupt nichts davon, wo liegen die Fehler?

Danke und Gruß
Olli

(every thread cycle; 25us by default?)

Depends on your Servo Thread, usually 1ms for a Mesa setup.

Over travel in G38.x does not influence the stored position, it would be fairly useless if it did:

After successful probing, parameters 5061 to 5069 will be set to the coordinates of X, Y, Z, A, B, C, U, V, W of the location of the controlled point at the time the probe changed state.

linuxcnc.org/docs/html/gcode/g-code.html#gcode:g38

Correct statement. The spindle requires indexing at 0deg before the probe tool be mounted and meas takes place. And ofc only effective in the angles the calibration is prog to be within. Best 'workaround' I found to address this delay/overtravel issue. Yet.

I don't know if the overtravel I'm observing is actually an issue, that's why I asked in the first place. If someone can confirm that the order of operations performed by LinuxCNC is as I understand them to be, it should not be an issue after all.

What I expect LinuxCNC to do:
- Check motion.probe-input as fast as possible (every thread cycle; 25us by default?)
- When the pin changes state, store the current position into #5061/etc.
- On the same cycle start decelerating.
- When the machine stops, finish G38.2 command and move on to the next command in the program.

Can you or somebody else confirm whether this is correct or wrong?

If it's correct, overtravel while decelerating should not be an issue, as far as I can tell, because the position I'm interested in is already recorded at the correct timestep.

Btw, are you Mecanix from cnczone forums? I found the thread about your probe and I was wondering if you ever measured its pretravel variation similar to how ZincBoy described in an old thread .

Does anyone have coreldraw and could draw me a small cdr testfile ?
without copyright ?
to include it in my git

just a few circles, lines and curves

Tanks,
Olli

forum.linuxcnc.org/9-installing-linuxcnc...ebian?start=0#305349

jdryg wrote:

Correct statement. The spindle requires indexing at 0deg before the probe tool be mounted and meas takes place. And ofc only effective in the angles the calibration is prog to be within. Best 'workaround' I found to address this delay/overtravel issue. Yet. 

You are 100% correct though. The Lcnc control could see improvement on the probing code (I recommend). I also run a 828 and 808 (sinumerik) and both sends the control into estop-like when the probe triggers, then reset. Not sure how that's done, slightly brutal on the mechanical but nonetheless there is zero overtravel. Saying estop-like here it could also well be disabling/enabling the drives too. 

Please update us on your progress. Subscribed, and thanks for raising this issue. 

Right. thanks.
done: github.com/kcjengr/probe_basic/issues/119

Out of curiosity: do you manage to have actual synchronization of remote shares on Linux file explorer without manually refreshing (either by F5 or going up a folder and down)?
Or is it just something that's not a thing?

You can change between 'Scarakins' and 'Identity' kinematics using the GUI button in the right panel or gcode commands 'M428' and 'M429'.

Hi Aciera,
If I change from "world mode" to "joint mode", the button "enter auto mode to run programs" is inactive.
How can I enter auto mode and run joint mode ?.
Thank you.

Maybe this could be of interest:


github.com/scottalford75/LinuxCNC-3D-Pri.../master/compensation

from version 2.9 on you can switch between cartesian mode (which you are using) and joint mode. There are no singularities in joint mode, so you may want to have a look at that.

Maybe I am not understanding the question, but after triggering the probe
the joint must obey the ini file set acceleration bounds when coming to a stop
and reversing. This could easily be many mS.

You are absolutely right. For some reason I totally forgot about deceleration. Probably because the probing speed I'm using is too low (50mm/min). I'll have to check my ini settings and try to calculate the total distance required for stopping after the probe triggers.

So, if this is the reason I'm observing this behavior, I should expect the probed position (#5061/etc) to correspond to the timestep when motion.probe-input was triggered, right? So, the maximum expected error to the probed position from LinuxCNC itself should be the distance the probe travels in 25us interval between motion.probe-input checks. Am I right?

Although not a fix (all systems has some sort of delays/accel/decel/ect), the workaround is to use a probe calibration routine. Easier to offset those cal values from the measurement than to real-time the system (imho).

Currently, I'm trying to see how good the probe/circuit is without calibration. As far as I understand, calibration can only really help if the probe behaves equally well from all approach angles (i.e. pretravel variation is small). If the probe always triggers at the exact same position when approaching the object from a specific angle (i.e. unidirectional repeatability is 0 independent of probe orientation) but the pretravel variation is too large (e.g. 100um) how can calibration help in this case? It might only help if I can guarantee that the probe is always inserted into the spindle in the exact same orientation, which unfortunately I cannot.FWIW, my test setup is a 63mm OD ball bearing. I'm probing the center using Probe Basic's routines and then run a custom routine to probe the outside of the bearing every 10deg 10 times.
 

Fwiw my calibration routine was inspired by github.com/hausen8/EasyProbe

You'll probably need to complete the missing Z calibration, however the X & Y are completed and functional. Have a look. And let us know how you're doing!

Thanks for the link. I'll take a look to see if I can find something different compared to Probe Basic's calibration routine.

Hi Arciera,

So if I understand you correctly you are planning on approximating the 3d clothoid fillets with the G5 spline gcode?
For what i have seen, is that a spline is a shorter, cq sharper curve between 2 points than a clothoid.
I have been thinking if we could change spline characteristics to approx a clothoid, but i don't know for now.
And we can use the spline  to solve the 3d clothoid fillets. like a helix to line fillet, or helix to arc fillet etc. All the fillets that
are out of plane we can use the spline for now. If we have the 3d clodhoid algo available, we just change the algoritme to use a 3d clothoid.

You extended the G5 2d cubic spline to 3d?
I used a 3d spline 3-degree. It's a standard spline curve available in opencascade library.
For motion a 5-degree or a quintic spline is maybe better, but we have to find out when we are going to do the look ahead.
Then calculating speeds become's essential.

Left to do is create the interpolation function for a helix.
Then i will do the path blending function.

At this moment, we have played along with tooldir blending, we could see if the result was valid in our graphics output.
This all is done in c++. This c++ code is runned from userland. Now the nice thing is, the kernel module uses
excact the same c++ functions. There is no code duplication or translation to c needed. Therefore the kernel
also opens the gcode file, read's it, parses it, loads data into memory etc. (In lcnc the gcode data is streamed from userland to kernel, in hal-core, kernel loads gcode itself.)
In userland, we only need the graphics, the rest of the memory is released, in the kernel we don't need the graphics,
there the graphics memory is released, so the program turns out to be memory efficient at runtime.

 

my1987toyota wrote:

United States Postal Service wanted people to pay just to send an email
because they felt that email would destroy there revenue stream because they wouldn't be selling the amount of stamps
they used to.

Well they were not wrong!