On-the-fly components?

I've been thinking about this here and there about something I'm gonna start reworking. It's basically one application that runs LinuxCNC traditionally with the ini file pointing to hal files. I use #INCLUDE's for special configurations....

The rework is going to add a second application that doesn't necessarily have to be running, but it needs HAL resources. I can obviously load them from the HAL files beforehand but that seems like a waste of resources to load a bunch of HAL components that might not be used.

Machinekit had a mechanism called "inst-comp" or instantiable components. There was a 2nd version of most HAL components that could be loaded on the fly because Machinekit targeted very minimal hardware. Curious if anything like that was ever adopted into LinuxCNC, I haven't noticed it.

If the fundamental outcome is to enable faster, easier and an effective process in getting parts and final products manufactured with less complex overheads, I say it's a good idea!

This machine doesn't make any parts, it's not a machine tool. Just trying to be efficient with processing load.

If it ain't contributing or benefiting to anything world-real, the most efficient way is to eliminate this load all together. Not the other way around.

Uhhhh.....

Yeah so, instantiable HAL components....is it a thing in LinuxCNC?

Yeah so, instantiable HAL components....is it a thing in LinuxCNC?

No

I don't think such complexity adds value
When tracing the kernel, it was apparent on my test machine the servo thread got everything done in about 200 usec and then the servo thread went to sleep for 800 usec until it was triggered again

So in most instances there is plenty of spare overhead before the thread is overrun. (By a factor of 4 in my test)

I mentioned the value case that MK used, which is why they did it. Kind of ashamed MK never reconverged with LCNC, they were ahead of the curve on alot of things. Being able to run the entire system on a DE10 nano was always pretty appealing to me, Solid FPGA performance just gotta be pretty mindful of CPU usage.

That's not what I'm doing here, I just need alot more HAL resources available at runtime though they may not be in use. If your test machine included like 20 PIDs and a bunch of other stuff im sure that headroom would diminish.

So let me ask this a different way since I think "instantiable components" was taken a bit to literally....

Just as there exists an "addf" command in halcmd to add a function to a thread, there is a "delf" command to remove it. I've never tried it but it doesn't make much sense to use such a command outside of runtime. So I guess the question is, is there any resources to be saved by adding and removing functions from hal during runtime? I know there's logistical issues with broken nets but they can be dealt with.

The testing I did was with a Fully configured Plasma  control box and a Mesa 7i76e with no spare IO ports and 5 stepper controllers so it was not a trivial environment.

To a large extent the use case for minimal hardware has diminished since MK was forked and seems to have died a slow death.

Why would you pay USD $225 for your E10-Nano when you can buy a Odroid H3+ for $165? Its a full blown Celeron PC  that  gives you a full blown PC in a similar footprint?