Floating point in base thread?

I usually run Mesa eth cards and generally don't use a base thread since it's not necessary/supported with the hm2 driver. I have been messing with it lately and on one machine I have a separate hal file just for handling a certain logic. As a test to try to speed it up, I ran the non-floating point components in a reasonably fast base thread, stuff like not, and, & edge. I ran into what seems like the thread mismatches causing servo thread component inputs to miss some of the base thread outputs. That's something I sort of expected but I sort of selectively chose what to run in the base thread and it seems to work well.

One thing I noticed was BLDC component docs suggest being able to run fp in a base thread. I use an 8i20 and 7i76e on my mill spindle motor. Everything currently runs in the servo thread but I was considering adding a base thread with FP to just run the BLDC component. I'm currently limited to about 2800rpm max probably because of the servo thread speed. The 7i76e handles the encoder feedback for the motor and the 8i20 is using the BLDC component to handle commutation, I'm wondering if it's reasonable to try running BLDC in the base thread on a setup like this. I figure the reason the base thread generally doesn't do FP is because FP requires the base thread to run slower than it otherwise would.

Since I currently don't run a base thread at all I'm thinking I can get away with a "slow" base thread, something like 5khz to start. At the moment I run the servo thread at 1.25khz. Any thoughts on whether this is a good idea or maybe there is some issue running a smart serial device over mixed threads like this?

you may look into the component limit3 this is a user component for special axis and blcd uige to get along and realtime access to non axis motors

Well...

You clearly could run bldc in a faster thread, but there would only be any advantage if the inputs that the component consumes, and the outputs it produced, were also running that fast. So you would need to read the commutation signals in the fast thread and write the (smart serial) 8i20 commands in that thread too.
So, that involves running your hms_eth.read and hm2_eth write in the fast thread.
Does that work?

You cannot mix base and servo threads accessing the 7i76e

You might try running on a faster CPU as a test to see if the commutation
is really the limit (some CPUs will do 4 KHz with HM2 eth)
Typicall you can just swap the linuxCNC hard drive and setup the Ethernet
on the new LinuxCNC host to do this

I think there's also the possibility that you are running a 220V motor on rectified 120V
(which will limit you to about 1/2 full speed)

PCW wrote: You cannot mix base and servo threads accessing the 7i76e

You might try running on a faster CPU as a test to see if the commutation
is really the limit (some CPUs will do 4 KHz with HM2 eth)
Typicall you can just swap the linuxCNC hard drive and setup the Ethernet
on the new LinuxCNC host to do this

I think there's also the possibility that you are running a 220V motor on rectified 120V
(which will limit you to about 1/2 full speed)

The motor is running on 320v, it's rectified 240v. it will actually run over 3000 but I get some spindle clank that I think is due to commutation delays. The CPU is a dual core mobile I5 (hyperthreading is off).

I didn't actually want to run the 7i76e on 2 different threads, I wanted to run the BLDC component on the base thread. I know it's iffy but I thought I could maybe get away with it but I'm not sure how the Smart Serial interface plays into it.

There is no point running the bldc calcs 10x with the same input then sending the output once...

You can just set the servo thread at 500.000 and test it to check if that is the bottleneck, that would theoreticaly give you twice the speed.

tommylight wrote: You can just set the servo thread at 500.000 and test it to check if that is the bottleneck, that would theoreticaly give you twice the speed.

At 2khz on the servo thread I hit RT delay errors right away on this PC. The main thing I was actually wondering was if an FP base thread running only a single FP component would fare better at running faster. Not sure if I'm thinking about it right, maybe it doesn't have anything to do with the actual number of operations per cycle. The idea mostly was to run BLDC in a 2khz or faster and just keep the rest running at the 1.2khz thread I currently run it at.

Sort of a moot point since it's been pointed out that the mixed threads won't work in this case anyway. I may just do what PCW suggested since I can confirm that yes, in Linux you can generally just slap the HDD (SSD in this case) into another PC setup the NIC and go to town as long as the kernel wasn't stripped down for specific hardware. This machine runs an industrial aluminum dual core brick with a mobile I5, I might just try running my other machine's Mini-ITX board on it that has an AMD desktop Ryzen APU. They're both setup to run on a 24v Power supply so it's not that big a deal.

Rt delays at 2kHz is not good at all.
I would not trust that to run a machine, ever.
Both of your PC's have issues, but give the other one a try, just remove the hard drive form the existing one and put it in the other one. Test, report back !