标签: controller

MX16171D100 是个100V 耐压的理想二极管 OR-ing 控制器，代替高边防电流倒灌场景功能的肖特基或 PMOS ，为多电源 OR-ing 结构的电源产品提供低功耗，小型化的解决方案， 可被广泛的应用在通讯电源，汽车，新能源，电动工具，通讯，安防等领域 .， MX16171D100 采用无锡明芯微电子的发明专利内置多级电荷泵技术和高边浮地驱动技术解决了高侧驱动的应用问题 采用 100V 工艺的耐压等级覆盖了通讯 48V 电源， 72V 电源，以及电动工具的 20V ， 40V 和 60V ， 80V 和电动车的 54V ， 72V 和 90V 等应用的场景，使用多电池芯并联供电的储能，太阳能电池板并联防止电流倒灌等场景，在应用中建议客户把 Vs 偏执电压引脚放在输入端 Vin ，这样当 Vin 没有电压的时候，该电荷泵不工作，产品功耗低，当输入电压低于 5v 的时候，客户要采用外接电源的方式提供 5v 或者以上的偏置电压给 Vs 供电使得电荷泵正常工作 特别推荐客户在使用该产品或者美国TI产品的时候要把偏压Vs教放在输入端Vin做偏置电压，这样做的目的是防止在Vin没有电的时候，处于反向截至状态电荷泵还在从Ｖｏｕｔ取电导致有电流损耗 特征参数 1. 很宽的工作电压范围 5V-100V ，在不考虑成本的情况下能够覆盖最低 5V 和最高 100V 的应用，能够降低客户的产品使用个数，做到一个产品全电压覆盖 2. 110V 的瞬态工作电压而不会损坏 3. 采用内部多级电荷泵技术驱动外接 NMOS ，外接 NMOS 的大小可选，适用于不同电流应用的需求 4. 反向电流 50nS 的响应速度 5. 2A 的快速关断电流使得反向电流截至关断实际纳秒级 6. 通用的 DFN3x2 的封装尺寸 输入 VIN = 29V,VVS = VIN, IO=1A ， VOUT 从悬空到 30.9V （点触） , 测试从 VOUT=VIN 到 VGATE=VIN+1V 的时间 tGATE(REV)=96ns 从该图我们看出当输出电压（ 30.9V ）突然高于输入 (29V) 的时候，芯片快速响应，在 100ns 以内关断了外接 MOS ， Vgs 电压从 10v 降低到 0V Vgs 无论在输入电压是多少的情况下都能稳定的跟随在 10V 左右

A friend of mine works for a company that builds small radio-controlled boats used for fishing. They are called "bait boats." He took me to their company and showed me some of the boats they make as well as the electronics inside. The boats had a speed controller, one battery meter, and a light switch. When I saw the huge rat's nest of wires, I thought to myself, "Holy moly, what a mess in there with so many wires and connections." I asked my friend to ask his manager whether they would be interested in having me design a single board with a speed controller, battery meter, and light switch. The manager told him that I could start working on the design. I immediately started learning as much as I could about speed controllers with reverse for brushed motors. In the beginning, I started to learn about mosfets and about driving mosfet gates. I first made my tests driving mosfet gates using push-pull made of MMBT2222 and MMBT2907, following this tutorial . The first test was OK as seen in the video I posted on youtube . The only problem was that when the power consumption rose to a certain point, the mosfets were overheating. Unfortunately the push-pull was great, but the ringing on the mosfet gate was even greater, as shown by my ol' trusty Tektronix 2213A. Then I started reading about integrated mosfet drivers and found the TC4427 IC, which has two drivers in one SOIC8 package. I thought that using this driver wouldn't increase the price much, so I started drawing a schematic and designing the board in Eagle.     I used one cheap ATtiny24 as the brain, one L7805AC2T for 5V regulation, one TC4427 mosfet driver, two IRFZ44S N-MOS, and two IRF5305S P-MOS. This is the first testing of the board to check how well the TC4427 was driving the mosfet gates. The software was made in WINAVR, and I was using USBtiny AVR to program the ATtiny24A. After that test I knew it was the way to go! After spending a few days thinkering with the algorithm used to control the mosfets, I managed to find the best and easiest one, which was providing nice soft break when changing rotation direction or decreasing the speed, and a user button for throttle interval programming in an easy manner. The soft break is a must for a longer life of the transmission mechanics of the boat. In the beginning the speed controller does not have the throttle interval programmed, and you can see how easy is to program it! Now this controller is used in my little foam boat.   After the speed controller algorithm checked out, the next step was designing the board for the little bait boats. In a few days the result was a speed controller with light swich, buzzer for battery level alarm, and button for programming throttle interval. It consisted of two boards: the control board and the power board. I used an IRF4905S P-mosfet and IRF3205S N-mosfet for greater power and the same TC4427 mosfet driver. The guys have been pleased with how the speed controller works, and now they use it in their boats. The price to manufacture is a lot less than other commercially available speed controllers, and the soft brake makes boat owners happy. Currently, I'm working on another version with four mosfets for forward and two for backward, because the bait boats need full throttle forward and half throttle backward to protect the propeller from the algae. This story was submitted by George Bogdan for Frankenstein's Fix,a design contest hosted by EE Times (US) . Nedelcu Bogdan Sebastian is 30 years old and studied computer science in high school and finished Politehnica University in Romania. He loves microcontrollers and embedded programming. He has just finished a successfull Kickstarter for the Matchbox ARM development board.

If you ask engineers about their favourite childhood toys,  you're likely to hear a list of nostalgic staples that sparked innovation in all of us who went on to solidify our calling with the title "engineer." We loved these toys because they allowed us to think of an idea and then actually create it. But, what happens to these young innovators as they become engineering students and their ideas become more complex? Until recently, these students discovered that the gap between toys and industrial tools was an ocean of devices that either catered to their budding yet incomplete knowledge or provided the depth of technical functionality desired, but never both. Identifying and understanding this deficiency, National Instruments (NI) wanted to create a solution that would provide the ease of learning that students need, while also giving them the power to release their creative potential within the time constraints of a class. For over 30 years, NI has witnessed some of the world's most established engineering companies, as well as some game-changing innovators, like CERN and SpaceX innovate and create incredible systems using our test and measurement technologies. But what about the engineers of tomorrow? How do LEGO bricks and Tinker Toys progress to life-saving medical equipment or the next hybrid electric vehicle? For several years, NI has thought about this question and—in 2013—provided an answer by releasing a new product for students—NI myRIO. Inspired by the same technology NI has provided to industry customers for years, NI myRIO equips today's students with the tools of their future careers (click here to see a video). NI myRIO is based on the same LabVIEW RIO architecture as NI's industrially used NI CompactRIO and NI Single-BoardRIO products. These products combine a processor, FPGA, and I/O, and are fully programmable with LabVIEW. In fact, NI myRIO uses the same Xilinx Zynq All-programmable SoC technology found in NI's newest CompactRIO, the cRIO-9068. Complete with 40 digital I/O lines, 10 analogue inputs, 6 analogue outputs, onboard accelerometer, LEDs and programmable button, students get to leverage copious reconfigurable I/O and boast the use of NI's first WiFi-enabled RIO product all in a handheld device. But, the hardware is only half of the equation. Surely we can't expect students to jump into the same programming complexity as seasoned, professional engineers, right? Well, at NI, we agree. Fortunately, LabVIEW has provided the handshake between the possibilities of industry and the first-year college student. NI ships the FPGA of myRIO pre-defined with AI, AO, PWMs, Quad Encoder inputs, UART, SPI, and I2C. Of course, using LabVIEW FPGA, students can choose to change this shipping personality if a project warrants it (and yes, they can always revert back to the default). While the NI myRIO processor and FPGA can be programmed in the exact same manner as its industrial counterparts, we wanted to offer students some help to quickly access I/O out of the box. LabVIEW provides 12 configuration-based Express VIs specifically for myRIO that allow for instant access to the pre-defined FPGA I/O without the need for extensive programming. When students are ready expand their programming skills, they can view the underlying code of any myRIO Express VI and can begin using that code to program in a more advanced mode. All pre-built LabVIEW functionality for myRIO is open, meaning that a student has the option to explore even the lowest level handshake between processor and FPGA.   Students connect to their myRIO via USB (versus traditional Ethernet) or WiFi to deploy code and monitor results. The ultra familiar and ubiquitous USB connection removes the complexity associated with Ethernet connectivity and WiFi allows students to access their device remotely with their PC or tablet. Rounding out the device's flexibility, students can also choose to leverage Linux and C/C++ to program the hardware with the popular Eclipse IDE. When designing myRIO, NI engineers were adamant that students engage in real system design not upon graduation, but now. We specifically chose the features and massaged the user experience to transform engineering students into full-fledged system designers, even providing a free guide for incorporating common components. Knowing that this product would play a role in the classroom with leading universities around the globe, NI is rolling out courseware that will address competencies in Embedded Systems, Controls and Mechatronics based on NI myRIO. In fact, Rice University has already incorporated NI myRIO into their Modelling Dynamic Systems curriculum using the popular haptic paddle force feedback device. NI myRIO encourages students to let their ideas run wild and provides them with the hardware and software to get the job done. Based on NI's industry recognised RIO hardware, the latest gadget for young engineers is anything but a toy. Check out the latest Waterloo Labs video— The Paintball Picasso System . This system is controlled by the NI myRIO embedded controller and LabVIEW software that enables the system to be controlled is a variety of ways, including taking an image from a USB webcam in order to outline the person, shooting more than 10 paintballs per second. You may rest assured that no students were harmed in the making of this video. About the author As product manager for Controls, Robotics, Mechatronics, and Embedded (CRoME) on National Instruments' Academic Marketing team, Margaret Barrett is responsible for building awareness of NI's offerings in the university space for these application areas. Margaret is a five-year veteran at National Instruments, where she began her career as an Applications Engineer and later transitioned to managing a subset of the AE department. Before joining National Instruments, she attended Texas AM University where she earned a degree in biomedical engineering with an emphasis in biomechanics in addition to earning a minor in mathematics.  

Discussions on favourite childhood toys are likely to yield a list of nostalgic staples that sparked innovation in all of us who went on to solidify our calling with the title "engineer." We loved these toys because they allowed us to think of an idea and then actually create it. But, what happens to these young innovators as they become engineering students and their ideas become more complex? Until recently, these students discovered that the gap between toys and industrial tools was an ocean of devices that either catered to their budding yet incomplete knowledge or provided the depth of technical functionality desired, but never both. Identifying and understanding this deficiency, National Instruments (NI) wanted to create a solution that would provide the ease of learning that students need, while also giving them the power to release their creative potential within the time constraints of a class. For over 30 years, NI has witnessed some of the world's most established engineering companies, as well as some game-changing innovators, like CERN and SpaceX innovate and create incredible systems using our test and measurement technologies. But what about the engineers of tomorrow? How do LEGO bricks and Tinker Toys progress to life-saving medical equipment or the next hybrid electric vehicle? For several years, NI has thought about this question and—in 2013—provided an answer by releasing a new product for students—NI myRIO. Inspired by the same technology NI has provided to industry customers for years, NI myRIO equips today's students with the tools of their future careers (click here to see a video). NI myRIO is based on the same LabVIEW RIO architecture as NI's industrially used NI CompactRIO and NI Single-BoardRIO products. These products combine a processor, FPGA, and I/O, and are fully programmable with LabVIEW. In fact, NI myRIO uses the same Xilinx Zynq All-programmable SoC technology found in NI's newest CompactRIO, the cRIO-9068. Complete with 40 digital I/O lines, 10 analogue inputs, 6 analogue outputs, onboard accelerometer, LEDs and programmable button, students get to leverage copious reconfigurable I/O and boast the use of NI's first WiFi-enabled RIO product all in a handheld device. But, the hardware is only half of the equation. Surely we can't expect students to jump into the same programming complexity as seasoned, professional engineers, right? Well, at NI, we agree. Fortunately, LabVIEW has provided the handshake between the possibilities of industry and the first-year college student. NI ships the FPGA of myRIO pre-defined with AI, AO, PWMs, Quad Encoder inputs, UART, SPI, and I2C. Of course, using LabVIEW FPGA, students can choose to change this shipping personality if a project warrants it (and yes, they can always revert back to the default). While the NI myRIO processor and FPGA can be programmed in the exact same manner as its industrial counterparts, we wanted to offer students some help to quickly access I/O out of the box. LabVIEW provides 12 configuration-based Express VIs specifically for myRIO that allow for instant access to the pre-defined FPGA I/O without the need for extensive programming. When students are ready expand their programming skills, they can view the underlying code of any myRIO Express VI and can begin using that code to program in a more advanced mode. All pre-built LabVIEW functionality for myRIO is open, meaning that a student has the option to explore even the lowest level handshake between processor and FPGA.   Students connect to their myRIO via USB (versus traditional Ethernet) or WiFi to deploy code and monitor results. The ultra familiar and ubiquitous USB connection removes the complexity associated with Ethernet connectivity and WiFi allows students to access their device remotely with their PC or tablet. Rounding out the device's flexibility, students can also choose to leverage Linux and C/C++ to program the hardware with the popular Eclipse IDE. When designing myRIO, NI engineers were adamant that students engage in real system design not upon graduation, but now. We specifically chose the features and massaged the user experience to transform engineering students into full-fledged system designers, even providing a free guide for incorporating common components. Knowing that this product would play a role in the classroom with leading universities around the globe, NI is rolling out courseware that will address competencies in Embedded Systems, Controls and Mechatronics based on NI myRIO. In fact, Rice University has already incorporated NI myRIO into their Modelling Dynamic Systems curriculum using the popular haptic paddle force feedback device. NI myRIO encourages students to let their ideas run wild and provides them with the hardware and software to get the job done. Based on NI's industry recognised RIO hardware, the latest gadget for young engineers is anything but a toy. Check out the latest Waterloo Labs video— The Paintball Picasso System . This system is controlled by the NI myRIO embedded controller and LabVIEW software that enables the system to be controlled is a variety of ways, including taking an image from a USB webcam in order to outline the person, shooting more than 10 paintballs per second. You may rest assured that no students were harmed in the making of this video. About the author As product manager for Controls, Robotics, Mechatronics, and Embedded (CRoME) on National Instruments' Academic Marketing team, Margaret Barrett is responsible for building awareness of NI's offerings in the university space for these application areas. Margaret is a five-year veteran at National Instruments, where she began her career as an Applications Engineer and later transitioned to managing a subset of the AE department. Before joining National Instruments, she attended Texas AM University where she earned a degree in biomedical engineering with an emphasis in biomechanics in addition to earning a minor in mathematics.

I am hoping someone comes forward with suggestions with regard to the question posed in the title of this blog. Let me illustrate the problem... I once designed a controller to heat a tank of liquid. Depending on the size of the tank, the customer would configure the system to use from one to six natural gas burners. In other words, there were systems with a maximum of two burners, some with four, and so on. There were also mixers in the tank, where the number of mixers corresponded to the number of burners. There was an analogue input that determined the system "demand" and—based on that demand—a number of burners (between one and the maximum) were ignited and the mixers (tied to a single control) activated at a particular RPM. As the demand increased, so the number of burners increased. Starting at one burner, the mixer RPM increased until a maximum was reached, at which point the RPM would then drop and the number of burners would be incremented. As the demand decreased, so the reverse happened (with hysteresis, of course). To add complexity to this sequence, igniting a burner was achieved with an external controller for safety certification reasons. Ignition could take up to 15 seconds; if it didn't succeed, a further two attempts would be made before the burner was deemed "inactive." If a burner was extinguished while operational, an attempt would be made to restart it. If a burner failed to ignite, the controller would note this, exclude it from further operations, and initiate the next burner in the sequence. When attempting ignition, all the mixers had to be reduced to a minimum rotation. However, the mixers had to be run at maximum RPM for one minute before attempting to ignite the first burner and for one minute after all of burners had been turned off. The system also controlled the level of liquid in the tank, and that level would be used enable or disable the heating process. The system had two different LCD character displays, one of which supported four languages. It was possible to display metrics on these displays and use them to modify dozens of parameters. I cannot imagine how many different operational combinations there were, and I have described only a ~40% subset of the actual requirements. As I developed the program, I debugged and proved it. It was a mammoth task. Since I knew the software so well, it was possible to extrapolate certain tests and to economise on some time; however, I had to test where there was any doubt at all. Once I'd completed everything, the customer went through acceptance tests. Realistically though, how do you try every conceivable set up and failure condition? Of course, the first time a system like this is used, everyone involved will be especially careful, but what happens further down the road? Many months after I'd completed the original system, the customer came back with a modification request. A Modbus serial link was added to the system, not only to report the metrics remotely, but also allowing the parameters to be adjusted as well as replacing the analogue demand with the demand determined over the serial link. This was a big change, but theoretically even small changes should be studied seriously for their impact. How can you validate the changes you make economically? How can the customer be sure that a bug has not been introduced through some forgotten linkage? I once performed a calculation showing that testing every combination with every time delay would take 10 years of continuous testing! Of course, there are defensive techniques like modular programming and test-driven development to aid the development process and prevent errors, but how can you actually prove that your design is error-free? I am not even talking about safety certification—just being able to ship a bug-free product. I have come across organisations at events like Design West that claim they can design a suite of tests, but aside from the cost (and surely they aren't cheap) they require a set of accurate specifications. If I am lucky, I start out with a requirements document, which subsequently remains static while ongoing changes and clarifications are recorded by means of numerous emails and notes. How do you address these issues? Any advice will be very gratefully received. Aubrey Kagan Engineering Manager Emphatec