Help picking mesa board redcaps/bldc component

andypugh wrote:

gmouer wrote:

I realize the question is intended for Pete but it prompted a question from me. I was not aware that more than one servo thread could be used, can you explain that a bit? All the HAL's I have seen (used) had a single base and servo thread.

Typically motmod starts two threads as you describe
www.linuxcnc.org/docs/html/man/man9/motion.9.html

It is quite common to not define the base thread for a Pico / Mesa / General Mechatronics setup, as it is not needed.

If you look at the manpage there, you can see that there is an option "base_thread_fp=1" to enable floating-point calculations in the base thread (which you would then set to 5kHz rather than the normal 50kHz)

There is no point running bldc at 5kHz unless the inputs and outputs are also updated at that rate, so the hm2 read and write functions also need to be in the fast thread.

Of course that prompted another question. The more I learn the more I realize what I don;t know.

Wouldn't setting it to 5khz from the normal 50khz also slow the motion planning part down also? There is only one base thread, we can set it to floating point and define its speed but there still is only a single base thread, correct? I must be missing something here.

I am going to have to digest this for a while and do some more reading. We can still get the hardware decided and ordered, the software comes later anyways.

Ok, so I have been pondering this stuff a bit and have some questions.

My assumption is the default base thread is run at 50khz, and is not normally used with a mesa board setup, and the idea is to lower that base thread to 5khz and use that base thread to handle the mesa read/write cycles. Correct?

I go back to Petes statement that a Atom computer stresses out at anything over 2khz and wouldn't be up to the job of the required 5khz thread speed. Is Pete talking about the thread running in the servo thread in that case? I am confused why something like the atom, if it can handle software step generation at the default base thread speed of 50khz then why couldn't it run at a much reduced base thread of 5khz and handle the commutation tasks in that base thread?

I am thinking Petes statements of the processor horsepower needed to run a 5khz thread is talking about the servo thread, not the base thread. Andy's comments were talking about using the unused base thread for the commutation task. Have I got this right?

I am thinking the processor horsepower requirements vary widely depending on which thread the commutation tasks are handled in.

No doubt you guys can slap my thinking back onto the correct road.

Normally I would run everything in a single servo thread at its just just simpler and less chance for
order problems that way, also unless you are running drives with tachometer feedback
you are in torque mode which will need a high servo thread rate for best performance

PCW wrote:

Normally I would run everything in a single servo thread at its just just simpler and less chance for
order problems that way, also unless you are running drives with tachometer feedback
you are in torque mode which will need a high servo thread rate for best performance

Going to use AMC brushless drives, in velocity mode, using encoder feedback to the drives (BE25a20 drives have encoder feedback inputs or tach). The positioning PID loop will be in Linuxcnc. (encoder also feeds into 7i77 encoder input)

OK that helps but I still think using multiple threads for this is inadvisable

PCW wrote:

OK that helps but I still think using multiple threads for this is inadvisable

I understand. Splitting the I/O between the 2 threads opens up the potential for timing issues. We certainly don't need to look for that kind of trouble. Troubleshooting it would get very nasty.

A quick question.... for a initial bench test, with one motor, the commutation in and out signals would be 5V, what do you think of using the 5i25's spare db25 connector as GPIO for this? Its only for a bench test to prove the motor/drive/bldc commutation functionality.