Advanced Search

10x smaller is being overly kind, I'd say 20~30x rather. In desperate times comes desperate measures, hence the kernel trial in my case. So far so good, and yes particularly on the parport laser and 3ax mill I have running here.

Still recommend a try, who knows. I've seen enhancement on the ethernet based controllers too... not getting those infamous random 'unexpected delay on task 0' (whatever the reason for those is/was) anymore.

Q; what's on your mains circuit apart from the controller/motors and al? Not having a 3000watts radiator periodically switching on/off like I had a week ago(lol)? That caused me quite a bit of troubleshooting too...

It could make a difference for parport machines, while for mesa cards it the margins are smaller. The biggest problem for me is regarding the uspace thingy. If i recall correctly, some time ago, before many updates and debian version, the max jitter was 10x smaller

Quick shot in the dark, tried another kernel before thinking of going the re-install-all route? Beware - compiling takes quite a bit of time and may turned out to be a waste of time. Worth a shot anyway (I had luck with it). Others; cold'er temp and dry environment == buzzy and zappy. 

forum.linuxcnc.org/10-advanced-configura...tency?start=0#288870

UPDATE: i've run a latency test:
Max intervals:

• Servo thread: 1133566 ns
• Base thread: 191345 ns
  
  Max jitter:
  • Servo thread: 134850 ns
  • Base thread: 166345 ns

Kernel-release: 6.1.0-17-rt-amd64
Kernel-version: #1 SMP PREEMPT_RT Debian 6.1.69-1 (2023-12-30)

As per probe basic installation procedure, i've installed linuxcnc-uspace, than i found the following lines on linuxcnc.org/downloads/

“linuxcnc-uspace” is compatible with the preempt-rt realtime kernel, which is close to standard Linux. This version runs in userspace like most other applications and will run with any preempt-rt kernel.“linuxcnc-uspace” will also run on a standard Linux kernel for use as a simulator, but it should not be used to control hardware.

On kcjengr.github.io/probe_basic/quick_start.html :

sudo apt install linuxcnc-uspace linuxcnc-uspace-dev mesaflash

What i would like to avoid is to have to remake an entire disk as installing linuxcnc this way leads to terrible performance

Here are two pictures of the control panel, it's a mess, i have to tidy it up a bit, i know 

Hallo, die verkabelung scheint korrekt zu sein,
Grüße

Do you have a picture of your setup and wiring? Maybe we can directly see some emi issues. If it's finaly the problem I don't know. No matter what it is I would take care a bit of emi.

Hello everybody,
I've been experiencing the dreaded "error finishing read" for the last three days, here are the commonly requested things in this situation:

• Debian 12 Bookworm installed following the procedure listed on the probe basic website: kcjengr.github.io/probe_basic/quick_start.html
• Linuxcnc 2.9.0~pre1+git20230208.f1270d6ed7-1
• Ping to 7i76e in the 0.15/0.28 ms, CR3, CR4, CR5, CR6 count up as in normal operation
• halcmd show param *.tmax doesn't show anything, but looking at hm2_7i76e.0.read.tmax with halmeter shows values in the upper 12.000.000
• CR1 LED on after error
• Power supply output 24.5/24.7V with ripples of +- 0.1V
• Machine config @ github.com/EragonPower/LinuxCNCMachineConfiguration
• Computer: AK34 Pro w/ Intel Celeron J3455 quad core@1.5GHz 6GB LDDR4, Dual Realtek Ethernet RL8111/8168/8411
• The error happens with and without hyperthreading
• Safe boot and fast boot off
• Tryied to change ethernet cable from a standard server CAT5 to a CAT6 but nothing changed
  
  Something that i've noticed is that these error waves come more frequent in some days than others, for example a month ago it only happend once in a week, yesterday it happend a few minutes after homing, today it happend as soon as Probe basic started.
  Frankly i don't know what to do, the only thing that comes in mind is that on the 7i76e manual suggest to ground the mesa using the high-left hole near the ethernet port.
  I'll try to ground it, but i'm not so sure about it considering the EMI interference of the VFD ecc, but maybe it could resolve something as yesterday the error appared as soon as i started the spindle.
  
  It all looks like a witch hunt for me, maybe someone has a better idea. Thanks in advace to everybody that looks into this
  

Sounds much nicer. Sadly once you go over to the ethercat darkside you have to manually write your hal files wich takes me back to when there was no support in pncconf for the 7i76e (So I have mostly done my configs by hand anyway.

For spindle synchronized motion you need to set the encoder scale
to the number of encoder counts per revolution (and you need index to work)

Hey,

after I get the XYZ running in gmoccapy I am at the spindel.
The hardware is connected, see attachted. Thats not the problem I think.

- Until now I configured closely 100% with PNC-Conf. But the spindle setup can not be done in pnc conf or can it?!
- Adding manual lines in .hal and .ini means I can never change my configuration with PNC-Conf again, right?

What I have done to get the spindle turning:
In .HAL I added:
# --- DIGITAL POTENTIOMETER OUTPUT SETUP ---
setp hm2_7i76e.0.7i76.0.0.spinout-minlim [SPINDLE_0]OUTPUT_MIN_LIMIT
setp hm2_7i76e.0.7i76.0.0.spinout-maxlim [SPINDLE_0]OUTPUT_MAX_LIMIT
setp hm2_7i76e.0.7i76.0.0.spinout-scalemax [SPINDLE_0]OUTPUT_SCALE

net spindle-vel-cmd-rpm-abs <= spindle.0.speed-out-abs => hm2_7i76e.0.7i76.0.0.spinout
net spindle-ccw <= spindle.0.reverse => hm2_7i76e.0.7i76.0.0.spindir
net spindle-enable <= spindle.0.on => hm2_7i76e.0.7i76.0.0.spinena


In .INI I added the last 3 vars:
[SPINDLE_0]
P = 0
I = 0
D = 0
FF0 = 1
FF1 = 0
FF2 = 0
BIAS = 0
DEADBAND = 0
MAX_OUTPUT = 2000
OUTPUT_MIN_LIMIT = 0
OUTPUT_MAX_LIMIT = 10000
OUTPUT_SCALE = 10000

At this point I can switch on the spindle and set the speed. My spindle has max 10k RPM so 1:1 to the GUI displayed value.

- How can I connect my encoder (spindle speed feedback) to the GUI and set the spindle is at speed window in accordance to this feedback?
The encoder feedback is working in the HALshow. Just A and B Encoder is ok. Index Signal is not wokring. The calculated velocity speed is about factor 66 to 69 (Could the factor be 2/3? I have resolver feedback in the motor. No discrete encoder). That means the velocity = 66 * real speed of motor.

- In the GUI there is a fixed value (6.000) in the grey bar below spindle control. I think this is the feedback value, right? Here I will need my 10.000 RPM. The red LEP will change to Green, when the spindle is "at Speed" / "in defined window" , correct?

- Just for understanding: When I will try to do synchronized tapping / threading then the Z Axis will be feeded in the spindle speed by the encoder feedback, correct?!

Have a nice weekend

Hi,

I read a lot of this issue so sorry for opening another topic but i don´t get it working.

- Using a mesa 7i76e
- Error occurs after 30 minutes to about 2 hours runtime.
- I allready disabled the CPU power safe options (i read in other topics here), see attached
- I allready increased the servo thread time to 2 ms - same issue
- My Ethernetcard is an Intel I219-LM
- CPU is i5 6500T
- Kernel version PREEMPT_RT Debian 6.1.55-1 (2023-09-23)

What I read in some other threads is that I have to disable something in IRQ coalsion Setting for an Intel network card. But I have absolutely no idea how I should do this? This seems to be the only thing I do not did for now. Can somebody introduce me step by step?

BR
Jannik

I wouldn't bother using the HY VFD's functions.

You can use LCNC's timing function(s) to let the pump run for a set period of time after the spindle is stopped.  My spindle fan is set in HAL to turn on after 30 seconds of operation and stay on 2 minutes after the spindle is shut down.  The 30 seconds is to stop the fan coming on during quickie testing or if it's just orienting for a tool change.

Have a look at timedelay.comp in the manual.  You can connect spindle.N.on (see motion comp) to timedelay.N.in and timedelay.N.out to the water pump.

On my water cooled spindle I have it setup when I power the system on the coolant for the spindle starts to flow. I did it this way so after a long run the pump will keep the water flowing so it can keep cool after the run is done and it will cool down a lot faster. 

Hallo,
ich bin gerade dabei meine Fräse auf Closed Loop Stepper umzurüsten und bin auf ein Problem gestossen.
Hier die Daten zur Maschine:
LinuxCNC Version 2.8.4
gmoccapy 3.1.3.8
Mesa7i76e
Ich möchte nun die Alarm Ausgänge der Steppertreiber (RTTAM Motor HSS60) nutzen und im Fehlerfall eines Treibers die ganze Maschine bzw. die Treiber abschalten. Ich habe das über Funktion joint.N.amp-fault-in. Leider haben diese Treiber die Eigenheit, dass beim Einschalten der Alarmausgang kurz aktiv ist und daher die Treiber wieder abschaltet werden (habe das aktuell über die Stromversorgung der Treiber gelöst).  Ich habe andere Treiber getestet. Die haben das Problem nicht. Leider passen diese aber nicht zu den Stepper die zum Einsatz kommen.

Meine Idee, ist nun, beim Einschalten der Maschine bzw. der Treiber einen Delay für die Abfrage der Eingänge zu haben. Leider lief meine Suche nach einer Software Lösung bis jetzt ins Leere. Hat jemand eine Idee? Falls das nicht über die Stromversorgung der Treiber funktioniert, kann ich die Funktion joint.N.amp-enable-out für die Deaktivierung der Treiber im Fehlerfall nutzen? Wie würde ich die mit dem estop verknüpfen?
Für die Spindel und den Notaustaster habe ich den estop so gelöst:

net estop-fu => logic.0.in-00 # Mesa Input 20 (Alarm FU) -> logic.0.in-00
#net motor-alarm-z => logic.0.in-01 # Mesa Input 31 (Alarm Z) -> logic.0.in-01
net estop-switch => logic.0.in-01 # Mesa Input 21 (Not aus Schalter) -> logic.0.in-02
net estop-ext <= logic.0.and # IO, sobald ein Eingang (Nothalt oder Z/FU Alarm) auf low ist.
net estop-out <= iocontrol.0.user-enable-out net estop-ext => iocontrol.0.emc-enable-in

Wäre es besser, die Spindelnotabschaltung und den Notaustaster auch über die joint Funktionen zu lösen?

Danke für eure Hilfe.

Norbert