Advanced Search

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 ?

Best way to get code changes for specific hardware into master would be to create a pull request with the description of the issue and the proposed (and tested) changes.
github.com/LinuxCNC/linuxcnc

@max68

No double posting please.

That's the current status. A few startup errors have gone away, but I think I need to change the entire pin assignment now. Are there any other serious errors you see besides the pin assignments?

   

exactly right. all my logic changed to base-thread.. and the spindle rotation works as expected. spindle speed mode or c-axis mode.

thank you PCW
best regards

I would think Logic should be possible with stepgen signals if
you addf the logic components to the base thread instead of the servo thread.

I tried using two modes on the lathe spindle.

I want to be able to change the spindle speed mode to c-axis mode which can be changed by entering Mcode

Here is an example of my code:

#######################

net caxis-cc-step <= stepgen.2.up
net caxis-ccw-step <= stepgen.2.down

net mode-caxis => and2.10.in0 => and2.11.in0
net caxis-cc-step => and2.10.in1
net caxis-ccw-step => and2.11.in1
net caxis-cc-out and2.10.out => or2.6.in0
net caxis-ccw-out and2.11.out => or2.7.in0



net spindle-cw-step <= stepgen.4.up
net spindle-ccw-step <= stepgen.4.down

net mode-spindle => and2.12.in0 => and2.13.in0
net spindle-cw-step => and2.12.in1
net spindle-ccw-step => and2.13.in1
net sp-cc-out and2.12.out => or2.6.in1
net sp-ccw-out and2.13.out => or2.7.in1

net servo-cc or2.6.out => parport.0.pin-08-out
net servo-ccw or2.7.out => parport.0.pin-09-out

#######################

M198 code:
#!/bin/bash
halcmd sets mode-caxis True
halcmd sets mode-spindle False
exit 0


M199 code:
#!/bin/bash
halcmd sets mode-caxis False
halcmd sets mode-spindle True
exit 0

#######################

I have tried all the codes above. M-code works well, it can change the spindle mode to c-axis or c-axis to spindle mode. but the resulting signal is not perfect.

I assume that the stepgen signal cannot use and2 or or2 logic, so that the stepping signal is damaged?