Advanced Search

IB_CnC wrote:

Printer is churning them out at the moment, should be able to test if it works over the weekend.

Printer? As in 3D printer?

Current status.
 

Going to try to get it going with some Optical sensors.
One of the pockets has a double flag to include the homing, all other pockets only 1 flag to detect the index position.

Printer is churning them out at the moment, should be able to test if it works over the weekend.

 

Just wait a second after the motor starts before reading RPM from encoder.

This would not work with rigid tapping (the OP's question)

Edited original post
But it happens in any subroutine, in simple nor complex.
It can be like this -

G91                                ; relative
G38.2 Z-164 F1000                ; quick find

---

HERE IT STOP

---

G1 Z3.0 F10000                    ; retreat by 3mm
G1 Z-2.0 F10000                    ; move toward 2mm
G38.2 Z-1 F5                    ; slow find
G1 Z1 F10000          

If I change G1 to G0, it never stops. But that not possible everywhere.

I have the same issue. Sometimes (every other day) I start a probing routine. It probes the first touch, hangs(seemingly), then I need to press 'stop' and start again. Then it works. I've always thought that it was my probe that was a bit iffy.

Is there a way to have a higher degree of logging than starting linuxcnc from the terminal. Would be interesting to see what the last command is that dosent complete, if any.

might be a good idea to attach the subroutine in question.

Found the STATUS and values for the widgets, thanks.
But how can I add the previous encoder value? I tried adding a variable and assigning the encoder value to it so that I can compare them before calling the function. But it seems that I have not figured out where exactly this variable can be written. The “init_pins” function seems to be called only once at startup. And the “_on_counts_value_changed” function is triggered only when the encoder value changes and it can be passed only the current value. Or do I think wrong and there is another way?

Hello.

Finally, my head blown up after a years of this problem.
Linux Wheezy 2.7,  2.8,  and the latest 2.9 (debian?) - problem still persist on several machines, several years, all versions.

Remaped M300 code to call o-subroutine (remaped in *.ini). For example, Z-touching. Soubroutine started, performing all commands, but just after touch plate (making contact), program stops with nothing. Respectively pause, but without "pausing". Just stop, do nothing, still pretending working. Need to press ESC and call routine again.
After a several testing, I am figured out that it always stop at first command for G1 move (G1 Z5 F1000, for example, no matter distance or absolute/relative or speed). A little anoying in Z-probing, just run it again, but very anoying with ATC - stopping during tool change. If I change command to G0, it work, but its not always possible to use G0, toolchange for example. Always at first G1 command in subroutine.

There is a days it not happens, but there is also days it happen all times. Absolutely random. No matter program running before or during or after, and never happen twice in a row. No matter computer, old or new. No matter version.
My head finaly blown up.

Need to figure it out. Stopping randomly during tool change is not a good option of ATC.
Thank you.

Ps.: Oh - never happen when calling M300 via button on pendant. Weird, ya?


Z-touch subroutine -

(ztouch.ngc)
o<ztouch> sub

#<vyska_osy_Z> = 191.000
#<vyska_senzoru> = 65.000
#<rozdil_vysek> = 126.000

M66E0L0                            ; prepocitani/aktualizace
M70                                ; ulozit soucasny modal state, obnovi se na konci
G90                                ; absolutni souradnice, kdyby nahodou byla zapla relativni
G53 G0 Z0                        ; vyjed uplne nahoru
G59.3                            ; prepnout souradnicovy system
G49                                ; zrusit kompenzace delky nastroje
G40                                ; zrusit kompenzace radiusu nastroje
G92.2                             ; docasne vypnout kompenzace G92/G52
G10 L20 P0 Z0                    ; nastavit soucasnou polohu jako nula
G91                                ; relativni souradnice
G38.2 Z-164 F1000                ; rychle najdi Ztouch s nastrojem
G4 P0.1                            ; momentik

---

HERE IT STOP

---

G1 Z3.0 F10000                    ; kousek se vratit o 3mm
G4 P0.1                            ; momentik pockat, aby opravdu dojel o 4mm vys
G1 Z-2.0 F10000                    ; zase priblizit k senzoru o 2mm
G38.2 Z-1 F5                    ; pomalicku se dotknout
G1 Z1 F10000                    ; odtahnout 1mm (vypnout senzor)

;#<z_work_offset> = [#[#5203 + #5220 * 20] + #5213 * #5210]    ; uplne presne nevim co to pocita, vytazeno z wiki
G10 L1 P#5400 Z#5063            ; nastavit vypoctenou delku nastroje do tabulky nastroju
G43                                ; znovunacist delku nastroje a zapnout kompenzaci

G90                                ; absolutni souradnice
G53 G0 Z0                        ; vyjed nahoru
G92.3                            ; obnovit kompenzace
M72                                ; obnovit modal state pred sondovanim




o<ztouch> endsub
 

Well it seems that pathpilot under non-tormach machines is all but ancient history. I can understand why. PP is so over complicated that it is extremely difficult to decode the software and modify it. I got it somewhat adapted to my bridgeport but not completed.

Meanwhile...... NativeCam has now been adapted to the newest versions of linuxcnc and I have that working. The main desirable feature of PP was its conversational BUT NativeCAM is actually far superior.

I used NativeCam for years but couldn't update linuxcnc because NativeCam wasn't compatible after LCNC went to Python3. All that is fixed now.

I'll fix that when I return Sunday.

JT

Hi Pcw,

One last question, if you run the scurve simulation config :  axis_scurve_mm.ini   using the startup menu.
Run's this ok for you?

Chef_2 wrote:

Uhi, das ist ja süß... all in one.

Ja viel können muss das nicht... Es handelt sich um eine Drehmaschine...
 

Willkommen im Forum,

die Aussage finde ich viel zu allgemein, es kommt auf die Drehmaschine an, wie diese ausgestattet ist.
Meine hat zB. nen Werkzeugrevolver mit Überwachung der Position, Glasmaßstäbe in X und Z,
programmierbarer Reitstock/Pinole, Spindelencoder, Bedienpanel, Minimalmengenschmierung.
Weiter geplant, Taster zum automatischen Vermessen der Werkzeuge.
Du siehst, da kommen eine Menge IOs zusammen, "nur" für eine Drehmaschine 

Hier gibt es sehr viele hilfsbereite und schlaue Menschen, man muss nur ordentlich Fragen.


Gruß
Olli
 

Have a look at the Rtelligent ECT42 www.rtelligentglobal.com/fieldbus-closed...-ect-series-product/
The motor needs to be a standard stepper motor with two coils.
This drive expects a very common quadrature signal A and B.
The encoder interface needs to be checked so they matches.

In general terms that's how one does it - use a drive that connects to EtherCAT.
Not very common, although the solution exists, to use a separate EtherCAT device
to generate step motor pulses and take encoder input and connect that to a stepper motor drive.
When you go with EtherCAT, use EtherCAT stepper motor drives.

My spindle has an encoder on and at the moment, regardless of what gear I am in, it will always run at the selected RPM. I tested this, I selected the low gear ratio manually and ran S1000 M3 and it ran 1000RPM. I then did a M5, set the gear to high ratio manually, set S1000 M3 and the spindle ran at 1000RPM.

Unfortunately there is no clutch on the gearbox so I wont be able to change gears while running.

I basically just need a way to change gears automatically when a spindle speed command is given. When a S command is given, the spindle should first stop if it is running, then change to the appropriate gear based on the S command given, then start and run at the commanded speed. If possible, I would like the spindle to stop, then run at a very low rpm , then change gears if needed, then run at the given rpm.

Is there any way to implement this ?