#linuxcnc-devel Logs

May 05 2023

#linuxcnc-devel Calendar

12:56 AM -!- #linuxcnc-devel mode set to +v by ChanServ
03:10 AM -!- #linuxcnc-devel mode set to +v by ChanServ
03:46 AM -!- #linuxcnc-devel mode set to +v by ChanServ
03:46 AM -!- #linuxcnc-devel mode set to +v by ChanServ
05:33 AM -!- #linuxcnc-devel mode set to +v by ChanServ
05:57 AM -!- #linuxcnc-devel mode set to +v by ChanServ
06:56 AM fdarling: seb_kuzminsky: I would like to write a realtime HAL component that can open a configuration file during the setup phase (not during realtime) to have more extensive configuration. Is this permissible? Are there any examples of doing non-realtime-friendly things inside of realtime components during the startup phase?
07:00 AM rene-dev5: seb_kuzminsky see my issue on github
09:10 AM -!- #linuxcnc-devel mode set to +v by ChanServ
09:27 AM seb_kuzminsky: fdarling: that probably won't work - realtime components in rtai operate entirely in kernel space, where file io is not practical
09:28 AM seb_kuzminsky: it's a super useful thing that people often want to do, and we chatted a bit about it at the Madison hackfest a few weeks ago
09:32 AM seb_kuzminsky: one suggestion was to write a second component, a non-realtime companion to your "main" realtime component. the non-realtime helper would do the file io and communicate it to the realtime component at startup, perhaps through a component-specific shared memory region or maybe through a hal "port" pin
09:35 AM seb_kuzminsky: rene-dev5: i'm looking at your issue and pr now
09:37 AM fdarling: seb_kuzminsky: what do you mean by HAL "port" pin? Is it something special besides a numeric type?
09:49 AM fdarling: seb_kuzminsky: are there any examples of using shared memory to communicate between a custom realtime component and a custom userspace component?
09:53 AM seb_kuzminsky: fdarling: hal_port_t: <https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/hal.h#L841-L926>
09:54 AM seb_kuzminsky: it's not used widely (or at all?) so may be broken :-/
09:55 AM seb_kuzminsky: fdarling: a good example of shm between rt and non-rt is hal_stream_t, as used by our standard and widely used streamer and sampler components
09:55 AM seb_kuzminsky: streamer and sampler (and the hal_stream_t they use) focus on a fifo of samples, what it sounds like you want (and what we talked about at the hackfest) was a slightly different mechanism:
09:57 AM seb_kuzminsky: imagine a non-rt component whose sole job in life is to read a .json or .yaml or .ini or similar config file, and use it to populate a component-specific struct in shm, which the rt component can then map in and use directly
09:57 AM fdarling: seb_kuzminsky: I am looking at streamer.c, and I am not seeing anything obviously doing shared memory
09:57 AM seb_kuzminsky: it's inside hal_stream_t
09:58 AM seb_kuzminsky: good morning(?) pere
09:58 AM pere: hi. 17:00 here. :)
09:59 AM fdarling: seb_kuzminsky: https://github.com/LinuxCNC/linuxcnc/blob/5bef504150d162a8bd4be00dcf79bf635f333cdc/src/hal/hal_lib.c#LL4192C18-L4192C33
09:59 AM seb_kuzminsky: fdarling: yup
10:01 AM fdarling: seb_kuzminsky: it looks like maybe I could use hal_stream as a solution?
10:03 AM seb_kuzminsky: are you asking me? i mean, it's fine by me! :-)
10:03 AM seb_kuzminsky: if it suits your needs, go for it
10:04 AM -!- #linuxcnc-devel mode set to +v by ChanServ
02:30 PM -!- #linuxcnc-devel mode set to +v by ChanServ
02:49 PM -!- #linuxcnc-devel mode set to +v by ChanServ
02:49 PM -!- #linuxcnc-devel mode set to +v by ChanServ
04:13 PM rene-dev5: seb_kuzminsky I split up the taskmodule into a separate PR. Im still struggling to find a good use for it.
08:18 PM seb_kuzminsky: rene-dev5: thanks
08:18 PM seb_kuzminsky: i don't now what good it does either
08:19 PM seb_kuzminsky: i think it's someone's half-finished project, possibly half-baked to begin with
09:09 PM linuxcnc-build: build #2735 of 4041.deb-buster-rtpreempt-amd64 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4041.deb-buster-rtpreempt-amd64/builds/2735 blamelist: CMorley <chrisinnanaimo@hotmail.com>, andypugh <andy@bodgesoc.org>, mrbubble62 <martin@mrbubble.net>, Steffen Moeller <moeller@debian.org>,
09:09 PM linuxcnc-build: Sebastian Kuzminsky <seb@highlab.com>, Hans Unzner <hansunzner@gmail.com>
09:12 PM rene-dev5: seb_kuzminsky did you see the iocontrol issue? it must cause many other bugs