I was requested to do a review of the S12ZVML-MINIKIT / S12ZVML-MINIBRD and was looking for feedback on my review as well as the product in general from those within the NXP community and more specifically the S12 community. The full review can be found on Element14's website here. I look forward to the feedback and comments from the community.
Having been asked by Element14 and given the option to review a second small motor control board I couldn’t pass up the opportunity. The S12ZVML-MINIKIT, developed by Freescale and rebranded by NXP, is a motor controller evaluation board. Its intended use is with 3-phase BLDC and PMSM motors in sensorless control applications. These include cordless tools, automotive applications, as well as others where low cost is important. Keep Reading...
I'm really glad that there is some feedback on the product. I'm not going to comment on the documentation, but I'd like to give you some comments on the technical matter.
Just a general introduction: personally, I have studied electric drives at the university, I have done my PhD in related field and I have intensively worked with sensorless motor control for 4 years now. Even after that I cannot say that I fully understand AC electric drives. And the same you can hear even from established professors - the more you know, the less you understand (or the more you realize how much you don't understand).
Just to clarify, the S12ZVML-MINIKIT is a tool, which helps educated people to start with a very basic application, which is based on widely known field-oriented control (PMSM) or six-step/block commutation (BLDC). If one doesn't understand how FOC works, I agree it would be very difficult to understand the application. On the other hand, 10 minutes of reading some quick start guide cannot replace 2 semesters and more of electric drives course. I agree that there are gaps in linking the documentation, which is already available, even dedicated to another product, but using the same approach. Normally (if a link is provided correctly) you would follow this document: https://www.nxp.com/docs/en/application-note/AN4912.pdf or this one https://www.nxp.com/docs/en/application-note/AN4642.pdf. The AN5327 https://www.nxp.com/docs/en/application-note/AN5327.pdf is providing information on the FOC control implementation, however, it's worth to look for more info, even a basic one at 3-Phase PMSM Control Workshop with NXP's Model-Based Design Toolbox or some external sources.
My feeling is, that customers expect to have a mobile flight simulator game experience and with that background, to fly a real aircraft with the same results. Maybe an exaggerated statement, but many times not so far from the real expectations.
Why this product is not so easy to use? The application itself has to be open enough to be used by professionals and that has been successful so far. Our experience is, that even if there are some generic use cases, many electric drives have to be threaten case by case. Making a super-generic application can do a good job with a specific demo motor, but especially in automotive applications, more fine-tuning and maybe some additional algorithms need to be added. EDIT: Therefore, any "smart feature" simplifying the user experience would make it hard or even impossible to add these advanced features.
For a new-bee, a motor is just spinning, slow or fast, left or right and that is good enough. For a professional, low acoustic noise, high efficiency or high dynamics make the difference.
From your testing, I can see that you are not familiar with the open-loop start-up sequence of sensorless drives. Why? Your sensorless settings are using 200 RPM as the Mergin speed 1 and the same setting for Merging speed 2. In the default settings, these are set to 150 RPM and 300 RPM. There are also some other settings changed especially in the speed loop control, which may cause an unexpected behavior. If this was the test case, then it was an example of misused settings. It would be fair to mention that random tuning of random values and expecting the application to run perfectly fine is just not the approach an engineer would do with such a development platform.
Testing the application at 100 RPM indicates that you are forcing the application to run in the region it was not designed for. In model-based sensorless operation, the field-oriented control works with BEMF observer roughly from 10% of the base (nominal) speed. In the MCAT, sensorless operation starts from the Merging speed 2, which is 200 RPM by your setting. Below this speed, the motor is designed just to speed up, not to operate continuously. And I would be very careful about saying that 200 RPM is perfect - based on my personal experience with the Linix motor, it would be at least 250 RPM, but it depends on the current limit, load and speed ramp. Errors thrown during the tests within the open-loop to sensorless transition are most likely connected to wrong settings of the open-loop start-up and the BEMF observer itself. There are many articles at IEEE Xplore covering this topic, in summary: even after years of research, there is no generic solution that works for all the motors. If certain setting works for one, it most likely will not work for other motors. And we are working on a solution which covers as many cases as possible.
It's worth to say that S12ZVML-MINIKIT is dedicated to automotive low-cost applications. It demonstrates how an application would look like in terms of almost minimal configuration for up-to 10 Amps of current (for sure, the on-board debugger is not intended to be part of the final application). There is also S12ZVM EVB or the devkit (MTRCKTSPNZVM128|Development Kit S12 MagniV | NXP ), which is probably the one you would be looking for, if more I/O pins and features are needed.
Thank you for the review, I believe it will rise some action items on our side.