I do agree about the brushless motor except for the fact that I actually do control a brushless motor in the standard linuxcnc way on my mill, though I don't think a milling spindle was the intended use case.
I have a mill that came with a brush less DC motor/controller and I blew up the first controller and the replacement just did not work so I picked up a Mesa 8i20 and built a power supply, and it runs off SS from my 7i76e. The hall sensors are connected to the 7i76e inputs, I attached an encoder to the motor (the 8i20 needs good velocity feedback through a PID loop. It works very well up to 3000rpms which is faster than the original controller would run the motor anyway. A torque mode servo drive is not ideal for a spindle but it works with the right PID settings, and this is a dual core x86 with not great latencies on a 1ms servo thread. It could be better, sure. But I'd be willing to bet that most of these type of cases could be solved in the way that hm2 handles stepgens, PWM and encoders, with a firmware module in hm2. The in hm2 CPU does not generate steps at all, it tells the FPGA firmware "hey, generate steps at this frequency/pulse width until I tell you to stop/speed up/slow down". and it works cuz the CPU responds "fast enough". So why not treat these issues as someone (like myself} who isn't super confident in userspace programs and needs something special does.....write an RT-hal component. In my case I can't write code, so I have a buddy do it, but custom components is my go to. So in the same train of thought, where an RT-hal component isn't quite upto snuff, write a hm2 firmware module for it. The biggest consideration for a firmware module like this in hm2 is figuring out what you need done fast in the FPGA and what you can realistically wait a servo-thread cycle for. If it's fully compatible with hm2 in general it isn't a major ordeal for maintainability. I know (Michael?) has done some things with capsense and nano-ADC as hm2 firmware modules. I use nano-adc with my board cuz it's there, and it works. the integer data coming out of it in hal isn't really useful for me and since I like components I had a buddy write me a component to turn the integer into a scaled float output, or a direct voltage readout as a pin. This is just my train of thought. On Thu, Sep 26, 2019 at 7:15 PM Chris Albertson <albertson.ch...@gmail.com> wrote: > Ideally, you would have an interface spec that was written at a high level > and it would abstract away where the Real-Time component ran. It could be > on the main (and only) CPU (kernel level task), on an STM32 > microcontroller or on an FPGA or I guess even an ASIC. Designing said > interface spec would take a lot of thinking. > > There are some use cases where you REALLY want to run a control loop at a > very fast frequency. Maybe this does not matter on a typical milling > machine but what if the use case were a robot that was balancing on two > feet while standing on loose dirt and rock? Yes, I keep thinking MK would > be a decent robot motor controller then think not and fall back on using a > number of STM32 chips and custom code. > > Another use case for VERY fast real-time processing is to commutate a > brushless motor. With most MK setups we do the motor commutation of > brushless motors and stepper motors in special controllers that we buy. > But if you look inside these controlerss they are not much more than a > microcontroller (or DSP chip) and some MOSFETS. An FPGA would be good at > this. > > > On Thu, Sep 26, 2019 at 2:48 PM justin White <blazin...@gmail.com> wrote: > >> So what is special about socfpga that makes this specific to socfpga >> chips rather than just an FPGA communicating to the CPU in another form? >> If I'm following the idea right we're basically talking about running hal >> components individually as FPGA soft cores. I follow that idea but what is >> the main benefit? Is it to mitigate the latency issues of the lower >> performance ARM cores of the SOC? Seems like alot of work, compatibility, >> portability, and maintainability issues. If I had to guess, I would say >> that a headless socfpga on mk-hal and mk-cnc running on a more competent >> cpu/gpu would make for a well performing, low cost system. The socfpga CPU >> would already be independent of the constraints caused by running a display >> and higher level languages right? I know there is work to be done in that >> area but that seems like a solution to alot of problems in and of itself. >> >> On Thu, Sep 26, 2019 at 5:04 PM Michael Brown <mib.holotro...@gmail.com> >> wrote: >> >>> >>> >>> On Thursday, 26 September 2019 21:19:04 UTC+2, ce...@tuta.io wrote: >>>> >>>> Sep 26, 2019, 17:53 by mib.ho...@gmail.com: >>>> >>>> > I'm probably the wrong guy to answer this question as I'm a noob into >>>> how sw os's work, but regarding linux memory access from the fpga: >>>> > >>>> Thanks. Sorry for probably idiotic questions, I am noob about FPGA >>>> development. >>>> >>>> >>> Ok :-) >>> >>> >>>> > >>>> > A (hw) function in fpga (also with dma channels), can address any >>>> linux memory location (even sw restricted ones). >>>> > >>>> > If needed it is also possible to setup say like a 64KB dual port >>>> shared memory block inside the fpga fabric and have both fpga and linux >>>> access to that. >>>> > >>>> Are both solutions useful for this scenario? I imagine that the >>>> frequency of change will be lot higher on FPGA side than on Linux side. For >>>> example the encoder counter will be updated almost constantly. >>>> >>>> Cern. >>>> >>>> >>> Well on the fpga side you don't have any cpu-like structure that governs >>> every thing, >>> only clock signals, and flags >>> and every function you implement runs on it's own simultaneously (in >>> parallel) (think 1 sw core for every function) >>> on every clock cycle. >>> >>> >>> >>>> > >>>> > >>>> > On Thursday, 26 September 2019 15:48:35 UTC+2, ce...@tuta.io wrote: >>>> > >>>> >> Sep 26, 2019, 01:29 by >> mib.ho...@gmail.com <>>> : >>>> >> >>>> >> > Well current state is that PR (Partial Reconfiguration) is brand >>>> new to the OS (Open Source) world, >>>> >> > as > IntelfPGA (former Altera) "just" have promised it for their >>>> 19.1 release (no lite version out yet), <>> https://github.com/>> >>>> machinekit/mksocfpga/issues/>> 100 < >>>> https://github.com/machinekit/mksocfpga/issues/100>>> > >>>> >> > on the contrary Xilinx have sneaked it out very quietly with their >>>> Vivado 2019.1 release this summer <>> https://github.com/>> >>>> machinekit/mksocfpga/issues/>> 100 < >>>> https://github.com/machinekit/mksocfpga/issues/100>>> > >>>> >> > >>>> >> > So while the idea has had time to settle in this old thread, the >>>> possibility of implementation here in Machinekit is brand new.... :-) >>>> >> > Michael B >>>> >> > >>>> >> Well, >>>> >> and how it is with the memory? And with the bus connection between >>>> hard ARM processor and FPGA fabric? Because now we have the HAL memory >>>> block locked into RAM with HAL library enabled allocating and memory >>>> (alignment) management from Linux side. But I presume that for FPGA-side >>>> components, that would not be good enough and this memory block will have >>>> to be directly in FPGA fabric so the components can use this space as a >>>> "register", right? Will then be possible to atimically access this memory >>>> (or variables there stored) both from Linux running on an ARM core and >>>> component in FPGA fabric? (I mean as a direct memory access, zero-copy, not >>>> some memory synchronization.) >>>> >> >>>> >> Cern. >>>> >> >>>> >> > >>>> >> > On Wednesday, 25 September 2019 20:49:04 UTC+2, >> ce...@tuta.io >>>> <>>> wrote: >>>> >> > >>>> >> >> I am late to the party, I know, sorry, but this idea is very >>>> interesting to me. As I know that perspectives and opinions change, I would >>>> like to inquire about the current state. If all in this thread is still >>>> valid or if it was redacted in some way? >>>> >> >> >>>> >> >> I need to wrap my head around this concept, but fundamentally >>>> speaking, I see no reason why it should not be possible and even how it is >>>> that much different from the current state. Because, currently the >>>> operation on HAL is discrete and sequential. But only up to the point. As I >>>> see it, the basic structure of HAL is the input and output of each block >>>> (component). What is happening inside the component is a black box and of >>>> no particular interest to the user or a system. That "happening" is enabled >>>> by so called threads or tasks (on the Linux OS side), but actually from >>>> theoretical point of view are also of no importance. >>>> >> >> >>>> >> >> Given the dawn of multicore, we can have multiple threads running >>>> independent on each other on different isolated CPU/cores all reaching the >>>> same memory. There is still the limit that threads on one instance has to >>>> be run in increments of the first one, but I am not sure if that is real >>>> limit or just something nobody changed from LinuxCNC days. (Because really, >>>> it is nonsense.) >>>> >> >> >>>> >> >> If you can somehow pass-through the memory (I/O) from FPGA-side >>>> HAL to Linux-side HAL, I think you are pretty much done and you have HAL in >>>> FPGA. (HostMot2 FPGA firmware is also a HAL type, but you have the ugly >>>> read/write functions. I call it the LinuxCNC way of thinking about it.) >>>> >> >> >>>> >> >> Because then it will be the same old, same old. >>>> >> >> >>>> >> >> And that opens up some very interesting possibilities. >>>> >> >> >>>> >> >> BTW, I have only very rough understanding about FPGA development. >>>> But that SystemC looks extremely promising. >>>> >> >> >>>> >> >> Cern. >>>> >> >> >>>> >> > >>>> >> > >>>> >> > >>>> >> > -- >>>> >> > website: > >> http://www.machinekit.io <http://www.machinekit.io>>> >>>> <>> http://www.machinekit.io <http://www.machinekit.io>>> >> blog: > >>>> >> http://blog.machinekit.io <http://blog.machinekit.io>>> <>> >>>> http://blog.machinekit.io <http://blog.machinekit.io>>> >> github: > >>>> >> https://github.com/machinekit <https://github.com/machinekit>>> >>>> <>> https://github.com/machinekit <https://github.com/machinekit>>> > >>>> >> > --- >>>> >> > You received this message because you are subscribed to the >>>> Google Groups "Machinekit" group. >>>> >> > To unsubscribe from this group and stop receiving emails from it, >>>> send an email to > >> machi...@>> googlegroups.com <>>> <mailto:>> >>>> machinekit+>> unsub...@googlegroups.com <>>> >> . >>>> >> > To view this discussion on the web visit > >> >>>> https://groups.google.com/d/>> msgid/machinekit/a9420e6d->> >>>> 4f39-46e2-97c1-d4f7af69c89e%>> 40googlegroups.com < >>>> https://groups.google.com/d/msgid/machinekit/a9420e6d-4f39-46e2-97c1-d4f7af69c89e%40googlegroups.com>>> >>>> <>> https://groups.google.com/d/>> msgid/machinekit/a9420e6d->> >>>> 4f39-46e2-97c1-d4f7af69c89e%>> 40googlegroups.com?utm_medium=>> >>>> email&utm_source=footer < >>>> https://groups.google.com/d/msgid/machinekit/a9420e6d-4f39-46e2-97c1-d4f7af69c89e%40googlegroups.com?utm_medium=email&utm_source=footer>>> >>>> >> . >>>> >> > >>>> >> >>>> >> >>>> > >>>> > >>>> > >>>> > -- >>>> > website: > http://www.machinekit.io <http://www.machinekit.io>> >>>> blog: > http://blog.machinekit.io <http://blog.machinekit.io>> >>>> github: > https://github.com/machinekit <https://github.com/machinekit> >>>> >>>> > --- >>>> > You received this message because you are subscribed to the Google >>>> Groups "Machinekit" group. >>>> > To unsubscribe from this group and stop receiving emails from it, >>>> send an email to > machi...@googlegroups.com <mailto: >>>> machinekit+unsubscr...@googlegroups.com>> . >>>> > To view this discussion on the web visit > >>>> https://groups.google.com/d/msgid/machinekit/b430e32c-13cc-47d2-ab88-3da6aa31a293%40googlegroups.com >>>> < >>>> https://groups.google.com/d/msgid/machinekit/b430e32c-13cc-47d2-ab88-3da6aa31a293%40googlegroups.com?utm_medium=email&utm_source=footer>> >>>> . >>>> > >>>> >>>> -- >>> website: http://www.machinekit.io blog: http://blog.machinekit.io >>> github: https://github.com/machinekit >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Machinekit" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to machinekit+unsubscr...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/machinekit/074a5843-6a29-4653-92a9-5fd90b428b03%40googlegroups.com >>> <https://groups.google.com/d/msgid/machinekit/074a5843-6a29-4653-92a9-5fd90b428b03%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> website: http://www.machinekit.io blog: http://blog.machinekit.io >> github: https://github.com/machinekit >> --- >> You received this message because you are subscribed to the Google Groups >> "Machinekit" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to machinekit+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/machinekit/CA%2BQ02MOBDLnKomrhc_1XPvkQd3ouhnxXxZJBNRQ3e2EpJ3RgNg%40mail.gmail.com >> <https://groups.google.com/d/msgid/machinekit/CA%2BQ02MOBDLnKomrhc_1XPvkQd3ouhnxXxZJBNRQ3e2EpJ3RgNg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > > > -- > > Chris Albertson > Redondo Beach, California > -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/CA%2BQ02MPBHk1B0LO6cnHW2Aezv2W74PXkWbjOjNHDc5S%3DYuAagw%40mail.gmail.com.
