#linuxcnc-devel Logs

Oct 15 2023

01:20 AM seb_kuzminsky: NML is shm message passing between Task and the UIs, and between Task and IO
01:29 AM seb_kuzminsky: communication between Task and Motion uses a different system, which is also shm message passing, but it's not NML
03:29 AM rigid_: seb_kuzminsky: NML is a transparent buffer <-> process bridge. Buffers can be shm, locmem, globmem etc. Processes can run locally or on a remote host. TASK <-> MOTION has been stripped down to rtapi but it once used NML. This README artefact says so: https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/motion-logger/README
03:31 AM rigid_: If NML support hadn't been removed and would work as designed, MOTION could run as part of a remote linuxcncsvr process connected for example via UDP.
03:54 AM rene-dev5: Can you show me the commit where it was removed
04:04 AM rigid_: rene-dev5: i don't feel to wade the code for that. I found a reference in an early emc code documentation
04:04 AM rigid_: sec
04:05 AM rigid_: "These functions are called by emc/src/emctask/{bridgeporttaskintf.cc,minimilltaskintf.cc}, and do such things as compose and send NML messages to the motion and IO systems."
04:05 AM rigid_: https://emc.sourceforge.net/NIST-archive/msg01167.html
04:26 AM rmu: rigid_: all realtime stuff used to live in kernel space. that was mandatory. no c++ there. you would have to take special care, build your own std lib that is guaranteed to not throw any exception whatsoever, but that is not the only problem.
04:26 AM rmu: look at your cited message
04:27 AM rmu: literally: "This is not NML, ..."
04:27 AM rmu: "emc/src/emctask/{bridgeporttaskintf.cc,minimilltaskintf.cc}
04:27 AM rmu: convert the NML messages resulting from either the GUI (jogs, homes,
04:27 AM rmu: etc.) or the interp_list (G0, G1, F60, etc.) into emcmot commands and
04:27 AM rmu: write them to the shared memory buffer.
04:27 AM rmu: "
04:27 AM rmu: btw, if you unearth the code you seem to think exists somewhere, you are most welcome to create a branch / PR
04:32 AM rmu: found a talk about the hoops you need to get through to make C++ work in the kernel (didn't watch though) https://www.youtube.com/watch?v=uQSQy-7lveQ&list=PLHTh1InhhwT7J5jl4vAhO1WvGHUUFgUQH&index=86
04:54 AM rigid_: ah, seems the motion-logger README is wrong then
04:54 AM rigid_: there should be no linuxcnc code running in kernel space at all
05:01 AM rmu: real time linux stuff used to be kernel mode only
05:04 AM rmu: so no way around that
05:04 AM rene-dev5: rigid_ agree, but that what rtai currently does.
05:06 AM rene-dev5: And before rt preempt came along it was the most connon rt system used by linuxcnc
05:12 AM rigid_: i'm not sure about the point of the discussion. I just thought emcmot directly communicated using NML to emctask in the past. But components always accessed EMCMOT using NML through the task abstraction layer.
05:13 AM rigid_: All I'm saying that linuxcnc has introduced a lot of inappropriate intimacy over the time by bypassing APIs.
05:15 AM rmu: there is no point to the discussion. you are under the impression that real time communication was network transparent at some point. which it never was. end of transmission.
05:16 AM rmu: parts of linuxcnc are a real mess, but that's just what happens to code over 25 years. <insert link to royal society of putting things on top of things>
05:16 AM rigid_: what makes you think it wasn't? realtime messaging and realtime code are two different things.
05:16 AM rmu: what's the point of realtime capable messaging if the realtime code can't use it
05:17 AM rmu: (rhetorical question)
05:18 AM rigid_: Realtime code can use it. It's just translated by another abstraction layer.
05:18 AM rmu: no. the other side of the abstraction layer as you call it is outside the realtime domain
05:19 AM rmu: read this https://emc.sourceforge.net/NIST-archive/msg01167.html
05:20 AM rigid_: yes, and the protocol has configurable features that allow handling real-time problems. Like queueing/non-queueing mode or blocking and non-blocking mode.
05:22 AM rmu: rene-dev5: i cleand up the imgui stuff a bit, currently it needs 2.9 and a cherry pick of the PR regarding state tag filename. it has g-code preview that actually shows the executing code
05:23 AM rmu: rigid_: those are not realtime problems
05:24 AM rene-dev5: rigid_ hal broke up the seperation. Hal doesn’t work over the network. But was necessary to have a layer for the drivers.
05:24 AM rigid_: oh, so rt applications must not decide to discard messages or to process a queue?
05:24 AM rene-dev5: rmu cool, I will check it out later.
05:25 AM rigid_: rene-dev5: yes, HAL functionality previously was part of EMCIO and EMCMOT
05:25 AM rene-dev5: task does more than just translate messages
05:26 AM rene-dev5: exactly. And since the ui also uses hal, you cant run it on a different host.
05:26 AM rene-dev5: some things are only accessible thru hal, mostly because it is such a pain to add new messages.
05:27 AM rmu: to communicate from non-rt with rt you need a queue that can be read and written to simultaneously without locking
05:27 AM rigid_: yeah, what would be needed is either a HAL API for EMCIO and EMCMOT or an NML API directly for HAL.
05:29 AM rigid_: or brew some API imitating halrmt
05:30 AM rigid_: best would be to not use the HAL layer directly. Software providing inputs/outputs in a Hardware related layer is smelly to begin with. Although I see why it has been done.
05:30 AM rigid_: ...probably mostly to avoid using NML
05:33 AM rene-dev5: Forgot emcio, it doesn’t exist anymore
05:33 AM rmu: rene-dev5: isn't halui the thing that is supposed to translate GUI NML messages to HAL?
05:34 AM rene-dev5: Yes, but it has a race condition when you use another ui at the same time.
05:34 AM rene-dev5: The whole thing was never designed for multiple UIs
05:34 AM rigid_: oh... maybe missing queueing/locking?
05:34 AM rmu: i noticed with my imgui thingy
05:35 AM rmu: e.g. log messages are not "broadcast", whoever gets the message first got it but nobody else
05:35 AM rene-dev5: No. If you read an error, its gone. Whoever reads it first, gets the error.
05:36 AM rene-dev5: if you change certain things, the other ui isn’t aware of it, and you end up with inconsistent states across the UIs
05:40 AM rene-dev5: Manual tool change for example cant be done with nml only.
05:44 AM rigid_: sounds like error messages need to be peek()d
05:44 AM rigid_: NML supports multiple readers/writters to channels but I'm not 100% aware how.
06:02 PM Unterhaus__ is now known as Unterhausen