Hi, check this out.
I get this output in my Serial Monitor every time.
If my sensor is in fact not aligning and this is why Init FOC fails, I’m expecting something like this:
Maybe there’s a way to disable the ---Terminal on COM20...Ctrl+H block from popping up. Would be funny if the four missing MOT: ... lines were hidden behind the four lines of the block, haha!
Otherwise, what could be the issue? Anybody know?
I’ve seen this happen regularly with all kinds of projects when I’m using platformio. I think that what might be happening is that when you run the pio program and monitor task, it compiles, grabs the serial to program your device and when that has finished the device starts running while the serial line is passed to a new process giving you the serial console. So because the device starts running as soon as it gets reset after programming and is not waiting for the serial monitor to be initialized some of its initial serial output can be lost. If I really need to see those first few lines I’ll just reset the device after the serial monitor comes online and it will initialize and print those first few lines again but this time with the monitor already active.
Hey thanks for the idea. My board doesn’t have a reset button, so I just tried doing if from software, so void(* resetFunc) (void) = 0;//declare reset function at address 0, and then calling resetFunc(); to do a reset within the loop() if I send a 1 from the Serial Monitor. Stuff stops, yes, but then it doesn’t boot up. Sadness.
I don’t think you can just jump to address 0 - that will be the boot-loader, and the system conditions probably won’t match what it expects? Which MCU type are you using?
In any case I think you can solve your problem by adding a short delay at the start of your program to give PlatformIO to connect the serial console… 2 or 3s should be sufficient.
Some setups (depending on MCU and the type of serial connection) also support waiting for the host to connect by doing:
while (!Serial) { delay(1); };
Yes, I had this idea today and it worked! Thanks for taking the time to reply, either way.
I am a little worried that there are consequences to putting in a delay because for some reason I see MOT: Driver not initialized, not sure why…Well, it’s not like I could see it earlier at all, so happy with the progress.
I’ll share my findings in the morning. I’ll be doing Serial.begin and 3s delay at the start of setup because it seems to work.
(I’m working on a B-G431B-ESC1. Any idea if it needs any build_flags in platformIO? I see them included in examples but it’s 2023 now and the platformIO support for the board seems to be there. MCU is a STM32G4)
Hey,
One thing I note: you’re missing the lib_archive = false in the platformio.ini
Without it there is no PWM output, so its clear why the motor doesn’t spin even in open-loop…
BUT!
BUT if you enable it, and get PWM, then I think you have to be really careful with the motor you’re using…
I see you have a voltage_limit of 0.036… set. This is good as it will offer some protection, but it might be too low to get movement, you’ll have to see…
There’s a dependency here on the PWM resolution, if the driver.voltage_power_supply is 24V, and the limit is 0.036V, then the system can only output 0.0018 * pwm_resolution different levels, that might be too little…
The agro example doesn’t set voltage limits, be sure to set them before running it with the lib_archive = false added!!!
Set a global limit using driver.voltage_limit = 0.01f; or something like this.
Set a motor limit using motor.voltage_limit = 0.005f; half the driver limit is good as this limit acts on the Q axis voltage, which can be positive or negative.
The example also doesn’t call motor.move() and motor.loopFOC() in the main loop, I’m not sure the monitoring can work without them.
See our “full control” examples for inspiration…
My code has seen quite a few amendments in the past day or two. There are a few obvious things missing that I spotted after my last commit, like motor.move and motor.loopFOC, but lib_archive = false was not one of them! Thanks so much for even having a glance. It will take me a few more days before I’ve got a handle on the repo, it’s kind of big. I’ll definitely be keeping my threads here active this week.
If the board has no reset you could always just remove and reapply power. The delay at start or wait for serial options are far more elegant though, especially if you put them behind an #ifdef Debug or something so it doesn’t mess with the device when you finish development and deploy it.
Got some working code. Updated my repo. Commander works, motor.monitor works, and to be honest I’ve ommitted setting driver.voltage_limit and just set motor.current_limit. Got some good results but at a higher speed things got very hot. Tried to do 20A. Impressed with the ESC1 so far. This was on velocity_openloop mode.
You can use the button on the B-G431B-ESC1 to trigger an interrupt and in the interrupt routine you can reset the board (I am away from home, so can‘t tell you the name of the reset function). I use it all the time during development.
/Chris
That’s what I was thinking! Off the top of my head, I think the button maps to pin PC6 or PB6 or something like that, but…well it seems it will work if I find the reset function/routine you’re talking about. I know I’ve seen it used recently. Thanks.
This is how I use the button on the B-G431B-ESC1:
void ButtonIrqHandler()
{
motor.disable();
HAL_NVIC_SystemReset();
}
void setup()
{
attachInterrupt(digitalPinToInterrupt(A_BUTTON), ButtonIrqHandler, FALLING);
pinMode(A_BUTTON, INPUT);
}
Godsend. Big thank you! I’ll include this is my main on Monday.
