At such low current you may not benefit from current sensing.
Check the Mosquito design, it may have most of what you need but you need to replace the MCU.
Cheers,
Valentine
Thanks Valentine. Your mosquito will be great for cross checking! Nice board.
Why does low current mean I won’t get much benefit from current sensing, too noisy? Or do you mean the low currents mean that I’ll not have much bemf i.e. Vin ~= I *R works well at these slower speeds?
I’ve never been happy with the cogging I tend to see with smaller gimbals at low speed/low load (closed loop) and thought perhaps current sensing was the answer.
1 Like
Seems about right.
That’s a motor design problem, anticogging algorihm is needed there. I’m not sure current sensing would make any difference.
You may be able to mostly avoid it with a well designed motor. But that’s $$$.
Cheers,
Valentine
Here’s a thread discussing anti-cogging Anyone interested in collaborating on anti-cogging (lowest hanging fruit for smoother motion) - #43 by Candas1
Candas1 linked a good article in post #37.
Hey @Owen_Williams so nice to see you back 
Maybe take a look at the MPS (monolithic power) drivers also? I especially like the MP6540 but there’s a few to choose from…
1 Like
I snagged some very low cogging motors, they are very hard to find. You want what’s called a ring magnet. It’s the SM type motor, most are the IP type. The IP type use flat plate magnets, the SM use curved magnets. However I think it’s because the ring magnets have no gaps in between the magnets.
However they are quite hard to find and yes expensive, so I think it would be a really good idea to figure out some anti cogging stuff. Once the software is written then anyone in the world can use a cheaper easier to get motor and get the same results as an expensive hard to find motor. Progress.
Owen, why do you need integrated FETs? It shaves some $ off but is the per unit cost the main thing?
I also would like to use one of the G431 chips as the higher clock speed and M4 core with floating point has floated to the surface as important features, and I know someone else that I think would like to go that route, and the current is also in the same region as what you need. I think maybe we should collaborate.
The lepton runs the motor.move(target) command at 5 khz in open loop, while it runs at 37.5 khz on the b-g431B-ESC1 board, so it is way faster. Also less glitching and noise, although these may be soluble through other means, that floating point hardware and faster clock rate is clearly useful in this context for sure.
As I see it, the next really big SimpleFOC dev. Is Klipper integration, which will enable Gcode controlled machines, to run w. SimpleFOC.
@Owen_Williams
I’m about to start assembling the Field Stack Beta Run. Why not just focus on Klipper ?
SimpleFOC has a Step/Dir interface. If you connect that interface to the output of a microcontroller running something like GBRL, couldn’t you make SimpleFOC work with GCODE?
Interpreting GCODE in my opinion is completely outside of the scope of engine drivers. There are countless variants of GCODE that you have to specify when using a CAM tool.
That is the whole point. If using Klipper w. SimpleFOC, we don’t need the usual step-generating MCU.
Each node will then work like sub-drivers in OPnP
@JorgeMaker maybe you should reed up on Klipper. Klipper interpret Gcode and sends the move commands to each node. Or turn on LEDs, heat-bed, etc.
But of course, diving into actual USB implementation, like Klipper does. Will either make your Studio useless or you will have to upgrade that with a real USB option (64-bit)
Maybe Klipper will be the place to monitor data while in use?
Recent dev. On Klipper → https://github.com/Klipper3d/klipper/tree/master/src/stm32
USB EP
// Setup the transfer descriptors in dedicated usb memory
static void
btable_configure(void)
{
epm_ep_desc_setup(0, USB_CDC_EP0_SIZE);
epm_ep_desc_setup(USB_CDC_EP_ACM, 0);
epm_ep_desc_setup(USB_CDC_EP_BULK_OUT, USB_CDC_EP_BULK_OUT_SIZE);
epm_ep_desc_setup(USB_CDC_EP_BULK_IN, 0);
}
I was planning to release a g431 lepton variant, when i get some time.
1 Like
Valentine, that’s awesome, I know another guy that is also going down this road, I think we should totally collaborate, I’m waiting to hear back more of his thoughts by email. Releasing a proposed draft could be a good way to do that for sure. I think the guy I know may be willing to pay for getting boards made, and I can help with testing. I think this is going to be a really good thing for the community
Yo can develop an interpreter of Klipper commands making possible to run Klipper on the same microcontroller that you are using for your SimpleFOC instance, effectively creating a “Klipper Node.”
However, in my opinion, this is not in line with the purpose of SimpleFOC, as it operates at a higher layer. If you look at examples such as oDrive, VESC, or Moteus, none of them go beyond basic motion planning for a single axis.
It’s going to be very close to the Lepton may be with more pins broken out. Then people can use it to mod the board as they need.
I moved this discussion to the proper thread;
I’m still getting back into simplefoc, so klipper/gcode isn’t on my mind at the moment. There are quite a few great boards in development, but like most people I want to make my own!
I’m likely to go the drv8316 route, my pcb design skills and rusty electronics knowledge makes the onboard 200ma buck, integrated fets and current sensing appealing.
Once I’m comfortable with my board/motor setup. I’ll work on a combined power/brain board controlling multiple motor boards perhaps with a bit of ML/vision recognition.
3 Likes
@Owen_Williams I like the DRV8316… there’s a working design I did here:
its in the shape of shield for Arduino MKR sized boards.
There’s also a design by Adin here:
which has an on-board SAMD21 MCU. Check his thread if you want to use the buck to power the MCU and have the system self-start
I agree with you on this @JorgeMaker, I would not add Klipper code to the main SimpleFOC library. I think only a small proportion of users would be interested.
But for those that are interested in this, I think we could make a Klipper-SimpleFOC library which builds on top of SimpleFOC. But someone would have to want to invest the time and effort not only to do the code, but also the examples and documentation… I think it would be a big project in the end.
2 Likes
I very much agree with modularity and separating libraries is part of that. I do however think that a driver that can accept G-code like commands looks like it’s particularly useful. There seems to be a trend down this road with stepper motor drivers and so on. Ultimately it’s more modules, more kits, if good modularity is employed more modules never hurts, you use which ones you need and when and extra ones don’t slow anything down or whatever. We are not at the stage where we need to worry about clutter in the ecosystem. The main thing is indeed the amount of work vs the priority level. Being fairly well acquainted with CNC machines and their electronics, you can generally get your module that interprets G-code and controls the dumb robot made as the ecosystem stands. Controlling the motors directly with grbl or linuxcnc or Marlin is in the bag already and having communication interfaces as is done between the tmc2209 chips and marlin in some cases has downsides. I know it prevents the use of linear advance for instance because you can’t update the speed of the stepper motor quite fast enough to do that kind of detailed motion stuff. I think input shaping could also be harmed by such an approach. I think the best approach in that exact context, where very precise motor control is required, is a blazing fast processor and everything from gcode to step/dir or whatever on one chip.
I agree with all of you regarding Klipper. It’s awesome to be amongst such wisdom in programming.
@JorgeMaker it will be fun to see how we can use the existing step format from Klipper. I think we just have to look at is as a variable rad/resolution, which should be set according to encoder resolution. So instead of sending actual step pulses to the TMC driver or what ever. We send move commands within the context of the machine dimensions. How this performs is a great unknown. Maybe it is best suited for dual core MCUs. But then again, why not move the conversion to the mainframe and send out floats to the MCU…
Thinking some about this, @runger I agree the workload to make Klipper talk SFOC (rad’s in floats) is a huge undertaking, nonetheless something that is possible and could be a option down the line. Maybe the Klipper community is not all interested in this, and would rather just remain in the comfort of the proprietary stepper drivers. The fastest way to actually showcasing it, is definitely going with the step format and conversion to rad’s.
@Owen_Williams hope it’s ok that we wrap this theme up in here. I’m looking forward to see your progress!
@Anthony_Douglas
I agree, the potential is there. Let’s unlock it.
A side note, since breaking in the Field Stack I did manage to completely mess up my sleep, so I’ve been somewhat short tempered. It’s all good. Keep up the great work.