Advanced Search

In the end I managed to fix it. HALShow was really helpful, and using a small oscilloscope made it easy to see exactly where the signal chain was stopping.
I’ll leave the relevant HAL and INI sections below in case anyone else needs them.

HAL Part
# ---setup spindle control signals---
setp hm2_[MESA](BOARD).0.pwmgen.pwm_frequency [SPINDLE_0](PWM_FREQUENCY)
setp hm2_[MESA](BOARD).0.pwmgen.00.scale [SPINDLE_0](SCALE)

net spindle-enable spindle.0.forward => hm2_[MESA](BOARD).0.pwmgen.00.enable
net spindle-speed-cmd spindle.0.speed-out => hm2_[MESA](BOARD).0.pwmgen.00.value
net spindle-enable => hm2_7i95.0.ssr.00.out-01

INI Part
[SPINDLE_0]
PWM_FREQUENCY = 2000
P = 0.0
I = 0.0
D = 0.0
FF0 = 1.0
FF1 = 0.0
FF2 = 0.0
BIAS = 0.0
DEADBAND = 0.0
SCALE = 24000
MIN_RPM = 3000

Thanks everyone for the help!

Uii, 60 steps, wo hast du denn den her
Mal davpn abgesehen, ich frei mich immer über bilder eurer konstuktionen.

So, hmm, jaaa, deine rechnung passt, allerdings befürschte ich das LinuxCNC, bzw der PID regler da einfach keinen spielraum hat um irgendwas zu regeln.
Ich werde das morgen mal am simulator ausprobieren.

Kannst amber mal versuchen den Min-Ferror auf z.b. 1.0 zu setzen und den P-Wert vom PID auf 25 oder so, um zu sehen ob es besser wird.
Vielleicht auch mal beim PID die deadband auf 1 setzen.

Aber wo bitte bekommt man einen stepper mit 60 steps auflösung her
kannst du nicht am treiber die microsteps höher stellen ?

Hi everyone,
I’m configuring LinuxCNC with a Mesa 7i95T and I’d like to ask for a quick sanity-check of my .hal and .ini files, I'm new to the subject so just to make sure I didn’t do anything stupid before I move forward.Quick context: with the 7i95T there isn’t a full “wizard” configurator. I generated a base config with PnCconf, then had to manually edit a bunch of things (I/O mapping, firmware for PWM, encoder/MPG, etc.). The machine now works, but I’d really like a second pair of eyes on:

• Mesa pin mapping ↔ LinuxCNC signals (inputs/outputs, enables, polarity)
• thread setup / addf order (servo-thread, base-thread if used)
• common HAL mistakes: duplicated nets, non-existing pins, unconnected signals, wrong inversions
• INI mistakes: JOINT/AXIS settings, limits, SCALE, stepgen/encoder params, homing sequence, etc.

I’m attaching the following:

• machine.ini
• machine.hal
• if needed, I can also post all the other HAL files like postgui.hal etc

If someone can spend a couple minutes to point out anything that looks wrong or risky, I’d really appreciate it.Thanks!

Also note that there is no /etc/apt/sources.list.d/debian.sources in my Debian 13 after doing a full upgrade.

JT

Thllll wrote:

I am unable to reproduce the error on the sim because I needed to trigger the probe while it was going to home or the starting location to start probing. This would cause a G38.2 error then the lockout would start. I ran a debug and returned a [Error] from a specific routine. I should have grabbed a screenshot.. I noticed a difference in the sim subroutines folder vs the subroutines folder I got from the github. I replaced all the files and lockout is no longer accruing

If you by chance find the offending routine again, please let me know!

I assume the issue for the probe triggering while going to home or to the starting position was for tool setting?  or was this for a custom 3d touch probe subroutine you created?  I would like to try and find where the issue was coming from to make sure it gets corrected and doesn't re-appear in future edits.

Thanks!

Chris

nice! I think the more uniform future solution will be the suite of var file widgets i have been testing, but this will work for now and is similar to how i store, save and update var file parameters. its just a pain in the butt to have to custom code things in like that.

the new var widgets will handle all of the heavy lifting for saving, storing, loading, updating etc. so all you would need to do is drop the desired widget in your ui and assign it a variable number and it will just work as expected from that point forward. I also have made some changes so that the precision will not be lost when storing/loading between the var file and the qt interface where previously after a store/save occurred the values were getting truncated at the displayed decimal place formatting. the new widgets will have an option to check for high precision storage so that the full value untruncated is retained even with a truncated display. should make things more robust!

Lieber Oliver,

ich benoetige noch einmal Deine Aufmerksamkeit. Mir will es nicht so recht gelingen eine vernuenftige Geschwindigkeit und Schritteweite einzustellen.
Ich habe Schrittmotoren welche im Fullstep Mode 60 Schritte fuer eine Umdrehung benoetigen. Eine Undrehung erzeugt einen Vorschub von 5 mm. Wenn ich eine maximale Geschwindigkeit von 5mm/sec einstellen moechte, welche Paramater sind fuer die Stepdir Konfiguration zu setzen? Ich dachte Scale bekommt einen Wert von 12 (60Steps/5mm) = 12 Steps/mm, und MaxVelocity 5(mm/s) - Aber so richtig will es nicht gelingen, der Motor flattert nur...
Ich danke Dir, liebe Gruesse,
Robert

a

were you reloading the table after saving it? this is what removes any previous offset that may be in cached memory even after storage location has changed i think.

rodw wrote:

Debian trixie uses the new deb822 format so sources.list is no longer used.
Instead  look in /etc/apt/sources.list.d/debian.sources for the sources in the new format
 

I added the mesact repository in debian 13 to synaptic package manager and it put it in sources.list... so it must still work.

JT

ok great!

I would not use stable in the repositories because the os can change next time debian is released. Better to use trixie... to bad debian doesn't do something sensible like using numbers.

JT

Yes, the EL5151 provides integer counts, which get converted to float by the LinuxCNC EtherCAT driver.
So with the misconception of floats having only 32bit being resolved, everything makes sense now.

Hello,

I am currently also in the process of setting up an AX5112 servo drive. Unfortunately, there does not seem to be any newer firmware available for my device that would allow me to use Drive Manager 2, so I have to stick with Drive Manager Classic.

My problem is that I cannot see the Drive Manager at all in the tabs of the drive/motor configuration. At the moment I am only supplying the drive with 24 V so that I can familiarize myself with it.

Does anyone have an idea what could be wrong here? I can hardly find any documentation on how to use Drive Manager Classic in TwinCAT 3. The Drive Manager Classic itself is installed via the package manager.

A friend of mine helped me and adjusted the source.list accordingly. Now the Mesa Configuration Tool works.