Thanks, but the USB stick was really broken and it blocks any PC it's plugged into. I'm using the handwheel to modify it with an ESP32.

I have the variator now basically working.

To the 3 problems I laid out a few days ago:

1: The problem was really at 2 points. For one, the line
setp [HMOT](CARD0).pwmgen.05.
offset-mode should have been 1 and was 0, and on top the VFD was set slightly wrong. Using open-loop FOC now, the tuning went much better.

2: The divide-by-0 issue is still somewhat there, but giving both ".in" pins a starting value greater than 0 makes it so it still throws an error at startup but works as expected thereafter.

3: It seems that I cannot manipulate the error term directly, but what works is to take commanded and feedback, calculate the error, and scale that error. With that, I can “reassemble” a feedback that leads the PID component to get the error I want it to.

With all that, I am able to have stable control over the whole RPM range of about 65 RPM to 3000 RPM.

The variator control still has to be improved, but the principle seems absolutely workable.

I figured out the problem. The spindle at speed wasn't going true for the clockwise direction of the spindle causing the code to hang.

I have been experimenting with planner type 1 for a while now with 3-axis milling machine. Generally it seems to work but I'm having problems with g33.1. What is the current state with tp1, should it work when running g33.1? Right now I get error "ruckig_plan_position: invalid limits (v=0.000000, a=3000.000000, j=120000.000000)" at every spindle revolution. In ini file I have nonzero traj(default_linear_velocity, max_linear_velocity), axis' and joints(max_velocity).

EDIT: did more testing. Slowed down spindle speed, looks like the error appears all the time and not only once in revolution. The z-axis velocity seems to be bouncing between 0 to something when the control tries to keep the axis synced, and the tp1 planning breaks every time the speed goes past zero. The other (bigger) problem is when g33.1 is on the bottom and spindle rotation changes, joint2 following error appears.

I solved this temporarily by adding a hal pin to tp which sets true when spindle synchronized motion is on and used that to live change to tp0. With that rigid tapping works just fine although the same z-axis velocity bouncing is present.
 

The instructions to install ethercat are here:
forum.linuxcnc.org/ethercat/45336-etherc...-how-to-step-by-step

We use an xml file to define PDOs and map to linuxcnc pins but its nothing like twincat stuff.

I've been working on a custom ISO that installs ethercat and tunes the kernel but its slow going.

grandixximo wrote:

With ec_igb or ec_igc native driver: interrupt moderation is irrelevant, they use polling not interrupt.
With ec_generic: interrupt moderation is active and you should disable it with

ethtool -C <iface> adaptive-rx off rx-usecs 0 tx-usecs 0

probably as soon as possible on boot, before ethercat starts.
To know which drive you are using, check your erhercat.conf file

You can use a udev rule to do this. we use one for ethercat to use as an example. You might be able to extend the ethercat script  to add ethtool commands for: 
<iface> gro off lro off tso off
-set-eee <iface> eee off
 

Could you please provide the error logs?

ah thanks I uncommented that out. No change to the behavior though.
 

pid.s.index-enable is still commented out in the last file you attached.

ich arbeite aktuell mit einem externen Touchscreen-Monitor, der an ein Ubuntu-System angeschlossen ist. Es handelt sich dabei um ein Setup, das eher für industrielle Anwendungen gedacht ist (ähnlich wie ein Panel PC / Kiosk-System).

Das Problem ist, dass der Touch zwar erkannt wird, aber die Eingabe nicht ganz präzise ist bzw. teilweise verzögert reagiert. Ich habe bereits versucht, einige Einstellungen zu prüfen, aber bisher ohne Erfolg.

Hat jemand Erfahrung mit der Kalibrierung von Touchscreens unter Ubuntu oder kennt mögliche Lösungen (Treiber, Tools etc.)?

Ich habe auch einige industrielle Touchscreen-Lösungen gesehen, die speziell für solche Anwendungsfälle optimiert sind, z. B. hier:
baobaotechnology.com/our-products/touchscreen-computers/

Vielleicht hat jemand ähnliche Hardware im Einsatz und kann Tipps geben.

Vielen Dank im Voraus!

Okay, I cleaned it up and made sure a signal spindle-index-enable was connected. We still get to the G33.1 line and it sits there and doesnt move in the z axis.

Sorry, let me clean that up a bit.
 

I'm currently working on the Probe_basic version. In the Handrad.hal and probe_basic_postgui.hal files, there are two lines that are causing problems. I’ll just copy the relevant parts here:

handrad.hal
net pdnt.program.is-idle whb.halui.program.is-idle halui.program.is-idle
net pdnt.program.is-paused whb.halui.program.is-paused halui.program.is-paused

and

postgui
#net prog-running not.0.in <= halui.program.is-idle
#net prog-paused halui.program.is-paused => time.0.pause
net cycle-timer time.0.start <= not.0.out
net cycle-seconds qtpyvcp.timerseconds.in <= time.0.seconds
net cycle-minutes qtpyvcp.timerminutes.in <= time.0.minutes
net cycle-hours qtpyvcp.timerhours.in <= time.0.hours
# *** Time items required for Probe Basic to run ***

As far as I understand, program.is-idle starts and “resets” a timer, and program.is-paused pauses the timer. 

I _will_ try to do the feedbback test again as I think I only connected the stepgen fb to joint fb, not pid fb aswell.

The drive is at 10000 PPR and around 1.45:1 spindle:motor overdrive, from my calculations 6k rpm spindle speed is around the limit. there is a 2500 step/10k line encoder on the spindle itself I use for feedback.

I am looking through the HAL again and wondering maybe I DO have the scaling wrong? Though the positions and speeds report correct, maybe the scales are backwards, the end math turns out correct, but calculations midway are off? I'm trying to think of anything now, really.

• -ENCODER_SCALE is 10000
• -Spindle SCALE is 114.83 (10000/1.45/60) (not sure why it needs to be divided by 60 though? I assume because RPS instead of RPM, but I thought this value should not be bound by time, only steps/rev? I'm not sure...
• -JOINT_2 (C axis in my case) SCALE is 19.07 (10000/1.45/360). I turned on the scale switching in M102/103, not sure how you get it to work without that?

What makes me think that I have something off is the scaling by 360 of the enc-pos signal in the HAL. As in I have 10000 lines per rev, so multiplying it by 360 instead of dividing makes no sense to me the way I have it now. 

Yeah that’s the one