Normally Raptor™ Electronic Control Units (ECUs) support the capability of awakening in response to a voltage on the ignition or wake line, typically identified as ‘WAKE_INPUT1’ on the datasheet. Additionally, some Raptor ECUs support the capability to configure the unit to wake on another environmental stimulus such as an incoming CAN message, or a change on the LIN bus. This capability can be used in many application situations, such as to wake up internal controllers when the vehicle door is opened. This Power User Tip provides an overview of configuring the software to accommodate these scenarios.
Along with this Power User Tip, we have prepared a sample model so you can follow along.
You may download it here.
Setting the Wake Source
For this example, we will be enabling Wake-On-CAN for CAN3 on this ECU. To configure the ECU to awaken based on messaging on CAN3, we implement an App Trigger set to execute on Startup. Inside that subsystem, we use the ‘Set Hardware Option’ block to configure the WAKE_SOURCE for the ECU.
This configuration change will take effect after the first power-up after programming. The ECU will need to be awakened via WAKE_INPUT1 (Ignition) to be available for programming. This input is always enabled for waking the ECU regardless of what other sources you may have configured.
Reading the Source of Wake
Typically an application will want to determine the wake source or reason that it was awakened. In the normal case where the ECU is only able to be awakened via the WAKE_INPUT1 (Ignition) input this is often simply implied because in that case there is only one way to wake the ECU. In cases where there are multiple wake sources available, the application may need to use different logic for keeping the ECU awake based on which source is responsible for the wake up. To read the WAKE_SOURCE, you can use an ‘Internal Measurement’ block as shown below.
Controlling ECU Shutdown
When utilizing a communication-based wake source (CAN/LIN) there must not be any bus traffic on the wake source. On many systems, this network management determines when the modules go to sleep through a messaging protocol. If your controller is the master, you will need to tell other devices when to shut off their broadcasting and go to sleep. If your module is not the network master, you will need to honor network management as a slave and allow the other modules to go to sleep by shutting off broadcast. An alternative to a protocol based network management would be to shut off the power from all other ECUs to ensure they stop broadcasting.
In a basic standard operating scenario where the ECU is waking based on an ignition line, the ECU will stay awake as long as the ignition line stays high. When the line goes low the ECU will typically tidy up, store Nonvolatile Memory, and then go to sleep. In the case of Wake-On-CAN, the logic needs to be a little more complex. CAN messages arrive at various intervals. Assume a single message on the CAN bus being sent at a 500 ms rate. That is likely enough time for the ECU to wake, store Nonvolatile Memory, and go back to sleep. You would not want to wake, store and sleep every 500 ms as you would quickly wear out the storage memory. More likely, you would want to Wake-On-CAN and stay awake as long as you see messaging, perhaps sleeping after messaging stops for 10 seconds.
In order to implement that, you could implement a timer that counts up every Foreground execution.
Then whenever you see the message you need (in this case we are looking for 0x4000 extended specifically), you would reset the counter.
Then, in the power-down subsystem where the ECU power control is implemented, you can determine the wake reason and use the timer to keep the ECU awake as long as messaging is coming in every 10 seconds.
Here we have implemented updates to keep the ECU alive based on either the WAKE_INPUT1 source or in the case of a Wake-On-CAN for 10 seconds after the last expected CAN message (ID 0x4000 extended).
The sample model provided gives an example of an implementation for developing a Wake-ON-CAN solution for Raptor ECUs. For any questions or concerns, please New Eagle’s Support page.
Bonus Tip on GCM-5605B-048-1906:
This module has a hardware-based wake source that doesn’t have any software configuration to select the wake source. It will wake from the key switch, CAN2 or LIN2. This means any of these sources will wake the module and keep it from going to sleep once woken. As a result, you will need to perform network management on CAN2 and LIN2 if utilized in your system.
New Eagle offers a variety of ways to keep up to date with their Raptor Suite of Tools. Sign up for the Raptor Newsletter to learn more about how the Raptor Platform can take your solution to production.
As 2019 comes to an end, the Raptor platform celebrates new beginnings with everything from the release of Raptor 2019b to extensions to its hardware product line. Keep reading to learn what’s new, or subscribe to our Raptor News for notifications of the latest updates delivered right to your inbox.
Raptor-Dev is now better than ever with significant improvements to CAN and DBC blocks, and nearly 50 items implemented or resolved in total, including:
- Support for Mathworks 2019b
- VeeCAN: Added USB support for VeeCAN500, Simulator improvements
- GCM196: CAN driver tuning options added, several optional build issues resolved
- GCM48: Upcoming support for this new low-cost, high-capability ECU
- J1939: Updates for Diagnostic Messaging support on multiple CAN busses
- LIN block improvements, including support for upcoming LIN slave capability
Download Raptor-Cal 2019b to take advantage of better performance, usability, and memory usage, plus nearly 30 additional improvements, including:
- Significant updates for performance and memory usage
- DAQ list management performance and consistency updates
- Calibration Transfer & Compare workflow improvements
- Datalogging enhancements
Raptor 2019b Release Webinar
Go in-depth on Raptor 2019b by joining our Raptor 2019b Webinar on January 16, 2020.
We’ll highlight what’s new in the 2019b release, preview what’s planned for the 2019b_2.0 and 2020a releases, and update you on future hardware training resources, all with time for Q&A.
Register now so you don’t miss out!
Hands-On Raptor Training
Learn how to use the Raptor platform in the MATLAB® and Simulink® environment to create real-world applications by registering for our three-day, embedded model-based development (eMBD) Raptor Training program on January 21-23, 2020.
Sign up now before space runs out!
NEW! GCM 48
The GCM 48 is joining the Raptor product line as a rugged, low-cost option for budget-minded developers. Featuring 6 CAN buses, 3 LIN Masters (one capable of LIN slave programming) and configurable discrete inputs and outputs, now’s the time to place your pre-order by contacting our team!
New Eagle is thrilled to announce that founder Mickey Swortzel is listed among the Top 50 Women 2 Watch in 2020 by the Women Presidents’ Organization (WPO). These top 50 women run day-to-day management as the CEO/president/partner of privately-held, multi-million dollar service-based companies.
“It is an honor to be named to this list of exceptional women,” says Mickey Swortzel. “But more than an award for myself, it’s an award for our team and our customers. We’re doing exceptional work in the autonomous and EV/HEV industries. This award speaks to the value we’re bringing to our customers and opportunities for our team.”
What Is Women 2 Watch?
Women 2 Watch sheds light on the impact of women-led companies on the global economy. To determine who ranks in the top 50, the WPO uses a mathematical formula combining percentage with absolute growth. The WPO then calculates whether each company has experienced significant prosperity from 2014 to 2019. along with promise for increased growth moving forward.
“Every year we have strong contenders from within the WPO membership for The Fifty Fastest Growing Women-Owned/Led Companies™ list,” says WPO Chief Executive Officer Camille Burns in an official statement. “This year it will be sponsored by American Express. We think it is extremely important to recognize these successful women around the world who are thriving. The economic impact of these women-led businesses on the global economy is being felt directly through the jobs they create and the communities they serve.”
About the Women Presidents’ Organization
The WPO is a peer advisory organization founded with the goal of connecting leading women across six continents to help each other progress their businesses’ success. Each month, chapters of 20 women presidents from a range of industries meet to share their business experience and expertise.
We proudly extend our congratulations to Mickey and her fellow awardees as we celebrate being one of many women-owned businesses worldwide. If you or someone you know is interested in applying for the 2020 Women 2 Watch list or joining the WPO, visit the WPO website for details.
Join us for our popular Raptor Training program where participants will receive hands-on training with our embedded model-based controls, Raptor platform.
Tuesday, January 21 – Thursday, January 23, 2020
New Eagle Headquarters
110 Parkland Plaza
Ann Arbor, MI 48103
If you cannot attend the first training of the new year, reach out to our sales team to inquire about additional options customized to your needs. Also, be sure to subscribe to New Eagle’s Raptor newsletter to stay informed about our Raptor Platform’s tips and tricks, updates and future classes.
What to Expect in Raptor Training
Attendees will use a throttle body controller project as an introductory guide to Raptor-Dev in the MATLAB/Simulink library. This will allow them to create a model intended for a target piece of hardware. Then, participants will use Raptor-CAL to flash the compiled software onto the hardware and make live calibratable adjustments on the flashed ECU.
On-Site, Customized Raptor Training Options
Can’t make it or prefer a more personalized training of New Eagle’s embedded model-based development tools? Our Raptor experts can travel to your team’s work facility for hands-on instruction catered to your needs.
To learn more about these options and schedule a training at your location, email us at [email protected].
REGISTER NOW as we only have a few seats left!
In MATLAB R2019b, MathWorks released a new Simulink feature called Subsystem Reference. It is a modeling construct that is good for componentization and is similar to libraries and Model Reference but has a slightly different use case.
An Introduction to Subsystem Reference from Mathworks:
Subsystem reference allows you to save the contents of a subsystem in a separate SLX file and reference it using a Subsystem Reference block. You can create multiple instances referencing the same subsystem file. When you edit any instance of a referenced subsystem, the changes are saved in the separate SLX file in which the subsystem is stored and all the referenced instances of that file are synchronized.
When you save a subsystem to a separate file you can reuse it multiple times by using Subsystem Reference blocks referencing the same subsystem file.
You can identify a Subsystem Reference block by the triangles in the opposite corners of the block icon.
A referenced subsystem supports all the semantics of a regular subsystem. A referenced subsystem adapts itself to the context of the parent model and has identical execution behavior when compared to a nonreferenced subsystem.
Libraries and Model Reference
This new feature sounds very similar to Libraries and Model Reference, but they are each slightly different and provide for difference use cases:
Libraries are intended for a large amount of reuse for a small amount of functionality and stable implementations. The Raptor Blockset library uses this functionality. When composing large applications where a team needs to make changes to different areas of the model, libraries can be used, but there are a few problems that can occur:
- It is easy to disable or parameterize a link that disconnects the local implementation from the reference implementation creating future maintenance complications.
- You can’t perform an update (CTRL+D) on a library so making frequent edits can be a challenge.
Model Reference is a standalone file that has very rigid architectural boundaries in both simulation and code generation. They can provide some benefits in simulation and code generation because the generated files don’t need to be rebuilt every time. However, Model Reference has some challenges:
- Signal properties must be specified at the boundaries and thus cannot be inherited from its connecting blocks.
- Code customization is difficult due to the rigid constraints and limits on flexibility (Raptor-Dev does not support Model Reference due to these constraints).
Subsystem Reference is a blend of these two. It is stored in a separate file, but it does not have rigid architectural constraints of Model Reference or the added overhead of minor changes to a model like libraries. From a modeling standpoint, the subsystem reference will open in the model browser and edits (and updates) can be performed when editing the reference from the full model.
It should be noted that unlike libraries, there is no “disable link” feature on a subsystem reference. All instances of the subsystem reference will share an implementation.
More comparisons between these different constructs can be found on the MathWorks website here:
How Subsystem Reference Works
Starting with the VeeCAN 500 template application:
>> raptor_create_project(‘SubsystemReferenceRaptorDemo’, ‘DISP-VC500-1904’)
Navigate to this subsystem:
Let’s create a Subsystem Reference for the Screens subsystem thus allowing two developers to edit the main model and the subsystem in parallel.
First, right-click on the subsystem and select the following:
You will be prompted for the name of the file to create for this subsystem. For this example, “ScreensComponent” was chosen.
Therefore, the model looks like this:
Note the triangles in the upper left and lower right. This signifies that the subsystem is a Subsystem Reference. Double-clicking on the block opens the contents of the new Subsystem Reference file. Any changes made in this view will be propagated to the full parent model.
More importantly, the file is stored separately and can be revision controlled separately from the main model.
Download the sample files created for this Raptor User Tip follow this link.
Be Sure You Know This About Subsystem Reference
- This is a new feature in MATLAB R2019b, so there may be some wrinkles.
- As noted earlier, all instances will share the same implementation so if the reference is shared between two applications then both applications will get the changes.
- If the Subsystem Reference file is opened, it behaves like a library (cannot update/sim/code gen). It needs the context of the full application for these features.
- Inputs and Outputs can be inherited so adding a signal specification block to protect the Subsystem Reference from inheriting unexpected data types would be a good idea.
As we enjoy the holiday season and the beginning of a new year, we’re thrilled to announce a variety of innovative solutions and improvements designed to help you navigate your path to market with more efficiency than ever. From all-new drive-by-wire kits to a variety of additions to the Raptor hardware line, keep reading to learn what’s new this winter!
Transit, Bold, and Volt Join New Eagle’s Drive-By-Wire Lineup
New Eagle’s Autonomous Development Platform continues its expansion with the addition of the Ford Transit, Chevy Bolt, and Chevy Volt Drive-By-Wire (DBW) kits. Built on ruggedized, certifiable hardware like automotive-grade OEM controllers, these kits not only deliver high levels of reliability for safety-critical applications, but easy scalability for seamless fleet deployment. Learn more about our autonomous solutions, or schedule a demo today!
New Additions to the Raptor Hardware Line
From platform solutions for controlling actuators, data collection and management, display to an on-board or remote operators, to a variety of ECUs and displays that range in pin count, input, output, memory, and processor configuration, Raptor’s growing suite of automotive-grade products are making it easier than ever to get to production. Our relationships with OEM suppliers allow us to serve as a one-stop-shop for getting the best parts for your system. Explore some of our new and featured products below!
This five-inch, high-resolution color display wrapped in a rugged, environmentally-sealed enclosure, delivering high-performance graphics and video capabilities. Features 2 CAN channels, one ethernet, and one video input. Able to act as a low-cost, all-in-one display and controller solution.
Electrically and environmentally rugged, ideal for delivering tough, flexible instrumentation in harsh environments. Features a high-resolution LCD Display, allowing it to act as a reader and/or data logger for monitoring your system’s parameters. Includes 9 inputs, 4 outputs, and 2 CAN 2.0B communication channels.
With its 5 CAN buses, 3 LIN Masters, 2 ethernet channels, and variety of configurable discrete inputs and outputs, this powerful GCM is ideal for autonomous drive-by-wire, electric-hybrid, and intelligent machine control applications. Its CPU is a high-performance, multi-core architecture with a companion safety power system basis chip able to support the highest level of functional safety (ASIL-D). Contact [email protected] to pre-order.
This rugged, low-cost controller module features 6 CAN buses, 3 LIN Masters with 1 LIN bus capable of LIN Slave programming, and configurable discrete inputs and outputs. Contact [email protected] to pre-order.
Designed to control the fresh air of spark-ignition engines in combination with an electronic throttle control system, this controller is ideal for flex-fuel ETB applications. CNG and LPG are permissible if injected in the airflow after the throttle body.
With its ability to function at high fuel pressures, these injectors are ideal for enhancing engine performance and running quality through an optimized spray pattern. Available in a variety of multi-orifice tips for improved mixture preparation and atomization with lower BSFC and better idle quality than many other injectors.
Mitsubishi Heavy Industries Automotive Thermal Systems group (MCC) offers the EWH40Dx AC Compressor to compress low temperature/pressure gaseous refrigerant to a higher temperature/pressure state and circulate it through the refrigerant subsystem. This refrigerant subsystem can aid with passenger cabin comfort cooling or for cooling of energy storage components within the drivetrain. Designed for ~400v systems.
Mitsubishi Heavy Industries Automotive Thermal Systems group (MCC) offers the EWH40Dx heater is off-the-shelf no additional customer funded tooling is required, with engineering design and development (ED&D) available free of charge. The high-quality EWH40Dx heater is reliable, trusted by vehicles have been sold all around tyhe world. Designed for ~400v systems.
This solid-state DC load reversing contactor is wired in an H-Bridge configuration, rated for up to 30A at 24VDC. The H-Bridge provides an efficient way to reverse polarity on a variety of DC loads, including solenoids, motors, brake/clutch assemblies, etc.
New Eagle’s PWM to Analog Converter converts three separate channels of PWM signals to proportional 0-5V analog signals, which is especially useful when paired with control modules with PWM outputs, but no 0-5V analog outputs.
It’s easier to protect your investment and get the most out of powerful software tools like Raptor with New Eagle’s engineering support and software maintenance plans. With qualified developers and engineers available to help you get the most out of these powerful tools, along with access to the latest updates and bug fixes, you’ll benefit from fewer delays and a more efficient project timeline.
To learn more about support offerings available, visit our support resources page or add dollars to your existing support fund on our webstore.
Get Trained on Raptor
Build or sharpen your Raptor skills by registering for ou three-day, hands-on Raptor Training program. In this embedded model-based development (eMBD) course, you’ll learn the basics of using the Raptor platform in a MATLAB® and Simulink® environment to create real-world applications.
Register for the next available course at our Ann Arbor, Michigan headquarters before space runs out!
Establishing trusted relationships with major original equipment manufacturers (OEM) can be an overwhelming task for those looking to acquire parts for smaller, lower volume projects. Even when these relationships begin, collecting the integration information necessary to develop a system is tedious and can significantly slow down a project’s timeline. If you’re developing low volume projects, the inability to establish these types of relationships is frustrating.
This is where New Eagle can help you. Our well-established relationships with major OEMs can supply you with the production hardware and integration details you need to develop your project. Whether it’s a low budget concept project or high-volume production program, get access to what you need starting on day one of your development project. If you’re still thinking about cultivating your own relationships with automotive suppliers, learn about the necessary steps you’ll need to take.
Developing Relationships with OEMs
Major suppliers strive to deal with Tier 1 or high-volume production programs since they guarantee high rewards. These companies are designed to handle continued, high-volume programs, like fleet management or high-level commercial vehicle distribution. If you’re able to support a consistent supply of components from these manufacturers then great! If you can’t, then they won’t have the time or resources to develop a relationship with you.
Once you do get the conversation going, the legal steps you must take to get the relationship off the ground can be costly and time consuming. Why? Because these relationships require more than your average Non-Disclosure Agreements, which, in and of themselves, are already extensive for these suppliers.
Multiple Production Parts from a Variety of Manufacturers
After establishing the legalities, the next step is to research all the available parts and figure out which ones will work best with your system. However, your complex system has multiple parts. How are you going to ensure that every part of the system can communicate with one another? You must go to each vendor and gather all the detailed product and software integration information for each part.
Consider how difficult this could be when procuring products from multiple different vendors. Especially since not many standard distributors supply this necessary documentation.
Work with a Trusted OEM Distributor
There is another option to cultivating your own relationships with automotive suppliers. Work with an establishment who already has those relationships in place. Here’s where New Eagle can help you. Over the years, we’ve cultivated relationships with a variety of OEMs, doing our due diligence to promote trusting relationships that benefit you. With this trust in place, we receive a consistent supply of components from these manufacturers for distribution and integration. This allows us to support both fast-paced, low budget concept projects as well as high-volume production programs.
As a trusted distributor, we have years of experience working with lower volume projects as these OEMs will often send us referrals. We act as the liaison between suppliers, such as John Deere and BorgWarner, and non-Tier 1 companies such as yourself. As another benefit, certain vendors, like Mitsubishi, only supply their products to our distribution team.
New Eagle is Your One-Stop, Production Shop
When purchasing through New Eagle, all relevant information will be right at your fingertips. We have taken the time to not only navigate these supplier relationships for you, but to also gather all product information for external distribution. With an NDA in place, access all of our product’s data sheets, CAD files, .dbc files, etc. on our Product Wiki or Product Guide regardless of the original manufacturer. If we don’t have the information, we can leverage our relationships with these OEMs to get it for you.
Are you not certain which hardware you’ll need? We have you covered with our experienced sales and engineering teams. They can work with you to figure out which components will integrate best with your system. By working with us as your one-stop, production shop, we can also provide you with
- Insight during your project’s earliest stages.
- Strategy in mass production.
- A supply of high-volume, production components.
Now, do you still want to cultivate your own relationships with Tier 1 automotive suppliers? Or, would you rather save time and money with New Eagle’s one-stop, production shop? We can offer you the same ruggedized, off-the-shelf hardware tailored to suit a variety of applications. Should you need additional assistance in getting to production, we offer consultation services and a software tool platform called Raptor™. Email [email protected] to start this conversation with us. We’re here to assist you.
If the end game of control system development is to get your system or vehicle into production, you need to be as efficient as possible at each stage of the development life-cycle. It can be really frustrating, and costly, to get underway with a project and run into roadblocks that could have been avoided with the right tools. We’ve identified three mistakes that can create friction and ultimately slow your project to a halt.
1. Not Thinking About Hardware First
We have a saying around here: Hardware selection drives tool selection. Kevin Alley, Director of Programs at New Eagle explains:
“One of the challenges control engineers face is that when they’re in prototype development they don’t know what kind of controller hardware they’re going to need. If they choose a software platform at the front of their project that doesn’t have the right I/O for what is needed later…they’ll have to start over. That’s going to cost time and money.”
Ideally, engineers should select controller hardware first, and with this in mind: controllers are more than just a piece of hardware. As vehicles and the software that controls them becomes increasingly more complex, the software itself becomes a significantly larger part of the value-added to the vehicle.
Selecting ruggedized, high-quality hardware that supports your ideal software is now a critical choice that needs to move higher upstream in the development process. Your hardware selection impacts your schedule and your budget. But if so much of your vehicle’s value is reliant on its software, you better have the right ECU to support it.
How New Eagle Can Help:
Unless you’re working for the big guys with an ‘unlimited’ budget, it probably makes more sense to use an off-the-shelf controller with an accessible, highly flexible, and open development environment such as Raptor™. You could select one of our many ECU models available at volume pricing, and use it directly with our Raptor development toolset.
If you have an existing ECU you’d like to use, we can port Raptor into it, then you can use it to develop, test and control your vehicle, without friction. Better yet, you can start development today with one of our off-the-shelf ECUs and then easily port your Simulink model when YOUR controller comes online.
And, if you need a custom ECU, we can build you one to match your requirements, leveraging our existing relationships with high-volume automotive-grade ECU suppliers.
2. Using the Wrong Development Tools
Engineers love rapid prototyping tools because they’re fast and familiar. Many of them may even have learned the rapid prototyping development environment in school, and want to stay in their comfort zone. We get it and support it.
The key is to understand that most rapid prototyping tools are just that, useful for prototyping only. That’s where they leave you. They are too expensive and don’t have the facilities needed for production. And if you use a rapid prototyping tool that can’t get you to production, or one that you can’t afford –another point of friction is created. We would like to suggest that some rapid prototyping tools can take you to production.
“That’s really the core of why New Eagle was founded. We wanted to offer controls engineers the same development style that they were used to, but with the added benefit of being able to take it all the way to production. The challenge was making high-quality controllers for them to run on that were affordable, and we have done that with our volume pricing.”
How New Eagle Can Help:
We created Raptor-Dev so that engineers could quickly create custom software in a highly effective development environment, one that is already familiar to many.
Raptor-Dev is an open ECU development environment that lets you quickly develop in the Simulink environment and run on production embedded hardware without the friction common to embedded system development.
3. Using a Disparate Set of Tools
This arguably creates the highest volume of headaches. Mismatched tools mean manual adaptations that eat up your time, create more friction, and introduce another source of costly errors. Imagine running into roadblocks that require hand-writing new code at each of these stages:
“What if, at any stage of development, you ran into a problem, and you could quickly change code in minutes vs. taking a week or more to get a new version from your vendor? How about changing the function of the code in seconds using a streamlined calibration interface vs. rebuilding everything. These quick-cycle iteration capabilities over many iterations will really add up – saving you time and cost.”
How New Eagle Can Help:
The Raptor Platform™ is an end-to-end solution that allows you to work within a holistic development system that takes you through to production, quickly. Engineers can design, develop, calibrate, validate, manage and service their vehicles all within a compatible suite of tools.
Kevin explains the not-as-obvious value of the Raptor tool-chain:
“We’ve heard from our customers that one of the things they really appreciate is the fact that they can keep their IP in-house because Raptor eliminates the need to constantly submit requests for software changes to an outside vendor – instead they can just do it on their own. When we say ‘Take Control’ here at New Eagle, that’s what we’re talking about. Helping engineers take control of their project from start to finish.”
If you’re interested in getting started with Raptor, consider our Raptor Starter Kit. It includes Raptor-Dev, Raptor-Cal & Raptor-CAN.
You can also read more about each of the tools in the tool-chain in our eBook about the Raptor Platform.
Local Interconnect Network (LIN) provides a low-cost communication network alternative to CAN where lower bandwidth and less versatility are acceptable. LIN is a serial communication protocol that efficiently supports the control of mechatronic nodes in distributed applications. LIN uses a master/slave bus access concept with one master per bus.
LIN is a message-based protocol with message identifiers and message content similar to CAN. Also similar to CAN, the LIN standard does not specify the content or meaning of the messages which are to be transmitted within a LIN network, which are application specific and up to the application developer. The LIN standard introduces the LIN description file (*.LDF file) which is used to describe the LIN network. This file is analogous to a the *.DBC file used in CAN networks.
In a similar way to how Raptor-Dev automatically handles the details of CAN message packing and unpacking for you based on the DBC file using code-generation, the details for LIN messages are handled with Raptor-Dev for you using the LDF file. This user tip shows you how to configure a simple LIN master that communicates with two LIN slave nodes. The sample model is available for download.
Below you will see the model, starting at the top-level (with the model shown above). First, you must define the LIN bus using the “LIN Definition” block. This configures the LIN hardware driver for a particular channel, providing the baud rate and time base. This block also configures the software driver based on the LDF file you specify.
Next looking inside the ‘Foreground’ block, the architecture of the LIN network is more apparent:
The master (GCM80) will operate according to the schedule(s) defined in the LDF file–if one is present in the LDF. If there is no schedule present in the LDF, Raptor-Dev will automatically create a simple round-robin schedule for you based on the messages used in your model. In this example, there is only one schedule defined in the example LDF file, so there is one schedule available in the “LIN Set Schedule” block. You can define multiple schedules from which to choose. Schedule 0 will be “Empty,” meaning no schedule is selected, thus no messages will be sent on the bus.
Referencing the LDF with a text editor, shown here, you can see how the schedule is composed.
In the example model, using the“LIN_SCHED” variable as an adjustment block in Raptor-Dev, you are able to change the value to select a different schedule in Raptor-Cal. This will cause the bus traffic on the LIN network to change.
It is helpful to be able to read the state of the current schedule, which can be done with the “LIN Get Schedule” block:
As with CAN, errors may occur with the message transmission in LIN. The “LIN State” block allows monitoring of the LIN bus:
Now, having configured the master, it is important to recall the way in which slaves operate on a LIN bus. The master will tell the slaves what to do, and when to do it according to the schedule.
In this example, the master sends data to a slave with the “LIN Tx Message” block, and data sent from a slave to the master is received with the “LIN Rx Message” block. These blocks handle all the packing and unpacking for you automatically based on the LDF file identified in the LIN Definition block.
Within these subsystems for sending and receiving LIN messages, a LIN Trigger block can be used to do extra logic based on the transmission or reception of a message. For receiving messages, the trigger will fire AFTER the message arrives and the receive block output data ports will contain the newly arrived data. For transmitting messages, the trigger will fire BEFORE the message is sent to the bus, the data in the outgoing messages will be collected from the transmit block if the block is inside the trigger callback.
In this example, a counter is incremented every time a particular frame is sent, and another counter is incremented every time a particular frame is received:
Triggers can be particularly helpful for creating internal logic for handling LIN frame events, and also to assure that you are processing or transmitting the latest data.
This user tip has shown how LIN is supported within Raptor-Dev. Hopefully, it will feel very familiar since LIN is exposed in the tool in a very similar way to CAN.
Choosing an Electronic Control Unit (ECU) for your EV / HEV / Autonomous vehicle is a huge decision with implications way beyond vehicle control. While some people see it as ‘just a piece of hardware’, we believe your ECU choice greatly impacts your development process and ultimately what you’ll be able to deliver, and when. The supervisory or vehicle control unit you choose will affect your costs and even your to time to market in ways you may not anticipate.