Repository navigation
Developer Meeting Agenda 2026-10-11 - 10:00 CEST #4615
grandixximo
started this conversation in
Agenda
Replies: 1 comment 4 replies
|
What is the process to get something on the agenda? I can edit it, but it seems stuff gets removed afterwards. The HALUI / Task situation should be discussed IMO, also the external offsets float thing, in a sense that is more important than odd corner cases like sim_encoder or the 32bit fixes in NML. |
4 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
According to our bi-weekly schedule alternating between "early" and "late", this video meeting is Sunday 2026-Oct-11 at 10:00 CEST.
https://greenlight.bbb.uni-rostock.de/b/ste-c4d-brs-3k6
Access code: 869782
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2026&month=10&day=11&hour=8&min=0&sec=0&p1=319&p2=236&p3=240&p4=136&p5=165&p6=256
Agenda
hal_bridge, and @rene-dev's objection that this puts ZMQ on top of NML instead of replacing it; his plan in NML replacement #4571 is to move halui into task first, then replace NML with flatbuffers over websockets. WIP: halui: pin-only GUI bridge surface (halui side of the #4613 split) #4616 (draft) sketches a split: halui only exposes plain HAL pins, and a userspace comp speaks the ZMQ. @BsAtHome on WIP: halui: pin-only GUI bridge surface (halui side of the #4613 split) #4616: every patch adds another layer (NML, HAL, ZMQ), HAL was meant as the RT interface and is turning into a polled message bus, and there is still no written list of requirements for the NML replacement. Since then Nml cleanup #4627 (step 1, NML out of the places where it is only a helper) is merged and move Halui into task #4644 (step 2, halui into task) is open as a draft. In NML replacement #4571 the talk moved to transport: websockets as the one transport so browser clients need no bridge (@rene-dev, @rmu75), or an interface independent of the transport (@BsAtHome); @alex-pres now agrees websockets fit the UI side. @BsAtHome objects that code is landing before a plan has consensus, and that step 1 left logging undecided (item 12). Questions:(long long)print casts and asked for a move to fmt, which hal: print 64-bit values and pointers without long long casts #4617 does for the remaining HAL print sites (PRId64/PRIxPTR, no casts). Decision wanted: do we still want the tree to build on ILP32, and if so, do we keep new code 32-bit clean in review, or do we declare LP64 only and stop checking?v2.10.0-pre2is tagged. What is left:hal.hh) and pybind11 bindings on the new API.halfileupdate) was draft until the renaming settled, and hal: Break the HAL API - Move to 64-bit exclusively #4565 settled it. hal: Add halcompupdate to migrate .comp files to the new HAL API #4256 (halcompupdate) conflicts after the break. Users are on the new API now without either converter; can these go in next?.mbccbfiles need recompiling from.mbccsafter the break. Last meeting left open where we tell users: release notes, NEWS, or docs?conv_*components withreplace_nan/replace_inf_positive/replace_inf_negativepins, and noclampon the real to int direction (needs .hal file updates).bool/sint/uintas a warning instead of an error, which also fixeshal_get_bool()reading false on big-endian.git switchquestion on include: move the exported headers into a directory of their own #4461 is answered (silent both ways), and it is rebased on current master. Merge?v2.10.0-pre2tag exists, whileVERSION_BASEsays2.10.0~pre2, so the tilde/dash question now applies to a real tag. Open points from last time: strictness on an untaggedVERSION_BASEchange, non-release tags, source packages built from a zip, and the backport to 2.9. Rework versioning scripts and workflow #4584 is still draft and conflicts.[a-zA-Z_][a-zA-Z0-9_]*. inifile: accept dash in section and variable identifiers #4573 is closed; xhc-hb04: rename dashed ini identifiers, migrate old configs in update_ini #4601 renames the dashed xhc-hb04 identifiers and migrates old configs inupdate_ini. Once it is in, the Tcl flattening in Remove Tcl from sample configs #4524 can start with the pendant configs.[DISPLAY]CYCLE_TIME, Unify [DISPLAY]CYCLE_TIME unit handling across GUIs #4424. Decided on 2026-09-13: every GUI/VCP reads the value the gmoccapy way first. No PR yet. Who takes it?HOME_OFFSETis answered in the thread. HOME_OFFSET is doing double duty #4527 (HOME_OFFSETdouble duty) has a design proposal now, see item 15. Add Support for Dogbone Homing #4009 dogbone homing conflicts with master.mc_axisproposal, discussion Proposal: mc_axis — a PLCopen MC Part 1 axis component for HAL (extra joints, axes without G-code) #4647 by @yurc: a PLCopen Motion Control Part 1 axis as a HAL component (power, absolute/relative/velocity moves, halt, set-position, the PLCopen state machine, following error and drive fault handling, optional CiA-402 profile position), for extra joints and HAL-only axes. Field-tested on an EtherCAT servo; tests and a sim config are on the branch. @andypugh points at the overlap withlimit3andsimple_tp. Do we take it into the tree, and under which name? Related: should thecia402component move from linuxcnc-ethercat into the tree?HOME_OFFSETdouble duty, issue HOME_OFFSET is doing double duty #4527, follow-up from the 2026-09-13 meeting. InHOME_ABSOLUTE_ENCODERmodeHOME_OFFSETis the encoder zero, everywhere else the switch position, so a machine with an absolute encoder and home switches cannot express both. Proposal in the issue, in three phases:[JOINT_n]HOME_ENCODER_OFFSET, falling back toHOME_OFFSET, so existing configs behave the same.HOME_ENCODER_TOLERANCEplausibility check at boot, re-reference through the home switch when the check fails, and a pin showing where the position came from.@rene-dev asks for a solid test suite covering all encoder types first. Is the direction right, and are the parameter and file names acceptable?
See PRs for merge/comments.
[AXIS_<letter>] TYPE, follow-up to Honor [AXIS_<letter>] TYPE in the interpreter, canon and motion #4581.int64_t: see item 3.long longcasts, see item 3.All reactions