#linuxcnc-devel Logs

Nov 14 2023

03:58 AM NoSpark: Error constructing label({'text': ''}):
04:07 AM NoSpark: 'pyvcp_tablerow' object has no attribute 'tk'
04:07 AM NoSpark: did somebody break pyvcp in master?
04:25 AM rigid: NoSpark: maybe try git bisect to find the faulty commit
04:57 AM rigid: rmu: nice. do udp sockets also work?
04:57 AM rigid: and how would you go on to reduce code needed for newly added command features?
05:02 AM rmu: rigid: did not try udp yet. udp in zeromq only works for radio/dish sockets, which are somewhat similar to pub/sub
05:04 AM rmu: https://github.com/rmu75/cockpit/blob/main/src/shcom.cpp#L409 vs https://github.com/rmu75/cockpit/blob/rs/zmq/src/zmqcom.cpp#L140
05:04 AM rmu: one problem just now is the massive amount of status updates that are broadcast
05:05 AM rmu: my debug tool looks at the queue with refresh rate of screen, but linuxcnc nowadays sends updates with 1kHz
05:06 AM rmu: socket option conflate etc.. cannot and doesn't really work well over TCP
05:09 AM rmu: so for networked apps, status will probably have to be delivered via a request/reply socket
05:13 AM rmu: https://github.com/rmu75/linuxcnc/blob/rs/zmq-experiments/src/emc/flatbuf/emc_cmd.fbs#L282 vs https://github.com/rmu75/linuxcnc/blob/rs/zmq-experiments/src/emc/nml_intf/emc_nml.hh#L994 + https://github.com/rmu75/linuxcnc/blob/rs/zmq-experiments/src/emc/nml_intf/emc.cc#L219 + https://github.com/rmu75/linuxcnc/blob/rs/zmq-experiments/src/emc/nml_intf/emc.hh#L129 and possibly more
05:15 AM rigid: UDP would be preferred for reliable network links from latency aspects. currently there's both UDP and TCP supported
05:17 AM rigid: I tried UDP via wifi and it seems to work. at least I got no errors.
05:17 AM rmu: for now, I try to keep everything 1:1 to existing NML stuff so it keeps predictable and pluggable, but there are ideas how to simplify emctask and co
05:17 AM rmu: there is no reason why UDP shouldn't work
05:17 AM rigid: cool
05:18 AM rmu: i hope to have every command implemented by beginning of next week
05:19 AM rmu: now it's mostly writing boring boilerplate code receiving flatbuffer struct, stuffing it into emc nml struct and feeding it to emcIssueCommand
05:22 AM rigid: Has there been any discussion in the past about abstracting the toplevel linuxcnc API? It's very bad that every GUI/module/... needs to generate messages itself.
05:24 AM rigid: Also a lot of duplicate code that way. Ideally, no GUI should ever touch NML/zmq/flatbuffers code but only high level API(s).
05:27 AM rigid: rmu: maybe just make sure to test network sockets during the process. currently, linuxcncrsh-tcp is the only test that actually tests remote processes. (And before my PR it tested practically nothing.)
05:30 AM rmu: rigid: yes i'm constantly testing TCP and will try multicast and udp radio/dish sockets
05:30 AM rmu: there is a somewhat high-level "api" in form of shcom
05:31 AM rmu: i keep zmqcom combatible with that as far as it makes sense
05:32 AM rmu: emcmodule will probably be reengineered with pybind at some point, and then it would make sense to use shcom or similar and put missing stuff there
05:32 AM rigid: ah cool, mentioned it since I didn't see a test for it.
05:32 AM rigid: it seems shcom is only for the shell UIs, there's another version of it in emcmodule.cc ... tk stuff seems to do stuff differently
05:32 AM rmu: versus reimplementing everything in emcmodule
05:34 AM rmu: status updates via tcp are currently somewhat of a blocker, will have to deal with that first, but commands via tcp work exactly like via unix domain sockets
05:35 AM rmu: nothing in shcom says "this file can only be used by command line stuff"
05:35 AM rmu: but i don't know the specific reasons things were done as they were
05:36 AM rmu: i agree those 25 separate implementations of "try_nml", "update_status" and similar need to be extracted into a library
05:40 AM rigid: it doesn't say so in the file but it's used by only commandline stuff. also the filename strongly hints to it.
05:41 AM rigid: yeah, some sort of linuxcnc_client.so ... maybe not even that since there's no separate client package.
05:42 AM rigid: maybe even just add it to linuxcnc.h/linuxcnc_api.cc in some lcnc_*() namespace
05:42 AM rigid: ...or class
05:42 AM rmu: +1 for namespace
05:43 AM rmu: also somebody please replace that evil CANON interface with something sane ;-)
05:44 AM rmu: that thing is one of the main reasons why multiple parallel interpreters in one linuxcnc instance are kinda impossible
05:44 AM rigid: yeah, can always add a wrapper class. There's something similar already for EmcIniFile()
05:45 AM rigid: i never understood the thoughts behind naming that module "canon"
05:45 AM rigid: even something badly like "cart_cs_stuff" would seem slicker
05:47 AM rmu: i think canon comes from "canonical machining functions" or something like thath
05:47 AM rmu: rs274 standard
05:52 AM rigid: hm, "These functions are intended to tell a controller what to do at the control level below the level in which the Interpreter is running. "
05:53 AM rigid: strange to name the actual module rs274ngc but the interface stuff canon_* ... why not just rs274 or rs274_machine or something more descriptive
06:08 AM rmu: i think they wanted a "C" interface to easily adapt to existing more primitive machine controllers
06:10 AM rigid: it's paragraph 4 of the standard http://alvarestech.com/temp/RoboAseaIRB6S2-Fiat/graco.unb.br/pub/alvares/retrofitting/linuxcnc.org/handbook/RS274NGC_3/RS274NGC_34a.html ... it's just not named consistently across modules hence my confusion
06:11 AM rigid: naming in general looks like from some 8.3 aera... same with "tp"
06:12 AM rmu: the opengl stuff needs a major overhaul in the not so far future anyways
06:12 AM rigid: i like when the structure is concise and aesthetically pleasing
06:12 AM rmu: then the canon interface can be rethought
06:17 AM rigid: andypugh: btw. i squashed the commits of https://github.com/LinuxCNC/linuxcnc/pull/2739 into one + tests
01:35 PM Unterhaus_ is now known as unterhausen
07:21 PM andypugh: rigid: Been busy, hopefully I will get to look at it later in the week
07:21 PM andypugh: Gove me a prod if not.
11:50 PM rigid: no rush