Оновлення LinuxCNC

Тепер ваш комп’ютер знає, де взяти нову версію програмного забезпечення, далі нам потрібно її встановити.

Процес знову ж таки відрізняється залежно від вашої платформи.

Якщо ви просто запускаєте звичайний G-код і не знаєте, що таке підключаємий інтерпретатор, то цей розділ вас не стосується.

Рідко використовуваною функцією LinuxCNC є підтримка підключаємих інтерпретаторів, якими керує недокументований INI-файл [TASK]INTERPRETER.

Версії LinuxCNC до версії 2.9.0 обробляли неправильне налаштування [TASK]INTERPRETER, автоматично повертаючись до використання інтерпретатора G-коду за замовчуванням.

Починаючи з версії 2.9.0, неправильне значення [TASK]INTERPRETER призведе до відмови LinuxCNC запускатися. Виправте цю ситуацію, видаливши налаштування [TASK]INTERPRETER з вашого INI-файлу, щоб LinuxCNC використовував інтерпретатор G-коду за замовчуванням.

Якщо ви просто запускаєте звичайний G-код і не використовуєте підключаємий інтерпретатор canterp, то цей розділ вас не стосується.

У надзвичайно малоймовірному випадку, якщо ви використовуєте canterp, майте на увазі, що модуль переміщено з /usr/lib/libcanterp.so до /usr/lib/linuxcnc/canterp.so, і налаштування [TASK]INTERPRETER відповідно потрібно змінити з libcanterp.so на canterp.so.

Тепер можна додавати налаштування до розділу [SPINDLE] INI-файлу.

MAX_FORWARD_VELOCITY = 20000 Максимальна швидкість шпинделя (в об/хв)

MIN_FORWARD_VELOCITY = 3000 Мінімальна швидкість шпинделя (в об/хв)

MAX_REVERSE_VELOCITY = 20000 Якщо цей параметр пропустити, він матиме значення MAX_FORWARD_VELOCITY за замовчуванням.

MIN_REVERSE_VELOCITY = 3000` Цей параметр еквівалентний MIN_FORWARD_VELOCITY, але для зворотного обертання шпинделя. Якщо його пропустити, за замовчуванням використовуватиметься MIN_FORWARD_VELOCITY.

INCREMENT = 200 Встановлює розмір кроку для команд збільшення/зменшення швидкості шпинделя. Це значення може бути різним для кожного шпинделя. Цей параметр діє з AXIS та Touchy, але зверніть увагу, що деякі екрани керування можуть обробляти речі по-різному.

HOME_SEARCH_VELOCITY = 100 - Прийнято, але наразі нічого не робить

HOME_SEQUENCE = 0 - Прийнято, але наразі нічого не робить

gcode.parse no longer drives the preview through per-move Python callbacks. For a canon that subclasses gcode.RendererCanon - rs274.glcanon.GLCanon is one, so every in-tree preview is - the whole program is built in C++ (GCodeRenderer, src/emc/rs274ngc/gcode_renderer.{hh,cc}): the g92/rotation/g5x transform, arc segmentation, rigid taps, (AXIS,hide) suppression, the vertices per drawn plane, the extents, the path lengths and the dwell and tool-change records. The finished program is handed over once, at the end of the parse, as a gcode.PreviewGeometry through the canon’s adopt_geometry(). A parse reads two more things off such a canon: program_geometry (the GEOMETRY strings and the rotation offsets) and arcdivision, which defaults to 64 and is read once at parse start. Every parse starts from a zero transform with nothing drawn; where the machine stands arrives as the caller’s initcode (a G53 G0 per axis), which the leading-traverse drop repositions on rather than draws. A RendererCanon subclass without a callable adopt_geometry is a TypeError from gcode.parse, not a silent fall back to callbacks.

The per-event canon protocol is unchanged for every other canon: rs274.interpret.PrintCanon, the interpreter tests and out-of-tree users of gcode.parse still receive straight_feed, arc_feed, next_line and the rest exactly as before, and rs274.interpret.Translated / ArcsToSegmentsMixin remain for them. The gcode module itself was rewritten on pybind11; its functions keep their names and signatures. One behaviour change: gcode.linecode() snapshots the running parse, and raises ValueError when no parse is in progress.

The drawing itself lives in lib/python/rs274/glcanon_scene.py, in four tiers. Nothing here changes what the preview looks like; it is where to start reading if you need to fix or extend one part of it.

Transforms go through a scoped model-view stack: with ctx.mv.push(): restores the previous transform on exit, including when an exception unwinds through it, so a part cannot leak a transform onto a later one. Offsets, small origin and axes share one such scope (RelativeCoordGroup), because the axes are drawn in the offset frame the offsets progressively build.

Parts read a FrameContext - an explicit, enumerated list of machine, view and renderer state, built once per frame by GlCanonDraw - rather than the widget itself. That is what lets them be tested without a window: build a context by hand, call part.draw(ctx), and assert on the vertices it emitted.

Click-to-select is not a part - it draws nothing to the screen. Picker renders the same program geometry into an offscreen framebuffer with line numbers encoded as colour and resolves the nearest hit; GlCanonDraw.select(x, y) delegates to it. It shares one ProgramGeometry with the drawing part, so the pickable geometry and the drawn geometry cannot drift apart.

Setting GLCANON_DEBUG=1, the preview’s one verbosity switch, raises the rs274 logger to DEBUG, checks glGetError after each pass, logs which parts the scene drew and which it skipped whenever that split changes, and reports depth/blend state a part left behind.

mdro mqtt-видавник pi500_vfd pmx485-тест qtplasmac-cfg2prefs qtplasmac-матеріали qtplasmac-plasmac2qt qtplasmac-налаштування sim-факел svd-ps_vfd

anglejog div2 enum filter_kalman flipflop homecomp limit_axis mesa_uart millturn scaled_s32_sums tof ton