Actions
Forum Thread Details
  • Replies 21 replies
  • Subscribers 2563 subscribers
  • Views 1560 views
  • Users 0 members are here
Related

Feedback regarding a companies comments on user expectations

kas.lewis

Hello All,

 

I was looking to get some connect regarding feedback I received from NXP regarding my review of their motor control eval platform. As I do not wish to sway sentiment one way or the other I will leave my comments for after receiving some feedback from the community. I would very much appreciate you open honest comments on both my review as well as the response to this review.

 

Thanks

Kas

 

The review can be found here, the company response/commnet can be found below.

 

 

Hello,

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.

 

Ad SOFTWARE

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.

 

Ad HARDWARE

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.

Parents

  • I thought your review was excellent and found it very interesting to read. At the end of the day a roadtest is a personal appraisal of a product and how well it worked in your particular review scope, that the vendors know before you are selected for the review.

     

    Communication in the engineering world is always an issue, especially from engineers working in niche areas needing to explain the workings of their products. All to often engineers are quick to believe that people should understand their explanations and if they don't then it is not the engineer that is wrong, but in reality it probably is. I agree with that acronyms should always be written in their expanded format first, or a list of acronyms provided with the documentation.

     

    Whilst it is great, if the person you are conversing with can understand your field and product, this is often not the case, and sometimes engineers do need to look at how they explain things and reduce their jargon. But, I guess, criticism is sometimes hard to swallow and I wonder if the company saw your review as more of a criticism than you probably intended.

     

    As @DAB has said, if your review has opened their eyes a little and made them realise some parts that they can improve on, then your roadtest has achieved more than any of mine ever have.

     

    Kind regards.

Reply

  • I thought your review was excellent and found it very interesting to read. At the end of the day a roadtest is a personal appraisal of a product and how well it worked in your particular review scope, that the vendors know before you are selected for the review.

     

    Communication in the engineering world is always an issue, especially from engineers working in niche areas needing to explain the workings of their products. All to often engineers are quick to believe that people should understand their explanations and if they don't then it is not the engineer that is wrong, but in reality it probably is. I agree with that acronyms should always be written in their expanded format first, or a list of acronyms provided with the documentation.

     

    Whilst it is great, if the person you are conversing with can understand your field and product, this is often not the case, and sometimes engineers do need to look at how they explain things and reduce their jargon. But, I guess, criticism is sometimes hard to swallow and I wonder if the company saw your review as more of a criticism than you probably intended.

     

    As @DAB has said, if your review has opened their eyes a little and made them realise some parts that they can improve on, then your roadtest has achieved more than any of mine ever have.

     

    Kind regards.

Children
  • in reply to three-phase

      wrote:

     

    ..sometimes engineers do need to look at how they explain things and reduce their jargon.

    Agree : ) it is a major benefit of RoadTests, that it is a good way for people to become world-experts at that : ) Products are complicated enough, it's a nice skill to have. Here people are not shy to even use colouring pencils to draw cute explanations : )

    I often think "what would Apple do".. even though I don't own an Apple device, I admire how they can really simplify tech so that everyone can understand and use their products.