NI XNET Hardware and Software Manual National Instruments

Transcript

1 XNET NI-XNET Hardware and Software Manual NI-XNET Hardware and Software Manual July 2014 372840H-01

2 Support Worldwide Technical Support and Product Information ni.com Worldwide Offices ni.com/niglobal to access the branch office Websites, which provide up-to-date contact information, Visit support phone numbers, email addr esses, and current events. National Instruments Corporate Headquarters 11500 North Mopac Expressway Aust in, Texas 78759-3504 USA Tel: 512 683 0100 For further support information, refer to the appendix. To comment on National Instruments NI Services . feedback ni.com/info and enter the Info Code tional Instruments Website at documentation, refer to the Na © 2009–2014 National Instruments. All rights reserved.

3 Legal Information Limited Warranty This document is provided ‘as is’ and is subject to being change d, without notice, in future editions. For the latest version, refer to ly for technical accuracy; however, ni.com/manuals NI MAKES NO EXPRESS OR IMPLIED . NI reviews this document careful WARRANTIES AS TO THE ACCURACY OF THE INFORMATION CONTAINED HEREIN AND SHALL NOT BE LIABLE FOR ANY ERRORS. be free of defects in materials and workmanship that cause the product to fail to s ubstantially conform to NI warrants that its hardware products will the applicable NI published sp ecifications for one (1) year from the date of invoice. y in accordance warrants that (i) its software products will perform substantiall For a period of ninety (90) days from the date of invoice, NI and with the applicable documentation provided with the software and (ii) the software media will be free from defects in materials workmanship. ct or non-conformance during the ll, in its discretion: (i) rep air or replace the affected If NI receives notice of a defe applicable warranty period, NI wi Hardware will be warranted for the remaind the affected product. Repaired or replaced product, or (ii) refund the fees paid for er of the original warranty period or ninety (90) days, whichever is l onger. If NI elects to repair or replace th e product, NI may use new or refurbished p arts or products that are nce and reliability and are at least functionally equi valent to the origin al part or product. equivalent to new in performa t to NI. NI reserves the right You must obtain an RMA number from NI before returning any produc nd testing to charge a fee for examining a Hardware not covered by the Limited Warranty. This Limited Warranty does not apply if the defect of the product e, installatio n, repair, or calibration resulted from improper or inade quate maintenanc e of an improper hardware or software ized modification; improper environment; us (performed by a party other than NI); unauthor key; improper use or operation outside of the spec ification for the product; improper voltages; acci dent, abuse, or neglect; or a hazard such as lightning, flood, or other act of nature. STOMER’S SOLE REMEDIES, AND SHALL APPLY EVEN IF THE REMEDIES SET FORTH ABOVE ARE EXCLUSIVE AND THE CU SUCH REMEDIES FAIL OF THEIR ESSENTIAL PURPOSE. EXCEPT AS EXPRESSLY SET FORTH HEREIN, PRODUCTS ARE PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND AND NI DISCLAIMS ALL WARRANTIES, EXPRESSED OR IMPLIED, WITH RESPECT TO THE PRODUCTS, INCLUDING ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE OR NON-INFRINGEMENT, AND ANY WARRANTIES THAT MAY ARISE FROM USAGE OF TRADE OR COURSE OF DEALING. NI DOES NOT WARRANT, GUARANTEE, OR MAKE ANY REPRESENTATIONS REGARDING THE USE OF OR THE RESULTS OF THE USE OF THE PRODUCTS IN TERMS OF CORRECTNESS, ACCURACY, RELIABILITY, OR OTHERWISE. NI DOES NOT WARRANT THAT THE OPERATION OF THE PRODUCTS WILL BE UNINTERRUPTED OR ERROR FREE. ement with warranty terms covering the products, then the warra In the event that you and NI have a separate signed written agre nty terms in the separate agreement shall control. Copyright Under the copyright laws, this publication may not be reproduced or transmitted in any form, el ectronic or mechanical, includin g photocopying, recording, storing in an information retrie val system, or translating, in whole or in part, without the prior written consent o f National Instruments Corporation. National Instruments respects the intellectu s to do the same. NI software is protecte d by copyright and other al property of others, and we ask our user Where NI software may be used to intellectual property laws. use NI software only reproduce software or other materials belonging to others, you may applicable license or reproduce in accordance with the terms of any . to reproduce materials that you may other legal restriction End-User License Agreements and Third-Party Legal Notices You can find end-user licen se agreements (EULAs) and third-party legal notices in the following locations: \_Legal Information and directories. Notices are located in the • EULAs are located in the • directory. \Shared\MDF\Legal\license \_Legal Information.txt for information on including legal information in installers built with NI •Review products. U.S. Government Restricted Rights tity of the United States Government (“Government”), the use, duplication, reprodu ction, release, If you are an agency, department, or other en modification, disclosure or transfer of the technical data included in this manual is governed by the Restricted Rights provisi ons under Federal Acquisition Regulation 52.227-14 for civilian agencies and Defe nse Federal Acquisition Regulation Supplement Section 252.227-70 14 and 252.227-7015 for military agencies. Trademarks NI Trademarks and Logo Guidelines ni.com/trademarks for more information on National Instruments trademarks. Refer to the at ARM, Keil, and μVision are trademarks or re gistered of ARM Ltd or its subsidiaries. S are trademarks of the LEGO Group. LEGO, the LEGO logo, WEDO, and MINDSTORM TETRIX by Pitsco is a trademark of Pitsco, Inc. ™ ™ and FOUNDATION are trademarks of the Fieldbus Foundation. FIELDBUS FOUNDATION ® is a registered trademark of and licensed by Beckhoff Automation GmbH. EtherCAT ® is a registered Community Trademark of CAN in Automation e.V. CANopen ™ ™ and EtherNet/IP are trademarks of ODVA. DeviceNet vernier.com are Go!, SensorDAQ, and Vernier are registered trademarks of Vernier Software & Technology. Vernier Software & Technology and trademarks or trade dress. Xilinx is the registered trademark of Xilinx, Inc. Taptite and Trilobular are regist ered trademarks of Research Engineerin g & Manufacturing Inc.

4 ® FireWire is the registered trademark of Apple Inc. ® Linux rvalds in the U.S. and other countries. is the registered trademark of Linus To ® ® ® ® ® ® ™ , MATLAB , and xPC TargetBox , Simulink are registered trademarks, and TargetBox , Stateflow and , Real-Time Workshop Handle Graphics ™ are trademarks of The MathWorks, Inc. Target Language Compiler ® Tektronix gistered trademarks of Tektronix, Inc. , Tek, and Tektronix, Enabling Technology are re ® word mark is a registered tradem ark owned by the Bluetooth SIG, Inc. The Bluetooth ™ word mark and logos are owned by PC MCIA and any use of such marks by National Instruments is under license. The ExpressCard The mark LabWindows is used under a license from Microsoft Cor poration. Windows is a registered trademark of Microsoft Corporat ion in the United States and other countries. Other product and company name s mentioned herein are trademarks or tr ade names of their respective companies. Members of the National Instruments Alliance Partner Program ar e business entities independent fr ve no agency, om National Instruments and ha nture relationship with National Instruments. partnership, or joint-ve Patents ts/technology, refer to the appropriate location: Help»Patents in your software, For patents covering National Instruments produc the file on your media, or the National Instruments Patent Notice at ni.com/patents . patents.txt Export Compliance Information Refer to the Export Compliance Information at ni.com/legal/export-compliance for the National Instruments global trade compliance policy and how to obtain relevant HTS codes, ECCNs, and other import/export data. WARNING REGARDING USE OF NATIONAL INSTRUMENTS PRODUCTS YOU ARE ULTIMATELY RESPONSIBLE FOR VERIFYING AND VALIDATING THE SUITABILITY AND RELIABILITY OF THE PRODUCTS WHENEVER THE PRODUCTS ARE INCORPORATED IN YOUR SYSTEM OR APPLICATION, INCLUDING THE APPROPRIATE DESIGN, PROCESS, AND SAFETY LEVEL OF SUCH SYSTEM OR APPLICATION. PRODUCTS ARE NOT DESIGNED, MANUFACTURED, OR TESTED FOR USE IN LIFE OR SAFETY CRITICAL SYSTEMS, HAZARDOUS ENVIRONMENTS OR ANY OTHER ENVIRONMENTS REQUIRING FA IL-SAFE PERFORMANCE, INCLUDING IN THE OPERATION OF NUCLEAR FACILITIES; AIRCRAFT NAVIGATION; AIR TRAFFIC CONTROL SYSTEMS; LIFE SAVING OR LIFE SUSTAINING SYSTEMS OR SUCH OTHER MEDICAL DEVICES; OR ANY OTHER APPLICATION IN WHICH THE FAILURE OF THE PRODUCT OR SERVICE COULD LEAD TO DEATH, PERSONAL INJURY, SEVERE PROPERTY DAMAGE OR ENVIRONMENTAL HARM (COLLECTIVELY, “HIGH-RISK USES”). FURTHER, PRUDENT STEPS MUST BE TAKEN TO PROTECT AGAINST FAILURES, INCLUDING PROVIDING BACK-UP AND SHUT-DOWN MECHANISMS. NI EXPRESSLY DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY OF FITNESS OF THE PRODUCTS OR SERVICES FOR HIGH-RISK USES.

5 Compliance tibility Information Electromagnetic Compa plicable regulatory requiremen ts and limits for electromagnetic This hardware has been tested and found to comply with the ap 1 . These requirements and limits are eclaration of Conformity (DoC) indicated in the hardware’s D compatibility (EMC) as when the hardware is designed to provide reasonable protection against harmful interference operated in the intended , for example when either highly sensitive or noisy hardware is being used in clos e electromagnetic environment. In special cases proximity, additional mitigation m the potential for electromagnetic interference. easures may have to be employed to minimize While this hardware is compliant with the ere is no guarantee that interference will applicable regulatory EMC requirements, th minimize the potential for the hardware to n not occur in a particular installation. To cause interference to radio and televisio rformance degradation, install and use this hardware in strict accordance with the reception or to experience unacceptable pe 1 instructions in the hardwa re documentation and the DoC . If this hardware does cause interference with licensed radio co mmunications services or other n earby electronics, which can be determined by turning the hardware off and on, you are encourag ed to try to correct the inte rference by one or more of the following measures: • (the device suffering interference). Reorient the antenna of the receiver Relocate the transmitter (the device generating • interference) with respect to the receiver. • Plug the transmitter into a different outlet so that the transmitter and th e receiver are on different branch circuits. osure (windowless version) to Some hardware may require the use of a metal, shielded encl quirements for meet the EMC re special EMC environments such as, for marine use or in heavy in dustrial areas. Refer to the hardware’s user documentation and 1 for product installation requirements. the DoC When the hardware is connected to a test ob ject or to test leads, the system may b ecome more sensitive to disturbances or may cause interference in the local electromagnetic environment. Operation of this hardware in a residential area is likely to cause harmful interference. Us ers are required to correct the interference at their own expense or cease operation of the hardware. Changes or modifications not expressly appr oved by National Instruments could void the user’s right to operate the hardware under the local regulatory rules. 1 The Declaration of Conformity (DoC) contains important EM C compliance information and in structions for the user or installer. To obtain the DoC for this product, visit ni.com/certification , search by model number or product line, and click the appropriate link in the Certification column.

6 Contents About This Manual Related Documentation... xxxi Chapter 1 Introduction Chapter 2 Installation and Configuration Safety Information ... 2-1 Measurement & Automation Explorer (MAX) ... 2-3 Verifying NI-XNET Hardware Installation ... 2-4 XNET C Series Modules Firmware Update ... 2-5 ... 2-7 ... Configuring NI-XNET Interfaces ... ... ... ... ... LabVIEW Real-Time (RT) Configur ation ... 2-7 Getting Started with CompactRIO... ...2-8 Tools ... ...2-12 System Configuration API ... ... 2-13 Chapter 3 NI-XNET Hardware Overview .3-1 Overview... NI-XNET FlexRay Hardware ... 3-1 FlexRay Physical Layer... 3-1 Transceiver... 3-1 Bus Power Requirements ... 3-1 Cabling Requirements for FlexRay... 3-1 Cable Lengths and Number of Devices ... 3-2 Termination ... 3-2 Pinout... 3-2 NI-XNET CAN Hardware ... 3-3 NI-XNET Transceiver Cables ... 3-3 ... 3-3 XS Software Selectable Physical Layer ... High-Speed Physical Layer ... 3-4 Transceiver... 3-4 Bus Power Requirements ... 3-4 CAN... 3-5 Cabling Requirements for High-Speed Cable Lengths ... 3-5 National Instruments T Hardware and Software Manual NI-XNE vii ©

7 Contents Number of Devices ... 3-5 Cable Termination ... 3-5 Cabling Example ... 3-7 Low-Speed/Fault-Tolerant Physical Layer . ... 3-7 Transceiver ... 3-7 Bus Power Requirements... 3-8 Cabling Requirements for Low-Speed/ Fault-Tolerant CAN... 3-8 Number of Devices ... 3-9 Termination ... 3-9 Determining the Necessary Termination Resistance for the Board... 3-10 Single Wire CAN Physical Layer ... 3-11 Transceiver ... 3-11 Bus Power Requirements... 3-12 Cabling Requirements for Single Wire CAN ... 3-12 Cable Length... 3-12 Number of Devices ... 3-12 Termination (Bus Loading) ... 3-12 External CAN Transceiver... 3-12 Pinouts... 3-13 PXI-8511/8512/8513 and PCI-8511/8512/ ... 3-13 ... 8513... C Series NI 9861/9862 ... 3-14 NI-XNET LIN Hardware ... 3-14 LIN Physical Layer ... 3-14 Transceiver ... 3-15 Bus Power Requirements... 3-15 Cabling Requirements for LIN ... 3-15 Cable Lengths ... 3-15 Number of Devices ... 3-16 Termination ... 3-16 Pinout ... 3-16 PXI-8516 and PCI-8516 ... 3-16 C Series NI 9866 and NI-XNET LIN Transceiver Cable... 3-17 Isolation ... ... 3-17 LEDs... ... 3-17 9 Synchronization ... 3-1 PXI NI-XNET and PCI NI-XNET ... 3-19 C Series and NI-XNET Transceiver Cables ... 3-20 ni.com viii NI-XNET Hardware and Software Manual

8 Contents Chapter 4 NI-XNET API for LabVIEW Getting Started ... 4 -1 LabVIEW Project ... 4-1 Examples ... 4-1 Palettes... 4-2 Basic Programming Model ... 4-3 ... ... ... 4-4 Interfaces... ... ... ... ... ... ... ... 4-4 What Is an Interface?... ... ... ... ... ... How Do I View Available Interfaces? ... ... 4-5 ... ... ... ... Measurement and Automation Explorer (MAX) ... 4-5 I/O Name... 4-6 LabVIEW Project...4-6 System Node ... 4-6 .4-7 Databases ... What Is a Database? ... 4-7 What Is an Alias?... 4-8 Database Programming ... 4-9 Already Have File? ... 4-9 Can Use File As Is?... 4-9 Select From File ... 4-10 Edit and Select ... 4-11 Want to Use a File? ... 4-12 Create New File Using the Database Editor ... 4-12 Create in Memory ... 4-12 Multiple Databases Simultaneously... ...4-13 Sessions... ... 4-13 What Is a Session?... 4-13 Session Modes ... 4-14 ... ... 4-15 ... Frame Input Queued Mode .. ... ... Frame Input Single-Point Mode... ... ... ... ... 4-18 ... ... Frame Input Stream Mode ... ... ...4-19 ... Frame Output Queued Mode... 4-22 Frame Output Single-Point Mode ... ... 4-24 Frame Output Stream Mode... 4-27 ... 4-29 Signal Input Single-Point Mode... Signal Input Waveform Mode... 4-32 Signal Input XY Mode ... 4-35 Signal Output Single-Point Mode ... 4-37 Signal Output Waveform Mode ... 4-38 Signal Output XY Mode ... 4-41 Conversion Mode ...4-45 ix © National Instruments NI-XNET Hardware and Software Manual

9 Contents How Do I Create a Session? ... 4-47 LabVIEW Project ... 4-48 XNET Create Session.vi ... 4-48 Using CAN ... 4- 48 Understanding CAN Frame Timing... 4-48 Configuring Frame I/O Stream Sessions ... 4-49 Using FlexRay ... 4-5 0 Starting Communication ... 4-50 Understanding FlexRay Frame Timing... 4-51 Protocol Data Unit (PDU)... 4-51 4-51 Using LIN ... Changing the LIN Schedule ... 4-51 Understanding LIN Frame Timing ... 4-52 LIN Diagnostics ... ... ... ... ... ... ... ... 4-52 Special Considerations for Using Stream Output Mode with LIN ... 4-52 Using LabVIEW Real-Time... 4-53 High Priority Loops ... 4-53 XNET I/O Names... 4-54 Deploying Databases... 4-54 Memory Use for Databases ... 4-54 FlexRay Timing Source ... 4-55 plication ... 4-55 Creating a Built Real-Time Ap NI-XNET API for LabVIEW Reference ... 4-56 XNET Session Constant... 4-56 XNET Create Session.vi ... 4-57 XNET Create Session (Conversion).vi... 4-58 XNET Create Session (Frame Input Queued).vi ... 4-59 XNET Create Session (Frame Input Si ngle-Point).vi ... 4-60 XNET Create Session (Frame Input Stream).vi ... 4-61 ... 4-63 XNET Create Session (PDU Input Queued ).vi ... ... Point).vi ... ... XNET Create Session (PDU Input Single ... 4-63 XNET Create Session (Frame Output Queued).vi ... 4-64 XNET Create Session (Frame Output Single-Point).vi ... 4-65 XNET Create Session (Frame Output Stream).vi ... 4-66 XNET Create Session (PDU Output Queued).vi... 4-68 XNET Create Session (PDU Output Sing le-Point).vi ... 4-68 XNET Create Session (Generic).vi... 4-69 XNET Create Session (Signal Input Si ngle-Point).vi ... 4-71 XNET Create Session (Signal Input Waveform).vi ... 4-72 XNET Create Session (Signal Input XY).vi... 4-73 Single-Point).vi... 4-74 XNET Create Session (Signal Output XNET Create Session (Signal Output Waveform).vi... 4-75 XNET Create Session (Signal Output XY).vi ... 4-76 x NI-XNET Hardware and Software Manual ni.com

10 Contents ... 4-77 XNET Session Property Node. Interface Properties ... ... ... ... ... ... ... 4-78 CAN Interface Properties . ... ... ... ... 4-78 Interface:CAN:External Tran sceiver Config ... 4-79 Interface:CAN:FD Baud Rate ... ... ... ... 4-82 Interface:CAN:I/O Mode ... ... ... ... 4-84 Interface:CAN:Listen Only? .. ... ... ... 4-85 Interface:CAN:Pending Transm it Order ... 4-86 Interface:CAN:Single Shot Transmit? ... ... 4-88 ... ... ...4-89 Interface:CAN:Termination ... ate ... ... 4-91 Interface:CAN:Transceiver St Interface:CAN:Transceiver T ype ... ... 4-94 Interface:CAN:Transmit I/O Mode ... ... ... 4-96 FlexRay Interface Properties ... ... ... ... 4-97 ... Interface:FlexRay:Accepted Startup Range ... 4-97 Interface:FlexRay:Allow Halt Due To Clock?... 4-98 Interface:FlexRay:Allow Pass ive to Active ... 4-99 eep When Stopped ... 4-100 Interface:FlexRay:Auto Asl ... 4-101 ift Damping.. Interface:FlexRay:Cluster Dr Interface:FlexRay:Coldstart? . ... ... 4-102 ... Channels ... ... 4-103 Interface:FlexRay:Connected Correction ... 4-104 Interface:FlexRay:Decoding Interface:FlexRay:Delay Co mpensation Ch A... 4-105 Interface:FlexRay:Delay Co mpensation Ch B ... 4-106 Interface:FlexRay:Key Slot Id entifier ... ... 4-107 Interface:FlexRay:Latest Tx... ... ...4-109 ... Interface:FlexRay:Listen Ti meout ... ... 4-110 Interface:FlexRay:Macro Initia l Offset Ch A ... 4-111 Interface:FlexRay:Macro Initia l Offset Ch B... 4-112 Interface:FlexRay:Max Drift.. ... ... ... 4-113 Interface:FlexRay:Micro Initia l Offset Ch A ... 4-114 Interface:FlexRay:Micro Initia l Offset Ch B ... 4-115 ... ... ... 4-116 Interface:FlexRay:Microtick .. Interface:FlexRay:Null Frames To Input Stream? ... 4-117 ection... ... 4-118 Interface:FlexRay:Offset Corr Interface:FlexRay:Offset Co ... 4-119 rrection Out... Interface:FlexRay:Rate Corr ection ... ... 4-120 Interface:FlexRay:Rate Corr ection Out ... ... 4-121 Interface:FlexRay:Samples Pe r Microtick ... 4-122 Interface:FlexRay:Single Slot Enabled? ... ... 4-123 ... 4-124 Interface:FlexRay:Sl eep ... ... ... Interface:FlexRay:Statistics ... 4-126 Enabled?... xi © National Instruments NI-XNET Hardware and Software Manual

11 Contents Interface:FlexRay:Symbol Frames To Input Stream? ... 4-127 Interface:FlexRay:Sync Frames Channel A Even ... 4-128 Interface:FlexRay:Sync Frames Channel A Odd ... 4-129 Interface:FlexRay:Sync Frames Channel B Even ... 4-130 Interface:FlexRay:Sync Frames Channel B Odd... 4-131 e Status ... Interface:FlexRay:Sync Fram ... 4-132 Interface:FlexRay:Terminatio n... ... 4-133 Interface:FlexRay:Wakeup Ch annel... ... 4-134 Interface:FlexRay:Wakeup Patt ern ... ... 4-135 LIN Interface Properties. ... ... ... ... 4-136 Interface:LIN:Break ... ... 4-136 Length ... Interface:LIN:DiagP2 min ... ... ... 4-137 Interface:LIN:DiagSTmin... ... ... ... 4-138 Interface:LIN:Master? ... ... ... ... 4-139 Interface:LIN:Output Stream Slave Response List By NAD ... 4-140 Interface:LIN:Schedules ... ... ... ... 4-141 ... ... ... 4-142 Interface:LIN:Sleep .. ... Interface:LIN:Start Allowed without Bus Power? ... 4-145 Interface:LIN:Termination... ... ... ... 4-146 ... 4-147 Source Terminal Interface Proper ties... ... Interface:Source Ter minal:Start Trigge r... 4-147 Interface:Baud Rate... ... ... ... ... ... 4-148 ... 4-151 Interface:Echo Transmit? ... ... ... ... ... Interface:I/O Name... ... ... 4-152 ... ... ... ... ... 4-153 Interface:Output Stream List ... Interface:Output Stream List By ID ... ... ... 4-154 ... Interface:Output Stream Timing ... ... ... 4-155 Interface:Start Trigger Frames to Input Stream?. ... 4-159 Interface:Bus Error Frames to I nput Stream? ... ... 4-159 Frame Properties ... 4-160 CAN Frame Properties ... 4-160 Frame:CAN:Start Time Offset... 4-160 Frame:CAN:Transmit Time... 4-161 Frame:Active ... 4-162 d Checksums... 4-163 Frame:LIN:Transmit N Corrupte Frame:Skip N Cyclic Frames ... 4-164 xii NI-XNET Hardware and Software Manual ni.com

12 Contents Auto Start? ... 4-165 Cluster ...4-166 Database ... 4-167 List of Frames ... 4-168 List of Signals ... 4-169 Mode ... 4-170 Number in List ... 4-170 Number of Values Pending ... 4-171 Number of Values Unused ...4-172 Payload Length Maximum...4-173 Protocol ... 4-174 Queue Size ... 4-175 Resample Rate... 4-181 XNET Read.vi ... 4-182 XNET Read (Frame CAN).vi ... 4-184 XNET Read (Frame FlexRay).vi ... 4-188 XNET Read (Frame LIN).vi ... 4-193 XNET Read (Frame Raw).vi ... 4-198 ... 4-201 XNET Read (Signal Single-Point).vi... XNET Read (Signal Waveform).vi... 4-202 XNET Read (Signal XY).vi ... 4-204 XNET Read (State CAN Comm).vi...4-207 XNET Read (State FlexRay Comm).vi... 4-211 XNET Read (State LIN Comm).vi ... 4-215 XNET Read (State FlexRay Cycle Macrotick).vi... 4-220 XNET Read (State FlexRay Statistics).vi ... 4-222 XNET Read (State Time Comm).vi...4-224 XNET Read (State Time Current).vi ... 4-225 XNET Read (State Time Start).vi ... 4-226 XNET Read (State Session Info).vi ...4-228 XNET Write.vi ... 4-229 XNET Write (Signal Single-Point).vi ... ...4-231 XNET Write (Signal Waveform).vi ...4-232 XNET Write (Signal XY).vi ... 4-234 XNET Write (Frame CAN).vi ... 4-236 XNET Write (Frame FlexRay).vi ... ... 4-240 XNET Write (Frame LIN).vi ... 4-244 XNET Write (Frame Raw).vi... 4-248 XNET Write (State FlexRay Symbol).vi ... 4-251 XNET Write (State LIN Schedule Change).vi... 4-252 ... 4-255 hedule Change).vi XNET Write (State LIN Diagnostic Sc NI-XN © National Instruments xiii ET Hardware and Software Manual

13 Contents ... Database Subpalette ... ... ... ... 4-258 ... ... XNET Database Property Node... 4-258 Clusters... 4-259 ShowInvalidFromOpen? ... 4-260 XNET Database Constant... 4-261 XNET Cluster Property Node... 4-261 FlexRay Properties ... 4-262 FlexRay:Action Point Offset ... 4-262 FlexRay:CAS Rx Low Max... 4-263 FlexRay:Channels ... 4-264 FlexRay:Cluster Drift Damping... 4-265 FlexRay:Cold Start Attempts... 4-266 FlexRay:Cycle ... 4-267 FlexRay:Dynamic Segment Start... 4-268 FlexRay:Dynamic Slot Idle Phase ... 4-269 FlexRay:Latest Guaranteed Dynamic Slot ... 4-270 FlexRay:Latest Usable Dynamic Slot ... 4-271 FlexRay:Listen Noise ... 4-272 FlexRay:Macro Per Cycle... 4-273 FlexRay:Macrotick ... 4-274 FlexRay:Max Without Clock Correction Fatal... 4-275 FlexRay:Max Without Clock Correction Passive... 4-276 FlexRay:Minislot Action Po int Offset ... 4-277 FlexRay:Minislot ... 4-278 FlexRay:Network Management Vector Length ... 4-279 FlexRay:NIT Start... 4-280 FlexRay:NIT ... 4-281 s ... 4-282 FlexRay:Number of Minislot FlexRay:Number of Static Slots ... 4-283 FlexRay:Offset Correction St art ... 4-284 FlexRay:Payload Length Dynamic Maximum ... 4-285 FlexRay:Payload Length Maximum ... 4-286 FlexRay:Payload Length Static ... 4-287 FlexRay:Static Slot ... 4-288 FlexRay:Symbol Window St art ... 4-289 FlexRay:Symbol Window... 4-290 FlexRay:Sync Node Max... 4-291 FlexRay:TSS Transmitter ... 4-292 FlexRay:Use Wakeup ... 4-293 Idle ... 4-294 FlexRay:Wakeup Symbol Rx FlexRay:Wakeup Symbol Rx Low ... 4-295 FlexRay:Wakeup Symbol Rx Window... 4-296 xiv NI-XNET Hardware and Software Manual ni.com

14 Contents FlexRay:Wakeup Symbol Tx Idle... 4-297 FlexRay:Wakeup Symbol Tx Low... 4-298 Baud Rate ... 4-299 CAN:FD Baud Rate ... 4-300 CAN:I/O Mode... 4-301 Comment ... 4-302 ... 4-302 Configuration Status ... Database...4-303 ECUs... 4-303 Frames ... 4-304 LIN:Schedules ... 4-305 LIN:Tick ... 4-306 Name (Short) ... 4-307 PDUs... 4-309 PDUs Required? ... 4-310 Protocol... 4-312 Signals ... 4-312 XNET Cluster Constant ... 4-313 XNET ECU Property Node... 4-313 Cluster...4-314 FlexRay:Coldstart? ... 4-314 FlexRay:Connected Channels... 4-315 FlexRay:Startup Frame ... 4-315 FlexRay:Wakeup Channels ... 4-316 FlexRay:Wakeup Pattern ... 4-316 Comment ... 4-318 Configuration Status ... ... 4-318 ... ... 4-319 Frames Received... ... ... ... Frames Transmitted ... 4-319 LIN:Master?... 4-320 LIN:Protocol Version ... 4-320 LIN:Initial NAD ... 4-321 LIN:Configured NAD... 4-321 LIN:Supplier ID... 4-322 LIN:Function ID ... 4-322 LIN:P2min ... 4-323 LIN:STmin... 4-323 Name (Short) ... 4-324 XNET ECU Constant... 4-326 XNET Frame Property Node ... 4-326 CAN:Extended Identifier? ...4-326 CAN:Timing Type... 4-327 CAN:Transmit Time ... 4-329 Cluster...4-330 xv © National Instruments NI-XNET Hardware and Software Manual

15 Contents Comment ... 4-330 Configuration Status.. ... 4-331 Default Payload ... 4-332 FlexRay:Base Cycle ... 4-334 FlexRay:Channel Assignment... 4-336 FlexRay:Cycle Repetition ... 4-337 FlexRay:Payload Preamble? ... 4-339 FlexRay:Startup? ... 4-340 FlexRay:Sync? ... 4-341 FlexRay:Timing Type ... 4-342 FlexRay:In Cycle Repetitions:Channel Assignments ... 4-343 FlexRay:In Cycle Repetitions:Enabled? ... 4-344 FlexRay:In Cycle Repetitions:Identifiers... 4-345 Identifier ... 4-346 LIN:Checksum ... 4-348 Mux:Data Multiplexer Signal... 4-349 Mux:Is Data Multiplexed? ... 4-349 Mux:Static Signals ... 4-350 Mux:Subframes ... 4-350 Name (Short) ... 4-351 Payload Length... 4-353 PDU_Mapping ... 4-354 Signals ... 4-355 XNET Frame Constant ... 4-356 XNET PDU Property Node ... 4-356 Cluster ... 4-357 Comment ... 4-357 Configuration Status.. ... 4-358 Frames ... 4-359 Mux:Data Multiplexer Signal... 4-359 Mux:Is Data Multiplexed? ... 4-360 Mux:Static Signals ... 4-360 Mux:Subframes ... 4-361 Name (Short) ... 4-362 Payload Length... 4-363 Signals ... 4-364 XNET PDU Constant ... 4-364 XNET Subframe Property Node... 4-365 Dynamic Signals ... 4-366 Frame... 4-366 Multiplexer Value ... 4-367 Name (Short) ... 4-368 PDU ... 4-370 xvi NI-XNET Hardware and Software Manual ni.com

16 Contents XNET Signal Property Node ... 4-371 Byte Order ... 4-372 Comment ... 4-374 ... 4-375 Configuration Status ... Data Type ... 4-376 Default Value... 4-377 Mux:Dynamic? ... 4-378 Frame ... 4-379 Maximum Value ... 4-379 Minimum Value... 4-380 Mux:Multiplexer Value ... 4-380 Mux:Data Multiplexer? ... 4-381 Name (Short) ... 4-382 Number of Bits ... 4-384 PDU ... 4-385 Scaling Factor ... 4-386 Scaling Offset ... 4-386 Start Bit... 4-387 Mux:Subframe ... 4-389 Unit ... 4-389 XNET Signal Constant... 4-390 XNET Database Open.vi... 4-390 XNET Database Close.vi ... 4-391 XNET Database Close (Cluster).vi ... 4-392 XNET Database Close (Database).vi ...4-393 XNET Database Close (ECU).vi ... 4-394 XNET Database Close (Frame).vi ... 4-395 XNET Database Close (PDU).vi ... 4-396 XNET Database Close (Signal).vi ... 4-397 XNET Database Close (Subframe).vi ... 4-398 XNET Database Close (LIN Schedule).vi... 4-399 XNET Database Close (LIN Schedule Entry).vi ...4-400 XNET Database Create Object.vi ... 4-401 XNET Database Create (Cluster).vi ... 4-402 XNET Database Create (Dynamic Signal).vi ... 4-404 XNET Database Create (ECU).vi... 4-406 XNET Database Create (Frame).vi ... 4-407 XNET Database Create (PDU).vi... 4-408 XNET Database Create (Signal).vi ... 4-409 XNET Database Create (Subframe).vi ... 4-410 XNET Database Create (LIN Schedule).vi ... 4-412 XNET Database Create (LIN Schedule Entry).vi... 4-413 xvii © National Instruments NI-XNET Hardware and Software Manual

17 Contents XNET Database Delete Object.vi... 4-415 XNET Database Delete (Cluster).vi... 4-416 XNET Database Delete (ECU).vi ... 4-417 XNET Database Delete (Frame).vi ... 4-418 XNET Database Delete (PDU).vi ... 4-419 XNET Database Delete (Signal).vi ... 4-420 XNET Database Delete (Subframe).vi... 4-421 XNET Database Delete (LIN Schedule).vi ... 4-422 XNET Database Delete (LIN Schedule Entry).vi ... 4-423 XNET Database Merge.vi ... 4-424 XNET Database Merge (Frame).vi ... 4-425 XNET Database Merge (PDU).vi ... 4-427 XNET Database Merge (ECU).vi ... 4-429 XNET Database Merge (LIN Schedule).vi ... 4-431 XNET Database Merge (Cluster).vi... 4-433 XNET Database Save.vi ... 4-435 File Management Subpalette ... 4-436 XNET Database Add Alias.vi ... 4-436 XNET Database Remove Alias.vi... 4-438 XNET Database Get List.vi ... 4-439 XNET Database Deploy.vi... 4-441 XNET Database Undeploy.vi... 4-443 XNET LIN Schedule Property Node ... 4-444 Cluster ... 4-444 Comment ... 4-445 Configuration Status.. ... 4-446 Entries... 4-447 Name (Short) ... 4-448 Priority... 4-449 Run Mode ... 4-450 XNET LIN Schedule Entry Property Node ... 4-451 Collision Resolving Schedule ... 4-452 Delay ... 4-453 Event Identifier... 4-453 Frames ... 4-454 Name (Short) ... 4-455 Node Configuration:Free Format :Data Bytes ... 4-456 Schedule ... 4-457 Type... 4-458 XNET Database Get DBC Attribute.vi ... 4-459 Notify Subpalette ... 4-461 XNET Wait.vi... 4-461 XNET Wait (Transmit Complete).vi... 4-462 XNET Wait (Interface Communicating).vi... 4-463 xviii NI-XNET Hardware and So ftware Manual ni.com

18 Contents XNET Wait (CAN Remote Wakeup).vi ... 4-465 XNET Wait (LIN Remote Wakeup).vi... 4-466 XNET Create Timing Source.vi... 4-467 ay Cycle).vi... 4-467 XNET Create Timing Source (FlexR Advanced Subpalette ... 4-476 XNET Start.vi ... 4-476 XNET Stop.vi... 4-479 XNET Clear.vi ... 4-481 XNET Flush.vi ... 4-482 XNET Connect Terminals.vi ... 4-483 XNET Disconnect Terminals.vi... 4-490 XNET Terminal Constant ... 4-491 XNET System Property Node... 4-491 Devices ... 4-492 ... 4-492 ... ... ... ... Interfaces (FlexRay) ... Interfaces (All)... ... ... ... ... ... 4-493 ... ... ... ... ...4-493 Interfaces (CAN) ... Interfaces (LIN) ... ... ... ... ... 4-494 ... Version:Build... 4-495 Version:Major... 4-496 Version:Minor ... 4-497 Version:Phase ... 4-498 Version:Update ... 4-499 XNET Device Property Node ... 4-500 Form Factor ... 4-500 Interfaces ... ... 4-501 ... ... ... ... Number of Ports... 4-502 Product Name ... 4-502 Product Number... 4-503 Serial Number... 4-503 Slot Number... 4-504 XNET Interface Property Node ... 4-504 CAN.Termination Capability ... 4-505 CAN.Transceiver Capability ... 4-506 Device ...4-507 Name... 4-507 Number ... 4-508 Port Number ... 4-509 Protocol... 4-510 XNET Interface Constant... 4-511 XNET Blink.vi ... 4-511 XNET System Close.vi ... 4-513 XNET String to IO Name.vi ... 4-514 NI-XNE National Instruments © xix T Hardware and Software Manual

19 Contents XNET Convert.vi... 4-515 XNET Convert (Frame CAN to Signal).vi... 4-516 XNET Convert (Frame FlexRay to Signal).vi ... 4-519 XNET Convert (Frame LIN to Signal).vi ... 4-522 XNET Convert (Frame Raw to Signal).vi... 4-524 XNET Convert (Signal to Frame CAN).vi... 4-526 FlexRay).vi ... 4-528 XNET Convert (Signal to Frame XNET Convert (Signal to Frame LIN).vi ... 4-531 XNET Convert (Signal to Frame Raw).vi... 4-533 Controls Palette ... 4-535 XNET Session Control ... 4-535 Database Controls ... 4-535 System Controls... 4-536 Additional Topics ... 4-53 7 Overall... 4-537 ... 4-537 Creating a Built Application ... Cyclic and Event Timing ... 4-538 Error Handling ... 4-539 Fault Handling ... 4-540 Multiplexed Signals ... 4-542 Raw Frame Format ... 4-544 Special Frames... 4-549 Required Properties ... ... 4-554 State Models ... 4-556 TDMS ... 4-564 CAN ... 4-569 NI-CAN ... 4-569 CAN Timing Type and Session Mode ... 4-571 CAN Transceiver State Machine ... 4-575 FlexRay ... 4-577 FlexRay Timing Type and Session Mode ... 4-577 Protocol Data Units (PDUs) in NI-XNET ... 4-580 FlexRay Startup/Wakeup... 4-583 LIN ... 4-586 ... 4-586 LIN Frame Timing and Session Mode .. XNET I/O Names... 4-590 I/O Name Classes ... 4-591 XNET Cluster I/O Name ... 4-592 XNET Database I/O Name ... 4-595 XNET Device I/O Name ... 4-598 XNET ECU I/O Name... 4-598 XNET Frame I/O Name ... 4-601 XNET Interface I/O Name... 4-604 XNET Session I/O Name ... 4-605 xx NI-XNET Hardware and Software Manual ni.com

20 Contents XNET Signal I/O Name ... 4-607 XNET Subframe I/O Name... 4-610 XNET Terminal I/O Name ... 4-611 XNET LIN Schedule I/O Name... 4-612 XNET LIN Schedule Entry I/O Name ... 4-614 XNET PDU I/O Name ... 4-615 Chapter 5 NI-XNET API for C Getting Started ... 5 -1 LabWindows/CVI... 5-1 Examples ... 5-1 Visual C++ 6 ... 5-2 Examples ... 5-3 ... ... 5-3 Interfaces... ... ... ... ... ... ... ... ... What Is an Interface?... ... ... ... ... ... 5-3 ... ... 5-4 How Do I View Available Interfaces? ... ... ... ... Measurement and Automation Explorer (MAX) ... 5-4 .5-4 Databases ... What Is a Database? ... 5-4 What Is an Alias?... 5-5 Database Programming ... 5-6 Already Have File? ... 5-6 Can I Use File as Is? ... 5-6 Select From File ... 5-7 Edit and Select ... 5-7 Want to Use a File? ... 5-7 Create New File Using the Database Ed itor ... 5-7 Create in Memory ... 5-7 Sessions... ... 5-8 What Is a Session?... 5-8 Session Modes ... 5-9 ... ... 5-10 ... Frame Input Queued Mode .. ... ... ... ... ... ... 5-12 Frame Input Single-Point Mode... ... Frame Input Stream Mode ... ... ...5-13 ... ... Frame Output Queued Mode... 5-16 Frame Output Single-Point Mode ... ... 5-18 Frame Output Stream Mode... 5-21 ... 5-24 Signal Input Single-Point Mode... Signal Input Waveform Mode... 5-26 Signal Input XY Mode ... 5-28 Signal Output Single-Point Mode ... 5-30 Signal Output Waveform Mode ... 5-31 xxi National Instruments © NI-XNET Hardware and Software Manual

21 Contents Signal Output XY Mode ... 5-34 Conversion Mode ... 5-38 NI-XNET API for C Reference ... 5-41 Functions ... 5-41 nxBlink ... 5-41 nxClear... 5-43 nxConnectTerminals... 5-44 ... 5-51 ... nxConvertFramesToSignalsSinglePoint... ... ... ... 5-53 nxConvertSignalsToFramesSinglePoint... ... ... ... nxCreateSession... 5-55 nxCreateSessionByRef ... 5-61 nxdbAddAlias ... 5-63 nxdbCloseDatabase ... 5-65 nxdbCreateObject ... 5-66 nxdbDeleteObject ... 5-68 nxdbDeploy ... 5-69 nxdbFindObject ... 5-71 nxdbGetDatabaseList... 5-73 nxdbGetDatabaseListSizes ... 5-75 nxdbGetDBCAttribute ... 5-77 nxdbGetDBCAttributeSize ... 5-79 nxdbGetProperty... 5-80 nxdbGetPropertySize ... 5-81 nxdbMerge ... 5-82 nxdbOpenDatabase ... 5-85 nxdbRemoveAlias ... 5-86 nxdbSaveDatabase ... 5-87 nxdbSetProperty ... 5-88 nxdbUndeploy ... 5-89 nxDisconnectTerminals ... 5-90 nxFlush ... 5-92 nxGetProperty... 5-93 nxGetPropertySize ... 5-95 nxGetSubProperty ... 5-96 nxGetSubPropertySize... 5-97 nxReadFrame ... 5-98 nxReadSignalSinglePoint ... 5-101 nxReadSignalWaveform... 5-103 nxReadSignalXY ... 5-105 nxReadState ... 5-107 nxSetProperty ... 5-119 nxSetSubProperty ... 5-120 nxStart... 5-121 nxStatusToString ... 5-123 xxii NI-XNET Hardware and Software Manual ni.com

22 Contents nxStop ...5-124 nxSystemClose... 5-126 nxSystemOpen ... 5-127 nxWait ...5-128 nxWriteFrame ... 5-130 nxWriteSignalSinglePoint... 5-133 nxWriteSignalWaveform ... 5-134 nxWriteSignalXY...5-136 nxWriteState... 5-138 Properties ... 5-141 XNET Cluster Properties ... 5-141 Baud Rate ... 5-141 CAN:FD Baud Rate ... 5-142 CAN:I/O Mode ... 5-143 Comment ... 5-144 ... 5-144 Configuration Status ... Database...5-145 ECUs... 5-145 FlexRay:Action Point Offset ... 5-146 FlexRay:CAS Rx Low Max ...5-147 FlexRay:Channels... 5-148 ... 5-149 FlexRay:Cluster Drift Damping ... FlexRay:Cold Start Attempts... 5-150 FlexRay:Cycle ... 5-151 FlexRay:Dynamic Segment Start ... 5-152 FlexRay:Dynamic Slot Idle Phase ... 5-153 FlexRay:Latest Guaranteed Dyna mic Slot ... 5-154 FlexRay:Latest Usable Dynamic Slot...5-155 FlexRay:Listen Noise ... 5-156 FlexRay:Macro Per Cycle ...5-157 FlexRay:Macrotick ... 5-158 ection Fatal ... FlexRay:Max Without Clock Corr ... 5-159 ection Passive . FlexRay:Max Without Clock Corr ... 5-160 FlexRay:Minislot ...5-161 fset... 5-162 FlexRay:Minislot Action Point Of FlexRay:Network Management Vector Length ... 5-163 FlexRay:NIT ... 5-164 FlexRay:NIT Start ... 5-165 ... 5-166 FlexRay:Number of Minislots ... FlexRay:Number of Static Slots ... 5-167 FlexRay:Offset Correction Start ... ... 5-168 FlexRay:Payload Length Dynamic Maximum ... 5-169 FlexRay:Payload Length Maximum... 5-170 FlexRay:Payload Length Static ... 5-171 NI-X © National Instruments xxiii NET Hardware and Software Manual

23 Contents FlexRay:Static Slot... 5-172 FlexRay:Symbol Window ... 5-173 FlexRay:Symbol Window Start ... 5-174 FlexRay:Sync Node Max ... 5-175 FlexRay:TSS Transmitter... 5-176 FlexRay:Use Wakeup... 5-177 FlexRay:Wakeup Symbol Rx Idle. ... 5-178 FlexRay:Wakeup Symbol Rx Low ... 5-179 FlexRay:Wakeup Symbol Rx Wind ow ... 5-180 FlexRay:Wakeup Symbol Tx Idle... 5-181 FlexRay:Wakeup Symbol Tx Low... 5-182 Frames ... 5-183 Name (Short) ... 5-184 PDUs ... 5-185 PDUs Required? ... 5-186 Protocol ... 5-188 Schedules... 5-188 Signals ... 5-189 Tick... 5-190 XNET Database Properties... 5-191 Clusters... 5-191 ShowInvalidFromOpen? ... 5-192 XNET Device Properties ... 5-193 Form Factor ... 5-193 ... Interfaces ... ... 5-194 ... ... ... Number of Ports ... 5-194 Product Name ... 5-195 Product Number ... 5-195 Serial Number ... 5-196 Slot Number ... 5-196 XNET ECU Properties ... 5-197 Cluster ... 5-197 Comment ... 5-197 ... 5-198 Configuration Status.. FlexRay:Coldstart?... 5-199 FlexRay:Connected Channels ... 5-199 FlexRay:Startup Frame ... 5-200 FlexRay:Wakeup Channels ... 5-200 FlexRay:Wakeup Pattern... 5-201 ... Frames Received ... ... 5-201 ... ... ... Frames Transmitted... 5-202 LIN Master ... 5-202 LIN Version... 5-203 LIN:Initial NAD ... 5-203 ni.com xxiv NI-XNET Hardware and Software Manual

24 Contents LIN:Configured NAD... 5-204 LIN:Supplier ID... 5-204 LIN:Function ID ... 5-205 LIN:P2min ... 5-205 LIN:STmin... 5-206 Name (Short) ... 5-207 XNET Frame Properties... 5-208 CAN:Extended Identifier? ...5-208 CAN:Timing Type... 5-209 CAN:Transmit Time ... 5-211 Cluster...5-212 Comment ... 5-212 Configuration Status ... ... 5-213 Default Payload ... 5-214 FlexRay:Base Cycle ... 5-216 FlexRay:Channel Assignment ... 5-218 FlexRay:Cycle Repetition... 5-219 FlexRay:In Cycle Repetitions:Channel Assignments... 5-221 FlexRay:In Cycle Repetitions:Enabled?... 5-222 FlexRay:In Cycle Repetitions:Ide ntifiers ... 5-223 FlexRay:Payload Preamble? ...5-224 FlexRay:Startup? ...5-225 FlexRay:Sync? ... 5-226 FlexRay:Timing Type... 5-227 Identifier ... 5-228 LIN:Checksum... 5-230 Mux:Data Multiplexer Signal ... 5-231 Mux:Is Data Multiplexed? ...5-231 Mux:Static Signals... 5-232 Mux:Subframes ... 5-232 Name (Short) ... 5-233 Payload Length ... 5-234 PDU References ... 5-235 PDU Start Bits ... 5-236 PDU Update Bits ...5-237 Signals ... 5-238 XNET Interface Properties...5-239 CAN.Termination Capability ... 5-239 CAN.Transceiver Capability ... 5-240 Device ...5-241 Name... 5-241 Number ... 5-242 Port Number ... 5-243 Protocol... 5-244 xxv National Instruments © NI-XNET Hardware and Software Manual

25 Contents XNET LIN Schedule Properties ... 5-245 Cluster ... 5-245 Comment ... 5-245 ... 5-246 Configuration Status.. Entries... 5-247 Name ... 5-247 Priority... 5-248 Run Mode ... 5-249 XNET LIN Schedule Entry Properties ... 5-250 Collision Resolving Schedule ... 5-250 Delay ... 5-250 Event Identifier... 5-251 Frames ... 5-252 Name ... 5-253 Name Unique to Cluster ... 5-254 Node Configuration:Free Format :Data Bytes ... 5-255 Schedule ... 5-256 Type... 5-257 XNET PDU Properties ... 5-258 Cluster ... 5-258 Comment ... 5-258 Configuration Status.. ... 5-259 Frames ... 5-260 Mux:Data Multiplexer Signal... 5-260 Mux:Is Data Multiplexed? ... 5-261 Mux:Static Signals ... 5-261 Mux:Subframes ... 5-262 Name (Short) ... 5-262 Payload Length... 5-263 Signals ... 5-264 XNET Session Properties ... ... 5-265 Interface Properties ... ... ... ... ... ... 5-265 CAN Interface Properties... ... ... ... 5-265 Interface:CAN:External Transceiver Config ... 5-265 Interface:CAN:FD Baud Rate ... 5-268 Interface:CAN:I/O Mode ... ... 5-270 Interface:CAN:Listen On ly? ... ... 5-271 Interface:CAN:Pending Transmit Order ... 5-272 Interface:CAN:Single Shot Transmit? ... 5-274 ... 5-275 Interface:CAN:Terminat ion ... ver State ... 5-277 Interface:CAN:Transcei xxvi NI-XNET Hardware and Software Manual ni.com

26 Contents Interface:CAN:Transcei ver Type ... 5-280 Interface:CAN:Transmit I/O Mode ... 5-282 ... 5-283 ... FlexRay Interface Properties .. ... Interface:FlexRay:Accepted Startup Range ...5-283 Interface:FlexRay:Allow Halt Due To Clock?... 5-284 Interface:FlexRay:Allow Passive to Active... 5-285 Interface:FlexRay:AutoAsleepWhen Stopped ...5-286 Interface:FlexRay:Cluster Drift Damping... 5-287 ... 5-288 art? ... Interface:FlexRay:Coldst Interface:FlexRay:Connected Channels... 5-289 Interface:FlexRay:Decoding Correction ... 5-290 Interface:FlexRay:Delay Compensation Ch A ... 5-291 Interface:FlexRay:Delay Compensation Ch B ... 5-292 Interface:FlexRay:Key Sl ot Identifier ... 5-293 ... 5-295 Interface:FlexRay:Latest Tx ... Interface:FlexRay:Listen Timeout ... 5-296 Interface:FlexRay:Macro Initial Offset Ch A ... 5-297 Interface:FlexRay:Macro Initial Offset Ch B ... 5-298 Interface:FlexRay:Max Dr ift ... ... 5-299 Interface:FlexRay:Micro Initial Offset Ch A ... 5-300 Interface:FlexRay:Micro Initial Offset Ch B ... 5-301 ... 5-302 ick... Interface:FlexRay:Microt Interface:FlexRay:Null Frames To Input Stream? ...5-303 Correction ... 5-304 Interface:FlexRay:Offset Interface:FlexRay:Offset Correction Out... 5-305 Interface:FlexRay:Rate Correction ... 5-306 Interface:FlexRay:Rate Correction Out... 5-307 NI-XN © National Instruments xxvii ET Hardware and Software Manual

27 Contents Interface:FlexRay:Samples Per Microtick ... 5-308 Interface:FlexRay:Single Slot Enabled? ... 5-309 Interface:FlexRay:Sleep . ... ... 5-310 Interface:FlexRay:Statistics Enabled?... 5-312 Frames To Input Interface:FlexRay:Symbol Stream? ... 5-313 Interface:FlexRay:Sync Frame Status ... 5-314 Interface:FlexRay:Sync Frames Channel A Even ... 5-315 Interface:FlexRay:Sync Frames Channel A Odd ... 5-316 Interface:FlexRay:Sync Frames Channel B Even ... 5-317 Interface:FlexRay:Sync Frames Channel B Odd ... 5-318 ination ... 5-319 Interface:FlexRay:Term Interface:FlexRay:Wakeup Channel ... 5-320 Interface:FlexRay:Wakeup Pattern ... 5-321 LIN Interface Properties ... ... ... ... 5-322 Interface:LIN:Break Leng th ... ... 5-322 Interface:LIN:DiagP2min. ... ... 5-323 Interface:LIN:DiagSTmi n ... ... 5-324 ... Interface:LIN:Master? ... ... 5-325 Interface:LIN:Output Stream Slave Response List By NAD... 5-326 Interface:LIN:Schedule Names ... 5-327 Interface:LIN:Sleep ... ... ... 5-328 Interface:LIN:Start Allowed without Bus Power? ... 5-331 Interface:LIN:Terminatio n ... ... 5-332 Source Terminal Interface Pr operties ... ... 5-333 Interface:Source Te rminal:Start Trigger ... 5-333 ... Interface:Baud Rate ... ... ... 5-334 Interface:Echo Transmit?... ... ... 5-337 ... Interface:Output Stream List ... ... ... 5-338 Interface:Output Stream List By ID... ... 5-339 Interface:Output Stream Ti ming ... ... 5-340 Interface:Start Trigge r Frames to Input Stream? ... 5-344 eam? ... 5-345 Interface:Bus Error Frames to Input Str xxviii NI-XNET Hardware and Software Manual ni.com

28 Contents Frame Properties ... 5-346 CAN Frame Properties ... 5-346 Offset... 5-346 Frame:CAN:Start Time Frame:CAN:Transmit Time... 5-347 upted Checksums... 5-348 Frame:LIN:Transmit N Corr Frame:Skip N Cyclic Frames ... 5-349 Auto Start? ... 5-350 ClusterName ... 5-351 DatabaseName ... 5-351 List ... 5-352 Mode ... 5-352 Number in List... 5-353 Number of Values Pending... 5-353 Number of Values Unused ... 5-355 Payload Length Maximum ... 5-356 Protocol... 5-356 Queue Size ... 5-358 Resample Rate ... 5-364 XNET Signal Properties... 5-365 Byte Order ... 5-365 Comment ... 5-367 Configuration Status ... ... 5-368 Data Type ... 5-369 Default Value... 5-370 Frame ... 5-371 Maximum Value ... 5-371 Minimum Value... 5-372 Mux:Data Multiplexer? ... 5-373 Mux:Dynamic? ... 5-374 Mux:Multiplexer Value ... 5-375 Mux:Subframe ... 5-375 Name (Short) ... 5-376 Name Unique to Cluster ... 5-377 Number of Bits ... 5-378 PDU ... 5-379 Scaling Factor ... 5-379 Scaling Offset ... 5-380 Start Bit... 5-381 Unit ... 5-383 XNET Subframe Properties ... 5-383 Dynamic Signals ... 5-383 Frame ... 5-384 Multiplexer Value ... 5-385 Name (Short) ... 5-386 NI-XN © National Instruments xxix ET Hardware and Software Manual

29 Contents Name Unique to Cluster ... 5-387 PDU ... 5-387 XNET System Properties... 5-388 Devices ... 5-388 ... 5-389 ... ... ... ... Interfaces (All) ... ... ... 5-389 Interfaces (CAN) ... ... ... ... ... Interfaces (FlexRay) .. ... ... ... ... 5-390 ... ... 5-390 Interfaces (LIN)... ... ... ... Version:Build ... 5-391 Version:Major ... 5-392 Version:Minor ... 5-393 Version:Phase... 5-394 Version:Update... 5-395 6 Additional Topics ... 5-39 Overall... 5-396 Cyclic and Event Timing ... 5-396 Multiplexed Signals ... 5-397 Raw Frame Format ... 5-399 Special Frames... 5-407 ... 5-410 Required Properties ... State Models ... 5-412 CAN ... 5-419 NI-CAN ... 5-419 CAN Timing Type and Session Mode ... 5-421 CAN Transceiver State Machine ... 5-425 FlexRay ... 5-427 FlexRay Timing Type and Session Mode ... 5-427 Protocol Data Units (PDUs) in NI-XNET ... 5-430 FlexRay Startup/Wakeup... 5-433 LIN ... 5-435 LIN Frame Timing and Session Mode .. ... 5-435 Chapter 6 nd Common Questions Troubleshooting a Appendix A Summary of the CAN Standard Appendix B Summary of the FlexRay Standard xxx NI-XNET Hardware and Software Manual ni.com

30 Contents Appendix C Summary of the LIN Standard Appendix D Specifications Appendix E LabVIEW Project Provider Appendix F Bus Monitor Appendix G Database Editor Appendix H NI Services Index xxxi © National Instruments NI-XNET Hardware and Software Manual

31 About This Manual This manual describes how to install and configure the NI-XNET hardware and software and summarizes the CAN, FlexRay, and LIN standards. It also includes the NI-XNET LabVIEW and C API reference. Related Documentation The following documents contain information that you may find helpful as you read this manual: • NI-XNET Hardware and Software Help NI-XNET Tools and Utilities Help • • NI-XNET Hardware and Software Installation Guide National Instruments NI-XNET Hardware and Software Manual xxxi ©

32 1 Introduction Welcome to NI-XNET, the National Instruments software for CAN, FlexRay, and LIN products. NI-XNET is designed to meet the following goals: • Ease of use : NI-XNET features provide f undamental concepts so that you can get started with programming. • Consistency : NI-XNET uses common industry concepts for embedded networks such as CAN. Thes e concepts help to abstract the differences between protocols, so you can focus on your application. • Completeness : NI-XNET provides a broad spectrum of features, from easy-to-use signal I/O, down to more advanced streaming of raw frames. You can use these features simultaneously on the same interface: input along with output and signal I/O along with frame I/O. : Read and Write functions are designed to Performance • execute quickly, without loss of data. Performance for LabVIEW Real-Time (RT) applications is a ke y focus of NI-XNET software and hardware architecture. If you are new to the CAN protocol, refer to Appendix A, Summary of the CAN Standard , for an introduction. If you are new to the FlexRay protocol, refer to Appendix B, Summary of the FlexRay Standard , for an introduction. If you are new to the LIN protocol, refer to Appendix C, Summary of the LIN Standard , for an introduction. Chapter 3, NI-XNET Hardware Overview , summarizes the features of National Instruments hardware for CAN, FlexRay, and LIN. Getting Started in If you use LabVIEW for programming, refer to Chapter 4, NI-XNET API for LabVIEW , for a description of NI-XNET software concepts and programming models. If you use C, C++, or another la nguage for programming, refer to Getting NI-XNET API for C in Chapter 5, , for a description of NI-XNET Started software concepts and programming models. National Instruments NI-XNET Hardware and Software Manual 1-1 ©

33 2 Installation and Configuration This chapter explains how to inst all and configure NI-XNET hardware. Safety Information The following section contains important safety information that you must follow when installing and using the module. not operate the module in a manner not specified in this document. Do Misuse of the module can result in a hazard. You can compromise the safety protection built into the module if the module is damaged in any way. If the module is damaged, return it to National Instruments (NI) for repair. Do not substitute parts or modify the module except as described in this s, accessories, and document. Use the module only with the chassis, module must have all covers cables specified in the installation instructions. You and filler panels installed during operation of the module. Do not operate the module in an explosive atmosphere or where there may be flammable gases or fumes. If you must operate the module in such an environment, it must be in a suitably rated enclosure. If you need to clean the module, use a soft, nonmet allic brush. Make sure that the module is completely dry and free from contaminants before returning it to service. Operate the module only at or below Pollution Degree 2. Pollution is foreign matter in a solid, liquid, or gaseous state that can reduce dielectric strength or surface resistivity. The fo llowing is a description of pollution degrees: • Pollution Degree 1 means no pollution or only dry, nonconductive pollution occurs. The pollution has no influence. • Pollution Degree 2 means that only nonconductive pollution occurs in most cases. Occasionally, however, a temporary conductivity caused by condensation must be expected. National Instruments NI-XNET Hardware and Software Manual 2-1 ©

34 Chapter 2 Installation and Configuration • Pollution Degree 3 means that conductive pollution occurs, or dry, nonconductive pollution occurs that becomes conductive due to condensation. You must insulate signal connections for the maximum voltage for which the module is rated. Do not exceed the maximum ratings for the module. Do not install wiring while the module is live with electrical signals. Do not remove or add connector blocks when power is connected to the system. Avoid contact between your body and the connector block signal when hot swapping modules. Remove power from signal lines before connecting them to or disconnecting them from the module. 1 installation category Operate the module at or below the marked on the 2 hardware label. Measurement circuits are subjected to working voltages and transient stresses (overvoltage) from the circuit to which they are connected during measurement or test . Installation categories establish standard impulse withstand voltage levels that commonly occur in electrical distribution systems. The following is a description of installation categories: ements performed on circuits not • Installation Category I is for measur distribution system referred to as directly connected to the electrical 3 MAINS voltage. This category is for m easurements of voltages from specially protected seco ndary circuits. Such voltage measurements include signal levels, special eq uipment, limited-energy parts of equipment, circuits powered by re gulated low-voltage sources, and electronics. • Installation Category II is for measurements performed on circuits directly connected to the electrical distribution system. This category refers to local-level el ectrical distributi on, such as that provided by a standard wall outlet (for example, 115 AC voltage for U.S. or 230 AC voltage for Europe). Examples of Installation Category II are measurements performed on househol d appliances, portable tools, and similar modules. 1 Installation categories, also referred to as measurement categories, are defined in electrical safety standard IEC 61010-1. 2 Working voltage is the highest rms value of an AC or DC voltage that can occur acro ss any particular insulation. 3 y rated measuring circuits may MAINS is defined as a hazardous live electrical supply system that powers equipment. Suitabl S for measuring purposes. be connected to the MAIN 2-2 NI-XNET Hardware and Software Manual ni.com

35 Chapter 2 Installation and Configuration • Installation Category III is for measurements performed in the building installation at the distribution level. This category refers to measurements on hard-wir ed equipment such as equipment in fixed installations, distribution boards, and circuit breakers. Other examples are wiring, including cables, bus bars , junction boxes, switches, socket outlets in the fixed installation, and stationary motors with permanent connections to fixed installations. Installation Category IV is for measurements performed at the primary • es include electricity electrical supply instal lation (<1,000 V). Exampl meters and measurements on primar y overcurrent protection devices and on ripple control units. Measurement & Automation Explorer (MAX) You can use Measurement & Automation Explorer (MAX) to access all National Instruments products. Like other National Instruments hardware products, NI-XNET uses MAX as the centralized location for XNET device configuration. To launch MAX, click the Measurement & Automation shortcut on the desktop or select Start»Programs»National Instruments»Measurement & Automation . For information about the NI-XNET software in MAX, consult the online help at Help»Help Topics»NI-XNET . You can view help for MAX Configuration tree items using the built-in MAX help pane. If this help pane does not appear on the right side of the button in the upper right corner. Show Help MAX window, click the 2-3 © National Instruments NI-XNET Hardware and Software Manual

36 Chapter 2 Installation and Configuration Verifying NI-XNET Hardware Installation Devices and Interfaces The MAX Configuration tree branch lists NI-XNET hardware (along with other local computer system hardware), as shown in Figure 2-1. Figure 2-1. NI-XNET Hardware Listed in MAX If the NI-XNET hardware is not listed here, MAX is not configured to search for new devices on startup. To search for the new hardware, press . To verify installation of the NI-XNET hardware, right-click the NI-XNET . If the self-test passes, the card icon shows a device and select Self-Test checkmark. If the self-test fails, the card icon shows an mark, and the X Test Status in the right pane describes the problem. Refer to Chapter 6, Troubleshooting and Common Questions , for information about resolving hardware installation problems. 2-4 NI-XNET Hardware and Software Manual ni.com

37 Chapter 2 Installation and Configuration XNET C Series Modules Firmware Update For C Series modules, the module firmware is not updated automatically when opening an XNET session. Theref ore, the right pane in MAX has a second tab that shows the module firmware status. Module and XNET Firmware Match Figure 2-2. If the module firmware matches the firmware that the current XNET version requires, the right pane in MA X is marked with a check mark, and button is disabled, as shown in Figure 2-2. In case the Update Firmware of a version mismatch, the right pane in MAX and the module in the MAX tree view are marked with an exclamatio n point (!), as shown in Figure 2-3. In this case, the text in the right pane says the firmware must be updated, and the button is enabled. Update Firmware 2-5 © National Instruments NI-XNET Hardware and Software Manual

38 Chapter 2 Installation and Configuration Figure 2-3. Firmware Update Needed If MAX indicates a firmware versi on mismatch, you must update the module firmware before using the module. NI-XNET Hardware and Software Manual 2-6 ni.com

39 Chapter 2 Installation and Configuration Configuring NI-XNET Interfaces The NI-XNET hardware interfaces are listed under the device name. To box change the interface name, select a new one from the Interface Name in the middle pane, as shown in Figure 2-4. Renaming an Interface Figure 2-4. LabVIEW Real-Time (RT) Configuration LabVIEW Real-Time (RT) combines easy-to-use LabVIEW programming with the power of real-time systems. When you use a National Instruments PXI-XNET card and use the NI-XNET PXI controller, you can install a API to develop real-time applications. For example, you can simulate the behavior of a control algorithm within a XNET device, using data from generate outgoing CAN or FlexRay received CAN or FlexRay messages to messages with deterministic response times. 2-7 © National Instruments NI-XNET Hardware and Software Manual

40 Chapter 2 Installation and Configuration , the installer copies components When you install the NI-XNET software for LabVIEW RT to the Windows system. As with any other NI product for LabVIEW RT, you then download the NI-XNET software to the LabVIEW Remote Systems RT system using the branch in MAX. For more information, refer to the LabVIEW RT documentation. After you install the NI-XNET hardware and download the NI-XNET software to the LabVIEW RT system, you can verify the installation. Find Remote Systems Devices and your RT target under and open the item. Perform a self test for all installed NI-XNET devices. Interfaces Getting Started with CompactRIO When you use a C Series NI-XNET mo dule in a CompactRIO chassis, the NI-XNET features on LabVIEW RT ar e the same as on other LabVIEW RT targets, such as PXI. Neverthe less, the communication between the NI-XNET RT driver and module does not exist in the default FPGA VI that ships with CompactRIO. Prior to us ing NI-XNET features, you must use LabVIEW FPGA to compile and run an FP GA VI that contains the required communication logic. The following steps describe how to use a C Series NI-XNET module in a CompactRIO chassis from its out-of-box configuration. 1. Install the required software to the host computer. a. LabVIEW (Including RT and FPGA) Install LabVIEW, LabVIEW R eal-Time, LabVIEW FPGA, and NI-RIO. For supported versions of the so ftware mentioned above, refer to the Supported Platforms section in the NI-XNET readme file. b. NI-XNET Install NI-XNET after the required LabVIEW components. 2. Install NI-XNET to the CompactRIO RT controller. Use MAX to find your CompactRIO controller under Remote Systems , then right-click Software and select Change/Remove Software . There are two ways to inst all the required components: • NI-RIO with NI Scan Engine Support If this selection is dimmed, refer to the explanation on the right to resolve the problem, or use custom installation. After selecting this item, the next page displays a list of add-ons. Scroll down to . NI-XNET the bottom of the add-on list to check 2-8 NI-XNET Hardware and Software Manual ni.com

41 Chapter 2 Installation and Configuration Custom Software Installation • Custom installation can be useful on controllers with small amounts of memory b ecause you can use it to avoid installing unused components. Select the NI-XNET item, which in turn selects the required dependencies (for example, NI-RIO IO Scan). Add modules to the LabVIEW project. 3. To compile an FPGA VI with the required communication logic, you must add NI-XNET modules in a LabVIEW project. a. Add the controller. Assuming your controller is online, you can right-click the project item and select New»Targets and Devices»Existing target or device Real-Time , then select your controller under CompactRIO . If your controller is offline, you can add it by selecting New target or device . b. Select the chassis programming mode. When you add the controller, a di alog asks you to select the programming mode for the chassis. Although NI-XNET uses scan engine components, you must select LabVIEW FPGA Interface as the chassis mode. This configures the chassis to support compiling an FPGA VI. dialog appears, click the Discover C Series Modules? If a Do Not Discover button and proceed to step d. c. Ignore errors for discovered NI-XNET modules. LabVIEW 2010 may report an error for NI-XNET modules, stating that LabVIEW FPGA is not supported. LabVIEW 2011 or later does not report this error. Do not change the chassis to Scan Interface mode. Ignore this error message and click Continue . d. Add NI-XNET modules. r the controller (not FPGA) and Right-click the chassis item unde select New»C Series Modules»Existing target or device . Select the plus sign to discover and then hold to select all NI-XNET modules in the list. Click OK to add the modules to the project. New You also can add NI-XNET modules offline by selecting target or device , and in the next dialog , then C Series Module select the appropriate Module Type (for example, NI 9862). When you use an NI-XNET module in a project, you do not module installed physically. For necessarily need to have that NI-XNET, the module in the project is simply a signal to the on is required for that slot. FPGA VI that NI-XNET communicati 2-9 © National Instruments NI-XNET Hardware and Software Manual

42 Chapter 2 Installation and Configuration Compile and run the FPGA VI. 4. can use an empty FPGA VI to get If you are new to CompactRIO, you s and examples. Select the FPGA started quickly with NI-XNET tool New»VI . When the target in the LabVIEW project, and then select front panel opens, click the LabVIEW run button (the arrow) to compile and run the VI. Although the VI is empty, it loads the required NI-XNET support. When compilation completes, and the VI runs the nel and proceed to the next step. first time, you can close the front pa If you have an existing FPGA VI in your project, you must recompile the FPGA VI to incorporate NI-XNET support for the configured slots. When the FPGA VI is recompiled, you run it using the same methods you used previously. This typically is done using Open FPGA VI Reference from a host VI. iled list of actions that cause The following tables provide a deta NI-XNET to load and unload. NI-XNET must be loaded for its XNET-enabled hardware to be detected. Within the tables, the term with a project that contains refers to an FPGA VI compiled FPGA VI at least one NI-XNET module. The term XNET-disabled FPGA VI refers to an FPGA VI compiled with no NI-XNET modules. Actions That Cause NI-XNET to Load Table 2-1. Comment Action Invoke NI-XNET loads regardless of Open FPGA VI whether is Reference with an XNET-enabled Run the FPGA VI checked in the configuration FPGA VI. dialog. — Run the XNET-enabled FPGA VI using Interactive Front Panel Communication. NI-XNET does not load when the CompactRIO system powers up. Even if you Note configure an XNET-enabled FPGA VI to load automatically on power on, you must perform an action from Table 2-1 prior to using NI-XNET. 2-10 NI-XNET Hardware and Software Manual ni.com

43 Chapter 2 Installation and Configuration NI-XNET to Unload Actions That Cause Table 2-2. Comment Action If the reference is not the last to Close FPGA VI Invoke with the shortcut Reference close, NI-XNET remains loaded. The shortcut options Close Close and Reset if Last option and (default). Reference Close and Abort without do not Reference Counting unload NI-XNET. Power down CompactRIO. — Run XNET-disabled FPGA VI. This applies to Open FPGA VI Reference or Interactive Front Panel Communication. Invoke Reset using the Invoke Reset of an open FPGA reference causes NI-XNET to unload, and Method node of the FPGA then immediately load again. If interface. you are using NI-XNET sessions during the reset, the sessions are invalidated. Other methods such as Abort do not unload NI-XNET. Run a different XNET-enabled When you change FPGA VIs, the FPGA VI from the XNET-enabled effect is the same as the reset method. NI-XNET unloads and FPGA VI currently loaded. then immediatel y loads again. l Communication, stopping the FPGA VI When using FPGA Interactive Front Pane Note does not unload NI-XNET. This applies to stopping the VI normally (for example, from the bVIEW abort button (the stop sign). front panel button), or using the La Wait for interfaces to be detected. 5. After the FPGA runs with NI-XNET support, it may take a few seconds for the new FPGA features to be detected, appropriate RT drivers to load, and NI-XNET modules to be detected. This delay occurs only after you perform the action from Table 2-1. NI-XN National Instruments 2-11 © ET Hardware and Software Manual

44 Chapter 2 Installation and Configuration There are several options for detecting NI-XNET interface hardware: • MAX Devices & Interfaces —You can detect the interfaces visually by opening the Devices & Interfaces tree under the RT controller in MAX. Once the hardware is detected, you can perform a self test to confirm that all hardware and software is ready to use. • LabVIEW Interface I/O Name —When you drop an XNET interface I/O name control on the front panel of an RT VI, the control uses features similar to MAX to display available interfaces. For interface detection to st right-click operate, you mu the RT controller in the LabVIEW project and select Connect (or Deploy ). Once connected, you can use the interface I/O name to select an interface pr ior to running the RT VI. • System API —If you need to detect in terfaces programmatically within a running RT VI, National Instruments provides APIs for nfiguration API can detect any this purpose. The NI System Co NI hardware product, includi ng NI-XNET interfaces. NI-XNET also provides a System API with properties specific to NI-XNET hardware. If you run your RT VI as a startup VI (for example, after power on), you must perform an action from Table 2-1, then use a System API to wait for the required interf aces prior to calling XNET Create Session . If you create an I/O session prior to detecting the specified interface, an interface-not-found error can occur. 6. Use NI-XNET. Once the interfaces are detected, yo u are ready to use them. Within your RT VI, NI-XNET sessions are used to read and write I/O data. For in Chapter 4, NI-XNET API for Sessions more information, refer to LabVIEW . Tools NI-XNET includes two tools you can launch from MAX: • Bus Monitor —Displays statistics for CAN, FlexRay, or LIN frames. This is a basic tool for analyzing CAN, FlexRay, or LIN network traffic. Launch this tool by ri ght-clicking an NI -XNET interface and from the context menu. selecting Bus Monitor The Bus Monitor supports Windows targets only. Note 2-12 NI-XNET Hardware and Software Manual ni.com

45 Chapter 2 Installation and Configuration • NI I/O Trace —Monitors function calls to the NI-XNET APIs. This tool helps in debugging application programming problems. To launch this tool, open the Software branch of the MAX Configuration tree, , and select NI I/O Trace right-click . Launch NI I/O Trace System Configuration API NI-XNET supports the National Instruments System Configuration API, many operations in MAX. This which provides programmatic access to enables you to perform these operations within your application. The System Configuration API gathers information using various product gather information for one type of experts. You can create a filter to product, such as filtering for NI-XNET devices only. The NI-XNET expert programmatic name is xnet . NI-XN © National Instruments 2-13 ET Hardware and Software Manual

46 3 NI-XNET Hardware Overview Overview NI-XNET is a suite of products that provide connectivity to CAN, FlexRay, and LIN networks. NI-XNET FlexRay Hardware FlexRay Physical Layer The FlexRay physical layer circuitr y interfaces the FlexRay protocol controller to the physical bus wires. Tr an s ce i ve r NI-XNET FlexRay hardware uses a pair of NXP TJA1080 FlexRay transceivers per port. The TJA1080 is fully compatible with the FlexRay standard and supports baud rates up to 10 Mbps. This device also supports advanced power management through a low-power sleep mode. Refer to Interface:FlexRay:Sleep property for more the NI-XNET Session information. For detailed TJA1080 specifications, refer to the NXP TJA1080 data sheet. Bus Power Requirements The FlexRay physical layer on PXI and PCI NI-XNET interfaces is internally powered. As such, there is no need to supply bus power. The Pinout COM pin serves as the reference gr ound for the bus signals. Refer to for the PXI and PCI NI-XNE T FlexRay interface pinout. Cabling Requirements for FlexRay Cables may be shielded or unshielded and should meet the physical medium requirements described in Table 3-1. National Instruments NI-XNET Hardware and Software Manual 3-1 ©

47 Chapter 3 NI-XNET Hardware Overview FlexRay Cable Characteristics Table 3-1. Va l u e Characteristic  80–110 Differential mode impedance @ 10 MHz 10 ns/m Specific line delay Cable attenuation @ 5 MHz (sine wave) 82 dB/km Cable Lengths and Number of Devices The cabling characteristics, cabling topology, and desired bit transmission th. Detailed recommendations for cable rates affect the allowable cable leng FlexRay Electrical Physical Layer length and number of devices are in the Consortium. In general, the available from the FlexRay Specification maximum electrical length for a passive bus topology is 24 m, with the number of devices limited to 22. Termination The simplest way to terminate FlexRay networks is with a single termination resistor between the bus wires Bus Plus and Bus Minus. The specific network topology determines the optimal termination values. For all XNET devices, the terminati on is software selectable. XNET between Bus Plus and Bus Minus or no  provides the option of 80 termination. You cannot set termination for channel A and channel B independently. Refer to the Termination attribute in the XNET API for more details. To determine the appropriate termination for your network, refer to the FlexRay Electrical Physic al Layer Specification for more information. property for Interface:FlexRay:Termination Refer to the NI-XNET Session more information. Pinout Table 3-2 describes the FlexRay DB9 pinout. FlexRay DB9 Pinout Table 3-2. Pin Signal Signal 1 NC No connection 2 FlexRayA BM FlexRay channel A bus minus 3-2 ni.com NI-XNET Hardware and Software Manual

48 Chapter 3 NI-XNET Hardware Overview nout (Continued) FlexRay DB9 Pi Table 3-2. Signal Pin Signal 3 COM FlexRay reference ground 4 FlexRay B BM FlexRay channel B bus minus SHLD FlexRay shield 5 Optional FlexRay reference ground 6 (COM) FlexRay channel A bus plus 7 FlexRay A BP 8 FlexRay B BP FlexRay channel B bus plus 9 (Ext_VBat) Optional external bus voltage NI-XNET CAN Hardware NI-XNET Transceiver Cables Hardware supporting NI-XNET Transcei ver Cables allows you to select each port individually by plugging in the appropriate Transceiver Cable. Each Transceiver Cable implements the interface physical layer of the interface. NI-XNET Transceiver Cables are designed to interface to NI-XNET host ports. XS Software Selectab le Physical Layer XNET CAN XS hardware allows you to se lect each port individually in the e following transceivers: physical layer for one of th High-Speed • • Low-Speed/Fault-Tolerant Single Wire • • External Transceiver When an XS port is selected as High-Speed, it behaves exactly as a dedicated High-Speed interface. When an XS port is selected as ant, it behaves exactly as a dedicated Low-Speed/Fault-Toler Low-Speed/Fault-Toler ant interface. When an XS po rt is selected as Single ed Single Wire interface. The bus Wire, it behaves exactly as a dedicat power requirements depend on the mode selected. Refer to the appropriate High-Speed, Low-Speed/ Fault-Tolerant, or Single Wire physical layer NI-XNET Hardware and Software Manual 3-3 National Instruments ©

49 Chapter 3 NI-XNET Hardware Overview section to determine the behavior for the mode selected. For example, the bus power requirements for an XS por t configured for Single Wire mode are identical to those of a dedicated Single Wire node. This feature is Interface:CAN:Transceiver Type property. provided as the ternal, all onboard transceivers are When an XS port is selected as Ex bypassed, and the CAN controller signal s are routed directly to the 9-pin D-SUB connector. External mode is intended for interfacing custom physical layer circuits to NI XNET CAN hardware. Refer to External CAN Transceiver for more details. High-Speed Physical Layer rcuitry interfaces the CAN protocol The High-Speed CAN physical layer ci controller to the physical bus wires. Tr an s ce i ve r NI-XNET CAN High-Speed hardware us es either the NXP TJA1041 or NXP TJA 1043 High-Speed CAN transceiver. The NI-XNET CAN HS/FD Transceiver Cable uses the TJA1043 transceiver. All other PXI and PCI NI-XNET High-Speed CAN interfaces use the TJA1041. Both the TJA1041 and TJA 1043 are fully compatible with the ISO 11898 standard and support baud rates of 40 kbps to 1 Mbps. These devices also support advanced power management through a low-power sleep mode. Refer to the NI-XNET Session Interface:CAN:Transceiver State property for more information. For detailed transceiver specifications, refer to the TJA1041 or TJA 1043 data sheet. Bus Power Requirements The High-Speed physical layer on PXI, PCI, and Transceiver Cable NI-XNET interfaces is internally power ed. As such, there is no need to supply bus power. The COM pin serves as the reference ground for the bus signals. Refer to Pinouts for the PXI and PCI NI-XNET CAN interface pinout. The High-Speed physical layer on C Series NI 9862 requires external power supply of +9 to +30 V to operate. Connect the external power supply to the Vsup pin on the module. The COM pins are for reference ground. Pinouts for the C Series NI-XNET CAN module pinout. Refer to 3-4 NI-XNET Hardware and Software Manual ni.com

50 Chapter 3 NI-XNET Hardware Overview for High-Speed CAN Cabling Requirements Cables should meet the physical medium requirements specified in ISO 11898, shown in Table 3-3. Belden cable (3084A) meets all these requirements and should be suitable for most applications. aracteristics of a CAN_H and Table 3-3. ISO 11898 Specifications for Ch CAN_L Pair of Wires Va l u e Characteristic  minimum, 120  108 Impedance nominal, maximum  132 70 m /m nominal Length-related resistance  5 ns/m nominal Specific line delay Cable Lengths d bit transmission rate affect the The cabling characteristics and desire allowable cable length. Detailed cable length recommendations are in the ISO 11898 and CiA DS 102 specifications. ISO 11898 specifies 40 m total cable length with a maximum stub length of 0.3 m for a bit rate of 1 Mbps. The ISO 11898 specification says that significantly longer cable lengths may be allowed at lower bit rates, but each node should be analyzed for signal integrity problems. Number of Devices nds on the electrical characteristics The maximum number of devices depe ll devices meet the requirements of of the devices on the network. If a devices to the bus. You can connect ISO 11898, you can connect at least 30 higher numbers of devices if the aracteristics do not device electrical ch degrade signal quality below ISO 11898 signal level specifications. The acteristics allow at least 110 CAN NI-XNET CAN hardware electrical char ports on the network. Cable Termination The pair of signal wires (CAN_H and CAN_L) constitutes a transmission terminated, each signal change on the line. If the transmission line is not y cause communication failures. line causes reflections that ma NI-XNET Hardware and Software Manual 3-5 National Instruments ©

51 Chapter 3 NI-XNET Hardware Overview Because communication flows both ways on the CAN bus, CAN requires that both ends of the cable be terminated. However, this requirement does a termination resistor. If multiple not mean that every device should have devices are placed along the cable, only the devices on the ends of the cable should have termination resistors. Refer to Figure 3-1 for an example of where termination resistors should be placed in a system with more than two devices. CAN CAN CAN Device Device Device CAN_H CAN 120 Ω 120 Ω Device CAN_L Termination Resistor Placement Figure 3-1. The termination resistors on a cable should match the nominal impedance of the cable. ISO 11898 requires a cable with a nominal impedance of 120   , so you should use a 120 resistor at each end of the cable. Each termination resistor should be capable of dissipating 0.25 W of power. NI-XNET devices feature software selectable bus termination for High-Speed CAN transceivers. On the PXI-8512, PCI-8512, PCI-8513 (in high-speed mode), or PXI-8513 (in high-speed mode), you can enable 120 termination resistors between CAN_H and CAN_L through an  API call. property for Refer to the NI-XNET Session Interface:CAN:Termination more information. ni.com 3-6 NI-XNET Hardware and Software Manual

52 Chapter 3 NI-XNET Hardware Overview Cabling Example le to connect two CAN devices. For Figure 3-2 shows an example of a cab the internal power configuration, no V+ connection is required. 9-Pin 9-Pin D-Sub D-Sub CAN_H Pin 7 Pin 7 120 Ω 120 Ω CAN_L Pin 2 Pin 2 SHIELD Pin 5 Pin 5 V+ Pin 9 Pin 9 V– Pin 3 Pin 3 Power Connector V+ V– Figure 3-2. Cable Connecting Two CAN Devices ant Physical Layer Low-Speed/Fault-Toler The Low-Speed/Fault -Tolerant CAN physical laye r circuitry interfaces the CAN protocol controller to the physical bus wires. Tr an s ce i ve r NI-XNET CAN Low-Speed/Fault-Toler ant hardware uses either the NXP TJA1054A or NXP TJA1055T Low-Speed/Fault-Tolerant transceiver. NI PXI and PCI XNET interfaces revision E and higher use the TJA1055T transceiver, while revision D and lower use the TJA1054A transceiver. To identify your PCI/PXI NI-XNET hardware revision, refer to the 19xxxx–4xL text on the green label in the top left corner on the indicates the hardware revision. secondary side of the board; NI-XNET Hardware and Software Manual 3-7 National Instruments ©

53 Chapter 3 NI-XNET Hardware Overview Both the TJA1054A and TJA 1055T support baud rates up to 125 kbps. The transceiver can detect and automatical ly recover from the following CAN bus failures: • CAN_H wire interrupted • CAN_L wire interrupted • CAN_H short-circuited to battery CAN_L short-circuited to battery • • CAN_H short-circuited to VCC • CAN_L short-circuited to VCC • CAN_H short-circuited to ground • CAN_L short-circuited to ground • CAN_H and CAN_L mutually short-circuited The TJA1054A and TJA 1055T support advanced power management Refer to the NI-XNET Session through a low-power sleep mode. Interface:CAN:Transceiver State property for more information. For sceivers, refer to the TJA1054 and detailed specifications for the tran TJA 1055T data sheet. Bus Power Requirements cal layer on PXI, PCI, and The Low-Speed/Fault-Tolerant physi Transceiver Cable NI-XNE T interfaces is internally powered. As such, . The COM pin serves as the reference there is no need to supply bus power Pinouts for the PXI and PCI NI-XNET ground for the bus signals. Refer to CAN interface pinout. The Low-Speed/Fault-Tolerant physical layer on the C Series NI 9861 requires external power supply of +9 to +30 V to operate. Connect the external power supply to the Vsup pin on the module. The COM pins are for reference ground. Refer to Pinouts for the C Series NI-XNET CAN module pinout. for Low-Speed/ Cabling Requirements Fault-Tolerant CAN Cables should meet the physical medium requirements shown in Table 3-4. Belden cable (3084A) meets all of those requirements and should be suitable for most applications. 3-8 NI-XNET Hardware and Software Manual ni.com

54 Chapter 3 NI-XNET Hardware Overview a CAN_H and CAN_L Pair of Wires Specifications for Characteristics of Table 3-4. Characteristic Va l u e  90 m Length-related resistance /m nominal 30 pF/m nominal Length-related capacitance: CAN_L and ground, CAN_H and ground, CAN_L and CAN_H Number of Devices nds on the electrical characteristics The maximum number of devices depe ll devices meet the requirements of of the devices on the network. If a typical Low-Speed/Fault-Tolerant CAN, you can connect up to 32 devices if the electrical mbers of devices to the bus. You can connect higher nu not degrade signal quality below characteristics of the devices do gnal level specifications. Low-Speed/Fault-Tolerant si Termination network requires a termination Every device on the Low-Speed CAN resistor for each CAN data line: RRTH for CAN_H and RRTL for CAN_L. or placement in a Low-Speed CAN Figure 3-3 shows termination resist network. Low-speed Low-speed Low-speed CAN Device CAN Device CAN Device RTH CAN_H RTL CAN_L RTH CAN_H RTL CAN_L RTL CAN_L RTH CAN_H CAN_H CAN_L Figure 3-3. Termination Resistor Placement for Low-Speed CAN Determining the Necessary Termi The nation Resistance for the Board correct termination resistor values section explains how to determine the for the Low-Speed CAN transceiver. property for Refer to the NI-XNET Session Interface:CAN:Termination more information. NI-XNET Hardware and Software Manual 3-9 National Instruments ©

55 Chapter 3 NI-XNET Hardware Overview y Termination Resistance Determining the Necessar for the Board Unlike High-Speed CAN, Low-Speed CAN requires termination at the Low-Speed CAN transceiver instead of on the cable. The termination requires two resistors: RTH for CAN_H and RTL for CAN_L. This configuration allows the NXP fault-tole rant CAN transceiver to detect and recover from bus faults. You can us e NI-XNET Low-Speed/Fault-Tolerant CAN hardware to connect to a Low-Speed CAN network having from two to 32 nodes as specified by NXP (including the port on the CAN Low-Speed/ Fault-Tolerant inte rface). You also can use the Low-Speed/Fault-Toleran t interface to communicate with individual Low-Speed CAN devices. It is important to determine the overall termination of the existing network, or the individual device termination, before connecting it to a Low-Speed/ Fault-Tolerant port. NXP recommends an overall RTH and RTL termination of 100–500  (each) for a properly terminated low- speed network. You can determine the overall network termination as follows: 1 1 1 1 1 -------------------------- - - ----------------------- - ----------------------- +++ ----------------------- = - ----------------------- R R R R R 3 2 1 RTHoverall RTHnode RTHnode RTHnoden RTHnode NXP also recommends an individual device RTH and RTL termination  . After determining the existing network or device of 500  –16 K termination, you can use the followi ng formula to indi cate which nearest be set to produce value the termination property needs to the proper overall RTH and RTL termination of 100–500  upon connection of the card: Low-speed Low-speed Low-speed CAN Device CAN Device CAN Device RTL CAN_L RTH CAN_H RTL CAN_L RTH CAN_H RTH CAN_H RTL CAN_L CAN_H CAN_L R where should be 100–500 overall  . RTH ni.com 3-10 NI-XNET Hardware and Software Manual

56 Chapter 3 NI-XNET Hardware Overview NI-XNET Low-Speed/Fault-Tolerant CAN hardware features software selectable bus termination resistors, allowing you to adjust the overall network termination through an API call. In general, if the existing network has an overall network termination of 125 or less, you should select the  5 K  option for your NI-XNET device. For existing overall network  termination above 125 termination option  , you should select the 1 K for your NI-XNET device. Single Wire CAN Physical Layer circuitry interfaces The Single Wire CAN physical layer the CAN protocol controller to the physical bus wires. Tr an s ce i ve r NI-XNET Single Wire hardware uses either the NXP AU5790 or ON Semiconductor NCV7356 Single Wire CAN transceiver. ware-selectable NI-XNET PCI CAN NI PCI-8513 and NI PCI-8513/2 soft interfaces (revision D and higher) nductor NCV7356 use the ON Semico Single Wire transceiver, while revision C (and lower) uses the NXP AU5790 Single Wire transceiver. NI PXI-8513 and NI PXI-8513/2 soft ware-selectable NI-XNET PXI CAN use the ON Semico nductor NCV7356 interfaces (revision E and higher) Single Wire transceiver, while re vision D (and lower) uses the NXP AU5790 Single Wire transceiver. To identify the your PCI/PXI NI-XNET hardware revision, refer to the the top left corner on the 19xxxx–4xL text on the green label in indicates the hardware revision. secondary side of the board; The NI-XNET Single Wire hardware supports baud rates up to 33.3 kbps in normal transmission mode and 83.3 kbps in High-Speed transmission mode. The achievable baud rate is primarily a function of the network characteristics (termination and numbe r of nodes on the bus), and assumes bus loading as per SAE J2411. Each Single Wire CAN port has a local bus load resistance of 9.09 k  between the CAN_H and RTH pins of the ainst the loss of ground. NI-XNET transceiver to provide protection ag Single Wire hardware also supports advanced power management through low-power sleep and wake up modes. Refer to the NI-XNET Session property for more information. Interface:CAN:Transceiver State For detailed transceiver specifications, refer to their respective data sheets. NI-XN © National Instruments 3-11 ET Hardware and Software Manual

57 Chapter 3 NI-XNET Hardware Overview Bus Power Requirements The Single Wire physical layer on PXI and PCI NI-XNET interfaces requires external power supply of +8 to +18 V (+12 V recommended) to operate. Connect the external power supply to the Ext_Vbat pin on the module. The COM pins are used for reference ground. Refer to Pinouts for the PXI and PCI NI-XNET CAN module pinout. Cabling Requirements for Single Wire CAN The number of nodes on the network, total system cable length, bus loading of each node, and clock tolerance are al l interrelated. It is therefore the system designer’s responsibility to factor in all the above parameters when designing a Single Wire CAN network. The SAE J2411 standard includes some recommended specifications that can help in making these decisions. Cable Length There can be no more than 60 m between any two ECU nodes. Number of Devices As stated previously, the maximum number of Single Wire CAN nodes allowed on the network depends on the device and cable electrical characteristics. If all devices and cab les meet the requirements of J2411, between 2 and 32 devices may be networked together. Termination (Bus Loading) All NI Single Wire CAN hardware includes a built-in 9.09 k  load resistor, as specified by J2411. External CAN Transceiver The external CAN transceiver mode on the PXI-8513 and PCI-8513 XS software selectable interfaces a llows you to connect custom CAN transceivers to the NI-XNET CAN ha rdware. The DB-9 connector on the PXI-8513 and PCI-8513 interfaces includ es five different pins to connect with the custom tran sceiver. Refer to Pinouts for the DB-9 pinout for external CAN transceiver. Refer to Interface:CAN:External Transceiver Config for more information about configuring the NI-XNET hardware to communicate with the custom transceiver. 3-12 NI-XNET Hardware and Software Manual ni.com

58 Chapter 3 NI-XNET Hardware Overview Pinouts PXI-8511/8512/8513 an d PCI-8511/8512/8513 Table 3-5 describes the CAN DB-9 pinout on PXI and PCI NI-XNET CAN interfaces. PXI and PCI NI-XNET CAN DB-9 Pinout Table 3-5. Signal D-SUB Pin Description 1 NC No connection 2 CAN_L CAN_L bus line CAN reference ground COM 3 No connection 4 NC 5 Optional CAN shield (SHLD) (COM) 6 Optional CAN reference ground 7 CAN_H CAN_H bus line 8 NC No connection Optional CAN power supply if bus (Ext_Vbat) 9 power/external VBAT is required (single wire CAN on XS hardware only) Table 3-6 describes the CAN DB-9 pinout on PXI and PCI NI-XNET External CAN transceivers. CAN Transceiver DB-9 Pinout PXI and PCI NI-XNET External Table 3-6. D-SUB Pin Signal Description 1 Output1 Generic output used to configure the transceiver mode 2 Data received from the CAN Bus Ext_RX 3 COM CAN reference ground Generic output used to configure the 4 Output0 transceiver mode (SHLD) 5 Optional CAN shield National Instruments ET Hardware and Software Manual NI-XN 3-13 ©

59 Chapter 3 NI-XNET Hardware Overview CAN Transceiver DB-9 Pinout PXI and PCI NI-XNET External Table 3-6. Signal D-SUB Pin Description 6 COM CAN reference ground 7 Ext_TX Data to transmit on the CAN Bus NERR 8 Input to connect to the NERR pin of your transceiver to route status back from the transceiver to the hardware 9 NC No connection C Series NI 9861/9862 Table 3-7 describes the CAN DB-9 pinout on C Series NI-XNET CAN interfaces. Table 3-7. C Series NI-XNET CAN DB-9 Pinout Description D-SUB Pin Signal No connection 1 NC CAN_L 2 CAN_L bus line COM CAN reference ground 3 No connection 4 NC Optional CAN shield 5 (SHLD) 6 (COM) Optional CAN reference ground 7 CAN_H bus line CAN_H 8 NC No connection VSUP External power supply (+9 V to 9 +30 V) required NI-XNET LIN Hardware LIN Physical Layer uitry interfaces the LIN protocol The NI-XNET LIN physical layer circ controller to the physical bus wire s. NI-XNET LIN interfaces are fully compliant with the LIN 1.3/2.0/2.1/2.2 specification. ni.com 3-14 NI-XNET Hardware and Software Manual

60 Chapter 3 NI-XNET Hardware Overview Tr an s ce i ve r NI-XNET LIN hardware uses the Atmel ATA6620 or ATA6625 LIN transceiver for PCI-XNET and PXI-XNET LIN Interfaces, and the NXP and Transceiver Cable XNET LIN TJA1028 transceiver for C Series interfaces. NI PXI-8516 and PCI-8516 XNET interfaces revision F and higher use the ATA6625 LIN transceiver, while revision E and lower use the ATA6620 LIN transceiver. To identify your PCI/PXI NI-XNET hardware revision, refer to the text on the green label in 19xxxx–4xL the top left corner on the indicates the hardware revision. secondary side of the board; le with the ISO-9141 standard and These transceivers are fully compatib support baud rates up to 20 kbps. For detailed specifications, refer to their respective data sheets. Bus Power Requirements The LIN physical layer on NI-XNET in terfaces requires an external power supply of +8 to +18 V, as the fo llowing table specifies. Connect the external power supply to the VBat/Vsup pin on the interface. The COM for the PXI and PCI pins are for reference ground. Refer to Pinout NI-XNET LIN interface pinout. NI-XNET LIN Hardware Bus Power Requirements Table 3-8. Specification Characteristic +8 to +18 VDC on VBat connector pin Voltage (referenced to COM) Current 55 mA maximum Cabling Requirements for LIN LIN cables should meet the physical medium requirement of a bus RC time constant of 5 μs. For detailed formulas for calculating this value, refer to Line Characteristics section of the LIN specification. Belden cable the (3084A) and other unterminated CAN/Serial quality cables meet these able for most applications. requirements and should be suit Cable Lengths The maximum allowable cable length is 40 m, per the LIN specification. NI-XN © National Instruments 3-15 ET Hardware and Software Manual

61 Chapter 3 NI-XNET Hardware Overview Number of Devices The maximum number of devices on a LIN bus is 16, per the LIN specification. Termination as nodes are terminated at the LIN cables require no termination, typically are pulled up from the LIN bus to VBat transceiver. Slave nodes with a 30 k  resistance and a serial diode. This termination usually is integrated into the transceiver package. The master node requires a 1 k  resistor and serial diode between th e LIN bus and VBat. On NI-XNET LIN products, master termination is software selectable; you can enable it in the API with the NI-XNET Session Interface:LIN:Termination property. Pinout PXI-8516 and PCI-8516 Table 3-9 describes the LIN DB-9 pinout on PXI and PCI NI-XNET LIN interfaces. Table 3-9. PXI and PCI NI-XNET LIN DB-9 Pinout Pin Signal Signal NC No connection 1 No connection 2 NC 3 COM LIN reference ground No connection 4 NC SHLD Optional LIN shield. Connecting the 5 optional LIN shield may improve signal integrity in a noisy environment. Optional LIN reference ground 6 (COM) LIN 7 LIN data line 8 NC No connection Supplies bus power to the LIN physical VBat 9 layer, as the LIN specification requires. All NI-XNET LIN interfaces require bus power of +8 to +18 VDC. 3-16 NI-XNET Hardware and Software Manual ni.com

62 Chapter 3 NI-XNET Hardware Overview C Series NI 9866 and NI-X NET LIN Transceiver Cable Table 3-10 describes the LIN DB-9 pinout on C Series and NI-XNET Transceiver Cable NI-XNET LIN interfaces. C Series NI-XNET LIN DB-9 Pinout Table 3-10. Signal Signal D-SUB Pin No connection NC 1 2 NC No connection 3 COM LIN reference ground No connection 4 NC Optional LIN shield 5 (SHLD) 6 (COM) Optional LIN reference ground 7 LIN data line LIN NC No connection 8 9 VSUP External power supply (+8 to +18 V) required Isolation All NI-XNET products protect your equipment from being damaged by high-voltage spikes on the target bus. Bus ports on PXI and PCI NI-XNET products support channel-to-channel and channel-to-bus isolation, and are galvanically isolated up to 500 Vrms (5 s max withstand). Bus ports on C Series and Transceiver Cable NI-XNET products support channel-to-bus isolation, and are galvanically isolated up to 1000 Vrms (5 s max withstand). LEDs NI-XNET one and two-port boards include two LEDs per port to help you monitor hardware and bus status. LED 1 primarily indicates whether the hardware is currently in use. LE D 2 primarily indicates the activity information of the connected bus. Each LED can disp lay two colors (red or green), which display in the following four patterns: 3-17 © ET Hardware and Software Manual NI-XN National Instruments

63 Chapter 3 NI-XNET Hardware Overview Pattern Meaning Off No LED illumination Solid LED fully illuminated Blinks at a constant rate of several times per second Blink Blinks in a pseudo-random pattern Activity The following LED indications are protocol independent: LED 1 LED 2 Condition/State Blinks green Blinks green Port identification NI-XNET catastrophic error Blinks red Blinks red No open session on hardware Off Off Open session on hardware, port is Off Solid green properly powered, and hardware is not communicating Open session on hardware, port is Solid red Off missing power The following LED conditions are specific to CAN: Condition/State LED 1 LED 2 Solid green Hardware is Activity green (returns to idle/off one second after communicating, and last TX or RX) controller is in Error Active state Hardware is Solid green Activity red (returns to communicating, and idle/off one second after controller is in Error last TX or RX) Passive state Solid green Hardware is running, and Solid red controller transitioned to bus off ni.com 3-18 NI-XNET Hardware and Software Manual

64 Chapter 3 NI-XNET Hardware Overview The following LED conditions are specific to FlexRay: LED 1 Condition/State LED 2 Activity green (continues Solid green Hardware is integrated while integrated) with a FlexRay cluster, and controller is in Normal Active state Activity red (continues Hardware is integrated Solid green while integrated) with a FlexRay cluster, and controller is in Normal Passive state Solid red Hardware was integrated Solid green with a FlexRay cluster and transitioned to Halt state The following LED conditi ons are specific to LIN: Condition/State LED 1 LED 2 Solid green Hardware is Activity green (returns to idle/off one second after communicating last TX or RX) Synchronization PXI NI-XNET and PCI NI-XNET The PXI chassis features a dedicated synchronization bus integrated into the backplane. NI-XNET products support use of this bus to synchronize with other National Instruments hardware products such as DAQ, IMAQ, and motion. The PXI synchronization bus consists of a flexible interconnect scheme for sharing timing and triggering signals in a system. ace is a connector at the top of the For PCI hardware, the RTSI bus interf card. You can synchronize multiple National Instruments PCI cards by connecting a RTSI ribbon cable between the cards that need to share timing and triggering signals. CAN/XS and FlexRay XNET products also feature two configurable timing and triggering ports on the device front panel. These ports are NI-XN © National Instruments 3-19 ET Hardware and Software Manual

65 Chapter 3 NI-XNET Hardware Overview TTL-tolerant user-configurable for inputting and outputting timebases and triggers. These signals are not electri cally isolated from the backplane. Refer to the XNET Connect Terminals function documentation for more details. C Series and NI-XNET Transceiver Cables All NI-XNET ports on a particular C Series chassis share a common timebase, allowing a bett er correlation of data on the ports. NI-XNET products support use of this timebase to synchronize with other National Instruments hardware products such as DAQ modules. Moreover, on a CompactRIO system, th e module’s timebase is corrected for drift with respect to the RT controller’s timebase, allowing the other modules in the chassis. capability to correlate data with On a CompactDAQ system, you can route the Start Trigger between multiple DAQmx and XNET modules. For information about performing Terminal:Start this routing in LabVIEW, refer to the Interface:Source Trigger . For property in Chapter 4, NI-XNET API for LabVIEW information about performing this routing in C/C++, refer to the NI-XNET Interface:Source Termin al:Start Trigger property in Chapter 5, . API for C 3-20 NI-XNET Hardware and Software Manual ni.com

66 4 NI-XNET API for LabVIEW This chapter explains how to use the NI-XNET API for LabVIEW and describes the NI-XNET LabVIEW VIs and properties. Getting Started This section helps you get started using NI-XNET for LabVIEW. It includes information about using NI-XNET within a LabVIEW project, NI-XNET examples, and using the NI-XNET palettes to create your own VI. LabVIEW Project Within a LabVIEW project, you can create NI-XNET sessions used within a VI to read or write network data. Using LabVIEW project sessions is best suited for static applications, in that the network data does not change from one execution to the next. Even if your application is more dynamic, a LabVIEW project is an excellent introduction to NI-XNET concepts. To get started, open a new LabVIEW project, right-click My Computer , and select New»NI-XNET Session . In the resulting dialog, the wi ndow on the left provides an introduction to the NI-XNET session in the LabVIEW project. The introduction links to help in the project, includin topics that describe how to create a session g a description of the session modes. Examples NI-XNET includes LabVIEW examples that dem onstrate a wide variety of use cases. The examples build on the basic concepts to demons trate more in-depth use cases. Most of the examples create a session at run time rather than a LabVIEW project. menu. To view the NI-XNET examples, select Find Examples... from the LabVIEW Help When you browse examples by ta Hardware Input and sk, NI-XNET examples are under Output . The examples are grouped by protocol in folders. Although , FlexRay , and LIN CAN T applications for eith er protocol, and each fo lder contains shared you can write NI-XNE examples, this organization helps you to find examples for your specific hardware product. National Instruments NI-XNET Hardware and Software Manual 4-1 ©

67 Chapter 4 NI-XNET API for LabVIEW—Getting Started A few examples are suggested to get started with NI-XNET. For CAN (at Hardware Input and Output»CAN»NI- XNET»Intro to Sessions»Signal Sessions ): • CAN Signal Input Single Point.vi with CAN Signal Output Single Point.vi . • CAN Signal Input Waveform.vi with CAN Signal Output Waveform.vi . Hardware Input and • CAN Frame Input Stream.vi (at ) with any output Output»CAN»NI-XNET»Intro to Sessions»Frame Sessions example. For FlexRay (at Hardware Input and Output»FlexR ay»Intro to Sessions»Signal Sessions ): FlexRay Signal Input Single Point.vi with • FlexRay Signal Output Single Point.vi . • FlexRay Signal Input Waveform.vi with FlexRay Signal Output Waveform.vi . ut»FlexRay»Intro to • FlexRay Frame Input Stream.vi (at Hardware Input and Outp )with any output example. Sessions»Frame Sessions For LIN (at XNET»Intro to Sessions»Signal Hardware Input and Output»LIN»NI- Sessions ): • LIN Signal Input Single Point.vi with LIN Signal Output Single Point.vi . • LIN Signal Input Waveform.vi with LIN Signal Output Waveform.vi . • LIN Frame Input Stream.vi (at Hardware Input and Ou tput»LIN»NI-XNET»Intro to Sessions»Frame Sessions ) with any output example. Open an example VI by double-clicking its name. To run the example, select values using the front panel controls, then read the instructions on the front panel to run the examples. Palettes After learning the fundamentals of NI-XNET with a LabVIEW project and the examples, you can begin to write your own application. The NI-XNET functions palette includes nodes th at you drag to your VI block diagram. When your VI block diagram is open, this palette is in the Measurement I/O»XNET functions palette. To view help for each node in the NI-XNET f unctions palette, open the context help window by selecting Show Context Help from the LabVIEW Help menu (or pressing ). As you hover over each node or subpalette, a brief summary appears. To open the complete help, link in the summary. Detailed help click the 4-2 NI-XNET Hardware and Software Manual ni.com

68 Chapter 4 IEW—Basic Programming Model NI-XNET API for LabV The NI-XNET controls palette includes I/O name controls that you drag to the your VI front T objects from the front panel. e VI end user to select NI-XNE panel. These controls enable th You view help for these controls in the same manner as on the functions palette. Basic Programming Model The LabVIEW block diagram in the following figure shows the basic NI-XNET programming model. Figure 4-1. Basic Programming Model for NI-XNET for LabVIEW Complete the following steps to create this block diagram: 1. Create an NI-XNET session in a LabVIEW project. The session name is MyInputSession, and the mode is Signal Input Single-Point. 2. and open the block diagram. Create a new VI in the project 4-3 © National Instruments NI-XNET Hardware and Software Manual

69 Chapter 4 NI-XNET API for LabVIEW—Interfaces Drag a while loop to the block diagram. Right-click the loop condition (the stop sign) and 3. create a control (stop button). 4. Drag the NI-XNET session from a LabVIEW pr oject to the while loop. This creates the XNET session wired to the corresponding XNET Read.vi . and create an indicator. 5. Right-click the data output from XNET Read.vi 6. lues. Stop the VI when you are done. Run the VI. View the received signal va When you complete the preceding steps, y ou have created a fully functional NI-XNET application. You can create sessions for other input or output modes using the same technique. When you drag an output session to the diagram, NI-XN ET creates a constant for data and wires that constant to XNET Write.vi . You can enter constant values to write, or to change the data at . run time, right-click the constant and select Change to Control NI-XNET enables you to create sessions for mult iple hardware interfaces. For each interface, aneously. The sessions output sessions simult you can use multiple input sessions and multiple session can use different modes. Fo r example, you can use a Signal Input Single-Point Mode at the same time you use a Frame Input Stream Mode session. The NI-XNET functions palette includes nodes that extend this programming model to perform tasks such as: (instead of a LabVIEW project). • Creating a session at run time • Controlling the configuration and state of a session. Browsing and selecting a hardware interface. • • Managing and browsing database files. Creating frames or signals at run tim • e (instead of using a database file). The following sections describe the fundamental concepts used within NI-XNET. Each section explains how to perform extended programming tasks. Interfaces What Is an Interface? The interface represents a single CAN, FlexRay, or LIN connector on an NI hardware device. ed to communicate with external hardware Within NI-XNET, the interface is the object us described in the database. Each interface name uses the following syntax: 4-4 NI-XNET Hardware and Software Manual ni.com

70 Chapter 4 NI-XNET API for LabVIEW—Interfaces CAN for a CAN interface, FlexRay for a FlexRay interface, or LIN The is either for a LIN interface. The number identifies the specific interface within the scope. The numbering starts at 1. For example, if you have a two-port CAN device, a two-port FlexRay , device, and a two-port LIN device in your system, the interface names are CAN1 , CAN2 LIN2 FlexRay1 , LIN1 , and FlexRay2 , respectively. Devices that use a transceiver cable get , le is connected and identified. only an interface name when the cab Although you can change the interface number within Measurement & Automation Explorer (MAX), the typical practice is to allow NI-XNET to select the number automatically. NI-XNET always starts at 1 an d increments for each new interface found. If you do not change the number in MAX, and your system always uses a single two-port CAN device, you can write all your applications to assume CAN1 and CAN2. For as long as that the same interface numbers for that device, CAN card exists in your system, NI-XNET uses even if you add new CAN cards. NI-XNET also uses the term to refer to the connector on an NI hardware device. This port physical connector includes the transceiver cable if applicable. The difference between the terms is that refers to the hardware object (physical), and interface refers to the software port is separation is that you can use the interface name as an alias object (logical). The benefit of th to any port, so that your application does not need to change when your hardware configuration changes. For example, if you have a PXI chassis with a single CAN PXI device in slot 3, the CAN port labeled Port 1 is assigned as interface CAN1 . Later on, if you remove the CAN PXI card and connect a USB device fo r CAN, the CAN port on the USB device is assigned as interface CAN1 . Although the physical port is in a different place, VIs written to work with either hardware use CAN1 configuration without change. How Do I View Ava ilable Interfaces? Measurement and Automation Explorer (MAX) Use MAX to view your available NI-XNET ha rdware, including all devices and interfaces. To view hardware in your local Windows system, select Devices and Interfaces under My System . Each NI-XNET device is listed with the hardware product name, such as NI PCI-8517 “FlexRay1, FlexRay2” . Select each NI-XNET device to view its physical sted with the current ports. Each port is li interface name assignment, such as FlexRay1 . In the selected port’s window on the right, you can change one property: the interface name. Therefore, you can assi gn a different interface name than the default. For example, you can I-8517 to FlexRay1 instead of FlexRay2. The change the interface for physical port 2 of a PC blinking LED test panel assists in identifyin your system contains g a specific port when 4-5 © National Instruments NI-XNET Hardware and Software Manual

71 Chapter 4 NI-XNET API for LabVIEW—Interfaces uct (for example, a chassis with five CAN multiple instances of the same hardware prod devices). To view hardware in a remote LabVIEW Real-Time system, find the desired system under and select Remote Systems under that system . The features of Devices and Interfaces NI-XNET devices and interfaces are the same as the local system. I/O Name When you create a session at run ti me, you pass the desired interface to XNET Create Session.vi XNET Interface I/O Name type. . The interface uses the The XNET Interface I/O name has a drop-down lis t of all available NI-XNET interfaces. This list matches the list of interfaces shown in MAX. You select a specific interface from the list for use with XNET Create Session.vi . XNET Create Session.vi By right-clicking the interface input, you can create a constant or nstant is placed on your block diagram. You control for the XNET Interface I/O name. The co typically use a constant when you have only a single NI-XNET device, to use fixed names You typically use a such as CAN1 and CAN2. The control is pl aced on your front panel. control when you have a large number of NI-XNET devices and want the VI end user to select from available interfaces. LabVIEW Project the session dialog. When you create a session in a LabVIEW project, you enter the interface in This dialog has a list of available interfaces, in a manner similar to the XNET Interface I/O name. oject and do not yet have NI-XNET hardware If you are creating a session in a LabVIEW pr in the dialog. This enables you in your system, you can type an interface name such as CAN1 to create sessions and program VIs prior to installing the hardware. System Node In some cases, you may need to provide features similar to MAX within your own application. For example, if you distribute your LabVIEW application to end users who are not familiar with MAX, you may need to display a similar view within the application itself. Advanced subpalette, NI-XNET provides property Within the NI-XNET functions palette nodes to query for available hardware. 4-6 NI-XNET Hardware and Software Manual ni.com

72 Chapter 4 NI-XNET API for LabVIEW—Databases Advanced System Exampl e Using Property Nodes Figure 4-2. The block diagram in the figure above shows ho w to populate a LabVIEW tree control with NI-XNET devices and interfaces, in a manner si milar to MAX. First, you get the list of devices from the XNET System node. For each XNET Device, you get its name and add you get its name and that name to the tree. For each XNET interface (port) in the device, add that name to the tree (with the device as the parent). select an interface for session cr eation, you can pass the interface If you use this tree control to name from the tree directly to . Although XNET Create Session.vi XNET Create Session.vi uses the XNET Interface I/O name as an input, LabVIEW can cast a string to that I/O name automatically. Databases What Is a Database? For the NI-XNET interface to communicate with hardware products on the external network, the actual embedded system, such as the NI-XNET must understand the communication in vehicle. This embedded communication is desc ribed within a standardized file, such as CANdb ( .ldf ) for FlexRay, or LIN Description File ( .xml .dbc ) for ) for CAN, FIBEX ( database . The database contains many LIN. Within NI-XNET, this file is referred to as a e embedded system. object classes, each of which describes a di stinct entity in th • Database : Each database is represented as a di stinct instance in NI-XNET. Although the create the database at run time (in memory). database typically is a file, you also can • Cluster clusters, where the cluster represents a : Each database contains one or more collection of hardware products connected over a shared cabli ng harness. In other words, Ray, or LIN network. For example, the each cluster represents a single CAN, Flex database may describe a single vehicle, where the vehicle contains one CAN cluster Chassis , and a LIN cluster Body , another CAN cluster Powertrain , one FlexRay cluster . PowerSeat 4-7 © National Instruments NI-XNET Hardware and Software Manual

73 Chapter 4 NI-XNET API for LabVIEW—Databases ECU it (ECU) represents a single hardware product in the • : Each Electronic Control Un embedded system. The cluster contains one or more ECUs connected over a CAN, FlexRay, or LIN cable. It is possible for a single ECU to be contained in multiple clusters, in which case it behaves as a gateway between the clusters. • Frame : Each frame represents a unique unit of da ta transfer over the cluster cable. The ta (signal) content. frame bits contain payload data and an identifie r that specifies the da Only one ECU in the cluster transmits (sends ) each frame, and one or more ECUs receive each frame. • Signal : Each frame contains zero or more values , each of which is called a signal. Within the database, each signal specifies its name, posit ion, length of the raw bits in the frame, and a scaling formula to convert raw bits to/ from a physical unit. Th e physical unit uses a LabVIEW double-precision floating-point numeric type. Other object classes include the PDU, Subframe, LIN Schedule, and LIN Schedule Entry. What Is an Alias? When using a database file with NI-XNET, you can specify the file path or an alias to the file. The alias provides a shorter, easier-to-r ead name for use within your application. For example, for the file path C:\Documents and Settings\All Users\Documents\Vehicle5\ MyDatabase.DBC you can add an alias named MyDatabase . In addition to improving readability, the a lias concept isolates your LabVIEW application from the specific file path. For example, if your application uses the alias MyDatabase and you change its file path to C:\Embedded\Vehicle5\MyDatabase.DBC your LabVIEW application continues to run without change. The alias concept is used in most NI-XN ET features for the database classes. The XNET I/O for database classes include features for adding a new alias, viewing existing aliases, Names deleting an alias, and so on. You also can perform these tasks at run time, using the VIs Database»File Mgt available in the NI-XNET functions palette subpalette. After you create an alias, it ex ists until you explicitly delete it. If you exit and relaunch LabVIEW, the aliases from the pr evious use remain. If you unin stall NI-XNET, the aliases are deleted; however, if you reinstall (upgrade ) NI-XNET, the aliases from the previous lete the database file itself, but merely the installation remain. Deleting an alias does not de association within NI-XNET. 4-8 NI-XNET Hardware and Software Manual ni.com

74 Chapter 4 NI-XNET API for LabVIEW—Databases An alias is required for deploying databases to LabVIEW Real-Time (RT) targets. When you deploy to a LabVIEW RT target, the large text file is compressed to an optimized binary the target. For more information about databases format, and that binary file is transferred to with LabVIEW RT, refer to Using LabVIEW Real-Time . Database Programming The NI-XNET software provides various methods for creating your application database configuration. The following figure shows a process for deciding the database source. A description of each step in th e process follows the flowchart. N o Ye s Already Have File? No No Yes Yes Want to Can I use Use a File? file as is? Create New Select From Create in Edit and File Using Memory Select File Editor Decision Process for Choosing Database Source Figure 4-3. Already Have File? If you are testing an ECU used within a vehicl e, the vehicle maker (or the maker’s supplier) already may have provided a database file. This file likely would be in CANdb, FIBEX, or LDF format. When you have this file, using NI-XNET is relatively straightforward. Can Use File As Is? Is the file up to date with respect to your ECU(s)? 4-9 National Instruments © NI-XNET Hardware and Software Manual

75 Chapter 4 NI-XNET API for LabVIEW—Databases If you do not know the answer to this question, the best choice is to assume Yes and begin using NI-XNET with the file. If you encounter problems, you can use the techniques discussed in Edit and Select to update your application without significant redesign. Select From File There are three options for sel ecting the database objects to use for NI-XNET sessions: a LabVIEW project, I/O names, and property nodes. LabVIEW Project The NI-XNET session in a LabVIEW project as sumes that you have a database file. The configuration dialog includes controls to browse to your database file, select a cluster to use, ple, if you create a Si gnal Input Single-Point and select a list of frames or signals. For exam session, you enter the database and cluster to us e, then select one or more signals to read. I/O Names If you create sessions at run time, you need to wire objects from the database file to XNET Create Session.vi . The easiest way to do this is to us e I/O names for the objects that you need. For example, assume that you want to create a Signal Input Single-Point session and want the XNET Create Session.vi from VI end user to select signals fr om the front panel. First, drag the NI-XNET functions palette. Change the VI selector to Signal Input Single-Point. Right-click the input and select Create»Control . This creates an array of XNET signal list Signal I/O names on your front panel. Right-click the signal list control and select Browse for Database File to find the database file. For a CANdb file, you can click the drop-do wn list for each array el ement to select from and available signals in the file. For a FIBEX or LDF file, right-click signal list Select Database to select a specific cluster within the file, then click the drop-down list to select signals. After you browse to the file and select a cluster, that information is saved with the VI, so you need to select only signal names from that point onward. Most NI-XNET examples use I/O names to select objects (frames or signals). As a default, the NI-XNET example VIs use an example databa se file installed with NI-XNET. You can change this file to a differen t file using the previous steps. Property Nodes If you create a session at run time, you may want to implement your own front panel controls to select objects from the database, rather than use I/O names. Although the programming is more advanced than I/O names, you can do this using property nodes for the database classes. subpalette. These property nodes are found in the NI-XNET functions palette Database 4-10 NI-XNET Hardware and Software Manual ni.com

76 Chapter 4 NI-XNET API for LabVIEW—Databases For example, assume you want a tree control on the VI front panel. The tree shows the frames and signals within a selected cluster. The VI us er selects signals from this tree control. The tree control block diagram uses a programming model similar to the Advanced System Example Using Property Nodes . Figure 4-4. Advanced Database Exam ple Using Property Nodes w to populate a LabVIEW tree control with The block diagram in the figure above shows ho the frames and signals for a specific cluster. Because a cluster represents a single network clusters. First, you need to show multiple connected to your NI-XNET interf ace, you do not r node. For each XNET Frame, you get its name get the list of frames from the XNET Cluste gnal in the frame, you get its name and add and add that name to the tree. For each XNET Si that name to the tree (with the frame as the parent). select signals for session creation, you can use names from the If you use this tree control to tree to form the signal names that you wire to XNET Create Session.vi . For information about signal name syntax, refer to XNET Signal I/O Name . Edit and Select There are two options for editing the databa se objects for the NI-XNET session: edit in memory and edit the file. Edit in Memory the NI-XNET session usin g one of the options First, you select the frames or signals for described in Select From File . Next, you wire the selected objects to the corresponding property node and set properties to change the value. When you edit the obj ect using its property node, this changes the representation in memory, but does not save the change to the file. When you pass the object the original file) are used. , the changes in memory (not XNET Create Session.vi into 4-11 © National Instruments NI-XNET Hardware and Software Manual

77 Chapter 4 NI-XNET API for LabVIEW—Databases Edit the File The NI-XNET Database Editor is a tool for editing database files for use with NI-XNET. Using this tool, you open an existing file, edit the objects, and save those changes. You can save the changes to the existing file or a new file. When you have a file with the changes you need, you select objects in your application as . described in Select From File Want to Use a File? If you do not have a usable database file, you can choose to create a file or avoid files altogether for a self-contained application. Create New File Usin g the Database Editor You can use the NI-XNET Database Editor to create a new database file. Once you have a file, . you select objects in your application as described in Select From File using a FIBEX file is recommended. FlexRay As a general rule, for FlexRay applications, mber of complex proper ties, and storage in communication configuration requires a large nu Database Editor a file makes this easier to manage. The NI-XNET has features that facilitate this configuration. Create in Memory to create new database objects in memory. You can use XNET Database Create Object.vi Using this technique, you can avoid files entirely and make your application self contained. You configure each object you cr eate using the property node. E ach class of database object that you must set (refer to contains required properties Required Properties ). Because CAN is a more straightforward prot ocol, it is easier to create a self-contained CAN frame with only ssion to transmit a application. For example, you can create a se two objects. 4-12 NI-XNET Hardware and Software Manual ni.com

78 Chapter 4 NI-XNET API for LabVIEW—Sessions Create Cluster and Frame for CAN Figure 4-5. Figure 4-5 shows a sample diagram that creates a cluster and frame in memory. The database name is . This special database name specifies a database that does not originate :memory: from a file. The cluster name is myCluster . For CAN, the only property required for the cluster myFrame Baud Rate is . The frame has . The cluster is wired to create a frame object named several required properties. The XNET Frame CAN:Timing Type property specifies how to Cyclic Data transmit the frame, with meaning to transmit every CAN:Transmit Time seconds (0.01, or 10 ms). The remaining prope rties configure the frame to use 8 bytes of XNET the subsequent diagram passed the frame to payload data and CAN standard ID 5. If , this would create a session you can use to write Create Session (Frame Output Queued).vi data for transmit. Using CAN . For additional information on in-memory configurations for CAN, refer to After you create and configure objects in memory, you can use XNET Database Save.vi to save the objects to a file. This enables you to implement a database editor within your application. Multiple Databases Simultaneously databases at the same time. You can open any NI-XNET allows opening up to seven distinct database from a database file or in memory. To open multiple in-memory databases, use the :memory1: , :memory[]: ; for example, :memory: , name :memory2: . Sessions What Is a Session? The NI-XNET session represents a connection between your National Instruments CAN/FlexRay/LIN hardware and hardware products on the external network. As discussed in , your application uses sessions to read and write I/O data. Basic Programming Model uration includes: Each session config 4-13 © National Instruments NI-XNET Hardware and Software Manual

79 Chapter 4 NI-XNET API for LabVIEW—Sessions • Interface : This specifies the National Instruments hardware to use. • Database objects : These describe how extern al hardware communicates. • Mode : This specifies the direction and representation of I/O data. In addition to read/write of I/O data, you can use the session to interact with the network XNET Read.vi includes selections to read the state of in other ways. For example, communication, such as whether communication has stopped due to error detection defined by the protocol standard. You can use sessions for multiple hardware interfaces. For each interface, you can use multiple input sessions and multiple output sessions simultaneously. The sessions can use different modes. For example, you can use a Signal Input Single-Point session at the same time you use a Frame Input Stream session. signals. For example, The limitations on sessions relate primarily to a specific frame or its if you create a Frame Out put Queued session for frameA , then create a Signal Output ), NI-XNET returns an error. This (a signal in Single-Point session for frameA.signalB frameA combination of sessions is not allowed, because writing data for the same frame with two sessions would result in inconsistent sequences of data on the network. Session Modes ls or frames), direction (input or output), and The session mode specifies the data type (signa how data is transferred between your application and the network. The mode is an enumeration of the following: • Signal Input Single-Point Mode : Reads the most recent value received for each signal. This mode typically is used for control or simulation applications, such as Hardware In the Loop (HIL). • Signal Input Waveform Mode : Using the time when the si gnal frame is received, resamples the signal data to a waveform with a fixed sample rate. This mode typically is used for synchronizing XNET data with DAQmx analog/digital input channels. • Signal Input XY Mode es its signals as a value/ : For each frame received, provid de for reading a sequ ence of all signal timestamp pair. This is the recommended mo values. : Writes signal values for • Signal Output Single-Point Mode the next frame transmit. This mode typically is used for control or simulation applications, such as Hardware In the Loop (HIL). • Signal Output Waveform Mode : Using the time when the signal frame is transmitted veform with a fixed sample according to the database, resamp les the signal data from a wa rate. This mode typically is used for synchronizing XNET data with DAQmx analog/digital output channels. 4-14 NI-XNET Hardware and Software Manual ni.com

80 Chapter 4 NI-XNET API for LabVIEW—Sessions Signal Output XY Mode • : Provides a sequence of signal values for transmit using each frame’s timing as the database specifies. Th is is the recommended mode for writing a sequence of all signal values. • : Reads all frames received from the network using a single Frame Input Stream Mode stream. This mode typically is used for analyzing and/or lo gging all frame traffic in the network. Frame Input Queued Mode • : Reads data from a dedicated queue per frame. This mode data specific to a frame (for example, CAN enables your application to read a sequence of identifier). • Frame Input Single-Point Mode : Reads the most recent value received for each frame. This mode typically is used for control or si mulation applications that require lower level access to frames (not signals). • Frame Output Stream Mode : Transmits an arbitrary sequ ence of frame values using a e in the database, but can single stream. The values ar e not limited to a single fram transmit any frame. : Provides a sequence of values for a single frame, for Frame Output Queued Mode • transmit using that frame’s timing as the database specifies. Frame Output Single-Point Mode : Writes frame values for the next transmit. This • mode typically is used for control or simulation applications that require lower level access to frames (not signals). Conversion Mode : This mode does not use any hardware. It is used to convert data • between the signal representatio n and frame representation. Frame Input Queued Mode This mode reads data from a dedicated queue pe r frame. It enables your application to read a e (for example, a CAN identifier). sequence of data specific to a fram You specify only one frame for the session, and XNET Read.vi returns values for that frame frames, create multiple sessions, one per frame. only. If you need sequential data for multiple The input data is returned as an array of frame values. Thes e values represent all values ce the previous call to received for the frame sin XNET Read.vi . If the session uses a CAN interface, XNET Read (Frame CAN).vi is the recommended way to read data for this mode. This VI returns an array of frames, where each frame is a LabVIEW cluster specific to the CAN protocol. If the sessi on uses a FlexRay or LIN interface, the read XNET selection for that protocol is recommended. For more advanced applications, use , which returns frames in an optimized, protocol-independent format. Read (Frame Raw).vi 4-15 © National Instruments NI-XNET Hardware and Software Manual

81 Chapter 4 NI-XNET API for LabVIEW—Sessions Example In this example network, frame C is a cyclic frame that transmits on the network once every r information about cyclic and event-driven 2 ms. Frame E is an event-driven frame. Fo frames, refer to Cyclic and Event Timing . Each frame contains two signals, one in th e first byte and another in the second byte. This example uses CAN. The fo llowing figure shows a timeline of a frame transfer on the XNET Read (Frame CAN).vi (one for C and CAN network, followed by two calls to one for E). Read Read E C C3,4 C1,2 C3,4 C5,6 E5,6 E7,8 E1,2 Time 0 ms 7 ms 1 ms 2 ms 3 ms 8 ms 6 ms 5 ms 4 ms 4-16 NI-XNET Hardware and Software Manual ni.com

82 Chapter 4 NI-XNET API for LabVIEW—Sessions The following figure shows the data returned from the two calls to XNET Read (Frame CAN).vi (two different sessions). returned an array of values for frame C, and The first call to XNET Read (Frame CAN).vi XNET Read (Frame CAN).vi the second call to returns an array for frame E. Each frame is a LabVIEW cluster with CAN-specific elemen ts. The example uses hexadecimal C and E as the identifier of each frame. The first tw o payload bytes contain the signal data. The timestamp represents the absolute time when the XNET interface received the frame (end of frame), accurate to microseconds. , this mode effectively sorts Frame Input Stream Mode Compared to the example for the received frames so you can proce ss them on an individual basis. 4-17 © National Instruments NI-XNET Hardware and Software Manual

83 Chapter 4 NI-XNET API for LabVIEW—Sessions Frame Input Single-Point Mode This mode reads the most recent value received fo r each frame. It typically is used for control or simulation applications that require lo wer level access to frames (not signals). This mode does not use queues to store each received frame. If the interface receives two frames prior to calling XNET Read.vi , that read returns signals for the second frame. specified for the session. The input data is returned as an array of fr ames, one for each frame is the recommended way XNET Read (Frame CAN).vi If the session uses a CAN interface, to read data for this mode. This instance retu rns an array of frames, where each frame is a LabVIEW cluster specific to the CAN protocol. If the session uses a FlexRay or LIN interface, the read selection for that prot ocol is recommended. For more advanced applications, you can use XNET Read (Frame Raw).vi , which returns frames in an optimized, protocol-independent format. Example the network once every In this example network, frame C is a cyclic frame that transmits on 2 ms. Frame E is an event-driven frame. Fo r information about cyclic and event-driven Cyclic and Event Timing . frames, refer to Each frame contains two signals, one in th e first byte and another in the second byte. The example uses CAN. The foll owing figure shows a timeline of a frame transfer on the . Each frame CAN network, followed by a single call to XNET Read (Frame CAN).vi contains its name (C or E), followed by the value of its two signals. 1s t 3rd 2nd Read Read Read C1,2 C3,4 C5,6 E1,2 E7,8 E5,6 Time 0 ms 7 ms 8 ms 3 ms 2 ms 1 ms 4 ms 5 ms 6 ms 4-18 NI-XNET Hardware and Software Manual ni.com

84 Chapter 4 NI-XNET API for LabVIEW—Sessions The following figure shows the data retu rned from each of the three calls to XNET Read (Frame CAN).vi . The session contains frame data for two frames: C and E. In the data returned from the first call to XNET Read (Frame CAN).vi , frame C contains of frame C values (1 and 2) were lost, because values 3 and 4 in its payload. The first reception this mode returns the most recent values. In the frame timeline, Time of 0 ms indicates the time at which the session started to receive received prior to the first call to frames. For frame E, no frame is XNET Read (Frame CAN).vi , so the timestamp is invalid, and the payload is the Default Payload . For this example we assume that the Default Payload is all 0. , payload values XNET Read (Frame CAN).vi In the data returned from the second call to se no new frame has been received since the 3 and 4 are returned again for frame C, becau XNET Read (Frame CAN).vi . The timestamp for frame C is the same as the previous call to first call to XNET Read (Frame CAN).vi In the data returned from the third call to XNET Read (Frame CAN).vi , both frame C and frame E are received, so both elements return new values. Frame Input Stream Mode This mode reads all frames r eceived from the network using a single stream. It typically is used for analyzing and/or logging all frame traffic in the network. The input data is returned as an array of frames. Because all frames are returned, your tification in each frame (such as a CAN identifier or FlexRay application must evaluate iden slot/cycle/channel) to interpret the frame payload data. is the recommended way If the session uses a CAN interface, XNET Read (Frame CAN).vi rns an array of frames, where each frame is a to read data for this mode. This instance retu LabVIEW cluster specific to the CAN protocol. If the session uses a FlexRay or LIN interface, the read selection for that prot ocol is recommended. For more advanced 4-19 © National Instruments NI-XNET Hardware and Software Manual

85 Chapter 4 NI-XNET API for LabVIEW—Sessions applications, you can use XNET Read (Frame Raw).vi , which returns frames in an optimized, protocol-independent format. Previously, you could use only one Frame Input Stream session for a given interface. Now, multiple Frame Input Stream sessions can be open at the same time. While using one or more Frame Input Stream sessions, you can use other sessions with different input modes. Received frames are copied to Frame In put Stream sessi ons in addition ample, if you create a Frame Input Single-Point to any other applicable input session. For ex a Frame Input Stream session, when FrameA is received, its session for FrameA, then create data is returned from the call to XNET Read.vi of both sessions. This duplication of ll traffic while running a higher level incoming frames enables you to analyze overa application that uses specific frame or signal data. When used with a FlexRay interface, frames fr om both channels are returned. For example, if a frame is received in a static slot on both ch annel A and channel B, two frames are returned . XNET Read.vi from Example frame that transmits on the network once every In this example network, frame C is a cyclic 2 ms. Frame E is an event-driven frame. Fo r information about cyclic and event-driven frames, refer to Cyclic and Event Timing . Each frame contains two signals, one in th e first byte and another in the second byte. The example uses CAN. The foll owing figure shows a timeline of a frame transfer on the XNET Read (Frame CAN).vi . Each frame CAN network, followed by a single call to contains its name (C or E), followed by the value of its two signals. Read C5,6 C3,4 C3,4 C1,2 E7,8 E1,2 E5,6 Time 0 ms 4 ms 2 ms 3 ms 8 ms 7 ms 6 ms 5 ms 1 ms NI-XNET Hardware and Software Manual 4-20 ni.com

86 Chapter 4 NI-XNET API for LabVIEW—Sessions . XNET Read (Frame CAN).vi The following figure shows the data returned from Frame C and frame E are returned in a single array of frames. Each frame is a LabVIEW cluster with CAN-specific elements. This exampl e uses hexadecimal C and E as the identifier of each frame. The signal data is contained in the first two payload bytes. The timestamp frame (end of frame), interface received the represents the absolute time when the XNET accurate to microseconds. 4-21 © National Instruments NI-XNET Hardware and Software Manual

87 Chapter 4 NI-XNET API for LabVIEW—Sessions Frame Output Queued Mode This mode provides a sequence of values for a smit using that frame’s single frame, for tran timing as specified in the database. The output data is provided as an array of frame values, to be transmitted sequentially for the frame specified in the session. This mode allows you to specify only one fram e for the session. To transmit sequential values for multiple frames, use a differ ent Frame Output Queued sess ion for each frame or use the Frame Output Stream Mode . If the session uses a CAN interface, XNET Write (Frame CAN).vi is the recommended way to write data for this mode. This instance provides an array of frame values, where each value is a LabVIEW cluster specific to the CAN protocol. If the session uses a FlexRay or LIN interface, the write selection for that pr otocol is recommended. For more advanced applications, you can use XNET Write (Frame Raw).vi , which provides frame values in an optimized, protocol-independent format. The frame values for this mode are stored in a queue, such that every value provided is transmitted. For this mode, NI-XNET transmits each frame a ccording to its properti es in the database. bytes in each frame value , the number of payload XNET Write.vi Therefore, when you call must match that frame’s property. The other frame value elements are Payload Length ignored, so you can leave them uninitialized. For CAN interfaces, if the number of payload bytes you write is smaller than the Payload Leng th configured in the database, the requested number of bytes transmits. If the number of pa yload bytes is larger than the Payload Length configured in the database, the queue is flushe d and no frames transmit. For other interfaces, transmitting a number of payload bytes different than the frame’s payload may cause unexpected results on the bus. Examples frame that transmits on the network once every In this example network, frame C is a cyclic en frame that uses a transmit time (minimum interval) of 2.0 ms. Frame E is an event-driv 2.5 ms. For information about cyclic and event-driven frames, refer to Cyclic and Event Timing . Each frame contains two signals, one in th e first byte and another in the second byte. The example uses CAN. The foll owing figure shows a timeline of a frame transfer on the CAN network. Each frame contains its name (C or E), followed by the value of its two signals. XNET Write (Frame CAN).vi , one for frame C, The timeline begins with two calls to followed immediately by another call for frame E. 4-22 NI-XNET Hardware and Software Manual ni.com

88 Chapter 4 NI-XNET API for LabVIEW—Sessions Write C5,6 C5,6 C3,4 C1,2 E7,8 E5,8 Time 0 ms 8 ms 5 ms 6 ms 7 ms 4 ms 3 ms 2 ms 1 ms . XNET Write (Frame CAN).vi The following figure shows the data provided to each call to The first array shows data for the session with frame C. The second array shows data for the session with frame E. 4-23 © NI-XNET Hardware and Software Manual National Instruments

89 Chapter 4 NI-XNET API for LabVIEW—Sessions Auto Start? , each session starts within the call Assuming the property uses the default of true to XNET Write (Frame CAN).vi . Frame C transmits followed by frame E, both using the frame values from the first elem ent (index 0 of each array). According to the database, frame C transmits on ce every 2.0 ms, and frame E is limited to an event-driven transmit once every 2.5 ms. At 2.0 ms in the timeline, the frame value with bytes 3, 4 is taken from index 1 of the frame C array and used for tr ansmit of frame C. When 2.5 ms have elapsed after acknowledgment of the previous transmit of frame E, the frame value with bytes 5, 8, 0, 0 is taken from index 1 of frame E array and used for transmit of frame E. At 4.0 ms in the timeline, the frame value with bytes 5, 6 is taken from index 2 of the frame C array and used for tr ansmit of frame C. Because there are no more frame values for fram e E, this frame no long er transmits. Frame E is event-driven, so new frame valu es are required for each transmit. Because frame C is a cyclic frame, it transmits repeatedly. Although th ere are no more frame values for frame C, the previous frame value is used again at 6.0 ms in the timeline, and every XNET Write (Frame CAN).vi 2.0 ms thereafter. If is called again, the new frame value is used. Frame Output Single-Point Mode This mode writes frame values for the next tr ansmit. It typically is used for control or simulation applications th at require lower level access to frames (not signals). This mode does not use queues to store frame values. If XNET Write.vi is called twice before the next transmit, the transmitted frame uses the value from the second call to XNET Write.vi . The output data is provided as an array of frames, one for each frame specified for the session. XNET Write (Frame CAN).vi If the session uses a CAN interface, is the recommended way to write data for this mode. This instance prov ides an array of frame values, where each value is a LabVIEW cluster specific to the CAN prot ocol. If the session uses a FlexRay or LIN interface, the write selection for that prot ocol is recommended. For more advanced applications, you can use XNET Write (Frame Raw).vi , which provides frame values in an optimized, protocol-independent format. For this mode, NI-XNET transmits each frame a ccording to its properti es in the database. Therefore, when you call XNET Write.vi , the number of payload bytes in each frame value property. The other frame value elements are Payload Length must match that frame’s 4-24 NI-XNET Hardware and Software Manual ni.com

90 Chapter 4 NI-XNET API for LabVIEW—Sessions ignored, so you can leave them uninitialized. For CAN interfaces, if the number of payload bytes you write is smaller than the Payload Length configured in the database, the requested number of bytes transmits. If the number of payload bytes is larger than the Payload Length configured in the database, the queue is flushe d and no frames transmit. For other interfaces, transmitting a number of payload bytes different than the frame’s payload may cause unexpected results on the bus. Example frame that transmits on the network once every In this example network, frame C is a cyclic 2.0 ms. Frame E is an event-driven frame that uses a transmit time (minimum interval) of 2.5 ms. For information about cyclic and event-driven frames, refer to Cyclic and Event Timing . e first byte and another in the second byte. Each frame contains two signals, one in th owing figure shows a timeline The example uses CAN. The foll of a frame transfer on the CAN network. Each frame contains its name (C or E), followed by the value of its two signals. The timeline shows three calls to XNET Write (Frame CAN).vi . 2nd 3rd 1st Write Write Write C1,2 C3,4 C5,6 C5,6 E3,4 E7,8 Time 0 ms 6 ms 7 ms 8 ms 3 ms 2 ms 1 ms 4 ms 5 ms 4-25 © National Instruments NI-XNET Hardware and Software Manual

91 Chapter 4 NI-XNET API for LabVIEW—Sessions The following figure shows the data pr ovided to each of the three calls to XNET Write (Frame CAN).vi . The session contains frame values for two frames: C and E. Assuming the Auto Start? property uses the default of true, the session starts within the first call to . Frame C transmits followed by frame E, both using XNET Write (Frame CAN).vi frame values from the first call to XNET Write (Frame CAN).vi . XNET Write (Frame CAN).vi After the second call to , frame C transmits using its value l interval of 2.5 ms has not (bytes 3, 4), but frame E does not transmit, because its minima of the previous transmit. elapsed since acknowledgment 4-26 NI-XNET Hardware and Software Manual ni.com

92 Chapter 4 NI-XNET API for LabVIEW—Sessions Because the third call to XNET Write (Frame CAN).vi occurs before the minimum interval elapses for frame E, its next transmit uses its va lue (bytes 3, 4, 0, 0). The value for frame E in the second call to XNET Write (Frame CAN).vi is not used. Frame C transmits the third time using the value from the third call to XNET Write (Frame CAN).vi (bytes 5, 6). Because frame C is cyclic , it transmits again using the same value (bytes 5, 6). Frame Output Stream Mode y sequence of frame values usi ng a single stream. The values This mode transmits an arbitrar are not limited to a single frame in th e database, but can transmit any frame. The data wired to XNET Write.vi is an array of frame values, each of which transmits as soon as possible. Frames transmit se quentially (one after another). This mode is not supported for FlexRay. Like Frame Input Stream sessions, you can create more than one Frame Output Stream session for a given interface. ork based entirely on the time when you call For CAN, frame values transmit on the netw XNET Write.vi in the database is ignored. For . The timing of each frame as specified example, if you provide XNET Write.vi , the first frame value transmits four frame values to immediately, followed by the next three values transmitted back to back. For this mode, the CAN frame payload length in the database is ignored, and the payload provided to XNET Write.vi is always used. XNET Write (Frame CAN).vi is the recommended way to write data for this mode for CAN. This instance provides an array of frame va lues, where each value is a LabVIEW cluster is the recommended way to specific to the CAN protocol. XNET Write (Frame LIN).vi write data for this mode for LI ray of frame values, where each N. This instance provides an ar value is a LabVIEW cluster specific to the LIN protocol. For more advanced applications, you in an optimized format. can use XNET Write (Frame Raw).vi , which provides frame values Similar to CAN, LIN frame values transmit on the network based entirely on the time when you call XNET Write.vi . The timing of each frame as speci fied in the database is ignored. The LIN frame payload length in the database is ignored. For LIN, this mode is allowed only frame is empty, only the header part of the on the interface as master. If the payload for a the header + response for the frame is frame is transmitted. For a nonempty payload, transmitted. If a frame for transmit is defined in the database (in-memory or otherwise), it is transmitted using its database checksum type. If the frame for transmit is not defined in the database, it is transmitted using enhanced checksum. 4-27 © National Instruments NI-XNET Hardware and Software Manual

93 Chapter 4 NI-XNET API for LabVIEW—Sessions XNET Write (Frame LIN).vi is the recommended way to write data for this mode for LIN. This instance provides an array of frame va lues, where each value is a LabVIEW cluster specific to the LIN protocol. For more advanced applications, you can use XNET Write in an optimized format. (Frame Raw).vi , which provides frame values The frame values for this mode are stored in a queue, such that every value provided is transmitted. Example In this example CAN database, frame C is a cy clic frame that transmits on the network once every 2.0 ms. Frame E is an even t-driven frame that uses a tran smit time (minimum interval) of 2.5 ms. For information about cyclic and event-driven CAN frames, refer to Cyclic and . Event Timing Each frame contains two signals, one in th e first byte and another in the second byte. The following figure shows a timeline of a fr ame transfer on the CAN network. Each frame contains its name (C or E), followed by the va lue of its two signals. The timeline begins with XNET Write (Frame CAN).vi a single call to . Write C3,4 C1,2 E3,4 E5,6 E7,8 Time 0 ms 4 ms 5 ms 6 ms 7 ms 8 ms 3 ms 2 ms 1 ms XNET Write (Frame The following figure shows the data provided to the single call to es for frames C and E. . The array provides valu CAN).vi 4-28 NI-XNET Hardware and Software Manual ni.com

94 Chapter 4 NI-XNET API for LabVIEW—Sessions , each session starts within the call property uses the default of true Assuming the Auto Start? to XNET Write (Frame CAN).vi . All frame values transmit immediately, using the same sequence as the array. a slower timing in the databa se, the Frame Output Stream Although frame C and E specify mode disregards this timin g and transmits the frame values in quick succession. Within each frame values, this example uses an invalid timestamp value (0). This is acceptable, because each frame value ti mestamp is ignored for this mode. ame, this mode does not repeat its Although frame C is specifi ed in the database as a cyclic fr transmit. Unlike the , the Frame Output Stream mode does not Queued Mode Frame Output use CAN frame properties from the database. Signal Input Single-Point Mode r each signal. It typically is used for control This mode reads the most recent value received fo as Hardware In the Loop (HIL). or simulation applications, such 4-29 © National Instruments NI-XNET Hardware and Software Manual

95 Chapter 4 NI-XNET API for LabVIEW—Sessions received frame. If the interface receives This mode does not use queues to store each XNET Read.vi , that call to XNET Read.vi returns signals for the two frames prior to calling second frame. Use for this mode. For more advanced applications, XNET Read (Signal Single-Point).vi you can use XNET Read (Signal XY).vi , which returns a timestamp for each signal value. You can use the additional timestamps to dete rmine whether each value is new since the last read. for a frame. This signal name is :trigger:. , You also can specify a trigger signal and once it is specified in the XNET Create Session.vi signal list, it returns a value of 0.0 if the frame did not arrive since the last Read (or St art), and 1.0 if at least one frame of this ID arrived. You can specify multiple trigger signals for different fram es in the same session. For multiplexed signals, a si gnal may or may not be contained in a received frame. To define a trigger signal for a multiplexed signal, use the signal name :trigger:.. st Read or Start. received since the la Example In this example network, frame C is a cyclic frame that transmits on the network once every 2 ms. Frame E is an event-driven frame. Fo r information about cyclic and event-driven frames, refer to . Cyclic and Event Timing Each frame contains two signals, one in th e first byte and another in the second byte. The example uses CAN. The foll owing figure shows a timeline of a frame transfer on the CAN network. Each frame contains its name (C or E), followed by the value of its two signals. XNET Read (Signal Single-Point).vi . The timelines shows three calls to 3rd 2nd 1st Read Read Read C5,6 C1,2 C3,4 E5,6 E1,2 E7,8 Time 0 ms 1 ms 4 ms 7 ms 3 ms 2 ms 6 ms 5 ms 8 ms 4-30 NI-XNET Hardware and Software Manual ni.com

96 Chapter 4 NI-XNET API for LabVIEW—Sessions The following figure shows the data retu rned from each of the three calls to XNET Read (Signal Single-Point).vi . The session contains all four signals. XNET Read (Signal Single-Point).vi , values 3 and 4 In the data returned from the first call to of frame C (1 and 2) are returned for the signa ls of frame C. The valu es of the first reception were lost, because this mode returns the most recent values. In the frame timeline, Time of 0 ms indicates the time at which the session started to receive received prior to the first call to XNET Read (Signal frames. For frame E, no frame is Single-Point).vi , so the last two values return the signal Default Values. For this example, assume that the Default Value is 0.0. In the data returned from the second call to XNET Read (Signal Single-Point).vi , values 3 and 4 are returned again for the signals of fr ame C, because no new frame has been received since the previous call to XNET Read (Signal Single-Point).vi . New values are returned for frame E (5 and 6). XNET Read (Signal Single-Point).vi In the data returned from the third call to , both frame all signals return new values. C and frame E are received, so The following figure shows the data for the same frame timing, but using XNET Read (Signal XY).vi . The signal values are the same, but an additional timestamp is provided for each signal. 4-31 © National Instruments NI-XNET Hardware and Software Manual

97 Chapter 4 NI-XNET API for LabVIEW—Sessions For the first call to XNET Read (Signal XY).vi , notice that the timestamps for frame E (last two signals) are invalid (all zero). This indicates that frame E has not been received since the session started, and therefore th e signal values are the default. For the second call to XNET Read (Signal XY).vi , notice that the timestamps for frame C (first two signals) are the same as the first call to XNET Read (Signal XY).vi . This indicates evious read, and therefor that frame C has not been received since the pr e the signal values are repeated. Signal Input Waveform Mode Using the time when the signal frame is receive d, this mode resamples the signal data to a waveform with a fixed sample rate. This mode typically is used for synchronizing XNET data with DAQmx analog/digital input channels. XNET Read (Signal Waveform).vi Use for this mode. You can wire the data XNET Read (Signal Waveform).vi returns directly to a LabVIEW Waveform Graph or Waveform Chart. The data consists of an array of waveforms, one for each signal specified for the session. Each waveform contains t0 (timestamp of first samp le), dt (time between samples in seconds), and an array of resampled values for the signal. You specify the resample rate using the XNET Session property. Resample Rate 4-32 NI-XNET Hardware and Software Manual ni.com

98 Chapter 4 NI-XNET API for LabVIEW—Sessions Example In this example network, frame C is a cyclic frame that transmits on the network once every 2 ms. Frame E is an event-driven frame. For information about cyclic and event-driven frames, refer to Cyclic and Event Timing . Each frame contains two signals, one in th e first byte and another in the second byte. of a frame transfer on the The example uses CAN. The foll owing figure shows a timeline XNET Read (Signal Waveform).vi CAN network, followed by a single call to . Each frame contains its name (C or E), followed by the value of its two signals. Read C3,4 C5,6 C3,4 C1,2 E7,8 E5,6 E1,2 Time 0 ms 2 ms 1 ms 4 ms 5 ms 6 ms 7 ms 8 ms 3 ms 4-33 © National Instruments NI-XNET Hardware and Software Manual

99 Chapter 4 NI-XNET API for LabVIEW—Sessions XNET Read (Signal Waveform).vi . The The following figure shows the data returned from session contains all four signals and uses the default resample rate of 1000.0. XNET Read (Signal Waveform).vi , t0 provides an absolute In the data returned from timestamp for the first sample. Assuming this is the first call to XNET Read (Signal Waveform).vi after starting the session, this t0 refl ects that start of the session, which corresponds to Time 0 ms in the frame timelin e. At time 0 ms, no frame has been received. Therefore, the first sample of each waveform uses the signal default valu e. For this example, assume the default value is 0.0. In the frame timeline, fr ame C is received twice with signal values 3 and 4. In the waveform because the time of ng the frame only once, nguish this from receivi diagram, you cannot disti led into the waveform timing. each frame reception is resamp In the frame timeline, frame E is received twice in fast succession, once with signal values 7 and 8, then again with signals 5 and 6. These two frames are received within one sample of the waveform (within 1 ms). Th e effect on the data from XNET Read (Signal Waveform).vi is that values for the firs t frame (7 and 8) are lost. You can avoid the loss of signal data by setting the session resample rate to a high rate. NI-XNET timestamps receive fram es to an accuracy of 100 ns . Therefore, if you use a resample rate of 1000000 (1 MHz), each frame’s signal values are represented in the waveforms without loss of data. Nevertheless, using a high resample rate can result in a large amount of duplicated (redundant) values. For example, if the resample rate is 1000000, in one million dupli cated signal values. a frame that occurs once per second results This tradeoff between accuracy and efficiency is a disadvantage of the Signal Input Wave f o rm m o d e . 4-34 NI-XNET Hardware and Software Manual ni.com

100 Chapter 4 NI-XNET API for LabVIEW—Sessions The Signal Input XY Mode does not have the disadvantages mentioned previously. The signal value timing is a direct re flection of received frames , and no resampling occurs. Signal Input XY Mode provides the most efficient and accurate representation of a sequence of received signal values. Signal Input XY Mode esponding LabVIEW is that the corr One of the disadvantages of indicator (XY Graph) does not provide the same features as the indicator for Signal Input Waveform (Waveform Graph). Fo r example, the Waveform Grap h can plot consecutive calls XNET Read.vi in a history, whereas XY Graph can pl to ot only values from a single call to XNET Read.vi . In summary, when reading a sequence of receive d signal values, use Si gnal Input Waveform mode when you need to synchronize CAN/FlexRay/LIN data with DAQmx analog/digital input waveforms or display CAN/FlexRay/LIN data on the front panel (without significant when you need to analyze CAN/FlexRay/LIN data Signal Input XY Mode validation). Use on the diagram, for validation purposes. Signal Input XY Mode For each frame received, this mode provides the frame signals as a timestamp/value pair. This is the recommended mode for readi ng a sequence of all signal values. The timestamp represents the ab solute time when the XNET in terface received the frame (end of frame), accurate to microseconds. Use XNET Read (Signal XY).vi for this mode. You can wire the data XNET Read (Signal XY).vi returns directly to a LabVIEW XY Graph. each signal specified for the The data consists of an arra y of LabVIEW clusters, one for session. Each cluster contains two arrays, for value. For each one for timestamp and one ys the same, such that it represents a single signal, the timestamp and value array size is alwa array of timestamp/value pairs. Each timestamp/value pair represents a value from a received frame. When signals exist in erent from one cluster (signal) to another. different frames, the array size may be diff The received frames for this mode are stor ed in queues to avoid signal data loss. Example In this example network, frame C is a cyclic frame that transmits on the network once every 2 ms. Frame E is an event-driven frame. For information about cyclic and event-driven . Cyclic and Event Timing frames, refer to e first byte and another in the second byte. Each frame contains two signals, one in th 4-35 © National Instruments NI-XNET Hardware and Software Manual

101 Chapter 4 NI-XNET API for LabVIEW—Sessions The example uses CAN. The foll owing figure shows a timeline of a frame transfer on the . Each frame contains CAN network, followed by a single call to XNET Read (Signal XY).vi its name (C or E), followed by the value of its two signals. Read C5,6 C3,4 C3,4 C1,2 E5,6 E1,2 E7,8 Time 0 ms 7 ms 8 ms 1 ms 4 ms 2 ms 6 ms 5 ms 3 ms The following figure shows the data returned from . The session XNET Read (Signal XY).vi contains all four signals. Frame C was received four times, resulting in arrays of size 4 in the first two clusters. Frame E arrays of size 3 in the first two clusters. The timestamp and was received 3 times, resulting in value arrays are the same size for each signal. Th e timestamp represents the end of frame, to microsecond accuracy. 4-36 NI-XNET Hardware and Software Manual ni.com

102 Chapter 4 NI-XNET API for LabVIEW—Sessions The XY Graph displays the data from XNET Read (Signal XY).vi . This display is an accurate representation of si gnal changes on the network. Signal Output Single-Point Mode This mode writes signal values for the next fram e transmit. It typically is used for control or simulation applications, such as Hardware In the Loop (HIL). This mode does not use queues to store signal values. If XNET Write.vi is called twice before XNET the next transmit, the transmitted frame uses signal values from the second call to Write.vi . Use XNET Write (Signal Single-Point).vi for this mode. You also can specify a trigger signal for a frame. This signal name is :trigger:. , and once it is specified in the XNET Create Session.vi signal list, you can write a value of 0.0 to suppress writing of that fr ame, or any value not equal to 0.0 to write the frame. You can specify multiple trigger signals for different frames in the same session. Example frame that transmits on In this example network, frame C is a cyclic the network once every uses a transmit time (minimum interval) of 2.0 ms. Frame E is an event-driven frame that 2.5 ms. For information about cyclic and event-driven frames, refer to Cyclic and Event . Timing Each frame contains two signals, one in th e first byte and another in the second byte. The example uses CAN. The foll owing figure shows a timeline of a frame transfer on the CAN network. Each frame contains its name (C or E), followed by the value of its two signals. The timeline shows three calls to XNET Write (Signal Single-Point).vi . 3rd 2nd 1st Write Write Write C1,2 C3,4 C5,6 C5,6 E3,4 E7,8 Time 0 ms 6 ms 7 ms 8 ms 3 ms 2 ms 1 ms 4 ms 5 ms 4-37 © National Instruments NI-XNET Hardware and Software Manual

103 Chapter 4 NI-XNET API for LabVIEW—Sessions ovided to each of the three calls to The following figure shows the data pr XNET Write (Signal Single-Point).vi . The session contains all four signals. Auto Start? Assuming the property uses the default of true, the session starts within the first call to XNET Write (Signal Single-Point).vi . Frame C transmits foll owed by frame E, both . using signal values from the first call to XNET Write (Signal Single-Point).vi If a transmitted frame contains a signal not included in the output session, that signal transmits its Default Value . If a transmitted frame contains bits no signal uses, those bits transmit the Default Payload . After the second call to XNET Write (Signal Single-Point).vi , frame C transmits using its because its minimal interval of 2.5 ms has not values (3 and 4), but frame E does not transmit, elapsed since acknowledgment of the previous transmit. Because the third call to occurs before the minimum XNET Write (Signal Single-Point).vi interval elapses for frame E, its next transmit uses its values (3 and 4). The values for frame E XNET Write (Signal Single-Point).vi are not used. in the second call to XNET Write (Signal Frame C transmits the third time using values from the third call to Single-Point).vi (5 and 6). Because frame C is cyclic, it transmits again using the same values (5 and 6). Signal Output Waveform Mode Using the time when the signal frame is tran smitted according to the database, this mode resamples the signal data from a waveform with a fixed sample rate. This mode typically is used for synchronizing XNET data with DAQmx analog/digital output channels. The resampling translates from the waveform timing to each frame’s tr ansmit timin g. When the time for the frame to transmit occurs, it uses the most recent signal values in the waveform that correspond to that time. XNET Write (Signal Waveform).vi Use for this mode. You can wire the data provided to XNET Write (Signal Waveform).vi directly from a LabVIEW Waveform Graph or 4-38 NI-XNET Hardware and Software Manual ni.com

104 Chapter 4 NI-XNET API for LabVIEW—Sessions ray of waveforms, one for each signal specified Waveform Chart. The data consists of an ar contains an array of resampled values for the signal. for the session. Each waveform Resample Rate You specify the resample rate using the XNET Session property. The frames for this mode are stored in queues. This mode is not supported for a LIN interface operating as slave. For more information, refer to . LIN Frame Timing and Session Mode Example frame that transmits on the network once every In this example network, frame C is a cyclic 2.0 ms. Frame E is an event-driven frame that uses a transmit time (minimum interval) of 2.5 ms. For information about cyclic and event-driven frames, refer to Cyclic and Event Timing . e first byte and another in the second byte. Each frame contains two signals, one in th of a frame transfer on the owing figure shows a timeline The example uses CAN. The foll CAN network. Each frame contains its name (C or E), followed by the value of its two signals. . XNET Write (Signal Waveform).vi The timeline begins with a single call to Write C5,6 C7,8 C5,6 C1,2 E5,6 E5,6 E5,6 Time 0 ms 5 ms 4 ms 1 ms 6 ms 7 ms 8 ms 3 ms 2 ms XNET Write (Signal data provided to the call to The following figure shows the and uses the default resample rate of . The session contains all four signals Waveform).vi 1000.0 samples per second. 4-39 © National Instruments NI-XNET Hardware and Software Manual

105 Chapter 4 NI-XNET API for LabVIEW—Sessions Assuming the Auto Start? property uses the default of true, the session starts within the call to XNET Write (Signal Waveform).vi . Frame C transmits followed by frame E, both using signal values from the first sample (index 0 of all four Y arrays). The waveform elements t0 (timestamp of first sample) and dt (time between samples in seconds) are ignored for the call to XNET Write (Signal Waveform).vi . Transmit of frames starts as soon as the XNET session starts. The frame properties in the database determine each frame’s transmit time. The session resample rate property determines the time between waveform samples. In the waveforms, the sample at index 1 occurs at 1.0 ms in the frame timeline. According to d to an event-driven , and frame E is limite the database, frame C transmits once every 2.0 ms transmit with interval 2.5 ms. Therefore, the sample at index 1 cannot be resampled to a transmitted frame and is discarded. Index 2 in the waveforms occurs at 2.0 ms in th e frame timeline. Frame C is ready for its next transmit at that time, so signal values 5 and 6 are taken from the first two Y arrays and used Frame E still has not reached its tr ansmit time of 2.5 ms from the for transmit of frame C. previous acknowledgment, so sign al values 1 and 2 are discarded. At index 3, frame E is allowed to transmit agai n, so signal values 5 and 6 are taken from the last two Y arrays and used for transmit of fram e E. Frame C is not ready for its next transmit, so signal values 7 and 8 are discarded. This behavior continues for Y array indices 4 through 7. For the cyclic frame C, every second frame E, every sample is interpreted as an sample is used to transmit. For the event-driven event, such that every third sample is used to transmit. 4-40 NI-XNET Hardware and Software Manual ni.com

106 Chapter 4 NI-XNET API for LabVIEW—Sessions Although not shown in the frame timeline, frame C transmits again at 8.0 ms and every 2.0 ms thereafter. Frame C repeats signal va lues 5 and 6 until the next call to XNET Write (Signal Waveform).vi . Because frame E is event driven, it does not transmit after the timeline shown, because no new event has occurred. Because the waveform timing is fixed, you canno t use it to represent events in the data. When used for event driven frames , the frame transmits as if each sample was an event. This mismatch between frame timing a nd waveform timing is a disadvantage of the Signal Output Wave f o rm m o d e . When you use the Signal Ou ided to XNET Write t XY Mode, the signal values prov tpu (Signal XY).vi are mapped directly to transmitted frames, and no resampling occurs. Un less your ap plication requires correlation of output d ata with DAQmx waveforms, Signal Output XY Mode is the recommended mode for writing a sequen ce of signal values. Signal Output XY Mode using each frame’s timing as This mode provides a sequence of signal values for transmit is the recommended mode for specified in the database. This writing a sequence of all signal values. Use for this mode. The data consists of an array of LabVIEW XNET Write (Signal XY).vi ssion. Each cluster contains two arrays, one for clusters, one for each signal specified for the se mestamp array is unused (reserved). timestamp and one for value. The ti frame for transmit. Therefore, the array of signal values is Each signal value is mapped to a mapped to an array of frames to transmit. When signals exist in the same frame, signals at the same index in the arrays are mapped to the sa me frame. When signals exist in different frames, the array size may be different from one cluster (signal) to another. The frames for this mode are stor ed in queues, such that every signal provided is transmitted in a frame. Examples In this example network, frame C is a cyclic frame that transmits on the network once every 2.0 ms. Frame E is an event-driven frame that uses a transmit time (minimum interval) of 2.5 ms. For information about cyclic and event-driven frames, refer to Cyclic and Event Timing . Each frame contains two signals, one in th e first byte and another in the second byte. The example uses CAN. The foll owing figure shows a timeline of a frame transfer on the CAN network. Each frame contains its name (C or E), followed by the value of its two signals. XNET Write (Signal XY).vi The timeline begins with a single call to . 4-41 © National Instruments NI-XNET Hardware and Software Manual

107 Chapter 4 NI-XNET API for LabVIEW—Sessions Write C5,6 C5,6 C3,4 C1,2 E7,8 E5,8 Time 0 ms 6 ms 4 ms 1 ms 2 ms 3 ms 8 ms 5 ms 7 ms The following figure shows the data provided to XNET Write (Signal XY).vi . The session contains all four signals. the session starts within a call to Auto Start? Assuming the property uses the default of true, XNET Write (Signal XY).vi . This occurs at 0 ms in the timeline. Frame C transmits followed by frame E, both using signal values from the first sample (index 0 of all four Y arrays). NI-XNET Hardware and Software Manual ni.com 4-42

108 Chapter 4 NI-XNET API for LabVIEW—Sessions According to the database, frame C transmits on ce every 2.0 ms, and frame E is limited to an event-driven interval of 2.5 ms. At 2.0 ms in the timeline, signal values 3 and 4 are taken from index 1 of the first two Y arrays and used for transmit of frame C. At 3.5 ms in the timeline, signal value 5 is ta ken from index 1 of the third Y array. Because this is a new value for frame E, it represents a new event, so the frame transmits again. Because no new signal value was provided at inde x 1 in the fourth array, the second signal of frame E uses the value 8 from the previous transmit. At 4.0 ms in the timeline, signal values 5 and 6 are taken from index 2 of the first two Y arrays and used for transmit of frame C. Because there are no more signal values for frame E, this fram e no longer transmits. Frame E is event driven, so new signal va lues are required for each transmit. Because frame C is a cyclic frame, it transmit s repeatedly. Although there are no more signal values for frame C, the values of the previous frame are used again at 6.0 ms in the timeline and every 2.0 ms thereafter. If is called again, the new signal XNET Write (Signal XY).vi values are used. The next example network demonstrates a potential problem that can occur with Signal Output XY Mode . frame that transmits on In this example network, frame C is a cyclic the network once every 2.0 ms. Frame X is a cyclic frame that transm its on the network once every 1.0 ms. Each frame contains two signals, one in the first byte and another in the second byte. The timeline begins . XNET Write (Signal XY).vi with a single call to Write C3,4 C1,2 C5,6 C7,8 X5,6 X3,4 X1,2 X1,2 X7,8 X1,2 X1,2 X1,2 Time 0 ms 7 ms 3 ms 2 ms 1 ms 5 ms 6 ms 8 ms 4 ms 4-43 © National Instruments NI-XNET Hardware and Software Manual

109 Chapter 4 NI-XNET API for LabVIEW—Sessions The following figure shows the data provided to XNET Write (Signal XY).vi . The session contains all four signals. The number of signal values in all four Y arrays is the same. The four elements of the arrays are mapped to four frames. The problem is that because frame X transmits twice as fast as frame C, the frames for the last two arrays transm it twice as fast as the frames for the first two arrays. The result is that the last pair of signals for fr ame X (1 and 2) transmit over and over, until the timeline has completed for frame C. This sort of behavior usually is unintended. The Signal goal is to provide a complete sequ Output XY Mode ence of signal values for each frame. e a different number of values for each signal, The best way to resolve this issue is to provid such that the number of elements corresponds to the timeline for the corresponding frame. If provided eight elemen the previous call to XNET Write (Signal XY).vi ts for frame X (last two Y arrays) instead of just four elements, this would have created a complete 8.0 ms timeline for both frames. Although you need to resolve this sort of timeline for cyclic frames, this is not necessarily true for event-driven frames. For an event-driven frame, you may decide simply to pass either zero . When you do th XNET Write (Signal XY).vi is, each call to or one set of signal values to 4-44 NI-XNET Hardware and Software Manual ni.com

110 Chapter 4 NI-XNET API for LabVIEW—Sessions XNET Write (Signal XY).vi can generate a single event, and the overall timeline is not a major consideration. Conversion Mode This mode is intended to convert NI-XNET signal data to frame data or vice versa. It does not use any NI-XNET hardware, and you do not sp ecify an interface when creating this mode. Conversion occurs with nor XNET Read.vi XNET Convert.vi . Neither XNET Write.vi work with this mode; they return an er ror because hardware I/O is not permitted. Conversion works similar to Single-Point mode. You specify a set of signals that can span multiple frames. Signal to frame conversion reads a set of va lues for the signals specified and writes them to the respective frame(s). Frame to signal conversion parses a set of frames and returns the latest signal value r ead from a corresponding frame. tations (CAN, FlexRay, LIN, or Raw). You Frames can be in any NI-XNET frame represen select the conversion directio g the appropriate instance of n and the frame type by choosin XNET Convert.vi . Example 1: Conversion of CAN Frames to Signals Suppose you have a database with a CAN frame with ID 0x123 and two unsigned byte signals assigned to it (byte 1 and byte 2). nversion session and calling XNET Convert (Frame CAN to Creating an appropriate co with the following input: Signal).vi 4-45 © National Instruments NI-XNET Hardware and Software Manual

111 Chapter 4 NI-XNET API for LabVIEW—Sessions results in the following signal values being returned: 1 and 3 are ignored because they have Explanation : The data are taken from frame 4. Frames se its data are overwritten later with the a wrong (unmatched) ID. Frame 2 is ignored becau values from frame 4, because frames are processed in the order of input. Example 2: Conversion of Signals to FlexRay Frames ames with slot ID 3 and 6, and each one has assigned a Suppose you have two FlexRay fr two-byte, Big Endian signal at byte 2 and 3 (zero based). Suppose also that all relevant default values of other signals in the frame are 0. 4-46 NI-XNET Hardware and Software Manual ni.com

112 Chapter 4 NI-XNET API for LabVIEW—Sessions Creating an appropriate co nversion session and calling XNET Convert (Signal to Frame FlexRay).vi with the following input: causes the following frames to be generated: : The first signal is converted to the byte sequence 0x01, 0x02 (1 Explanation 256 + 2), and  ame with slot ID 3. The second signal is the byte sequence is placed at byte 2 of the fr 256 + 4) and placed at converted to byte sequence 0x03, 0x04 (3  byte 2 of the frame with slot ID 6. All other data are filled with the default values (0). How Do I Create a Session? There are two methods for creating a session: a LabVIEW project and XNET Create r your application. create all sessions fo Session.vi . You typically use only one method to 4-47 © National Instruments NI-XNET Hardware and Software Manual

113 Chapter 4 NI-XNET API for LabVIEW—Using CAN LabVIEW Project Using LabVIEW project sessions is best suited fo e static, in that the r applications that ar network data does not change from one execution to the next. Refer to Getting Started for a description of creating a se ssion in a LabVIEW project. When you configure the session in a LabVIEW project, you select the interface, mode, and database objects with the NI-XNET user interf ace. The database objects (cluster, frames, and signals) must exist in a file. If you do not already have a database file, you can create one using the NI-XNET Database Editor , which you can launch from NI-XNET user interface. XNET Create Session.vi XNET Create Session.vi to create NI-XNET sessions at run time. This run-time You can use creation has advantages over a LabVIEW project , because the end user of your application can configure sessions from the front panel. The disadvantage is that the VI diagram is more complex. If your application is used for a specific produ ct (for example, an instrument panel for a specific make/model/year car), and the front panel must be simple (for example, a test button with a pass/fail LED), a LabVIEW project is th e best method to use for NI-XNET sessions. Because the configuration doe ect provides the easiest s not change, a LabVIEW proj programming model. products (for example, a test system for an If your application is used for many different engine in any make/model/year car), XNET Create Session.vi is the best method to use for NI-XNET sessions. On the front panel, the app lication end user can provide a database file and select the specific frames or signals to read and/or write. XNET Create Session.vi takes inputs for the interface, mode, and database objects. You select the interface using techniques described in How Do I View Available Interfaces? . The database objects depend on the mode (for example, Signal Input Waveform requires an array of signals). You select the database objects using techniques described in Database Programming . Using CAN This section summarizes some useful NI-XNET features sp ecific to the CAN protocol. Understanding CAN Frame Timing When you use an NI-XNET database for CAN, the properties of each CAN frame specify the CAN data transfer timing. To understand ho w the CAN frame timing properties apply to . CAN Timing Type and Session Mode NI-XNET sessions, refer to 4-48 NI-XNET Hardware and Software Manual ni.com

114 Chapter 4 NI-XNET API for LabVIEW—Using CAN Configuring Frame I/O Stream Sessions As described in Database Programming , you typically need to speci fy database objects when creating an NI-XNET session. The CAN protocol supports an exception that makes some applications easier to program. In sessions with Frame Input Stream or Frame Output Stream mode, you can read or write arbitrary frames. Because these modes do not use specific frames , only the database cluster properties apply. For CAN, the only required clus ter property is the baud rate. If the I/O mode of your cluster is CAN FD or CAN FD+BRS, the FD baud rate also is required. Although the CAN baud rate applies to all hardware on the bus (cluster), NI-XNET also provides the baud rate propertie set these interface properties s as interface properties. You can using the session property node. If your application uses only Frame I/O Stream sessions, no database object is required (no cluster). You simply can call and then set the baud rate using the XNET Create Session.vi session property node. The following figure sh ows an example diagram that creates a Frame Input Stream session and sets the baud rate to 500 kbps. The resulting session operates in the standard CAN I/O mode. Figure 4-6. Configure CAN Frame Input Stream If your application uses only Frame I/O Stream sessions, but you want to connect to a CAN FD bus, use the in-memory database :can_fd: or :can_fd_brs: as shown in Figure 4-7. These databases are configured as a CAN cluster with the CAN:I/O Mode set to CAN FD or CAN FD+BRS, as appropriate. If you use either database, you must set the Interface:CAN:FD Baud Rate property. ream for a CAN FD Session Configure CAN Frame Input St Figure 4-7. 4-49 © National Instruments NI-XNET Hardware and Software Manual

115 Chapter 4 NI-XNET API for LabVIEW—Using FlexRay Using FlexRay This section summarizes some fic to the FlexRay protocol. useful NI-XNET features speci Starting Communication FlexRay is a Time Division Multiple Access (TDMA) protocol, which means that all hardware products on the network share a synchronized clock. Slots of time for that clock determine when each frame transmits. To start communication on FlexRay, the first step is to start the synchronized network clock. In the FlexRay database, two or more hardware products are designated to transmit a special startup frame. These products (nodes) are called coldstart nodes. Each coldstart node uses the startup frame to contribute the shared network clock. its local clock as part of ired to start FlexRay communication, your Because at least two coldstart nodes are requ NI-XNET FlexRay interface may need to act as a coldstart node, and therefore transmit a special startup frame. The proper ties of each startup frame (inclu ding the time slot used) are specified in the FlexRay database. The following scenarios apply to FlexRay startup frames: : When you get started with your NI-XNET FlexRay hardware, you can • Port to port n simple programs, such as the NI-XNET connect two FlexRay interfaces (ports) to ru examples. Because this is a cluster with two nodes, each NI-XNET interface must transmit a differen t startup frame. • Connect to existing cluster : If you connect your NI-XNET FlexRay interface to an existing cluster (for example, a FlexRay netw ork within a vehicle), that cluster already must contain coldstart nodes. In this scenar io, the NI-XNET interface should not transmit a startup frame. Test single ECU that is coldstart : If you connect to a single ECU (and nothing else), • T interface must transm it a startup frame. and that ECU is a coldstart node, the NI-XNE different than the startup The NI-XNET interface must tran smit a startup frame that is frame the ECU transmits. • Test single ECU that is not coldstart : If you connect to a single ECU (and nothing else), and that ECU is not a coldstart node, you must connect two NI-XNET interfaces. The ECU cannot communicate without two coldstart nodes (two clocks). According to the terface can transmit only one startup frame. FlexRay specification, a single FlexRay in Therefore, you need to connect two NI-XNE T FlexRay interfaces to the ECU, and each NI-XNET interface must transmit a different startup frame. 4-50 NI-XNET Hardware and Software Manual ni.com

116 Chapter 4 NI-XNET API for LabVIEW—Using LIN NI-XNET has two options to transmit a startup frame: • Key Slot Identifier : The NI-XNET session property node includes a property called Interface:FlexRay:Key Slot Identifier . This property specifies the static slot that the session interface uses to tr ansmit a startup frame. The pr operty is zero by default, ansmits. If you set this prop erty, the value specifies the meaning that no startup frame tr a coldstart node. The st artup frame transmits static slot (identifier) to transmit as automatically when the interface starts, and its payload is null (no data). The session can be input or output, and the startup frame is not required in the session’s list of frames/signals. • Output Startup Frame : If you create an NI-XNET output session, and the session’s list of frames/signals uses a startup frame, th e NI-XNET interface acts as a coldstart node. FlexRay:Startup? property To find startup frames in the da tabase, look for a frame with the for an output session or use its identifier as the key slot. true. You can use that frame name When selecting a startup frame, avoid selecting one that the ECUs you connect to already transmit. Understanding FlexRay Frame Timing When you use an NI-XNET database for Flex Ray, the properties of each FlexRay frame specify the FlexRay data transfer timing. To understand how the FlexRay frame timing properties apply to NI-XNET sessions, refer to FlexRay Timing Type and Session Mode . In LabVIEW Real-Time, NI-XNET provides a timing source you can use to synchronize your LabVIEW VI with the timing of frames. For more information, refer to Using LabVIEW Real-Time . Protocol Data Unit (PDU) Many FlexRay networks use a Protocol Data Un it (PDU) to implement configurations similar use a single PDU within multiple frames for to CAN. The PDU is a signal container. You can faster timing. A single fram e can contain multiple PDUs, each updated independently. For . more information, refer to Protocol Data Units (PDUs) in NI-XNET Using LIN This section summarizes some useful NI-XNET features sp ecific to the LIN protocol. Changing the LIN Schedule LIN networks (clusters) always include a si ngle ECU in the system called the master. The er is a remote request for a frame headers. Each frame head master transmits a schedule of ECU in the network (slave) responds by specific frame ID. For each header, a single 4-51 © National Instruments NI-XNET Hardware and Software Manual

117 Chapter 4 NI-XNET API for LabVIEW—Using LIN transmitting the payload for the requested ID. The master ECU also can respond to a specific header, and thus the master can transmit pa yload data for the slave ECUs to receive. Unlike some other scheduled protocols such as FlexRay, LIN allows the master ECU to ple, the master can in change the schedule of frame headers. For exam itially use a “normal” schedule that requests IDs 1, 2, 3, 4, and then the master can change to a “diagnostic” schedule that requests IDs 60 and 61. With NI-XNET, you change the LIN schedule using XNET Write (State LIN Schedule Change).vi act as a master on the network, you . When you want the NI-XNET interface to XNET Write VI at least once, to specify the schedule to run. When you write must call this a schedule change, this automatically confi gures NI-XNET as master (the XNET Session Interface:LIN:Master? property is set to true). As a LIN master, NI-XNET handles all u, using the LIN interface hardware onboard real-time scheduling of frame headers for yo processor. I-XNET leaves the interface at its default If you do not write a schedule change, N configuration of slave. As a LIN slave, you still can write signal or frame values to an output session, but NI-XNET waits for each frame’s header to arrive before transmitting payload data. Understanding LIN Frame Timing Because LIN is a scheduled network, the head ers that the master tr ansmits determine the timing of all frames. To understand how and wh en each frame transmits, you must examine the entries in each schedule. Each entry transfers one frame (or possibly multiple frames). For more information, refer to the XNET LIN Schedule Entry Type property. Because it is possible to use a single frame in multiple schedules and schedule entries, the overall timing for an in vertheless, each LIN schedule entry dividual frame can be complex. Ne generally fits the concepts of cyclic and event timing that are common for other protocols such as CAN and FlexRay. For more information abou t how these concepts apply to LIN, refer to Cyclic and Event Timing . LIN Diagnostics Refer to XNET Write (State LIN Diagnostic Schedule Change).vi for details. Special Considerations for Using Stream Output Mode with LIN Refer to the Interface:Output Stream Timing property for details. 4-52 NI-XNET Hardware and Software Manual ni.com

118 Chapter 4 NI-XNET API for LabVIEW—Using LabVIEW Real-Time Using LabVIEW Real-Time The LabVIEW Real-Time (RT) module combin es LabVIEW graphical programming with the power of a real-time operating system, en abling you to build real-time applications. NI-XNET provides features and performance specifically designed for LabVIEW RT. High Priority Loops Many real-time applications contai n at least one loop that must execute at the highest priority. to read inputs, execute a control algorithm, and This high-priority loop typically contains code then write outputs. The high-priority loop execute s at a fast period, such as 500 μs (2 kHz). To ensure that the loop diagram executes within the period, the average execution time (cost) of read and write VIs must be low. The execution time also must be consistent from one loop iteration to another (low jitter). Within NI-XNET, the session modes for singl e-point I/O are designed for use within high-priority loops. This applies to all four single-point modes: input, output, signal, or frame. XNET Read.vi and XNET Write.vi provide fast and consistent execution time, and they avoid access to shared resources such as the memory manager. The session modes other than single-point all use queues to store data. Although you can use the queued session modes within a high priority loop, those modes use a variable amount of ocess the data, which le amount of time to pr data for each read/write. This requires a variab can introduce jitter to the loop. When using the queued modes, measure the performance of your code within the loop to ensure that it m eets your requirements even when bus traffic is variable. When XNET Read.vi and XNET Write.vi execute for the very first loop iteration, they often perform tasks such as auto-start of the sessi on, allocation of internal memory, and so on. These tasks result in high cost for the first iteration compared to any subsequent iteration. XNET Read.vi , discard the first and When you measure performance of XNET Write.vi iteration from th e measurement. or XNET Write.vi For another VI or property node (not XNET Read.vi ), you must assume it is not designed for use within high priority loops. The property nodes are designed for XNET Start.vi ) require time for configuration purposes. VIs that change state (for example, ss, there are exceptions for which certain hardware/software configuration. Neverthele ority use. Refer to the help for the specific features you properties and VIs support high-pri want to use within a high priority loop. This help may specify an exception. 4-53 © National Instruments NI-XNET Hardware and Software Manual

119 Chapter 4 IEW—Using LabVIEW Real-Time NI-XNET API for LabV XNET I/O Names You can use a LabVIEW project to program RT targets. When you open a VI front panel on s the target remotely (over TCP/IP). an RT target, that front panel accesse front panel on LabVIEW RT, the remote access When you use an XNET I/O name on a VI O name. For example, th e drop-down list of an provides the user interface features of that I/ XNET Interface provides all CAN, FlexRay, and LIN interfaces on the RT target (for example, a PXI chassis). For the remote access to operate properly, you must connect the LabVIEW RT target using a lick the target in a LabVIEW project and LabVIEW project. To connect the target, right-c ect, and the user in Connect . The target shows a green LED in proj terface of I/O names select is operational. If the RT target is disconnected in a LabV IEW project, each I/O name displays the text (target in its drop-down list. disconnected) Deploying Databases When you create an NI- XNET application for LabVIEW RT, you must assign an alias to your database file. When you deploy to the RT target, the text database file is compressed to an optimized binary format, and that binary file is transferred to the target. When you create NI-XNET sessions using a La bVIEW project, you assign the alias within Browse for Database File ). When you drag the session to a the session dialog (for example, VI under the RT target, then run that VI, NI-XNET automatically deploys the database file to the target. When you create NI-XNET sessions at run time, you must explicitly deploy the database to the RT target. There are two options for this deployment: : If you are using I/O names for database objects, you can click on an • XNET I/O Names I/O name and select Manage Database Deployment . This opens a dialog you can use to assign new aliases and deploy them to the RT target. • File Management Subpalette VIs : To manage database deployment from a VI running on the host (Windows computer ), use VIs in the NI-XNET File Management palette. This palette includes VIs to add an alias and deploy the database to the RT target. To delete the database file from the RT target after execution of a test, you perform this undeploy using either option described above. Memory Use for Databases or example, cluster, frame, signal) on the When you access properties of a database object (f diagram of your VI, NI-XNET opens the database on disk and maintains a binary image in 4-54 NI-XNET Hardware and Software Manual ni.com

120 Chapter 4 NI-XNET API for LabVIEW—Using LabVIEW Real-Time memory. Use XNET Database Close.vi to close the database prior to performing memory-sensitive tasks, such as a control loop on LabVIEW Real-Time. XNET Create Session.vi , NI-XNET internally When you pass database objects as input to opens the database, reads the information requ ired to create the session, then closes the database. Therefore, there is no need to exp licitly close the database after creating sessions. FlexRay Timing Source FlexRay is a deterministic protocol, which means it enables ECUs to synchronize code execution and data exchange. When you use La bVIEW to test an ECU that uses these ypically need to synchronize th e LabVIEW VI to the FlexRay deterministic features, you t that the ECU transmits a different value each communication cycle. For example, to validate FlexRay cycle, you must read that frame every FlexRay cycle. NI-XNET provides to create a LabVIEW rce (FlexRay Cycle).vi XNET Create Timing Sou timing source. You wire this timing source to a LabVIEW timed loop to execute LabVIEW se the length of time for each FlexRay cycle code synchronized to the FlexRay cycle. Becau ides the required real-time execution. is a few milliseconds, LabVIEW RT prov Creating a Built Real-Time Application NI-XNET supports creation of a real-time application, which y ou can set to run automatically when you power on the RT target. Create th e real-time application by right-clicking Build Specifications under the RT target, then selecting New»Real-Time Application . sessions are deployed to the If you created NI-XNET session s in a LabVIEW project, those RT target in the same manner as running a VI. Deployment of databases for the same as running a VI. a real-time application is 4-55 © National Instruments NI-XNET Hardware and Software Manual

121 Chapter 4 NI-XNET API for LabVIEW Reference NI-XNET API for LabVIEW— NI-XNET API for LabVIEW Reference This section describes the NI-XNE T LabVIEW APIs and properties. XNET Session Constant This constant provides the constant form of the XNET Session I/O name. You drag a constant to the block diagram of your VI, then select a session. You can change constants only during XNET Session I/O configuration, prior to running the VI. For a complete description, refer to Name . 4-56 NI-XNET Hardware and Software Manual ni.com

122 Chapter 4 bVIEW—XNET Create Session.vi NI-XNET API for La XNET Create Session.vi Purpose Creates an XNET session to read /write data on the network. Description The XNET session specifies a relationship be tween National Instruments interface hardware and frames or signals to access on the external network (cluster). The XNET session also specifies the input/output direction and how data is transferred between your application and the network. For more information about NI-X NET concepts and object classes, refer to , Databases , and Sessions . Interfaces Use this VI to create a session at run time. Run-time creation is useful when the session configuration must be selected using the front pa nel. If you prefer to create a session at edit time (static configuration), refer to Appendix E, LabVIEW Project Provider . specify the session mode to create: The instances of this polymorphic VI XNET Create Session (Signal Input Single-Point).vi • • XNET Create Session (Signal Input Waveform).vi • XNET Create Session (Signal Input XY).vi • XNET Create Session (Signal Output Single-Point).vi • XNET Create Session (Signal Output Waveform).vi • XNET Create Session (Signal Output XY).vi • XNET Create Session (F rame Input Stream).vi • XNET Create Session (Frame Input Queued).vi • XNET Create Session (Frame Input Single-Point).vi XNET Create Session (PDU Input Queued).vi • • XNET Create Session (PDU Input Single Point).vi XNET Create Session (Fra me Output Stream).vi • me Output Queued).vi • XNET Create Session (Fra XNET Create Session (Frame Output Single-Point).vi • • XNET Create Session (PDU Output Queued).vi • XNET Create Session (PDU Output Single-Point).vi r advanced applications, : (This instance is used fo • XNET Create Session (Generic).vi e configuration as strings.) when you need to specify th XNET Create Session (Conversion).vi • 4-57 © National Instruments NI-XNET Hardware and Software Manual

123 Chapter 4 XNET Create Session (Conversion).vi NI-XNET API for LabVIEW— XNET Create Session (Conversion).vi Purpose Creates an XNET session at run time for the Conversion Mode . Format Inputs t is the array of XNET signals to signal lis convert to or from frames. These signals are specified in your database and describe the values encoded in one or more frames. Error Handling error in is the error cluster input (refer to ). Outputs session out is the created session. ). is the error cluster output (refer to Error Handling error out 4-58 NI-XNET Hardware and Software Manual ni.com

124 Chapter 4 NI-XNET API for LabVIEW—XNET Create Session (Frame Input Queued).vi rame Input Queued).vi XNET Create Session (F Purpose Creates an XNET session at run time for the Frame Input Queued Mode . Format Inputs frame mode supports only one frame per is the XNET Frame to read. This session. Your database specifies this frame. interface is the XNET Interface to use for this session. Error Handling error in is the error cluster input (refer to ). Outputs session out is the created session. is the error cluster output (refer to ). Error Handling error out 4-59 © National Instruments NI-XNET Hardware and Software Manual

125 Chapter 4 NI-XNET API for LabVIEW—XNET Crea te Session (Frame Input Single-Point).vi me Input Single-Point).vi XNET Create Session (Fra Purpose Creates an XNET session at run time for the Frame Input Single-Point Mode . Format Inputs is the array of XNET Frames to read. Your database specifies frame list these frames. interface is the XNET Interface to use for this session. Error Handling error in is the error cluster input (refer to ). Outputs session out is the created session. ). is the error cluster output (refer to Error Handling error out 4-60 NI-XNET Hardware and Software Manual ni.com

126 Chapter 4 Create Session (Frame Input Stream).vi NI-XNET API for LabVIEW—XNET XNET Create Session (F rame Input Stream).vi Purpose Creates an XNET session at run time for the Frame Input Stream Mode . Format Inputs cluster is the XNET Cluster to use for interface configuration. The default :memory: , the in-memory database. value is There are five options: Empty in-memory database • : cluster is unwired, and the in-memory XNET Database Create Object.vi database is empty ( is not used). This option is supported for CAN only (not FlexRay or LIN). After Interface:Baud you create the session, you must set the XNET Session property using a Session node. You must set the baud rate prior to Rate starting the session. • Pre-defined in-memory database: Pass in special in-memory databases :can_fd: and :can_fd_brs:, as the cluster ( XNET Database Create Object.vi is not used). These databases are similar to the empty in-memory database (:memory:), but configure the cluster in either CAN FD or CAN FD+BRS mode, respectively. After you create and the session, you must set the XNET Session Interface:Baud Rate Interface:CAN:FD Baud Rate properties using a Session node. You must set these baud rates prior to starting the session. specifies a cluster within a • Cluster within database file : cluster database file. This is the most common option used with FlexRay. The cluster within the FIBEX database file contains all required properties to configure the interface. For CANdb files, although the file itself does not specify a CAN baud rate, you provide this when you add an alias to the file within NI-XNET. For LIN, the LDF file format already specifies the baud rate. : Call XNET Database Create • Nonempty in-memory database Object.vi to create a cluster within the in-memory database, use the 4-61 © National Instruments NI-XNET Hardware and Software Manual

127 Chapter 4 NI-XNET API for LabVIEW—XNET Cr eate Session (Frame Input Stream).vi XNET Cluster property node to set properties (such as baud rate), then wire from the Cluster node to this cluster. cluster . A subordinate session • Subordinate : Wire in :subordinate: of uses the cluster and interface confi guration from other sessions. For example, you may have a test appl ication with which the end user specifies the database file, cluster, and signals to read/write. You also have a second application with wh ich you want to log all received frames (input stream), but that app lication does not specify a database. You run this second application using a subordinate session, meaning start the interface, bu t depends on the primary it does not configure or test application. For a subordinat e session, start and stop of the interface (using XNET Start.vi ) is ignored. The subordinate session reads frames only when another nonsubordinate session starts the interface. interface is the XNET Interface to use for this session. error in is the error cluster input (refer to Error Handling ). Outputs session out is the created session. is the error cluster output (refer to ). Error Handling error out 4-62 NI-XNET Hardware and Software Manual ni.com

128 Chapter 4 NI-XNET API for LabVIEW—XNET Create Session (PDU Input Queued).vi XNET Create Session (PDU Input Queued).vi Purpose Creates an XNET session at run time for the Frame I nput Queued Mode. This selection uses a PDU instead of a fr ame, but otherwise it is the same as XNET Create XNET Read.vi . You read PDU data using the Session (Frame Input Queued).vi frame selections. The payload in each frame value contains the PDU’ s data, not the entire frame. XNET Create Session (PDU Input Single Point).vi Purpose Creates an XNET session at run time for the Frame Input Single-Point Mode. This selection uses one or more PDUs instead of frames, but otherwise it is the same as XNET Create Session (Frame Input Single-Point).vi . You read PDU data using the XNET e value contains the PDU’s data, not the frame selections. The payload in each fram Read.vi entire frame. 4-63 © National Instruments NI-XNET Hardware and Software Manual

129 Chapter 4 Output Queued).vi NI-XNET API for LabVIEW—XNET Cr eate Session (Frame XNET Create Session (F rame Output Queued).vi Purpose Creates an XNET session at run time for the Frame Output Queued Mode . Format Inputs frame mode supports only one frame per is the XNET Frame to write. This session. Your database specifies this frame. interface is the XNET Interface to use for this session. Error Handling error in is the error cluster input (refer to ). Outputs session out is the created session. ). is the error cluster output (refer to Error Handling error out 4-64 NI-XNET Hardware and Software Manual ni.com

130 Chapter 4 NI-XNET API for LabVIEW—XNET Creat e Session (Frame Output Single-Point).vi Output Single-Point).vi XNET Create Session (Frame Purpose Creates an XNET session at run time for the Frame Output Single-Point Mode . Format Inputs is the array of XNET Frames to write. Your database specifies frame list these frames. interface is the XNET Interface to use for this session. Error Handling error in is the error cluster input (refer to ). Outputs session out is the created session. is the error cluster output (refer to ). Error Handling error out 4-65 © National Instruments NI-XNET Hardware and Software Manual

131 Chapter 4 eate Session (Frame Output Stream).vi NI-XNET API for LabVIEW—XNET Cr rame Output Stream).vi XNET Create Session (F Purpose Creates an XNET session at run time for the . Frame Output Stream Mode Note This instance is supported for CAN and LIN only (not FlexRay). Format Inputs to use for interface configuration. cluster is the XNET Cluster I/O Name The default value is , the in-memory database. :memory: There are four options: • Empty in-memory database : cluster is unwired, and the in-memory database is empty ( XNET Database Create Object.vi is not used). u must set the XNET Session After you create the session, yo property using a Session node. You must set the Interface:Baud Rate CAN or LIN baud rate prior to starting the session. • Pre-defined in-memory database: Pass in special in-memory databases :can_fd: and :can_fd_brs:, as the cluster ( XNET Database Create Object.vi is not used). These databases are similar to the empty in-memory database (:memory:), but configure the cluster in either CAN FD or CAN FD+BRS mode, respectively. After you create and the session, you must set the XNET Session Interface:Baud Rate Interface:CAN:FD Baud Rate properties using a Session node. You must set these baud rates prior to starting the session. specifies a cluster within a • Cluster within database file : cluster database file. For CANdb files, although the file itself does not specify a CAN baud rate, you provide this when you add an alias to the file within NI-XNET. • Nonempty in-memory databas e: Call XNET Database Create Object.vi to create a cluster within the in-memory database, use the Cluster node to set properties (such as baud rate), then wire from the Cluster node to this cluster. 4-66 NI-XNET Hardware and Software Manual ni.com

132 Chapter 4 eate Session (Frame Output Stream).vi NI-XNET API for LabVIEW—XNET Cr interface is the XNET Interface to use for this session. is the error cluster input (refer to error in ). Error Handling Outputs session out is the created session. is the error cluster output (refer to ). error out Error Handling 4-67 © National Instruments NI-XNET Hardware and Software Manual

133 Chapter 4 NI-XNET API for LabVIEW—XNET Cr eate Session (PDU Output Queued).vi XNET Create Session (P DU Output Queued).vi Purpose Creates an XNET session at run time for the Frame Outp ut Queued Mode. This selection uses a PDU instead of a fr ame, but otherwise it is the same as XNET Create frame XNET Write.vi . You write PDU data using the Session (Frame Ou tput Queued).vi selections. The payload in each frame value contains the PDU’ s data, not the entire frame. XNET Create Session (PDU Output Single-Point).vi Purpose Creates an XNET session at run time fo r the Frame Output Single-Point Mode. This selection uses a PDU instead of a fr ame, but otherwise it is the same as XNET Create Session (Frame Output Single-Point).vi . You write PDU data using the XNET Write.vi each frame value contains the PDU’s data, not the entire frame selections. The payload in frame. 4-68 NI-XNET Hardware and Software Manual ni.com

134 Chapter 4 NI-XNET API for LabVIEW— XNET Create Session (Generic).vi XNET Create Session (Generic).vi Purpose Creates an XNET session at run XNET I/O Names . This VI is time using strings instead of for advanced applications , when you need to store the configuration as strings (such as within a text file). Format Inputs provides the list of signal s or frames for the session. list list syntax depends on the mode: The Mode list Syntax Signal Input list contains one or more XNET Signal names. Single-Point, If more than one name is provided, a comma must separate each name. Each name must use the Signal Output or Single-Point syntax as specified for the I/O name (new line and not included). list Signal Input contains one or more XNET Signal names. Wave fo r m , If more than one name is provided, a comma must Signal Output separate each name. Each name must use the Wave fo r m or syntax as specified for the I/O name (new line and not included). 4-69 © National Instruments NI-XNET Hardware and Software Manual

135 Chapter 4 XNET Create Session (Generic).vi NI-XNET API for LabVIEW— Mode list Syntax list contains one or more XNET Signal names. Signal Input If more than one name is provided, a comma must XY, Signal separate each name. Each name must use the Output XY or syntax as specified for not the I/O name (new line and included). Frame Input is empty (unwired). list Stream, Frame Output Stream Frame Input contains only one XNET Frame name. Only list one name is supported. The frame name must use Queued, syntax as specified for the I/O name the Frame Output (new line and Queued not included). Frame Input contains one or more XNET Frame names. list If more than one name is provided, a comma must Single-Point, Frame Output separate each name. The frame name must use the syntax as specified for the I/O name Single-Point not included). (new line and mode is the session mode. is the XNET Interface to use for this session. interface is the XNET Database to use for interface configuration. The database syntax specified for the database name must use the or I/O name. The default value is :memory: , the in-memory database. cluster is the XNET Cluster to use for in terface configurati on. The cluster . name must use the syntax specified for the I/O name ( prefix not included). error in is the error cluster input (refer to Error Handling ). Outputs session out is the created session. Error Handling error out is the error cluster output (refer to ). 4-70 NI-XNET Hardware and Software Manual ni.com

136 Chapter 4 NI-XNET API for LabV IEW—XNET Create Session (Signal Input Single-Point).vi nal Input Single-Point).vi XNET Create Session (Sig Purpose Creates an XNET session at run time for the Signal Input Single-Point Mode . Format Inputs is the array of XNET Signals to read. These signals are specified signal list in your database and describe the values encoded in one or more frames, or they are trigger signals for frames. For more information about trigger signals, refer to Signal Input Single-Point Mode . is the XNET Interface to use for this session. interface error in is the error cluster input (refer to Error Handling ). Outputs session out is the created session. is the error cluster output (refer to error out ). Error Handling 4-71 © National Instruments NI-XNET Hardware and Software Manual

137 Chapter 4 NI-XNET API for LabVIEW—XNET Cr eate Session (Signal Input Waveform).vi XNET Create Session (S ignal Input Waveform).vi Purpose Creates an XNET session at run time for the Signal Input Waveform Mode . Format Inputs signal list read. These signals are specified is the array of XNET Signals to in your database and describe the values encoded in one or more frames. interface is the XNET Interface to use for this session. Error Handling error in is the error cluster input (refer to ). Outputs session out is the created session. ). is the error cluster output (refer to Error Handling error out 4-72 NI-XNET Hardware and Software Manual ni.com

138 Chapter 4 NI-XNET API for LabVIEW—XNET Create Session (Signal Input XY).vi (Signal Input XY).vi XNET Create Session Purpose Creates an XNET session at run time for the Signal Input XY Mode . Format Inputs signal list read. These signals are specified is the array of XNET Signals to in your database and describe the values encoded in one or more frames. interface is the XNET Interface to use for this session. Error Handling error in is the error cluster input (refer to ). Outputs session out is the created session. is the error cluster output (refer to ). Error Handling error out 4-73 © National Instruments NI-XNET Hardware and Software Manual

139 Chapter 4 NI-XNET API for LabVIEW—XNET Create Session (Signal Output Single-Point).vi XNET Create Session (Signa l Output Single-Point).vi Purpose Creates an XNET session at run time for the . Signal Output Single-Point Mode Format Inputs write. These signals are specified signal list is the array of XNET Signals to in your database and describe the values encoded in one or more frames, or they are trigger signals for frames. For information about trigger signals, refer to Signal Output Single-Point Mode . is the XNET Interface to use for this session. interface is the error cluster input (refer to error in Error Handling ). Outputs session out is the created session. is the error cluster output (refer to Error Handling ). error out 4-74 NI-XNET Hardware and Software Manual ni.com

140 Chapter 4 NI-XNET API for LabVIEW—XNET Cr eate Session (Signal Output Waveform).vi nal Output Waveform).vi XNET Create Session (Sig Purpose Creates an XNET session at run time for the Signal Output Waveform Mode . Format Inputs signal list write. These signals are specified is the array of XNET Signals to in your database and describe the values encoded in one or more frames. interface is the XNET Interface to use for this session. Error Handling error in is the error cluster input (refer to ). Outputs session out is the created session. is the error cluster output (refer to ). Error Handling error out 4-75 © National Instruments NI-XNET Hardware and Software Manual

141 Chapter 4 NI-XNET API for LabVIEW—XNET Create Session (Signal Output XY).vi XNET Create Session (Signal Output XY).vi Purpose Creates an XNET session at run time for the Signal Output XY Mode . Format Inputs signal list write. These signals are specified is the array of XNET Signals to in your database and describe the values encoded in one or more frames. interface is the XNET Interface to use for this session. Error Handling error in is the error cluster input (refer to ). Outputs session out is the created session. ). is the error cluster output (refer to Error Handling error out 4-76 NI-XNET Hardware and Software Manual ni.com

142 Chapter 4 W—XNET Session Property Node NI-XNET API for LabVIE XNET Session Property Node Format Description . XNET Session I/O Name Property node used to read/write properties for an to change direction between read and write. Pull down this node to add properties. Right-click Right-click each property name to creat e a constant, control, or indicator. For help on a specific property, open the LabVIEW context help window () and move your cursor over the property name. For more information about LabVIEW property nodes, open the main LabVIEW help (select topic in Property Nodes menu) and look for the Search the LabVIEW Help from the Help the index. 4-77 © National Instruments NI-XNET Hardware and Software Manual

143 Chapter 4 LabVIEW—Interface Properties NI-XNET API for Interface Properties terface and not the sessi Properties in the Interface category apply to the in on. If more than one session exists for the interface, changing an interface property af fects all the sessions. CAN Interface Properties This category includes CAN- specific interface properties. ni.com 4-78 NI-XNET Hardware and Software Manual

144 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:CAN:External Transceiver Config Data Type Direction Required? Default 0x00000007 Write Only No Property Class XNET Session Short Name Intf.CAN.ExtTcvrCfg Description This property allows you to configure XS series CAN hardware to communicate properly your XS series CAN hardware has five lines with your external transceiver. The connector on th your transceiver. for communicating wi Purpose Direction Line Data received from the CAN bus. In Ext_RX Ext_TX Out Data to transmit on the CAN bus. Out Generic output used to configure the transceiver Output0 mode. Output1 Out Generic output used to configure the transceiver mode. NERR Input to connect to the nERR pin of your transceiver In the transceiver to the to route status back from hardware. The Ext_RX and Ext_TX lines ar e self explanatory and provide for the transfer of CAN data ee lines are for configuring the transceiver and to and from the transceiver. The remaining thr all transceivers use all pins. Typically, a retrieving status from the transceivers. Not transceiver has one or two lines that can conf igure the transceiver mode. The NI-XNET driver natively supports five transceiver modes: Normal, Sleep, Single Wire Wakeup, Single Wire High Speed, and Power-On. This property co nfigures how the NI-XNET driver sets the outputs of your external transceiver for each mode. NI-XNET Hardware and Software Manual 4-79 National Instruments ©

145 Chapter 4 NI-XNET API for LabVIEW—Interface Properties The configuration is in the form of a u32 writte n as a bitmask. The u32 bitmask is defined as: 30..15 14..12 5..3 2..0 8..6 11..9 31 SWWakeup PowerOn Reserved nERR Sleep Normal SWHighSpeed Connected Configuration Configuration Configuration Configuration Configuration Where each configuration is a 3-bit value defined as: 0 2 1 Output0 Value Output1 Value State Supported Interface:CAN:Transceiver State ceiver state. Based on the The property changes the trans ted, the configuration determines how the two transceiver configuration, if the state is suppor pins are set. If the state is not supported, an erro r is returned, because you tried to set an invalid support a Normal state, so the State Supported configuration. Note that all transceivers must bit for that configuration is ignored. Other internal state changes may occur. For example, if you put the transceiver to sleep and a tically is changed to the normal state. For remote wakeup occurs, the transceiver automa r the transceiver state, refer to information about the state machine fo CAN Transceiver State Machine in Additional Topics . If nERR Connected is set, the nERR pin into the connector determines a transceiver error. It is active low, meaning a value of 0 on this pin indicates an error. A value of 1 indicates no monitors this line and reports its status via error. If this line is connected, the NI-XNET driver the Transceiver Error field of XNET Read (State CAN Comm).vi . Examples connect Output0 to the nSTB pin and TJA1041 (HS) : To connect to the TJA1041 transceiver, Output1 to the EN pin. The TJA1041 does have an nERR pin, so that should be connected to the nERR input. The TJA1041 supports a power-on state, a sleep state, and a normal state. As this is not a single wire transceiver, it does not support any single wire state. For normal operation, the TJA1041 uses a 1 for both nSTB and EN. For sleep, the TJA1041 uses the standby mode, which uses a 0 for both nSTB and EN. For power-on, the TJA1041 uses a 1 for nSTB and a 0 for EN. The final configuration is 0x80005027. : You can connect and configure the TJA1054 identically to the TJA1041. TJA1054 (LS) AU5790 (SW) : To connect to the AU5790 transceiver, connect Output0 to the nSTB pin and Output1 to the EN pin. The AU5790 does not support any transceiver status, so you do not ports all states. For normal operation, the need to connect the nERR pin. The AU5790 sup AU5790 uses a 1 for both nSTB and EN. For sleep, the AU5790 uses a 0 for both nSTB and EN. For Single Wire Wakeup, the AU5790 requires nSTB to be a 0 and EN to be a 1. For Single Wire High-Speed, the AU5790 requires nSTB to be a 1, and EN to be a 0. For ni.com 4-80 NI-XNET Hardware and Software Manual

146 Chapter 4 NI-XNET API for LabVIEW—Interface Properties power-on, the sleep state is used so ther e is less interference on the bus. The final configuration is 0x00004DA7. © National Instruments 4-81 NI-XNET Hardware and Software Manual

147 Chapter 4 LabVIEW—Interface Properties NI-XNET API for Interface:CAN:FD Baud Rate Data Type Required? Default Direction No 0 Read/Write Property Class XNET Session Short Name Intf.CAN.FdBaudRate Description Note You can modify this property only when the interface is stopped. The Interface:CAN:FD Baud Rate property sets the fast data baud rate for CAN FD + BRS . The default value for this interface prope rty is the same as the cluster’s FD CAN:I/O Mode baud rate in the database. Your application can set this interface FD baud rate to override the value in the database. When the upper nibble (0xF0000000) is clear, this is a numeric baud rate (for example, 500000). NI-XNET CAN hardware currently accepts th e following numeric baud rates: 200000, 250000, 400000, 500000, 800000, 1000000, 1250000, 1600000, 2000000, 2500000, 4000000, 5000000, and 8000000. smit at the requested rate. If you attempt Not all CAN transceivers are rated to tran Note lified rate, XNET Start returns a warning. to use a rate that exceeds the transceiver’s qua Chapter 3, NI-XNET Hardware Overview , describes the CAN transceivers’ limitations. When the upper nibble is set to 0x8 (that is, 0x80000000), the remaining bits provide fields for more custom CAN communication baud rate programming. The fields are shown in the following table: 31..28 15...10 27..26 25..24 23..20 19..16 9..8 7..0 Normal b0000 Baud Rate (200 k–8 M) TSEG1 Tq (25–800) Res Custom b1000 Res SJW TSEG2 (0–3) (0–7) (1–15) 4-82 NI-XNET Hardware and Software Manual ni.com

148 Chapter 4 NI-XNET API for LabVIEW—Interface Properties (Re-)Synchronization Jump Width (SJW) • Valid programmed values are 0–3. – – The actual hardware interpretation of this value is one more than the programmed value. • Time Segment 2 (TSEG2) is the time segment after the sample point. – Valid programmed values are 0–7. specification, Bosch’s CAN with Flexible Data-Rate This is the Phase_Seg2(D) from – version 1.0. The actual hardware interpretation of this value is one more than the programmed – value. • Time Segment 1 (TSEG1) is the time segment before the sample point. – Valid programmed values are 1–15. – This is the combination of Prop_Seg(D) and Phase_Seg1(D) from Bosch’s CAN with Flexible Data-Rate specification, version 1.0. – The actual hardware interpretation of this value is one more than the programmed value. Time quantum (Tq) is used to • program the baud rate prescaler. – 0, in increments of 25 ns. Valid programmed values are 25–80 4-83 © National Instruments NI-XNET Hardware and Software Manual

149 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:CAN:I/O Mode Data Type Direction Required? Default CAN:I/O Mode Same as XNET Cluster Read Only — Property Class XNET Session Short Name Intf.CAN.IoMode Description This property indicates the I/O Mode the interface is using. It is a ring of three values, as described in the following table: Enumeration Va l u e Meaning CAN This is the default CAN 2.0 A/B standard I/O mode 0 as defined in ISO 11898-1:2003. A fixed baud rate is used for transfer, and the payload length is limited to 8 bytes. CAN FD CAN as specified in the This is the CAN FD mode 1 specification, version 1.0. with Flexible Data-Rate Payload lengths are allowed up to 64 bytes, but they fixed baud rate (defined are transmitted at a single Baud Rate by XNET Cluster Interface:Baud or Rate .) CAN as specified in the This is the CAN FD mode 2 CAN FD + BRS with Flexible Data-Rate specification, version 1.0, with the optional Baud Rate Switching enabled. The same payload lengths as CAN FD mode are allowed; additionally, the data portion of the CAN frame is transferred at a different (higher) baud rate CAN:FD Baud Rate (defined by XNET Cluster or Interface:CAN:FD Baud Rate ). The value is initialized from the database clus ter when the session is created and cannot be changed later. However, you can transmit standa rd CAN frames on a CAN FD network. Refer Interface:CAN:Transmit I/O Mode property. to the NI-XNET Hardware and Software Manual 4-84 ni.com

150 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:CAN:Listen Only? Direction Data Type Required? Default Read/Write No False Property Class XNET Session Short Name Intf.CAN.LstnOnly? Description Note You can modify this property only when the interface is stopped. rface transmits any information The Listen Only? property c onfigures whether the CAN inte to the CAN bus. the interface can transmit CAN frames and acknowledge received When this property is false, CAN frames. When this property is true, the interface can neither transmit CAN frames nor acknowledge a ive monitoring of netw ork traffic, which can received CAN frame. The true value enables pass be useful for debugging scenarios when you do not want to interfere with a communicating network cluster. 4-85 © National Instruments NI-XNET Hardware and Software Manual

151 Chapter 4 LabVIEW—Interface Properties NI-XNET API for Interface:CAN:Pending Transmit Order Data Type Direction Required? Default Read/Write No As Submitted Property Class XNET Session Short Name Intf.CAN.PendTxOrder Description Note You can modify this property only when the interface is stopped. Note Setting this property causes the internal queue to be flushed. If you start a session, queue frames, and then stop the session and ch ange this mode, some frames may be lost. Set this property to the desired value once; do not constantly change modes. terface manages the internal The Pending Transmit Order propert y configures how the CAN in re to transmit at the same time. NI-XNET queue of frames. More than one frame may desi stores the frames in an internal queue and tr ansmits them onto the CAN bus when the bus is idle. This property modifies how NI-XNET handles this queue of frames. The following table lists the accepted values: Enumeration Va l u e As Submitted 0 By Identifier 1 itted, frames are transmitt When you configure this property to be As Subm ed in the order that reordering of any frames, and a higher priority they were submitted into the queue. There is no frame may be delayed due to the transmission or retransmission of a previously submitted frame. However, this mode has the highest performance. entifier, frames with the highest priority When you configure this property to be By Id priority queue sorted identifier (lower CAN ID value) transmit first. Th e frames are stored in a by ID. If a frame currently bein g transmitted requires retransmission (for example, it lost priority frame is queued in the meantime, s error), and a higher arbitration or failed with a bu 4-86 NI-XNET Hardware and Software Manual ni.com

152 Chapter 4 NI-XNET API for LabVIEW—Interface Properties the lower priority frame is not immediately retried, but the higher priority frame is transmitted instead. In this mode, you can emulate multiple ECUs and still see a behavior similar to a real bus in that the highest priority message is transmitted on the bus. This mode may be slower in performance (possible delays between transm issions as the queue is re-evaluated), and lower priority messages may be delayed indefinitely due to frequent high-priority messages. National Instruments 4-87 NI-XNET Hardware and Software Manual ©

153 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:CAN:Single Shot Transmit? Data Type Direction Required? Default False Read/Write No Property Class XNET Session Short Name Intf.CAN.SingShot? Description You can modify this property only when the interface is stopped. Note Setting this property causes the internal queue to be flushed. If you start a session, Note queue frames, and then stop the session and ch ange this mode, some frames may be lost. Set this property to the desired value once; do not constantly change modes. The Single Shot Transmit? pr operty configures whether the CAN interface retries failed transmissions. When this property is false, failed transm issions retry as specified by the CAN protocol (ISO 11898–1, 6.11 Automatic Retransmission ). If a CAN frame is not transmitted successfully, the interface attempts to retransmit the frame as soon as the bus is idle again. This retransmit process continues until the frame is successfully transmitted. a CAN frame is not transmitted ed transmissions do not retry. If When this property is true, fail successfully, no further transmissions are attempted. 4-88 NI-XNET Hardware and Software Manual ni.com

154 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:CAN:Termination Data Type Direction Required? Default Read/Write No Off (0) Property Class XNET Session Short Name Intf.CAN.Term Description You can modify this property only when the interface is stopped. Note This property does not take eff ect until the interface is started. The Termination property configures the onboa rd termination of the NI-XNET interface CAN connector (port). The enumeration is generic and supports two values: Off and On. However, different CAN hardware has different terminat ion requirements, and the Off and On values have different meanings, as described below. High-Speed CAN High-Speed CAN networks are typi lf instead of within a node. cally terminated on the bus itse However, NI-XNET allows you to configure termination within the node to simplify testing. If your bus already has the correct amount of te rmination, leave this property in the default state of Off. However, if you require termination, set this property to On. Description Meaning Va l u e Off Disabled Termination is disabled. Termination (120  ) is enabled. On Enabled Low-Speed/Fault-Tolerant CAN Every node on a Low-Speed CAN network requires termination for each CAN data line (CAN_H and CAN_L). This configuration allows the Low-Speed/Fault-Tolerant CAN port to for more information about provide fault detection and recovery. Refer to Termination low-speed termination. In general, if the existing network has an overall network termination or less, turn on termination to enable the 4.99 k  option. Otherwise, you should of 125  option.  select the default 1.11 k 4-89 © National Instruments NI-XNET Hardware and Software Manual

155 Chapter 4 LabVIEW—Interface Properties NI-XNET API for Description Meaning Va l u e  . Off 1.11 k  Termination is set to 1.11 k On .  Termination is set to 4.99 k  4.99 k Single Wire CAN The ISO standard requires single wire transceivers to have a 9.09 k resistor, and no  additional configuration is supported. NI-XNET Hardware and Software Manual 4-90 ni.com

156 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:CAN:Transceiver State Required? Default Data Type Direction Read/Write No Normal (0) Property Class XNET Session Short Name Intf.CAN.TcvrState Description The Transceiver State property configures th e CAN transceiver and CAN controller modes. The transceiver state controls whether the trans ceiver is asleep or communicating, as well as configuring other special modes. The fo llowing table lists the accepted values. Va l u e Enumeration 0 Normal Sleep 1 Single Wire Wakeup 2 Single Wire High-Speed 3 Normal transceiver is in the This state sets the transceiver to normal co mmunication mode. If the Sleep mode, this performs a local wakeup of the transceiver and CAN controller chip. Sleep This state sets the transceiver and CAN controller chip to Sleep (or standby) mode. You can set the interface to Sleep mode only while the in terface is communicating. If the interface has ver to Sleep mode returns an error. not been started, setting the transcei Before going to sleep, all pending transmissions are transmitted onto the CAN bus. Once all terface and transceiver go into Sleep (or standby) pending frames have been transmitted, the in rther communication is not possible until a mode. Once the interface enters Sleep mode, fu wakeup occurs. The transceiver and CAN contro ller wake from Sleep mode when either a local wakeup or remote wakeup occurs. NI-XNET Hardware and Software Manual 4-91 National Instruments ©

157 Chapter 4 LabVIEW—Interface Properties NI-XNET API for the transceiver state to either Normal or A local wakeup occurs when the application sets Single Wire Wakeup. a remote node transmits a C AN frame (referred to as the A remote wakeup occurs when wakeup frame). The wakeup frame wakes up the NI-XNET interface transceiver and CAN controller chip. The CAN controller chip does not receive or acknowle dge the wakeup frame. After detecting the wakeup frame and idle bu s, the CAN interface enters Normal mode. When the local or remote wakeup occurs, frame transmissions resume from the point at which the original Sleep mode was set. You can use XNET Read (State CAN Comm).vi to detect when a wakeup occurs. To suspend the application while waiting for the remote wakeup, use XNET Wait (CAN Remote Wakeup).vi . Single Wire Wakeup sceivers, the node that For a remote wakeup to occur for Single Wire tran transmits the wakeup frame first must place the network into the Si ngle Wire Wakeup Transmission mode by asserting a higher voltage. This state sets a Single Wire transceiver into the Single Wire Wakeup Transmission mode, which forces the Single Wire transceiver to drive a higher voltage level on the network to wake up all sleeping nodes. Other than this higher voltage, this mode is similar to Normal mode. CAN frames can be recei ved and transmitted normally. If you are not using a Single Wire transceiver, settin g this state returns an error. If your current mode is Single Wire High-Speed, setting this mode returns an error because you are not allowed to wake up the bus in high-speed mode. The application controls the timing of how long the wakeup voltage is driven. The application typically changes to Single Wire Wakeup mode, transmits a single wakeup frame, and then returns to Normal mode. Single Wire High-Speed This state sets a Single Wire transceiver into Single Wire High-Speed Communication mode. Wire transceiver, setting this state returns an error. If you are not using a Single Single Wire High-Speed Communication mode disables the transceiver’s internal waveshaping function, allowing the SAE J2411 High Speed baud rate of 83.333 kbytes/s to be used. The disadvantage versus Single Wire Normal Communication mode, which only allows the SAE J2411 baud rate of 33.333 kbyt es/s, is degraded EMC performance. Other this mode is similar to No rmal mode. CAN frames can be than the disabled waveshaping, received and transmitted normally. 4-92 NI-XNET Hardware and Software Manual ni.com

158 Chapter 4 NI-XNET API for LabVIEW—Interface Properties This mode has no relationship to High-Speed transceivers. It is merely a higher speed mode of the Single Wire transceiver, typically used to download data when the onboard network is attached to an offboard tester ECU. The Single Wire transceiver does not support use of this mode in conjunction with Sleep mode. For example, a remote wakeup cannot transition from sleep to this Single Wire High-Speed mode. Therefore, se tting the mode to Sleep from Single Wire High-Speed mode returns an error. 4-93 NI-XNET Hardware and Software Manual National Instruments ©

159 Chapter 4 LabVIEW—Interface Properties NI-XNET API for Interface:CAN:Transceiver Type Data Type Direction Required? Default Read/Write No High-Speed (0) for High-Speed and XS Hardware; Low-Speed (1) for Low-Speed Hardware Property Class XNET Session Short Name Intf.CAN.TcvrType Description Notes You can modify this property on ly when the interface is stopped. For XNET hardware that provides a software-s electable transceiver, the Transceiver Type sceiver type. Use the XNET Interface property allows you to set the tran CAN.Transceiver property to determine whether your ha rdware supports a software-selectable Capability transceiver. You also can use this property to determine the currently configur ed transceiver type. The following table lists the accepted values: Enumeration Va l u e High-Speed (HS) 0 Low-Speed (LS) 1 2 Single Wire (SW) External (Ext) 3 Disconnect (Disc) 4 The default value for this property depends on your type of hardware. If you have e hardware value. If you have hardware that fixed-personality hardware, the default value is th supports software-selectable transceivers, the default is High-Speed. 4-94 NI-XNET Hardware and Software Manual ni.com

160 Chapter 4 NI-XNET API for LabVIEW—Interface Properties This attribute uses the following values: High-Speed This configuration enables the ansceiver supports baud rates High-Speed transceiver. This tr of 40 kbaud to 1 Mbaud. When using a High- Speed transceiver, you also can communicate NI-XNET Hardware Overview , to determine which with a CAN FD bus. Refer to Chapter 3, CAN FD baud rates are supported. Low-Speed/Fault-Tolerant This configuration enables th e Low-Speed/Fault-Tolerant tran sceiver. This transceiver supports baud rates of 40–125 kbaud. Single Wire This configuration enables the Single Wire transceiver. This transceiver supports baud rates of 33.333 kbaud and 83.333 kbaud. External This configuration allows you to use an extern al transceiver to connect to your CAN bus. Refer to Interface:CAN:External Transceiver Config for more information. Disconnect e CAN controller chip from the connector. You This configuration allows you to disconnect th can use this value when you physically change the external transceiver. 4-95 © National Instruments NI-XNET Hardware and Software Manual

161 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:CAN:Transmit I/O Mode Data Type Direction Required? Default Interface:CAN:I/O Mode Read/Write No Same as Property Class XNET Session Short Name Intf.CAN.TxIoMode Description This property specifies the I/O Mode the inte rface uses when transmitting a CAN frame. By default, it is the same as the XNET Cluster CAN:I/O Mode property. However, even if the interface is in CAN FD (+ BRS) mode, you can fo rce it to transmit fr ames in the standard CAN format. For this purpose, set this property to CAN. Note This property affect . Even if you set the transmit s only the transmission of frames I/O mode to CAN, the interface still can recei ve frames in FD modes (if the XNET Cluster CAN:I/O Mode property is configured in an FD mode). CAN:I/O Mode The Transmit I/O mode may not exceed the mode set by the XNET Cluster property. 4-96 NI-XNET Hardware and Software Manual ni.com

162 Chapter 4 NI-XNET API for LabVIEW—Interface Properties FlexRay Interface Properties These properties are calculated based on constraints in the FlexRay Protocol Specification . To calculate these properties, the constraints use cluster settings and knowledge of the oscillator that the FlexRay interface uses. tically calculates these properties, and they At Create Session time, the XNET driver automa are passed down to the hardware. However, you can use the XNET property node to change these settings. Note Changing the interface properties can affect the integration an d communication of the XNET FlexRay interface with the cluster. cepted Startup Range Interface:FlexRay:Ac Direction Data Type Required? Default No Calculated from Cluster Settings Read/Write Property Class XNET Session Short Name Intf.FlexRay.AccStartRng Description Range of measure clock deviation allowed for st artup frames during node integration. This property corresponds to the pdAcceptedStartupRange node parameter in the FlexRay Protocol Specification . The range for this property is 0–1875 MT. You can overwrite the default value by writing a value within the specified range to this for more information). Session States e FlexRay interface (refer to property prior to starting th 4-97 © National Instruments NI-XNET Hardware and Software Manual

163 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:FlexRay:Allo w Halt Due To Clock? Required? Default Direction Data Type Read/Write No False Property Class XNET Session Short Name Intf.FlexRay.AlwHltClk? Description Controls the FlexRay interface transition to the POC: halt state due to clock synchronization errors. If set to true, the node can transition to the POC: halt state. If set to false, the node does not transition to the POC: halt state and remains in the POC: normal passive state, allowing for self recovery. This property corresponds to the pAllowHaltDueToClock node parameter in the FlexRay Protocol Specification . The property is a Boolean flag. The default value of this property is false. You can overwrite the default value by writing a value within the specified range to this property prior to starting th e FlexRay interface (refer to Session States for more information). for more information about the POC: halt XNET Read (State FlexRay Comm).vi Refer to and POC: normal passive states. 4-98 NI-XNET Hardware and Software Manual ni.com

164 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:FlexRay:Allo w Passive to Active Data Type Required? Default Direction Read/Write No 0 Property Class XNET Session Short Name Intf.FlexRay.AlwPassAct Description Number of consecutive even/odd cycle pairs th at must have valid clock correction terms before the FlexRay node can transition from the POC: normal-passive to the POC: normal-active state. If set to zero, the node cannot transition from POC: normal-passive to POC: normal-active. This property corresponds to the pAllowPassiveToActive node parameter in the FlexRay Protocol Specification . The property is expressed as the number of even/odd cycle pairs, with values of 0–31. The default value of this property is zero. You can overwrite the default value by writing a value within the specified range to this property prior to starting th e FlexRay interface (refer to Session States for more information). for more information about the POC: XNET Read (State FlexRay Comm).vi Refer to rmal-passive states. normal-active and POC: no 4-99 © National Instruments NI-XNET Hardware and Software Manual

165 Chapter 4 LabVIEW—Interface Properties NI-XNET API for Interface:FlexRay:Auto Asleep When Stopped Data Type Direction Required? Default Read/Write No Calculated from Cluster Settings Property Class XNET Session Short Name Intf.FlexRay.AutoAslpStp Description This property indicates whet her the FlexRay interface (nod e) automatically places the FlexRay transceiver and controller into sleep wh en the interface is stop ped. The default value of this property is False, and you must hand le the wakeup/sleep processing manually using property. the XNET Session Interface:FlexRay:Sleep When this property is called with the value True while the interface is asleep, the interface is put to sleep immediately. When th value False, the interface is set is property is called with the to a local awake state immediately. If the interface is asleep when XNET Start.vi is called, the FlexRay interface waits for a wakeup pattern on the bus before transitioning out of the POC:READY state. To initiate a bus wakeup, you can set the XNET Session Interface:FlexRay:Sleep property with a value of Remote Wake. After XNET Stop.vi is called, if this property is Tr ue, the FlexRay interface automatically goes back to sleep to be ready to handle the wakeup on subsequent XNET Start.vi calls. When this property is False when XNET Stop.vi is called, the FlexRay interface remains in the sleep state it was in prior to the XNET Stop.vi call. You can overwrite the default value by writing this property prior to starting the FlexRay for more information). interface (refer to Session States 4-100 NI-XNET Hardware and Software Manual ni.com

166 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:FlexRay:Cluster Drift Damping Direction Data Type Required? Default Read/Write No Calculated from Cluster Settings Property Class XNET Session Short Name Intf.FlexRay.ClstDriftDmp Description Local cluster drift damping factor used for rate correction. pAllowPassiveToActive node parameter in the FlexRay This property corresponds to the . Protocol Specification The range for the property is 0–20 MT. The cluster drift damping property should be configured in such a way that the damping values in all nodes within the same clus ter have approximately the same duration. You can overwrite the default value by writing a value within the specified range to this e FlexRay interface (refer to property prior to starting th for more information). Session States 4-101 © National Instruments NI-XNET Hardware and Software Manual

167 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:FlexRay:Coldstart? Direction Required? Default Data Type Read No False Property Class XNET Session Short Name Intf.FlexRay.Coldstart? Description This property specifies whether the Flex Ray interface operates as a coldstart node on the cluster. This property is read on ly and calculated from the XNET Session property. If the KeySlot Iden tifier is 0 (invalid slot Interface:FlexRay:Key Slot Identifier identifier), the XNET FlexRay inte rface does not act as a coldstar t node, and this property is false. If the KeySlot Identifier is 1 or more , the XNET FlexRay interface transmits a startup frame from that slot, and the Coldstart? property is true. oolean flag (true/false). This property returns a B The default value of this property is false. 4-102 NI-XNET Hardware and Software Manual ni.com

168 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:FlexRay: Connected Channels Required? Default Direction Data Type Read/Write No Calculated from Cluster Settings Property Class XNET Session Short Name Intf.FlexRay.ConnectedChs Description This property specifies the channel(s) that the FlexRay interface (node) is physically this property is connected to all channels available on the connected to. The default value of cluster. However, if you are using a node connected to only one channel of a multichannel cluster that uses wakeup, you must set the value properly. If you do not, your node may not wake up, as the wakeup pattern cannot be r eceived on a channel not physically connected. This property corresponds to the pChannels FlexRay Protocol node parameter in the Specification . The values supported for this property (enu meration) are A = 1, B = 2, and A and B = 3. You can overwrite the default value by writing this property prior to starting the FlexRay interface (refer to for more information). Session States 4-103 © National Instruments NI-XNET Hardware and Software Manual

169 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:FlexRay:Decoding Correction Data Type Direction Required? Default Read/Write No Calculated from Cluster Settings Property Class XNET Session Short Name Intf.FlexRay.DecCorr Description node uses to calculate the lue that the receiving FlexRay This property specifies the va int and secondary reference point. The clock difference between the primary time reference po synchronization algorithm uses the primary tim e reference and the sync frame’s expected arrival time to calculate and compensate for the node’s local clock deviation. This property corresponds to the pDecodingCorrection node parameter in the FlexRay Protocol Specification . The range for the property is 14–143 MT. You can overwrite the default value by writing a value within the specified range to this Session States for more information). e FlexRay interface (refer to property prior to starting th 4-104 NI-XNET Hardware and Software Manual ni.com

170 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:FlexRay:Dela y Compensation Ch A Required? Default Direction Data Type Read/Write No Calculated from Cluster Settings Property Class XNET Session Short Name Intf.FlexRay.DelayCompA Description This property specifies the valu e that the XNET FlexRay interface (node) uses to compensate s into account the assumed propagation delay up for reception delays on channel A. This take to the maximum allowed propagation delay ( cPropagationDelayMax ) for microticks in the 0.0125–0.05 range. In practice, you should apply the minimum of the propagation delays of all sync nodes. This property corresponds to the pDelayCompensation[A] node parameter in the FlexRay Protocol Specification . The property range is 0–200 MT. You can overwrite the default value by writing a value within the specified range to this property prior to starting th Session States e FlexRay interface (refer to for more information). 4-105 © National Instruments NI-XNET Hardware and Software Manual

171 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:FlexRay:Dela y Compensation Ch B Required? Default Data Type Direction Read/Write No Calculated from Cluster Settings Property Class XNET Session Short Name Intf.FlexRay.DelayCompB Description This property specifies the valu e that the XNET FlexRay interface (node) uses to compensate s into account the assumed propagation delay up for reception delays on channel B. This take to the maximum allowed propagation delay ( Propagation Delay Max ) for microticks in the 0.0125–0.05 range. In practice, you should apply the minimum of the propagation delays of all sync nodes. pDelayCompensation[B] This property corresponds to the node parameter in the FlexRay Protocol Specification . The property range is 0–200 MT. You can overwrite the default value by writing a value within the specified range to this for more information). Session States e FlexRay interface (refer to property prior to starting th 4-106 NI-XNET Hardware and Software Manual ni.com

172 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:FlexRay:Ke y Slot Identifier Required? Default Data Type Direction Read/Write No 0 Property Class XNET Session Short Name Intf.FlexRay.KeySlotID Description XNET FlexRay interface This property specifies the FlexRay slot nu mber from which the transmits a startup frame, during the proces s of integration with other cluster nodes. For a network (cluster) of FlexRay nodes to start up for communication, at least two nodes must transmit startup frames. If your application is designed to test only one external ECU, frame. If the one to transmit a startup you must configure the XNET FlexRay interface frame itself, you must use two XNET FlexRay external ECU does not transmit a startup interfaces for the test, each of whic h must transmit a startup frame. onfiguring the XNET FlexRay in terface as a coldstart node There are two methods for c (transmit startup frame). Output Session with Startup Frame ains a startup frame (or one of Create an output session that cont its signals). The XNET Frame FlexRay:Startup? property is true for a startup frame. If you use this method, this Key Slot tup frame. You do not write this Identifier property contains the id entifier property of that star property. Write this Key Slot Identifier Property ite to transmit a startup frame using that slot. This interface uses the identifier (slot) you wr Note If you create an output session that cont ains the startup frame, with the same Identifier property, the data you write to the identifier as that specified in the Key Slot session transmits in the frame. If you do not create an output sessi on that contains the startup frame, the interface transmit s a null frame for startup purposes. th an identifier that does not that contains a startup frame wi If you create an output session match the Key Slot Identifier pr operty, an error is returned. 4-107 © National Instruments NI-XNET Hardware and Software Manual

173 Chapter 4 LabVIEW—Interface Properties NI-XNET API for The default value of this property is 0 (no startup frame). identifier that correspon You can overwrite the default value by writing an ds to the identifier of a startup frame prior to starti ng the FlexRay inte rface (refer to Session States for more information). ni.com 4-108 NI-XNET Hardware and Software Manual

174 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:FlexRay:Latest Tx Direction Data Type Required? Default Read No 0 Property Class XNET Session Short Name Intf.FlexRay.LatestTx Description This property specifies the number of the last minislot in which a frame transm ission can start a read-only property, as the FlexRay controller evaluates it in the dynamic segment. This is based on the configuration of the frames in the dynamic segment. This property corresponds to the pLatestTx node parameter in the FlexRay Protocol . Specification The range of values for this property is 0–7981 minislots. prior to closing the FlexRay interface. This property can be read any time 4-109 © National Instruments NI-XNET Hardware and Software Manual

175 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:FlexRay:Listen Timeout Direction Required? Default Data Type Read/Write No Calculated from Cluster Settings Property Class XNET Session Short Name Intf.FlexRay.ListTimo Description This property specifies the upper limit for the startup listen timeout and wakeup listen timeout. Refer to Summary of the FlexRay Standard for more information about startup and wakeup procedures within the FlexRay protocol. This property corresponds to the node parameter in the pdListenTimeout FlexRay Protocol Specification . The range of values for this property is 1284–1283846 MT. You can overwrite the default value by writing a value within the specified range to this e FlexRay interface (refer to Session States for more information). property prior to starting th 4-110 NI-XNET Hardware and Software Manual ni.com

176 Chapter 4 NI-XNET API for LabVIEW—Interface Properties o Initial Offset Ch A Interface:FlexRay:Macr Data Type Direction Required? Default Read/Write No Calculated from Cluster Settings Property Class XNET Session Short Name Intf.FlexRay.MacInitOffA Description This property specifies the integer number of m acroticks between the static slot boundary and the following macrotick boundary of the secondary time reference point based on the nominal macrotick duration. This property applies only to Channel A. This property corresponds to the pMacroInitialOffset[A] node parameter in the FlexRay Protocol Specification . The range of values for this property is 2–72 MT. You can overwrite the default value by writing a value within the specified range to this e FlexRay interface (refer to property prior to starting th for more information). Session States 4-111 © National Instruments NI-XNET Hardware and Software Manual

177 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:FlexRay:Macr o Initial Offset Ch B Data Type Required? Default Direction Read/Write No Calculated from Cluster Settings Property Class XNET Session Short Name Intf.FlexRay.MacInitOffB Description This property specifies the integer number of m acroticks between the static slot boundary and the following macrotick boundary of the secondary time reference point based on the nominal macrotick duration. This property applies only to Channel B. This property corresponds to the node parameter in the pMacroInitialOffset[B] FlexRay Protocol Specification . The range of values for this property is 2–72 MT. You can overwrite the default value by writing a value within the specified range to this e FlexRay interface (refer to Session States for more information). property prior to starting th 4-112 NI-XNET Hardware and Software Manual ni.com

178 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:FlexRay:Max Drift Direction Data Type Required? Default Read/Write No Calculated from Cluster Settings Property Class XNET Session Short Name Intf.FlexRay.MaxDrift Description maximum drift offset between two nodes that operate with This property specifies the unsynchronized clocks over one communication cycle. pdMaxDrift This property corresponds to the node parameter in the FlexRay Protocol Specification . The range of values for this property is 2–1923 MT. You can overwrite the default value by writing a value within the specified range to this Session States e FlexRay interface (refer to property prior to starting th for more information). 4-113 © National Instruments NI-XNET Hardware and Software Manual

179 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:FlexRay:Micro Initial Offset Ch A Required? Default Data Type Direction Read/Write No Calculated from Cluster Settings Property Class XNET Session Short Name Intf.FlexRay.MicInitOffA Description mber of microticks between the closest macrotick boundary This property specifies the nu described by the Macro Initial Offset Ch A property and the secondary time reference point. This parameter depends on the Delay Compensa tion property for Channel A, and therefore you must set it independ ently for each channel. This property corresponds to the node parameter in the pMicroInitialOffset[A] FlexRay Protocol Specification . The range of values for this property is 0–240 MT. You can overwrite the default value by writing a value within the specified range to this e FlexRay interface (refer to Session States for more information). property prior to starting th 4-114 NI-XNET Hardware and Software Manual ni.com

180 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:FlexRay:Micro Initial Offset Ch B Direction Required? Default Data Type Read/Write No Calculated from Cluster Settings Property Class XNET Session Short Name Intf.FlexRay.MicInitOffB Description mber of microticks between the closest macrotick boundary This property specifies the nu operty and the secondary time reference point. described by the Macro Initial Offset Ch B pr This parameter depends on the Delay Compensation property for Channel B, and therefore you must set it independ ently for each channel. This property corresponds to the pMicroInitialOffset[B] node parameter in the FlexRay Protocol Specification . The range of values for this property is 0–240 MT. You can overwrite the default value by writing a value within the specified range to this e FlexRay interface (refer to property prior to starting th for more information). Session States 4-115 © National Instruments NI-XNET Hardware and Software Manual

181 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:FlexRay:Microtick Direction Data Type Required? Default Read No Calculated from Cluster Settings Property Class XNET Session Short Name Intf.FlexRay.Microtick Description This property specifies the duration of a micro tick. This property is calculated based on the product of the Samples per Microtick interface property and the BaudRate cluster. This is a read-only property. This property corresponds to the pdMicrotick node parameter in the FlexRay Protocol Specification . This property can be read any time prior to closing the FlexRay interface. 4-116 NI-XNET Hardware and Software Manual ni.com

182 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:FlexRay:Null Fr ames To Input Stream? Data Type Direction Required? Default False Read/Write No Property Class XNET Session Short Name Intf.FlexRay.NullToInStrm? Description This property indi cates whether the Frame Input Stream Mode session should return FlexRay XNET Read.vi . null frames from lse, FlexRay null frames are not returned for a When this property uses the default value of fa session. This behavior is consistent with the other two frame input Frame Input Stream Mode modes ( Frame Input Single-Point Mode and Frame Input Queued Mode ), which never return FlexRay null frames from XNET Read.vi . XNET Read.vi When you set this property to true for a Frame Input Stream Mode session, returns all FlexRay null frames that are received by the interf ace. This feature is used to monitor all frames that occur on the network, regardless of whether new payload is available or not. When you use XNET Read (Frame FlexRay).vi instance of XNET Read.vi , each frame’s type field indicates a null frame. starting the FlexRay interface (refer to Session You can overwrite the default value prior to States for more information). 4-117 © National Instruments NI-XNET Hardware and Software Manual

183 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:FlexRay:Offset Correction Direction Data Type Required? Default Read No N/A Property Class XNET Session Short Name Intf.FlexRay.OffCorr Description This property provides the maximum permissible offset correction value, expressed in microticks. The offset correction synchronizes the cycle start time. The value indicates the number of microticks added or subtracted to the offset correction portion of the network idle time, to synchronize the interface to the FlexRay network. The value is returned as a signed lue calculation takes place every cycle, but the 32-bit integer (I32). The offset correction va correction is applied only at the end of odd cycles. This is a read-only property. This property can be read anytime prior to closing the FlexRay interface. 4-118 NI-XNET Hardware and Software Manual ni.com

184 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:FlexRay:Offset Correction Out Direction Data Type Required? Default Read/Write No Calculated from Cluster Settings Property Class XNET Session Short Name Intf.FlexRay.OffCorrOut Description maximum permissible offset correction value. This property specifies the magnitude of the This node parameter is based on the value of the maximum offset correction for the specific cluster. This property corresponds to the pOffsetCorrectionOut node parameter in the FlexRay Protocol Specification . The value range for this property is 5–15266 MT. You can overwrite the default value by writing a value within the specified range to this e FlexRay interface (refer to property prior to starting th for more information). Session States 4-119 © National Instruments NI-XNET Hardware and Software Manual

185 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:FlexRay:Rate Correction Direction Data Type Required? Default Read No N/A Property Class XNET Session Short Name Intf.FlexRay.RateCorr Description ection value, expressed in microticks. The rate Read-only property that provides the rate corr correction synchronizes frequency. The value indicates the number of microticks added to or subtracted from the configured number of micr oticks in a cycle, to synchronize the interface to the FlexRay network. The value is returned as a signed 32-bit inte ger (I32). The rate correction value calculation e, based on values measured in an even-odd takes place in the static segment of an odd cycl double cycle. This property can be read prio r to closing the FlexRay interface. 4-120 NI-XNET Hardware and Software Manual ni.com

186 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:FlexRay:Rate Correction Out Direction Required? Default Data Type Read/Write No Calculated from Cluster Settings Property Class XNET Session Short Name Intf.FlexRay.RateCorrOut Description ximum permissible rate correction value. This This property specifies the magnitude of the ma ximum rate correction for the specific cluster. node parameter is based on the value of the ma FlexRay This property corresponds to the pRateCorrectionOut node parameter in the Protocol Specification . The range of values for this property is 2–1923 MT. This property is calculated from the microticks per cycle and clock accuracy. You can overwrite the default value by writing a value within the specified range to this Session States e FlexRay interface (refer to property prior to starting th for more information). 4-121 © National Instruments NI-XNET Hardware and Software Manual

187 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:FlexRay:Samples Per Microtick Direction Required? Default Data Type Read/Write No Calculated from Cluster Settings Property Class XNET Session Short Name Intf.FlexRay.SampPerMicro Description This property specifies the number of samples per microtick. There is a defined relationship between the “ticks” of the microtick timebase and the sample ticks of bit sampling. Specifically, a microtick consists of an integral number of samples. As a result, there is a fixed phase relationship between the microtick timebase and the sample clock ticks. This property corresponds to the node parameter in the pSamplesPerMicrotick FlexRay Protocol Specification . The supported values for this property are 1, 2, and 4 samples. You can overwrite the default value by writing a value within the specified range to this e FlexRay interface (refer to Session States for more information). property prior to starting th 4-122 NI-XNET Hardware and Software Manual ni.com

188 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:FlexRay:Single Slot Enabled? Data Type Direction Required? Default False Read/Write No Property Class XNET Session Short Name Intf.FlexRay.SingSlotEn Description This property serves as a fl ag to indicate whether the Flex Ray interface (node) should enter single slot mode following startup. This Boolean property supports a strategy to limit frame transmissions following startup to a single frame (designated by the XNET Session Interface:FlexRay:Key Slot Identifier property). If you leave this property false prior to start (default), all co nfigured output frames transmit. If you set this property to true prior to start, only the key slot transmits. After the interface is communicating (integrate d), you can set this property to false at runtime to enable the remaining transmissions (the protocol’s ALL_SLOTS command). After the interface is communicating, you cannot set this property from false to true. This property corresponds to the pSingleSlotEnabled node parameter in the FlexRay Protocol Specification . Session starting the FlexRay interface (refer to You can overwrite the default value prior to for more information). States 4-123 © National Instruments NI-XNET Hardware and Software Manual

189 Chapter 4 LabVIEW—Interface Properties NI-XNET API for Interface:FlexRay:Sleep Required? Default Data Type Direction Write Only No N/A Property Class XNET Session Short Name Intf.FlexRay.Sleep Description XNET FlexRay interface sleep/awake state and Use the Sleep property to change the NI- optionally to initiate a wakeup on the FlexRay cluster. The property is a ring (enumerated list) with the following values: String Description Va l u e ceiver(s) to sleep Set interface and trans 0 Local Sleep 1 Set interface and transceiver(s) to awake Local Wake Remote Wake Set interface and transceivers to awake and attempt to 2 wake up the FlexRay bus by sending the wakeup pattern on the configured wakeup channel This property is write only. Setting a new value is effectively a request, and the property node ace sleep/wake state, use returns before the request is complete. To de tect the current interf XNET Read (State FlexRay Comm).vi . The FlexRay interface maintains a state machine to determine the action to perform when this e action on the FlexRay property is set (request). The following table specifies the sleep/wak interface. ni.com 4-124 NI-XNET Hardware and Software Manual

190 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Current Local State Request Sleep Aw a k e Change local state Local Sleep No action Attempt to integrate with the bus (move from Local Wake No action POC:READY to POC:NORMAL) No action Attempt to wake up the bus followed by an attempt Remote Wake to integrate with the bus (move from POC:READY to POC:NORMAL ACTIVE). If the interface is not yet started, setting Remote Wake schedules a remote wake to be generated once the interface has started. © National Instruments 4-125 NI-XNET Hardware and Software Manual

191 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:FlexRay:Statistics Enabled? Direction Data Type Required? Default Read/Write No False Property Class XNET Session Short Name Intf.FlexRay.StatisticsEn? Description This XNET Boolean property enables reporting FlexRay error statistics . When this property always return zero for is false (default), calls to XNET Read (State FlexRay Statistics).vi each statistic. To enable FlexRa y statistics, set this property to true in your application. interface (refer to You can overwrite the default value prior to starting the FlexRay Session States for more information). 4-126 NI-XNET Hardware and Software Manual ni.com

192 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:FlexRay:Symbol Frames To Input Stream? Data Type Direction Required? Default Read/Write No False Property Class XNET Session Short Name Intf.FlexRay.SymToInStrm? Description This property indicates whether the Frame Input Stream Mode session should return FlexRay symbols from XNET Read.vi . When this property uses the default value of False, FlexRay symbols are not returned for a Frame Input Stream Mode session. This behavior is consistent with the other two frame input modes (Frame Input Single-Point Mode and Frame Input Queued Mode), which never return . XNET Read.vi FlexRay symbols from When you set this property to true for a Frame Input Stream Mode session, XNET Read.vi returns all FlexRay symbols the interface receive s. This feature detects wakeup symbols and Media Access Test Symbols (MTS). When you use the XNET Read (Frame FlexRay).vi XNET Read.vi , each frame type field indicates a symbol. instance of When the frame type is FlexRay Symbol, the first payload byte (offset 0) specifies the type of symbol: 0 for MTS or 1 for wakeup. The frame payload length is 1 or higher, with bytes beyond the first reserved for future use. Th e frame timestamp specifies when the symbol window occurred. The cycle count, channel A indicator, and channel B indicator are encoded the same as FlexRay data frames. All othe r fields in the fram e are unused (0). Session starting the FlexRay interface (refer to You can overwrite the default value prior to for more information). States 4-127 © National Instruments NI-XNET Hardware and Software Manual

193 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:FlexRay:Sync Frames Channel A Even Data Type Direction Required? Default Read No N/A Property Class XNET Session Short Name Intf.FlexRay.SyncChAEven Description smitted or received on channel A of sync frames (slot IDs) tran This property returns an array operty returns an arra y in which each element during the last even cycle. This read-only pr holds the slot ID of a sync frame. If the interface is not started, this returns an empty array. If you start the interface, but it fa ils to communicate (integrate), th is property may be helpful in diagnosing the problem. , for more information about the Refer to Appendix B, Summary of the FlexRay Standard FlexRay protocol startup procedure. This property can be read any time prior to closing the FlexRay interface. 4-128 NI-XNET Hardware and Software Manual ni.com

194 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:FlexRay:Sync Frames Channel A Odd Data Type Direction Required? Default N/A Read No Property Class XNET Session Short Name Intf.FlexRay.SyncChAOdd Description smitted or received on channel A of sync frames (slot IDs) tran This property returns an array during the last odd cycle. This read-only property returns an array in which each element this returns an empty array. If holds the slot ID of a sync frame. If the interface is not started, you start the interface, but it fa is property may be helpful in ils to communicate (integrate), th diagnosing the problem. , for more information about the Refer to Appendix B, Summary of the FlexRay Standard FlexRay protocol startup procedure. This property can be read any time prior to closing the FlexRay interface. 4-129 © National Instruments NI-XNET Hardware and Software Manual

195 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:FlexRay:Sync Frames Channel B Even Data Type Direction Required? Default Read No N/A Property Class XNET Session Short Name Intf.FlexRay.SyncChBEven Description smitted or received on channel B of sync frames (slot IDs) tran This property returns an array operty returns an arra y in which each element during the last even cycle. This read-only pr holds the slot ID of a sync frame. If the interface is not started, this returns an empty array. If you start the interface, but it fa ils to communicate (integrate), th is property may be helpful in diagnosing the problem. , for more information about the Refer to Appendix B, Summary of the FlexRay Standard FlexRay protocol startup procedure. This property can be read any time prior to closing the FlexRay interface. 4-130 NI-XNET Hardware and Software Manual ni.com

196 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:FlexRay:Sync Frames Channel B Odd Data Type Direction Required? Default N/A Read No Property Class XNET Session Short Name Intf.FlexRay.SyncChBOdd Description smitted or received on channel B of sync frames (slot IDs) tran This property returns an array during the last odd cycle. This read-only property returns an array in which each element this returns an empty array. If holds the slot ID of a sync frame. If the interface is not started, you start the interface, but it fa is property may be helpful in ils to communicate (integrate), th diagnosing the problem. , for more information about the Refer toAppendix B, Summary of the FlexRay Standard FlexRay protocol startup procedure. This property can be read any time prior to closing the FlexRay interface. 4-131 © National Instruments NI-XNET Hardware and Software Manual

197 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:FlexRay:Sync Frame Status Data Type Direction Required? Default Read No N/A Property Class XNET Session Short Name Intf.FlexRay.SyncStatus Description This property returns the status of sync fr ames since the interface (enumeration) start. Within ’s limits since the interface ames is within the protocol means the number of sync fr Limits means that in at least one cycle, the number of sync frames was below Below Minimum start. the limit the protocol requires (2 or 3, depending on number of nodes). Overflow means that in at least one cycle, the number of sync fr ames was above the limit set by the XNET Cluster FlexRay:Sync Node Max property. Both Min and Max means that both minimum and overflow errors have occu rred (this is unlikely). If the interface is not started, this property retu rns Within Limits. If you start the interface, but it fails to communicate (integrate), this property may be helpful in diagnosing the problem. , for more information about the Refer to Appendix B, Summary of the FlexRay Standard FlexRay protocol startup and cluster integration procedure. This property can be read any time prior to closing the FlexRay interface. 4-132 NI-XNET Hardware and Software Manual ni.com

198 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:FlexRay:Termination Data Type Direction Required? Default False Read/Write No Property Class XNET Session Short Name Intf.FlexRay.Term Description on) connector (port). -XNET interface (enumerati This property controls termination at the NI This applies to both channels (A and B) on each FlexRay interface. False means the interface is not terminated (default). True means the interf ace is terminated. You can overwrite the default value by writing this property prior to starting the FlexRay Session States interface (refer to for more information). You can start the FlexRay interface or on the session. Normal Interface Only by calling XNET Start.vi with scope set to either 4-133 © National Instruments NI-XNET Hardware and Software Manual

199 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:FlexRay:Wakeup Channel Required? Default Data Type Direction Read/Write No A Property Class XNET Session Short Name Intf.FlexRay.WakeupCh Description Ray interface (node) uses to send a wakeup This property specifies the channel the Flex Interface:FlexRay:Sleep property pattern. This property is used only when the XNET Session is set to Remote Wake. pWakeupChannel This property corresponds to the node parameter in the FlexRay Protocol Specification . The values supported for this proper ty (enumeration) are A = 0 and B = 1. You can overwrite the default value by writing this property prior to starting the FlexRay for more information). Session States interface (refer to 4-134 NI-XNET Hardware and Software Manual ni.com

200 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:FlexRay:Wakeup Pattern Direction Required? Default Data Type Read/Write No 2 Property Class XNET Session Short Name Intf.FlexRay.WakeupPtrn Description of the wakeup symbol that are combined to This property specifies the number of repetitions ace (node) enters the POC:wakeup-send state. form a wakeup pattern when the FlexRay interf The POC:wakeup send state is one of the FlexRay controller state transitions during the wakeup process. In this state, the controller sends the wakeup pattern on the specified Wakeup Channel and checks for collisions on the bus. This property corresponds to the pWakeupPattern node parameter in the FlexRay Protocol Specification . The supported values for this property are 2–63. You can overwrite the default value by writing a value within the specified range to this e FlexRay interface (refer to property prior to starting th for more information). Session States 4-135 © National Instruments NI-XNET Hardware and Software Manual

201 Chapter 4 NI-XNET API for LabVIEW—Interface Properties LIN Interface Properties This category includes LIN- specific interface properties. Properties in the Interface category apply to the ion. If more than interface and not the sess one session exists for the interface, changing an interface property affects all the sessions. Interface:LIN:Break Length Required? Default Data Type Direction No 13 Read/Write Property Class XNET Session Short Name Intf.LIN.BreakLen Description This property determines the length of the seri al break used at the st art of a frame header (schedule entry). The value is specified in bit-times. The valid range is 10–36 (inclusive). The default value is 13, which is the value the LIN standard specifies. At baud rates below 9600, the upper limit may be lower than 36 to avoid violating hold times for the bus. For example, at 2400 baud, the valid range is 10–14. This property is applicable only when the interface is the master. 4-136 NI-XNET Hardware and Software Manual ni.com

202 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:LIN:DiagP2min Data Type Direction Required? Default No 0.05 Read/Write Property Class XNET Session Short Name Intf.LIN.DiagP2min Description nimum time in seconds between reception of the When the interface is the slave, this is the mi last frame of the diagnostic request message and transmission of the response for the first frame in the diagnostic response message by the slave. slave. An attempt to write the property for This property applies only to the interface as ue being reported. rrInvalidPropertyVal interface as master results in error nxE 4-137 © National Instruments NI-XNET Hardware and Software Manual

203 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:LIN:DiagSTmin Data Type Direction Required? Default Read/Write No 0 Property Class XNET Session Short Name Intf.LIN.DiagSTmin Description When the interface is the slave, this proper ty sets the minimum tim e in seconds it places between the end of transmission of a frame in a diagnostic response message and the start of transmission of the response for the next frame in the diagnostic response message. When the interface is the master, this proper ty sets the minimum time in seconds it places between the end of transmission of a frame in a diagnostic request message and the start of transmission of the next frame in the diagnostic request message. 4-138 NI-XNET Hardware and Software Manual ni.com

204 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:LIN:Master? Data Type Direction Required? Default Read/Write No False Property Class XNET Session Short Name Intf.LIN.Master? Description when the interface is stopped. Note You can set this property only This Boolean property specifies the NI-XNET LIN interface role on the network: master (true) or slave (false). single ECU in the system called the master. The In a LIN network (cluster), there always is a master transmits a schedule of er is a remote request for a frame headers. Each frame head specific frame ID. For each header, typically a single ECU in the network (slave) responds by transmitting the requested ID payload. The master ECU can respond to a specific header as transmit payload data for the slave ECUs to receive. For more well, and thus the master can information, refer to Appendix C, Summary of the LIN Standard . The default value for this property is false (sla ve). This means that by default, the interface does not transmit frame headers onto the network. When you use input sessions, you read e output sessions, the NI-XNET interface waits frames that other ECUs transmit. When you us for the remote master to send a header for a fr ions, then the interface ame in the output sess responds with data for the requested frame. If you call XNET Write (State LIN Schedule Change).vi to request execution of a schedule, that implicitly sets this property to true (master). You also can set this property to true using a property node, but no schedule is active by default, so you still must call XNET Write at some point to request a specific schedule. (State LIN Schedule Change).vi can input and output sessions. This property Regardless of this property’s value, you use specifies which hardware transmits the schedule d frame headers: NI-XN ET (true) or a remote master ECU (false). 4-139 © National Instruments NI-XNET Hardware and Software Manual

205 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:LIN:Output Stream Slave Response List By NAD Data Type Direction Required? Default Read/Write No Empty Array Property Class XNET Session Short Name Intf.LIN.OutStrmSlvRspListByNAD Description D property provides a The Output Stream Slave Response List by NA list of NADs for use property set to Replay Exclusive or with the replay feature ( Interface:Output Stream Timing Replay Inclusive). to replay might contain multiple slave response frames, each For LIN, the array of frames with the same slave response identifier, but each having been transmitte d by a different slave (per the NAD value in the data payload). This means that processing slave response frames for replay requires two levels of filtering. Fi rst, you can include or exclude the slave response or Interface:Output Stream List By frame or ID for replay using Interface:Output Stream List ID . If you do not include the slave response fram e or ID for replay, no slave responses are sponse frame or ID for replay, you can use the transmitted. If you do include the slave re Output Stream Slave Response List by NAD property to filter which slave responses (per the NAD values in the array) are transmitted. This property is always inclusive, regardless of the replay mode (inclusive or exclusive). If the N AD is in the list and the response frame or ID has been enabled for replay, any slave response for that NAD is transmitted. If the NAD is not in the list, no slave response for that NAD is transmitted. The property’s data type is an array of unsigned 32-bit integer (u32). Currently, only byte 0 is required to hold the NAD value. The remaining bits are reserved for future use. 4-140 NI-XNET Hardware and Software Manual ni.com

206 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:LIN:Schedules Direction Required? Default Data Type Read Only No N/A Property Class XNET Session Short Name Intf.LIN.Schedules Description for use when the NI-XNET LIN interface acts as This property provides the list of schedules a master ( Interface:LIN:Master? is true). When the interface is master, you can wire one of to request a schedule these schedules to XNET Write (State LIN Schedule Change).vi change. When the interface is slave, you cannot control the schedule, and XNET Write (State LIN Schedule Change).vi returns an error if it cannot set the interface into master mode (for ace already is started). example, if the interf This array of XNET LIN Schedule I/O names is the same list as the XNET Cluster property used to configure the session. LIN:Schedules 4-141 © National Instruments NI-XNET Hardware and Software Manual

207 Chapter 4 LabVIEW—Interface Properties NI-XNET API for Interface:LIN:Sleep Data Type Direction Required? Default N/A Write Only No Property Class XNET Session Short Name Intf.LIN.Sleep Description -XNET LIN interface sleep/awake state and Use the Sleep property to change the NI optionally to change remote node (ECU) sleep/awake states. The property is a ring (enumerated list) with the following values: Description Va l u e String Set interface to sleep locally and transmit sleep requests 0 Remote Sleep to remote nodes Set interface to awake locally and transmit wakeup Remote Wake 1 requests to remote nodes Local Sleep 2 Set interface to sleep locally a nd not to interact with the network 3 Set interface to awake locally and not to interact with Local Wake the network The property is write only. Setting a new value is effectively a request, and the property node tect the current interf returns before the request is complete. To de ace sleep/wake state, use XNET Read (State LIN Comm).vi . The LIN interface maintains a state machine to determine the action to perform when this ns specify the action when the interface is property is set (request). The following sectio master and slave. ni.com 4-142 NI-XNET Hardware and Software Manual

208 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Sleep/Wake Action for Master Table 4-1. Current Local State Sleep Request Aw a k e No action Remote Sleep Change local state; pause scheduler; transmit go-to-sleep request frame Remote Wake Change local state; transmit No action master wakeup pattern (serial break); resume scheduler Change local state No action Local Sleep No action Local Wake Change local state; resume scheduler When the master’s scheduler paus es, it finishes the pending entry (slot) and saves its current position. When the master’s scheduler resumes, it continues with the schedule where it left off (entry after the pause). length 8, payload byte 0 has the value 0, and The go-to-sleep request is frame ID 63, payload the remaining bytes have the value 0xFF. If the master is in the Sleep state, and a remote slave (ECU) transmits the slave wakeup XNET pattern, this is equivalent to setting this property to Local Wake. In addition, a pending VI does not apply to setting this XNET Wait returns. This Wait (LIN Remote Wakeup).vi property, because you know when you set it. Table 4-2. Sleep/Wake Action for Slave Current Local State Request Sleep Aw a k e Remote Sleep Error Error Remote Wake Change local state; transmit No action slave wakeup pattern Change local state Local Sleep No action Change local state Local Wake No action National Instruments NI-XNET Hardware and Software Manual 4-143 ©

209 Chapter 4 LabVIEW—Interface Properties NI-XNET API for According to the LIN protocol standard, Remote Sleep is not supported for slave mode, so that request returns an error. master (ECU) transmits the master wakeup pattern, If the slave is in Sleep state, and a remote this is equivalent to setting this property to Local Wake. In addition, a pending XNET Wait (LIN Remote Wakeup).vi returns. This XNET Wait VI does not apply to setting this property, because you know when you set it. ni.com 4-144 NI-XNET Hardware and Software Manual

210 Chapter 4 NI-XNET API for LabVIEW—Interface Properties wed without Bus Power? Interface:LIN:Start Allo Data Type Direction Required? Default Read/Write No False Property Class XNET Session Short Name Intf.LIN.StrtWoPwr? Description Note You can modify this property only when the interface is stopped. y configures whether the LIN interface does The Start Allowed Without Bus Power? propert not check for bus power present at interface start, or checks and reports an error if bus power is missing. When this property is true, the LIN interface does not check for bus power present at start, so no error is reported if the interface is started without bus power. When this property is false, the LIN interf ace checks for bus power present at start, and interface is started without bus power. nxErrMissingBusPower is reported if the 4-145 © National Instruments NI-XNET Hardware and Software Manual

211 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:LIN:Termination Data Type Direction Required? Default No Off (0) Read/Write Property Class XNET Session Short Name Intf.LIN.Term Description Notes You can modify this property on ly when the interface is stopped. until the interface is started. This property does not take effect NET interface LIN connector (port) onboard The Termination property configures the NI-X termination. The enumeration is generic and supports two values: Off (disabled) and On (enabled). The property is a ring (enumerated list) with the following values: String Va l u e Off 0 1 On termination resistor between Vbat and  Per the LIN 2.1 standard, th e Master ECU has a ~1 k Vbus. Therefore, use this proper ty only if you are using your interface as the master and do not already have external termination. NI-XNET LIN Hardware . bling and termination, refer to For more information about LIN ca 4-146 NI-XNET Hardware and Software Manual ni.com

212 Chapter 4 NI-XNET API for LabVIEW—Interface Properties terface Properties Source Terminal In This category includes properties to route trigger signals between multiple DAQmx and XNET devices. Interface:Source Terminal:Start Trigger Data Type Direction Required? Default Read/Write (Disconnected) No Property Class XNET Session Short Name Intf.SrcTerm.StartTrigger Description This property specifies the name of the internal terminal to use as the interface Start Trigger. The data type is NI Terminal (DAQmx terminal). in a CompactDAQ chassis. It is not supported This property is supported for C Series modules XNET Connect Terminals.vi for CompactRIO, PXI, or PCI (refer to for those platforms). Start Interface transition, to begin The digital trigger signal at this terminal is for the use the interface. This property communication for all sessions that routes the start trigger, but not the timebase (used for timestamp of receive d frames and cyclic transmit of frames). actDAQ, because all modules in the chassis Timebase routing is not required for Comp automatically use a shared timebase. Trigger to triggers in other modules and/or Use this property to connect the interface Start interfaces. When you read this property, you sp ecify the interface Start Trigger as the source of a connection. When you write this property, you specify the interface Start Trigger as the destination of a connection, and the value you wr ite represents the source. For examples that demonstrate use of this prope rty to synchronize NI-XNET and NI-DAQmx hardware, refer to category within the NI-XNET examples. Synchronization the es is disconnected when you cl The connection this property creat ear (close) all sessions that use the interface. 4-147 © National Instruments NI-XNET Hardware and Software Manual

213 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:Baud Rate Data Type Direction Required? Default Read/Write 0 (If Not in Database) Yes (If Not in Database) Property Class XNET Session Short Name Intf.BaudRate Description You can modify this property only when the interface is stopped. Note The Interface:Baud Rate property sets the CA N, FlexRay, or LIN interface baud rate. The default value for this interface property is the same as the cluster’s baud rate in the database. Your application can set this interface baud rate to override the value in the database, or when no database is used. CAN When the upper nibble (0xF0000000) is clear, this is a numeric baud rate (for example, 500000). NI-XNET CAN hardware currently accepts the following numeric baud rates: 33333, 40000, 50000, 62500, 80000, 83333, 100000, 125000, 160000, 200000, 250000, 400000, 500000, 800000, and 1000000. Note The 33333 baud rate is supported with single-wire transceivers only. Note Baud rates greater than 125000 are supported with high-speed transceivers only. When the upper nibble is set to 0x8 (that is, 0x80000000), the remaining bits provide fields for more custom CAN communication baud rate programming. Additionally, if the upper nibble is set to 0xC (that is, 0xC0000000), the remaining bits provide fields for higher-precision custom CAN communication baud rate programming. The higher-precision 4-148 NI-XNET Hardware and Software Manual ni.com

214 Chapter 4 NI-XNET API for LabVIEW—Interface Properties bit timings facilitate connectivity to a CAN FD cluster. The baud rate models are shown in the following table: 27..26 25..24 23 22..20 31..28 15..14 13..12 11..8 3..0 7..4 19..16 Baud Rate (33.3 k–1 M) b0000 Normal Tq (125–0x3200) b1000 Res SJW Custom TSEG2 (0–7) TSEG1 Res (1–15) (0–3) SJW (0–15) b1100 Tq (25–0x3200) TSEG1 (1–63) High TSEG2 (0–15) Precision • (Re-)Synchronization Jump Width (SJW) Valid programmed values are 0–3 in normal custom mode and 0–15 in – high-precision custom mode. The actual hardware interpretation of this value is one more than the programmed – value. • Time Segment 2 (TSEG2), which is the time segment after the sample point – Valid programmed values are 0–7 in normal custom mode and 0–15 in high-precision custom mode. – This is the Phase_Seg2 time from ISO 11898–1, 12.4.1 Bit Encoding/Decoding . – The actual hardware interpretation of this value is one more than the programmed value. • Time Segment 1 (TSEG1), which is the time segment before the sample point – 15 decimal) in normal custom mode and Valid programmed values are 1–0xF (1– 1–0x3F (1–63 decimal) in high-precision custom mode. – This is the combination of the Prop_Seg and Phase_Seg1 time from ISO 11898–1, 12.4.1 Bit Encoding/Decoding . – The actual hardware interpretation of this value is one more than the programmed value. to program the baud rate prescaler • Time quantum (Tq), which is used – Valid programmed values are 125–12800, in increments of 0x7D (125 decimal) ns for normal custom mode and 25–12800, in increments of 0x19 (25 decimal) ns for high-precision custom mode. – This is the time quantum from ISO 11898–1, 12.4.1 Bit Encoding/Decoding . An advanced baud rate example is 0x8014007D. This example breaks down into the following values: • SJW = 0x0 (0x01 in hardware, due to the + 1) • TSEG2 = 0x1 (0x02 in hardware, due to the + 1) NI-XNET Hardware and Software Manual 4-149 National Instruments ©

215 Chapter 4 LabVIEW—Interface Properties NI-XNET API for • TSEG 1 = 0x4 (0x05 in hardware, due to the + 1) • Tq = 0x7D (125 ns in hardware) Each time quanta is 125 ns. From IS0 11898–1, 12.4.1.2 Programming of Bit Time , the nominal time segments length is Sync_Seg(Fixed at 1) + (Prop_Seg + Phase_Seg1)(B) + Phase_Seg2(C) = 1 + 2 + 5 = 8. So, the total time for a bit in this example is 8 * 125 ns = 1000 ns = 1  s. A 1  s bit time is equivalent to a 1 MHz baud rate. LIN When the upper nibble (0xF0000000) is clear, you can set only baud rates within the LIN-specified range (2400 to 20000) for the interface. When the upper nibble is set to 0x8 (0x80000000), no check for baud rate within e value may contain the custom LIN-specified range is performed, and the lowest 16 bits of th baud rate. Any custom value higher than 65535 is masked to a 16-bit value. As with the culates the appropriate divisor values to noncustom values, the interface internally cal program into its UART. Because the interfac e uses the Atmel ATA6620 LIN transceiver, which is guaranteed to operate within the LIN 2.0 specification limits, there are some special considerations when programming custom baud rates for LIN: • The ATA6620 transceiver incorporates a TX dominant timeout function to prevent a faulty device that it is built into from holding the LIN dominant indefinitely. If the TX nt state for too long, th line into the transceiver is held in the domina e transceiver switches a limit on how long the LIN header break field its driver to the recessive state. This places that the interface transmits may be, and thus li mits the lowest baud rate you can set. At length is set for the interface, the point the baud rate or break it uses the baud rate bit time and break length settings internally to calculate the resulting break duration and returns an error if that duration is long enough to trigger the TX dominant timeout. At the other end of the baud range, the ATA6620 is specified to work up to 20000 baud. • While you can use the custom bit to program rates higher than that, the transceiver that rate is not guaranteed. behavior when operating above 4-150 NI-XNET Hardware and Software Manual ni.com

216 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:Echo Transmit? Data Type Direction Required? Default Read/Write No False Property Class XNET Session Short Name Intf.EchoTx? Description ame Input or Signal Input The Interface:Echo Transmit? prop erty determines whether Fr sessions contain frames that the interface transmits. When this property is true, and a frame transmit is complete fo r an Output session, the frame ions can use the Flags field to differentiate is echoed to the Input session. Frame Input sess XNET Read es the interface transmits. When using frames received from the bus and fram (Frame CAN).vi , XNET Read (Frame FlexRay).vi , or XNET Read (Frame LIN).vi , the echo? XNET Read Boolean in the frame cluster. When using Flags field is parsed into an (Frame Raw).vi , you can parse the Flags manually by reviewing the Raw Frame Format section. Signal Input sessio ns cannot differentiate the or igin of the incoming data. Echoed frames are placed into the input se ssions only after the frame transmit is Note e, no listener) such complete. If there are bus problems (for exampl that the frame did not transmit, the frame is not received. 4-151 © National Instruments NI-XNET Hardware and Software Manual

217 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:I/O Name Required? Default Data Type Direction Read Only N/A N/A Property Class XNET Session Short Name Intf.IOName Description to the interface used to create the session. The I/O Name property returns a reference rface property node to retrieve hardware You can pass this I/O name into an XNET Inte information for the interface, such as the name and serial number. The I/O Name is the same ET System property nod reference available from the XN e, which is used to read information for all XNET hardware in the system. You can use this property on the diagram to: • Display a string that contains the name of the interface as shown in Measurement and Automation Explorer (MAX). Provide a refnum you can wire to a property node to read information for the interface. • 4-152 NI-XNET Hardware and Software Manual ni.com

218 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:Output Stream List Data Type Direction Required? Default Read/Write No Empty Array Property Class XNET Session Short Name Intf.OutStrmList Description Note Only CAN and LIN interfaces curr ently support th is property. The Output Stream List property provides a list of frames for use with the replay feature Stream Timing Interface:Output ive or Replay Inclusive). In property set to Replay Exclus ( y frames that do not appear in the list. In Replay Exclusive mode, the hardware transmits onl Replay Inclusive mode, the hardware transmits on ly frames that appear in the list. For a LIN interface, the header of each fram e written to stream output is transmitted, and the Exclusive or Inclusive mode controls the response transmission. Using these modes, you can either st contains the frames emulate an ECU (Replay Inclusive, where the li the ECU transmits) or test an ECU (Replay Exclusive, where the list contains the frames the ECU transmits), or some other combination. This property’s data type is an array of XN ET Frame from a database. When you are using a database file such as CANdb or FIBEX, eac h XNET frame uses the string name. If you are not using a database file or prefer to specify the frames using CAN arbitration IDs or LIN instead of this property. unprotected IDs, you can use ream List By ID Interface:Output St 4-153 © National Instruments NI-XNET Hardware and Software Manual

219 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:Output Stream List By ID Data Type Direction Required? Default Read/Write No Empty Array Property Class XNET Session Short Name Intf.OutStrmListById Description Note Only CAN and LIN interfaces cu rrently support this property. The Output Stream List By ID property provides a list of frames for use with the replay Interface:Output Stream Timing feature ( property set to Replay Exclusive or Replay Inclusive). This property serves the same purpose as Interface:Output Stream List , in that it provides a list of frames for replay filterin g. This property provides an al ternate format for you to specify the frames by their CAN arbitration ID or LIN unpr otected ID. The property’s data type is an array of unsigned 32-bit integer (u32). Each integer represents a CAN or LIN frame’s identifier, using the same encoding as the Raw Frame Format . Within each CAN frame ID value, bit 29 (hex 20000000) indicates the CAN identifier format 29 is clear, the lower 11 bits (0–10) contain the (set for extended, clear for standard). If bit CAN frame identifier. If bit 29 is set, the lower 29 bits (0–28) contain the CAN frame identifier. LIN frame ID values may be within the range of possible LIN IDs (0–63). 4-154 NI-XNET Hardware and Software Manual ni.com

220 Chapter 4 NI-XNET API for LabVIEW—Interface Properties Interface:Output Stream Timing Data Type Direction Required? Default Read/Write No Immediate Property Class XNET Session Short Name Intf.OutStrmTimng Description Note Only CAN and LIN interfaces curr ently support th is property. The Output Stream Timing property configures how the hardware transmits frames queued using a Frame Output Stream session. The following table lists the accepted values: Enumeration Va l u e Immediate 0 1 Replay Exclusive 2 Replay Inclusive When you configure this property to be Immedi ate, frames are dequeu ed from the queue and transmits all frames in the queue as fast as transmitted immediately to the bus. The hardware possible. When you configure this property as Replay Excl usive or Replay Inclusive, the hardware is tes the frame timestamps and this mode, the hardware evalua placed into a Replay mode. In attempts to maintain the original transmission times as the timestamp stored in the frame indicates. The actual tran smission time is based on the relative time difference between the first dequeued frame and the time contained in the dequeued frame. property to Interface:Output Stream List When in one of the replay modes, you can use the supply a list. In Replay Exclusive mode, the hardware transmits only frames that do not e hardware transmits only frames that appear appear in the list. In Replay Inclusive mode, th you can either emul ate an ECU (Replay Inclusive, where the in the list. Using these modes, list contains the frames the ECU transmits) or te st an ECU (Replay Excl usive, where the list contains the frames the ation. You can replay all frames ECU transmits), or some other combin by using Replay Exclusive mode without setting any list. NI-XNET Hardware and Software Manual 4-155 National Instruments ©

221 Chapter 4 LabVIEW—Interface Properties NI-XNET API for Runtime Behavior When the hardware is in a replay mode, the first frame received from the application is and all subsequent frames are tr ansmitted at the appropriate delta considered the start time, from the start time. For example, if the firs t frame has a timestamp of 12:01.123, and the second frame has a timestamp of 12:01.456, the second frame is transmitted 333 ms after the first frame. If a frame’s time is identical or goes backwards relative to the first timestamp, this is treated the bus. Subsequent frames as a new start time, and the fram e is transmitted immediately on are compared to this new start time to determine the transmission time. For example, assume that the application sends the hardware four frames with the following timestamps: 12:01.123, 12:01.456, 12:01.100, and 12:02.100. In this scenario, the first frame transmits immediately, the second frame transmits 333 ms after the first, the third transmits immediately after the second, and the fourth transmits one second after the third. Using this behavior, you can replay a logfil e of frames repeatedly, and each new replay of the file begins with new timing. A frame whose timestamp goes backwards relative to the previous timestamp, but still is forward relative to the start time, is transmi tted immediately. For exam ple, assume that the with the following timestamps: 12:01.123, application sends the hardware four frames ario, the first frame transmits immediately, 12:01.456, 12:01.400, and 12:02.100. In this scen the second frame transmits 333 ms after the first, the third transmits immediately after the second, and the fourth transmits 544 ms after the third. When a frame with a Delay Fr ame frame type is received, the hardware delays for the requested time. The next frame to be dequeued is treated as a new first frame and transmitted immediately. You can use a Delay Frame with a ti me of 0 to restart time quickly. If you replay a logfile of frames repeatedly, you can insert a De lay Frame at the start of each replay to insert a delay between each iteration through the file. When a frame with a Start Trigger frame type is received, the hardware treats this frame as a new first frame and uses the absolute time asso ciated with this frame as the new start time. Subsequent frames are compared to this new start time to determine the transmission time. Using a Start Trigger is especia with data acquisition products, lly useful when synchronizing so that you can replay the first frame at the corr ect time relative to the start trigger for accurate synchronized replay. Special Considerations for LIN Only LIN interface as Master supports stream output. You do not need to set the interface explicitly to Master if you want to use stream output. Just create a stream output session, and the driver automatically sets the in terface to Master at interface start. You can use immediate mode to transmit a head er or full frame. You can transmit only the e frame to stream output with header for a frame by writing th the desired ID and an empty 4-156 NI-XNET Hardware and Software Manual ni.com

222 Chapter 4 NI-XNET API for LabVIEW—Interface Properties writing the frame to stream output with the data payload. You can transmit a full frame by n to stream output, and you have desired ID and data payload. If you write a full frame for ID ssion for frame with ID n , the stream output data takes priority (the created a frame output se stream output frame data is transmitted and not the frame output data). If you write a full frame to stream output, but the frame has not been defined in th e database, the frame transmits with Enhanced checksum. To control the checksum type transmitted for a frame, you first must create the frame in the data base and assign it to an ECU using the LIN specification you en must create a frame desire (the specification number determines th e checksum type). You th output object to transmit the re ream output to transmit the sponse for the frame, and use st header. Similarly, to transmit n corrupted checksums for a frame, you first must create a frame object in the database, create a frame out put session for it, set the transmit n corrupted checksums property, and then use str eam output to transmit the header. Regarding event-triggered frame handling for immediate mode, if the hardware can determine that an ID is for an event-tr iggered frame, which means an event-triggered frame has been processed as if it were in an event-triggered defined for the ID in the database, the frame is ite a full frame with event-tri slot in a schedule. If you wr ggered ID, the full frame is transmitted. If there is no collision, the next st ocessed. If there is a ream output frame is pr collision, the hardware executes the collision- resolving schedule. The hardware retransmits the frame response at the corresponding slot time in the collision resolving schedule. If you write a header frame with an ev ent-triggered ID and there is no collision, the next stream output frame is processed. If th ere is a collision, the hardware executes the collision-resolving schedule. You can mix use of the hardware scheduler and stream output immediate mode. Basically, the hardware treats each stream outpu t frame as a separate run-on ce schedule containing a single slot for the frame. Transmissi on of a stream output frame may interrupt a run-continuous schedule, but may not interrupt a run-once schedu le. Transmission of stream output frames is interleaved with run-continuous schedule slot executions, depending on the application timing of writes to stream output. Stream output is prioritized to the equivalent of the lowest priority level for a run-once schedule. If you write one or more run-once schedules with higher-than-lowest priority and write frames to stream output, all the run-once schedules are executed before stream output transmits an ything. If you write one or more run-once schedules with the lowest priority and write frames to stream output, the run-once schedules execute in the order you wrote them, and ar e interleaved with st ream output frames, depending on the application timing of writes to stream output and writes of run-once schedule changes. In contrast to the immediate mode, neither replay mode allows for the concurrent use of the hardware scheduler, and an error is reported if you attempt to do so. Event-triggered frame e hardware can determine that an ID is for an handling is different for the replay modes. If th event-triggered frame, which means an event-triggered frame has been defined for the ID in the database, the frame is transmitted as if it were being transmitted during the collision-resolving schedule for the event triggered frame. The full frame is transmitted with 4-157 © National Instruments NI-XNET Hardware and Software Manual

223 Chapter 4 LabVIEW—Interface Properties NI-XNET API for the Data[0] value (the underlying unconditional fr ame ID), copied into the header ID. If a frame cannot be found in the database, it is tr ansmitted with Enhanced checksum. Otherwise, it is transmitted with the checksum type defined in the database. The reply modes provide an easy means to replay headers only, full frames only, or some mix of the two. For either replay mode, the header for each frame is always transmitted and the slot delay is preserved. For replay inclusive, if you want only to re play headers, leave the property empty. To replay some of the responses, add their Interface:Output Stream List Interface:Output Stream List . For frames that are not in Interface:Output Stream frames to s for them, for which you can change the List , you are free to create frame output object checksum type or transm it corrupted checksums. There is another consideration for the replay of diagnostic slave response frames. Because the master always transmits only the diagnostic slave response header, and a slave transmits the response if its NAD matches the one transmitted in the preceding master request frame, an frames (each having the same include multiple slave response array of frames for replay might smitted by different slaves (each having a different NAD value slave response header ID) tran in the data payload). If you are using inclusive mode, you can choose not to replay any slave . Interface:Output Stream List response frames by not including the slave response frame in You can choose to replay some or all of the sl ave response frames by first including the slave , then including the NAD Interface:Output Stream List values for the slave response frame in responses you want to play back, in Interface:LIN:Output Stream Slave Response List By NAD . In this way, you have complete control ov er which slave responses are replayed (which request frame is handled like diagnostic slaves you emulate). Re play of a diagnostic master replay of any other frame; the header is always transmitted. Using the inclusive mode as an itted depending on whether or not the master example, the response may or may not be transm request frame is in Interface:Output Stream List . Restrictions on Other Sessions When you use Immediate mode, there are no re strictions on frames that you use in other sessions. When you use Replay Inclusive mode, you can create output sessi ons that use frames that do not appear in the Interface:Output Stream List property. Attempting to create an output property results in an error. Interface:Output Stream List session that uses a frame from the Input sessions have no restrictions. When you use Replay Exclusive mode, you cannot create any other output sessions. Attempting to create an output session returns an error. Input sessions have no restrictions. 4-158 NI-XNET Hardware and Software Manual ni.com

224 Chapter 4 NI-XNET API for LabVIEW—Interface Properties ames to Input Stream? Interface:Start Trigger Fr Data Type Direction Required? Default Read/Write No False Property Class XNET Session Short Name Intf.StartTrigToInStrm? Description The Start Trigger Frames to Inpu t Stream? property co nfigures the hardware to place a start trigger frame into the Stream Input queue afte r it is generated. A Start Trigger frame is generated when the interface is started. Th e interface start process is described in Interface Special Frames start trigger frame, refer to . For more information about the . Transitions The start trigger frame is especially useful if you plan to log and replay CAN data. es to Input Stream? Interface:Bus Error Fram Data Type Direction Required? Default Read/Write No False Property Class XNET Session Short Name Intf.BusErrToInStrm? Description Note Only CAN and LIN interfaces curr ently support th is property. The Bus Error Frames to Input Stream? property configures th e hardware to place a CAN or LIN bus error frame into the Stream Input queue after it is generated. A bus error frame is r. For more information about the bus error generated when the hardware detects a bus erro . Special Frames frame, refer to 4-159 © National Instruments NI-XNET Hardware and Software Manual

225 Chapter 4 NI-XNET API for LabVIEW—Frame Properties Frame Properties This section includes the frame-specific properties in the session property node. CAN Frame Properties This category includes CAN-specific frame properties. Frame:CAN:Start Time Offset Data Type Direction Required? Default Write Only No –1 Property Class XNET Session Short Name Frm.CAN.StartTimeOff Description the amount of time that must elapse between the session being Use this property to configure started and the time that the first frame is transm itted across the bus. This is different than the cyclic rate, which determines the time between subsequent frame transmissions. e schedule of frames on the bus, to offer more Use this property to have more control over th determinism by configuring cyclic frames to be spaced evenly. If you do not set this property or you set it to a negative number, NI-XNET chooses this start time offset based on the arbitration identifier and periodic transmit time. This property takes effect whenever a session is started. If you stop a session and restart it, the start time offset is re-evaluated. Note This property affects the active fram e object in the session. Review the Frame:Active tting a property on an active frame. property to learn more about se 4-160 NI-XNET Hardware and Software Manual ni.com

226 Chapter 4 NI-XNET API for LabVIEW—Frame Properties Frame:CAN:Transmit Time Data Type Direction Required? Default From Database No Write Only Property Class XNET Session Short Name Frm.CAN.TxTime Description Use this property to change the frame’s tran smit time while the session is running. The elapse between subseque nt transmissions of a transmit time is the amount of time that must cyclic frame. The default value of this prope rty comes from the database (the XNET Frame CAN:Transmit Time property). If you set this property while a frame object is currently started, the frame object is stopped, the cyclic rate updated, and then the frame ob ject is restarted. Because of the stopping and e offset is re-evaluated. starting, the frame’s start tim e object in the session. Review the This property affects the active fram Note Frame:Active property to learn more about se tting property on an active frame. Note The first time a queued frame object is started, the XNET frame’s transmit time determines the object’s default queue size. Changing this rate has no impact on the queue size. Depending on how you change the rate, the queue may not be sufficient to store data for an extended period of time. You can mitigate this by setting the session Queue Size property to provide sufficient storage for all rates you use. If you are using a single-point session, this is not relevant. 4-161 © National Instruments NI-XNET Hardware and Software Manual

227 Chapter 4 NI-XNET API for LabVIEW—Frame Properties Frame:Active Data Type Direction Required? Default Write Only No 0 Property Class XNET Session Short Name Frm.Active Description This property provides access to properties fo r a specific frame running within the session. Writing this property sets the active frame for subsequent properties in the Frame category. The string syntax supports the following options: Decimal number • : This is interpreted as the index of the signal or frame in the session’s list. If the session is signal I/O, subsequent frame properties change the signal’s parent frame. • XNET Frame : If the session is frame I/O, you can wire a frame name from the session’s property. List of Frames • : If the session is signal I/O, you can wire a signal name from the session’s XNET Signal List of Signals property. Subsequent frame properties change the signal’s parent frame. If the session is Frame Stream Input or Fram e Stream Output, this property has no effect, because stream I/O sessions do not use specific frames. frame or signal in the se ssion’s list. If the empty The default value of this property is 0, the first string is wired to this property, this is converted to 0 internally. 4-162 NI-XNET Hardware and Software Manual ni.com

228 Chapter 4 NI-XNET API for LabVIEW—Frame Properties Frame:LIN:Transmit N Corrupted Checksums Data Type Direction Required? Default Write Only No 0 Property Class XNET Session Short Name Frm.LIN.TxNCrptChks Description When set to a nonzero value, this property causes the next N number of checksums to be corrupted. The checksum is corrupted by nega ting the value calculated per the database; ( EnhancedValue * –1 ). This property is valid only for output ClassicValue * –1 ) or ( is always N sessions. If the frame is transmitted in an unconditional or sporadic schedule slot, decremented for each frame transmi ssion. If the frame is transmitte d in an event-triggered slot is not decremented. In that case, N N and a collision occurs, is decremented only when the collision resolving schedule is executed and the frame is successfully transmitted. If the frame is the only one to transmit in the event-triggered slot (no collision), N is decremented at event-triggered slot time. This property is useful for testing ECU behavior when a corrupted checksum is transmitted. This property affects the active fram Note e object in the session. Review the property to learn more about se Frame:Active tting a property on an active frame. 4-163 © National Instruments NI-XNET Hardware and Software Manual

229 Chapter 4 NI-XNET API for LabVIEW—Frame Properties Frame:Skip N Cyclic Frames Data Type Direction Required? Default Write Only No 0 Property Class XNET Session Short Name Frm.SkipNCyclic Description Note This property is currently supported by CAN interfaces only. value, this property causes the next cyclic frames to be skipped. N When set to a nonzero time arrives and the sk ip count is nonzero, a frame value is When the frame’s transmission dequeued (if this is not a single-point session), and the skip count is decremented, but the frame actually is not transmitted across the bus. When the skip count decrements to zero, subsequent cyclic transmissions resume. This property is valid only for output sessions and frames with cyclic timing (t hat is, not event-based frames). This property is useful for testing of ECU beha vior when a cyclic frame is expected, but is missing for N cycles. Note This property affects the active fram e object in the session. Review the Frame:Active property to learn more about se tting a property on an active frame. 4-164 NI-XNET Hardware and Software Manual ni.com

230 Chapter 4 NI-XNET API for LabVIEW—Auto Start? Auto Start? Data Type Direction Required? Default Read/Write No True Property Class XNET Session Short Name AutoStart? Description Automatically starts the output session on the first call to XNET Write.vi . For input sessions, start always is performed within the first call to XNET Read.vi (if not XNET Start.vi already started using e is no known use case for ). This is done because ther reading a stopped input session. For output sessions, as long as the first call to XNET Write.vi contains valid data, you can leave this property at its default value of true. If you need to call XNET Write.vi multiple times prior to starting the session, or if you are starting multiple sessions simultaneously, you XNET XNET Write.vi as desired, you can call can set this property to false. After calling Start.vi to start the session(s). set to When automatic start is performed, it is equivalent to XNET Start.vi with scope e interface is not already started, it starts the Normal. This starts the session itself, and if th interface also. 4-165 © National Instruments NI-XNET Hardware and Software Manual

231 Chapter 4 NI-XNET API for LabVIEW—Cluster Cluster Direction Data Type Required? Default Read Only N/A N/A Property Class XNET Session Short Name Cluster Description . This property returns the cluster (network) used with XNET Create Session.vi Use this property on the block diagram as follows: • As a refnum wired to a property node to acce ss information for the cluster and its objects (frames, signals, etc.). As a string containing the cluster name. This name typically is the database alias • followed by the cluster name. 4-166 NI-XNET Hardware and Software Manual ni.com

232 Chapter 4 NI-XNET API for LabVIEW—Database Database Data Type Direction Required? Default N/A N/A Read Only Property Class XNET Session Short Name Database Description This property returns the database used with XNET Create Session.vi . Use this property on the block diagram as follows: • As a refnum wired to a property node to access information for the database and its objects (frames, signals, etc.). As a string containing the database name. This name is typically a database alias, but it • also can be a complete file path. 4-167 © National Instruments NI-XNET Hardware and Software Manual

233 Chapter 4 NI-XNET API for LabVIEW—List of Frames List of Frames Direction Data Type Required? Default Read Only N/A N/A Property Class XNET Session Short Name ListFrms Description This property returns the list of frames in the session. This property is valid only for sessions of Frame Input or Frame Output mode. For a Signal List of Signals Input/Output session, use the property. Use each array element on th e block diagram as follows: • As a refnum wired to a property nod e to access informati on for the frame. ame name. The name is the one used to create the session. As a string containing the fr • 4-168 NI-XNET Hardware and Software Manual ni.com

234 Chapter 4 NI-XNET API for LabVIEW—List of Signals List of Signals Direction Data Type Required? Default Read Only N/A N/A Property Class XNET Session Short Name ListSigs Description This property returns the list of signals in the session. This property is valid only for sessions of Signal Input or Signal Output mode. For a Frame List of Frames Input/Output session, use the property. Use each array element on th e block diagram as follows: As a refnum wired to a property nod • e to access information for the signal. • name is the one used to create the session. As a string containing the signal name. The 4-169 © National Instruments NI-XNET Hardware and Software Manual

235 Chapter 4 NI-XNET API for LabVIEW—Mode Mode Data Type Direction Required? Default Read Only N/A N/A Property Class XNET Session Short Name Mode Description This property returns the session mode (ring). You provided this mode when you created the Session Modes session. For more information, refer to . Number in List Data Type Direction Required? Default N/A Read Only N/A Property Class XNET Session Short Name NumInList Description This property returns the number of frames or signals in the session’s list. This is a quick way or List of Signals property. to get the size of the List of Frames 4-170 NI-XNET Hardware and Software Manual ni.com

236 Chapter 4 NI-XNET API for LabV IEW—Number of Values Pending Number of Values Pending Data Type Direction Required? Default Read Only N/A N/A Property Class XNET Session Short Name NumPend Description This property returns the number of values (frames or signals) pe nding for the session. For input sessions, this is the number of frame/signal values available to XNET Read.vi . If timeout of this number and XNET of 0.0, you call XNET Read.vi with number to read Read.vi r of values successfully. should return this numbe For output sessions, this is the number of frames/signal values provided to XNET Write.vi but not yet transmitted onto the network. Stream frame sessions using FlexRay or CAN FD protocol may use a variable size of frames. operty assumes the largest possible frame size. If you use smaller In these cases, this pr frames, the real number of pe nding values might be higher. The largest possible frames sizes are: • CAN FD: 64 byte payload. • FlexRay: The higher value of the frame size in the static segment and the maximum frame size in the dynamic segment. The XNET Cluster FlexRay:Payload Length property provides this value. Maximum The execution time to read this property is sufficient for use in a high-priority loop on High Priority Loops LabVIEW Real-Time (RT) (refer to for more information). 4-171 © National Instruments NI-XNET Hardware and Software Manual

237 Chapter 4 IEW—Number of Values Unused NI-XNET API for LabV Number of Values Unused Direction Data Type Required? Default Read Only N/A N/A Property Class XNET Session Short Name NumUnused Description This property returns the number of values (f rames or signals) unused for the session. If you provides the size of the underlying queue(s). get this property prior to starting the session, it Contrary to the Queue Size property, this value is in number of frames for Frame I/O, not number of bytes; for Signal I/O, it is the number of signal values in both cases. After start, this property returns the queue size minus the property. Number of Values Pending For input sessions, this is the number of frame/signal values unused in the underlying queue(s). For output sessions, this is the number of frame/signal values you can provide to a subsequent XNET Write.vi . If you call XNET Write.vi with this number of values and timeout call to of 0.0, XNET Write.vi should return success. Stream frame sessions using FlexRay or CAN FD protocol may use a variable size of frames. In these cases, this pr operty assumes the largest possible frame size. If you use smaller frames, the real number of pe nding values might be higher. The largest possible frames sizes are: CAN FD: 64 byte payload. • • FlexRay: The higher value of the frame size in the static segment and the maximum frame size in the dynamic segment. The XNET Cluster FlexRay:Payload Length Maximum property provides this value. The execution time to read this property is sufficient for use in a high-priority loop on High Priority Loops LabVIEW Real-Time (RT) (refer to for more information). 4-172 NI-XNET Hardware and Software Manual ni.com

238 Chapter 4 NI-XNET API for LabVIEW—Payload Length Maximum Payload Length Maximum Direction Required? Default Data Type Read Only N/A N/A Property Class XNET Session Short Name PayldLenMax Description of all frames in this session, expressed as This property returns the maximum payload length bytes (0–254). This property does not apply to Signal sessions (only Frame sessions). For CAN Stream (Input and Output), this property depends on the XNET Cluster CAN:I/O property. If the I/O mode is CAN, this property is 8 bytes. If the I/O mode is CAN FD Mode or CAN FD + BRS, this property is 64 bytes. For LIN Stream (Input and Output), this pr operty always is 8 bytes. For FlexRay Stream (Input and Output), this property is the same as the XNET Cluster FlexRay:Payload Length property value. For Queued and Single-Point (Input and Output), this is the Maximum property. List of Frames maximum payload of all frames specified in the 4-173 © National Instruments NI-XNET Hardware and Software Manual

239 Chapter 4 NI-XNET API for LabVIEW—Protocol Protocol Data Type Direction Required? Default N/A N/A Read Only Property Class XNET Session Short Name Protocol Description This property returns the protocol th at the interface in the session uses. The values (enumeration) for this property are: CAN 0 1FlexRay 2LIN 4-174 NI-XNET Hardware and Software Manual ni.com

240 Chapter 4 for LabVIEW—Queue Size NI-XNET API Queue Size Data Type Direction Required? Default Read/Write No Refer to Description Property Class XNET Session Short Name QueueSize Description and not yet transmitted onto XNET Write.vi For output sessions, queues store data passed to data received from the network and not yet the network. For input sessions, queues store obtained using XNET Read.vi . For most applications, the default queue sizes are sufficient. You can write to this property to override the default. When you write (set) this property, you must do so prior to the first session start. You cannot set this property again after calling XNET Stop.vi . For signal I/O sessions, this property is the numbe r of signal values stored. This is analogous . XNET Write.vi to the number of values you use with XNET Read.vi or e number of bytes of frame data stored. For frame I/O sessions, this property is th For standard CAN and LIN frame I/O sessions, each frame uses exactly 24 bytes. You can use this number to convert the Queue Size (in er of frame values. bytes) to/from the numb For CAN FD and FlexRay frame I/O sessions, ea ch frame value size can vary depending on the payload length. For more information, refer to Raw Frame Format . als from more than one frame. Within the For Signal I/O XY sessions, you can use sign a dedicated queue. According to the formulas below, the implementation, each frame uses default queue sizes can be different for each frame. If you read the default Queue Size property for a Signal Input XY session, the larg est queue size is return ed, so that a call to XNET Read.vi l queues. If you read the default Queue Size property of that size can empty al for a Signal Output XY session , the smallest queue size is returned, so that a call to XNET Write.vi of that size can succeed when all queues are empty. If you write the Queue Size property for a Signal I/O XY session, that size is used for all frames, so you must ensure that it is sufficient for the frame with the fastest transmit time. gnals from more than For Signal I/O Waveform sessions, you can use si one frame. Within the es a dedicated queue. The implementation, each frame us Queue Size property does not 4-175 © National Instruments NI-XNET Hardware and Software Manual

241 Chapter 4 for LabVIEW—Queue Size NI-XNET API represent the memory in these queues, but rather the amount of time stored. The default queue sampled signal values. If you read the default allocations store Application Time worth of re Queue Size property for a Signal I/O Wave form session, it returns Application Time multiplied by the time Resample Rate . If you write the Queue Size property for a Signal I/O mples to a time, and that time Waveform session, that value is translated from a number of sa is used to allocate memory for each queue. this property is ignored. Single-Point sessions For Single-Point sessions (signal or frame), always use a value of 1 as the effective queue size. Default Value You calculate the default queue size based on the following assumptions: Application Time : The time between calls to • XNET Read.vi / XNET Write.vi in your application. Frame Time • : The time between frames on the network for this session. The following pseudo code describes the default queue size formula: if (session is Signal I/O Waveform) Queue_Size = (Application_Time * Resample_Rate); else Queue_Size = (Application_Time / Frame_Time); if (Queue_Size < 64) Queue_Size = 64; if (session mode is Frame I/O) Queue_Size = Queue_Size * Frame_Size; For Signal I/O Waveform sessions, the initial formula calculates the number of resampled values that occur within the Application Time. This is done by multiplying Application Time by the XNET Session Resample Rate property. For all other session modes, the initial formula divides Application Time by Frame Time. The minimum for this formula is 64. This minimu m ensures that you can r ead or write at least 64 elements. If you need to read or write more elements for a slow frame, you can set the Queue Size property to a larger set a large Queue Size, this number than the default. If you may limit the maximum number of fr ames you can use in all sessions. For Frame I/O sessions, this formula result is multiplied by each frame value size to obtain a queue size in bytes. For Signal I/O sessions, this formula result is used directly for the queue size property to provide the number of signal values for XNET Read.vi or XNET Write.vi . Within the Signal incorporates frame sizes, because the signal I/O session, the memory allocated for the queue frame values internally. values are mapped to/from 4-176 NI-XNET Hardware and Software Manual ni.com

242 Chapter 4 NI-XNET API for LabVIEW—Queue Size Application Time The LabVIEW target in which your application runs determines the Application Time: • Windows : 400 ms (0.4 s) • : 100 ms (0.1 s) LabVIEW Real-Time (RT) This works under the assumption that for Windows, more memory is available for input queues, and you have limited control over the application timing. LabVIEW RT targets pplication has better control over application typically have less available memory, but your a timing. Frame Time Frame Time is calculated differen tly for Frame I/O Stream sessio ns compared to other modes. e network (cluster), so the Frame Time is For Frame I/O Stream, you access all frames in th k. For other modes, you access specific frames related to the average bus load on your networ only, so the Frame Time is obtained from database properties for those frames. The Frame Time used for the default varies by session mode and protocol, as described below. CAN, Frame I/O Stream Frame Time is 100  s (0.0001 s). frames back to back This time assumes a baud rate of 1 Mbps, with (100 percent busload). For CAN sessions created for a standard CAN bus, the Frame Size is 24 bytes. For CAN sessions created for a CAN FD Bus (the cluster I/O mode is CAN FD or CAN FD+BRS), the frame size can vary up to 64 bytes. However, the default queue size is based on the 24-byte frame time. When connecting to a CAN FD bus, yo u may need to adjust this size as necessary. When you create an application to stress test NI-XNET performance, it is possible to generate CAN frames faster than 100  s. For this application, you must set the queue size to larger than the default. FlexRay, Frame I/O Stream  s (0.00002 s). Frame Time is 20 This time assumes a baud rate of 10 Mbps, with a cycle containing static slots only (no minislots or NIT), and frames on channel A only. queue size than large frames at a slow rate. Small frames at a fast rate require a larger Therefore, this default assumes static slots with 4 bytes, for a Frame Size of 24 bytes. 4-177 © National Instruments NI-XNET Hardware and Software Manual

243 Chapter 4 for LabVIEW—Queue Size NI-XNET API stress test NI-XNET performance, it is possible to generate When you create an application to FlexRay frames faster than 20 s. For this application, you mu st set the queue size to larger  than the default. LIN, Frame I/O Stream Frame Time is 2 ms (0.002 s). This time assumes a baud rate of 20 kbps, w ith 1 byte frames back to back (100 percent busload). For all LIN sessions, Frame Size is 24 bytes. CAN, Other Modes For Frame I/O Queued, Signal I/O XY, and Signal I/O Waveform, the Frame Time is different for each frame in the session (or frame within which signals are contained). For CAN frames, Frame Time is the frame property CAN:Transmit Time , which specifies the time between successive frames (in floating-point seconds). If the frame’s CAN Transmit Time is 0, this implies the possibility of back-to-back frames on fic typically occurs in the network. Nevertheless, this back-to-back traf bursts, and the average . To keep the default queue size to a reasonable rate over a long period of time is relatively slow value, when CAN Transmit Time is 0, the form ula uses a Frame Time of 50 ms (0.05 s). For CAN sessions using a standard CAN cluster, the frame size is 24 bytes. For CAN sessions using a CAN FD cluster, the frame size may diff er for each frame in the session. Each frame size is obtained from its XNET Frame Payload Length property in the database. FlexRay, Other Modes I/O Waveform, the Frame Time is different For Frame I/O Queued, Signal I/O XY, and Signal for each frame in the session (or frame within which signals are contained). between successive frames (in floating-point For FlexRay frames, Frame Time is the time seconds), calculated from cluster and frame proper ties. For example, if a cluster Cycle (cycle duration) is 10000 s, and the frame Base Cycle is 0 an  d Cycle Repetition is 1, the frame’s Transmit Time is 0.01 (10 ms). For these session modes, the Frame Size is diff erent for each frame in the session. Each Frame property in the database. Payload Length Size is obtained from its XNET Frame LIN, Other Modes 4-178 NI-XNET Hardware and Software Manual ni.com

244 Chapter 4 for LabVIEW—Queue Size NI-XNET API e schedule running in the LIN master node. It For LIN frames, Frame Time is a property of th ame always is larger than 8 ms, so that the is assumed that the Frame Time for a single fr default queue size is set to 64 frames throughout. For all LIN sessions, Frame Size is 24 bytes. Examples The following table lists example session configurations and the resulting default queue sizes. Session Configuration Default Queue Size Formula Frame Input Stream, CAN, 24 bytes 96000 (0.4 / 0.0001) = 4000; 4000  Windows 96000 (0.4 / 0.0001) = 4000; 4000  24 bytes; Frame Output Stream, CAN, Windows output is always same as input Frame Input Stream, FlexRay, 480000 (0.4 / 0.00002) = 20000; Windows 20000  24 bytes  (0.1 / 0.0001) = 1000; 1000 24000 24 bytes Frame Input Stream, CAN, LabVIEW RT 120000 (0.1 / 0.00002) = 5000; 5000  24 bytes Frame Input Stream, FlexRay, LabVIEW RT Frame Input Queued, CAN, (0.4 / 0.05) = 8; Transmit Time 0 uses 1536* Transmit Time 0.0, Windows Frame Time 50 ms; use minimum of 64 frames (64  24) (0.4 / 0.0005) = 800; 800 19200* 24 bytes  Frame Input Queued, CAN, Transmit Time 0.0005, Windows 1536* Frame Input Queued, CAN, (0.4 / 1.0) = 0.4; use minimum of 24) Transmit Time 1.0 (1 s),  64 frames (64 Windows (0.4 / 0.002) = 200; 200 24 bytes 4800 Frame Input Queued, FlexRay,  every 2 ms cycle, payload length 4, Windows Frame Input Queued, FlexRay, (0.1 / 0.002) = 50, use minimum of 64; 2048 payload length 16 requires 32 bytes; every 2 ms cycle, payload 64 32 bytes  length 16, LabVIEW RT NI-XNET Hardware and Software Manual © National Instruments 4-179

245 Chapter 4 for LabVIEW—Queue Size NI-XNET API Default Queue Size Session Configuration Formula Signal Input XY, two CAN (0.4 / 0.05) = 8, use minimum of 64; 64* and 800* frames, Transmit Time 0.0 and (0.4 / 0.0005) = 800; expressed as signal (read as 800) values 0.0005, Windows Signal Output XY, two CAN 64* and 800* (0.4 / 0.05) = 8, use minimum of 64; (read as 64) (0.4 / 0.0005) = 800; expressed as signal frames, Transmit Time 0.0 and values 0.0005, Windows Signal Output Waveform, Memory allocation is 400 and 64 frames 400* two CAN frames, 1 ms and to provide 0.4 sec of storage, queue size represents number of samples, or 400 ms, resample rate 1000 Hz, Windows (0.4  1000.0) Signal Output Waveform, Memory allocation is 400 and 64 frames 400* two CAN frames, 1 ms and to provide 0.4 sec of storage, queue size represents number of samples, or 400 ms, resample rate 1000 Hz, Windows (0.4  1000.0) * For a CAN FD cluster, the default queue size is based on th e frame’s database payload lengt h, which may be larger than 24 bytes (up to 64 bytes). 4-180 NI-XNET Hardware and Software Manual ni.com

246 Chapter 4 NI-XNET API for LabVIEW—Resample Rate Resample Rate Data Type Direction Required? Default ple Every Millisecond) 1000.0 (Sam No Read/Write Property Class XNET Session Short Name ResampRate Description Rate used to resample frame data to/from signal data in waveforms. This property applies only when the session mode is Signal Input Waveform or Signal Output Waveform. This property is ignored for all other modes. The data type is 64-bit floating point (DBL). The units are in Hertz (samples per second). 4-181 © National Instruments NI-XNET Hardware and Software Manual

247 Chapter 4 NI-XNET API for LabVIEW—XNET Read.vi XNET Read.vi Purpose Reads data from the network using an XNET session. Description The instances of this polymorphic VI specify the type of data returned. and XNET Write.vi are optimized for r eal-time performance. XNET Read.vi XNET Read.vi executes quickly and avoids access to shared resources that can induce jitter on other VI priorities. There are three categories of XNET Read instance VIs: instance must XNET Read.vi • Signal : Use when the session mode is Signal Input. The Signal Waveform instance when mode is match the mode exactly (for example, the Signal Input Waveform). instance • Frame : Use when the session mo de is Frame Input. The XNET Read.vi specifies the desired data type for frames and is not related to the mode. For an easy-to-use data type, use the CAN, FlexRay, or LIN instance. • State : Use to read state, status, and time in formation for the session interface. You can use these instances in addition to Signal or Frame instances, and they are not related to is optimized for performance. Although the mode. The data these instances return ta, those properties are not necessarily property nodes may return similar runtime da optimized for real-time loops. The XNET Read instance VIs are: XNET Read (Frame CAN).vi : The session uses a CAN interface, and the mode is • , Frame Input Queued Mode , or Frame Input Single-Point Frame Input Stream Mode Mode . • XNET Read (Frame FlexRay).vi : The session uses a FlexRay interface, and the mode is Frame Input Stream Mode , Frame Input Queued Mode , Frame Input Single-Point Frame Input Queued Mode Mode , PDU Input Queued Mode (similar to ), and PDU Input Single-Point Mode (similar to ). Frame Input Single-Point Mode • XNET Read (Frame LIN).vi : The session uses a LIN interface, and the mode is Frame Input Stream Mode , Frame Input Queued Mode , or Frame Input Single-Point Mode • XNET Read (Frame Raw).vi : A data type for frame input that is protocol independent and more efficient than the protocol-specific instances. • XNET Read (Signal Single-Point).vi : The session mode is Signal Input Single-Point. • XNET Read (Signal Waveform).vi : The session mode is Signal Input Waveform. XNET Read (Signal XY).vi : The session mode is Signal Input XY. • 4-182 NI-XNET Hardware and Software Manual ni.com

248 Chapter 4 NI-XNET API for LabVIEW—XNET Read.vi • XNET Read (State CAN Comm).vi : Returns the CAN interface’s communication state. XNET Read (State FlexRay Comm).vi : Returns the FlexRay interface’s • communication state. : • XNET Read (State LIN Comm).vi Returns the LIN interf ace’s communication state. : Returns the current global time of Ray Cycle Macrotick).vi • XNET Read (State Flex the session FlexRay interface, repr esented as cycle and macrotick. XNET Read (State FlexRay Statistics).vi : Returns the communication statistics for the • session FlexRay interface. • XNET Read (State Time Comm).vi : Returns the LabVIEW timestamp at which communication began for the session interface. • XNET Read (State Time Current).vi : Returns the session interface current time as a LabVIEW timestamp. • XNET Read (State Time Start).vi : Returns the LabVIEW timestamp at which communication started for the session in terface. This time always precedes the Communication time. for the session provided. : Returns the current state XNET Read (State Session Info).vi • 4-183 © National Instruments NI-XNET Hardware and Software Manual

249 Chapter 4 NI-XNET API for LabVIEW—XNET Read (Frame CAN).vi XNET Read (Frame CAN).vi Purpose AN frames. The session must use a CAN interface Reads data from a session as an array of C Frame Input Stream Mode , and , or Frame Input Single-Point Frame Input Queued Mode Mode . Format Inputs session in on is selected from the LabVIEW is the session to read. This sessi project or returned from XNET Create Session.vi . The session mode must be Frame Input Stream, Frame Input Qu eued, or Frame Input Single-Point. number to read is the number of frame values desired. If number to read is positive (or 0), the data array size is no greater than this number. If is negative (typically –1), all available frame values are number to read returned. If is negative, you must use timeout of 0. number to read This input is optional. The default value is –1. If the session mode is Fr ame Input Single-Point, set number to read to either –1 or the number of frames in the sessions list. This ensures that the XNET Read (Frame CAN).vi can return the current value of all session frames. timeout is the time to wait for number to read frame values to become available. timeout is a LabVIEW relative time, represented as 64-bit The floating-point in units of seconds. If timeout is positive, the XNET Read (Frame CAN).vi waits for number to read frame values, then returns that num ber. If the values do not arrive timeout prior to the , an error is returned. 4-184 NI-XNET Hardware and Software Manual ni.com

250 Chapter 4 IEW—XNET Read (Frame CAN).vi NI-XNET API for LabV timeout XNET Read (Frame CAN).vi waits indefinitely If is negative, the number to read for frame values. If timeout is zero, the XNET Read (Frame CAN).vi does not wait and immediately returns all available frame values up to the limit number to read specifies. This input is optional. The default value is 0.0. If the session mode is Frame Input Single-Point, you must leave timeout unwired (0.0). Because this mode reads the most r ecent value of each frame, timeout does not apply. error in is the error cluster input (refer to Error Handling ). Outputs , provided for use with subsequent VIs. session in is the same as session out returns an array of LabVIEW clusters. data Each array element corresponds to a frame the session receives. For a Frame Input Single-Point session mode, the order of frames in the array corresponds to the order in the session list. The elements of each cluster are spec ific to the CAN protocol. For more information, refer to Appendix A, Summary of the CAN Standard , or the CAN protocol specification. The cluster elements are: is the CAN frame arbitration identifier. identifier Is false, the identifier extended? uses standard format, so If 11 bits of this identifier are valid. If extended? Is true, the identifier uses extended format, so 29 bits of this identifier are valid. extended? determines whether the is a Boolean value that identifier uses extended format (tru e) or standard format (false). echo? is a Boolean value that determines whether the frame was (true), or received from the an echo of a successful transmit network (false). This value is true only when you enable echo of transmitted frames by setting the XNET Session Interface:Echo Transmit? property to True. 4-185 © National Instruments NI-XNET Hardware and Software Manual

251 Chapter 4 NI-XNET API for LabVIEW—XNET Read (Frame CAN).vi type is the frame type (decimal value in parentheses): CAN Data (0) The CAN data frame contains payload data. This is the most commonly used frame type for CAN. CAN Remote (1) A CAN remote frame. An ECU transmits a CAN remote frame to request data for the corresponding identifier . Your application can respond by writing a CAN data frame for the . identifier Log Trigger (225) A Log Trigger frame. This frame is generated when a trigger occurs on an external connection (for example, PXI_Trig0). For information about this frame, including the other frame fields, refer to Special Frames . Start Trigger (226) A Start Trigger frame is generated when the interface is started (refer to Start for more information). For Interface information about this frame, including the other frame fields, refer to Special Frames . CAN Bus Error (2) A CAN Bus Error frame is generated when a bus error is detected on the CAN bus. For information about this frame, including the other frame fields, refer to Special Frames . timestamp represents the absolute time when the XNET interface received the frame (end of frame) , accurate to microseconds. The timestamp uses the LabVIEW absolute timestamp type. payload is the array of data bytes for the CAN data frame. The array size indicates the recei ved frame value payload length. According to the CAN protocol, this payload length range is 0–8. For CAN FD, the range can be 0–8, 12, 16, 20, 24, 32, 48, or 64. For a received remote frame ( type of CAN Remote ), the payload length in the frame value specifies the number of payload bytes requested. This payload length is provided to your application by filling payload with the requested number of bytes. Your 4-186 NI-XNET Hardware and Software Manual ni.com

252 Chapter 4 NI-XNET API for LabV IEW—XNET Read (Frame CAN).vi application can use the payload array size, but you must ignore the actual values in the payload bytes. Frame For an example of how this data applies to network traffic, refer to Frame Input Input Stream Mode , Frame Input Queued Mode , or Single-Point Mode . ). is the error cluster output (refer to error out Error Handling Description Each CAN frame uses a LabVIEW cluster with The data represents an array of CAN frames. CAN-specific elements. The CAN frames are associated to the session’s list of frames as follows: Frame Input Stream Mode • : Array of all frame values received (list ignored). • Frame Input Queued Mode : Array of frame values received for the single frame specified in the list. • Frame Input Single-Point Mode values, one for each frame : Array of single frame specified in the list. XNET Due to issues with LabVIEW memory alloca tion for clusters with an array, this Read.vi instance can introduce jitter to a high-pr iority loop on LabVIEW Real-Time (RT) XNET Read (Frame Raw).vi for more information). The (refer to High Priority Loops instance provides optimal performance for high-priority loops. 4-187 © National Instruments NI-XNET Hardware and Software Manual

253 Chapter 4 NI-XNET API for LabVIEW—XNET Read (Frame FlexRay).vi XNET Read (Frame FlexRay).vi Purpose Reads data from a session as an array of FlexRay frames. The session must use a FlexRay Frame Input Frame Input Stream Mode , Frame Input Queued Mode , or interface and . Single-Point Mode Format Inputs session in is the session to read. This sessi on is selected from the LabVIEW project or returned from XNET Create Session.vi . The session mode must be Frame Input Stream, Frame Input Qu eued, or Frame Input Single-Point. number to read is the number of frame values desired. array size is no greater than is positive (or 0), the data If number to read this number. If is negative (typically –1), all available frame values are number to read returned. If number to read is negative, you must use a timeout of 0. This input is optional. The default value is –1. If the session mode is Fr ame Input Single-Point, set number to read to either –1 or the number of frames in the session list. This ensures that can return the current value of all XNET Read (Frame FlexRay).vi session frames. timeout frame values to become number to read is the time to wait for available. The timeout is a LabVIEW relative time, represented as 64-bit floating-point in units of seconds. If timeout is positive, XNET Read (Frame FlexRay).vi waits for number ber. If the values do not arrive frame values, then returns that num to read prior to the timeout, an error is returned. 4-188 NI-XNET Hardware and Software Manual ni.com

254 Chapter 4 W—XNET Read (Frame FlexRay).vi NI-XNET API for LabVIE timeout XNET Read (Frame FlexRay).vi waits indefinitely If is negative, number to read for frame values. If timeout is zero, XNET Read (Frame FlexRay).vi does not wait and immediately returns all available frame values up to the limit number to read specifies. This input is optional. The default value is 0.0. If the session mode is Frame Input Single-Point, you must leave timeout unwired (0.0). Because this mode reads the most r ecent value of each frame, timeout does not apply. error in is the error cluster input (refer to Error Handling ). Outputs , provided for use with subsequent VIs. session in is the same as session out returns an array of LabVIEW clusters. data Each array element corresponds to a frame the session receives. For the Frame Input Single-Point a nd PDU Input Single-Point session modes, the order of frames/payload in the array corresponds to the order in the session list. The elements of each cluster are specifi c to the FlexRay protocol. For more information, refer to Appendix B, Summary of the FlexRay Standard , or the . FlexRay Protocol Specification The cluster elements are: slot within the FlexRay cycle. specifies the slot number specifies the cycle number. cycle count The FlexRay cycle count increments from 0 to 63, then rolls over back to 0. startup? is a Boolean value that specifies whether the frame is a startup frame (true) or not (false). es whether the frame is a sync sync? is a Boolean value that specifi frame (true) or not (false). is a Boolean value that specifies the value of the preamble? in the frame header. payload preamble indicator 4-189 © National Instruments NI-XNET Hardware and Software Manual

255 Chapter 4 NI-XNET API for LabVIEW—XNET Read (Frame FlexRay).vi preamble? being true If the frame is in the static segment, indicates the presence of a netw ork management vector at the FlexRay:Network beginning of the payload. The XNET Cluster Management Vector Length property specifies the number of bytes at the beginning. being true If the frame is in the dynamic segment, preamble? indicates the presence of a messag e ID at the beginning of the payload. The message ID is always 2 bytes in length. If preamble? is false, the payload does not contain a network management vector or a message ID. chA is a Boolean value that specifies whether the frame was received on channel A (t rue) or not (false). is a Boolean value that specifies whether the frame was chB received on channel B (t rue) or not (false). echo? Is a Boolean value that determines whether the frame was an echo of a successful transmit (true) or received from the network (false). This value is true only when you enable echo of transmitted frames by setting the XNET Session Interface:Echo Transmit? property to true. Frames are echoed only to a session with the Frame Input Stream Mode. type is the frame type (decimal value in parentheses): FlexRay Data (32) FlexRay data frame. The frame contains payload data. This is the most commonly used frame type for FlexRay. All elements in the frame are applicable. FlexRay Null (33) FlexRay null frame. When a FlexRay null frame is received, it indicates that the transmitting ECU did not have new data for the current cycle. Null frames occur in the static segment only. This frame type does not apply to frames in the dynamic segment. rs only when you This frame type occu set the XNET Session Frames To Input Interface:FlexRay:Null 4-190 NI-XNET Hardware and Software Manual ni.com

256 Chapter 4 W—XNET Read (Frame FlexRay).vi NI-XNET API for LabVIE Stream? property to true. This property enables logging of received null frames to a session with the Frame Input Stream Mode . Other sessions are not affected. For this frame type, the payload array is and preamble? empty (size 0), and echo? are false. The remaining elements in the frame reflect the data in the received null frame and the timestamp when it was received. FlexRay Symbol (34) FlexRay symbol frame. The frame contains a symbol received on the FlexRay bus. For this frame type, the first payload byte (offset 0) specifies the type of symbol: 0 for MTS, 1 for wakeup. The frame payload length is 1 or higher, with bytes beyond the first byte reserved for future use. The frame timestamp specifies when the symbol window occurred. The cycle count, channel A indicator, and channel B indicator are encoded the same as FlexRay data frames. All other fields in the frame are unused (0). Log Trigger (225) A Log Trigger frame. This frame is generated when a trigger occurs on an external connection (for example, PXI_Trig0). For information about this other frame fields, frame, including the refer to Special Frames . A Start Trigger frame is generated when Start Trigger (226) the interface is started (refer to Start Interface for more information). For information about this frame, including the other frame fields, refer to Special Frames . timestamp represents the absolute time when the XNET interface , accurate to microseconds. The received the frame (end of frame) uses the LabVIEW absolute timestamp type. timestamp 4-191 © National Instruments NI-XNET Hardware and Software Manual

257 Chapter 4 NI-XNET API for LabVIEW—XNET Read (Frame FlexRay).vi While the NI-XNET FlexRay interface is communicating (integrated), this timestamp is normally derived from FlexRay global time, the FlexRay network timebase. Under this configuration, the timestamp does not drift as compared to the FlexRay global time ( XNET Read (State FlexRay Cycle Macrotick).vi ), but it may drift relative to other NI hardware products and the LabVIEW absolute timebase. If you prefer to synchronize this timestamp to other sources, you can use XNET Connect Terminals.vi to change the source of the Master Timebase terminal. payload is the array of data bytes for FlexRay frames of type FlexRay Data FlexRay Null . or The array size indicates the recei ved frame value payload length. According to the FlexRay protocol, this length range is 0 –254. For PDU session modes, only the payload for the particular PDU is returned, not the entire frame. For an example of how this data applies to network traffic, refer to Frame Input Stream Mode , Frame Input Queued Mode , or Frame Input Single-Point Mode . ). Error Handling is the error cluster output (refer to error out Description es. Each FlexRay frame uses a LabVIEW cluster The data represents an array of FlexRay fram with FlexRay-specific elements. The FlexRay frames are associated to the session list of frames as follows: • Frame Input Stream Mode : Array of all frame values received (list ignored). Frame Input Queued Mode : Array of frame values received for the single frame specified • in the list. • Frame Input Single-Point Mode : Array of single frame values, one for each frame specified in the list. • PDU Input Queued Mode: Array of frame (P DU payload) values received for the single PDU specified in the list. This mode is similar to , Frame Input Queued Mode • PDU Input Single-Point Mode: Array of single frame ( PDU payload) values, one for each PDU specified in the list. This mode is similar to Frame Input Single-Point Mode . Due to issues with LabVIEW memory alloca tion for clusters with an array, this XNET Read.vi instance can introduce jitter to a high-pr iority loop on LabVIEW Real-Time (RT) XNET Read (Frame Raw).vi (refer to High Priority Loops for more information). The instance provides optimal perfor mance for high-priority loops. 4-192 NI-XNET Hardware and Software Manual ni.com

258 Chapter 4 W—XNET Read (Frame LIN).vi NI-XNET API for LabVIE XNET Read (Frame LIN).vi Purpose N frames. The session must use a LIN interface Reads data from a session as an array of LI Frame Input Single-Point and Frame Input Stream Mode , Frame Input Queued Mode , or . Mode Format Inputs session in is the session to read. This sessi on is selected from the LabVIEW XNET Create Session.vi project or returned from . The session mode must be Frame Input Stream, Frame Input Qu eued, or Frame Input Single-Point. number to read is the number of frame values desired. array size is no greater than is positive (or 0), the data If number to read this number. is negative (typically –1), all available frame values are number to read If is negative, you must use a timeout of 0. returned. If number to read This input is optional. The default value is –1. If the session mode is Fr ame Input Single-Point, set number to read to the session list. This ensures that either –1 or the number of frames in can return the curren XNET Read (Frame LIN).vi t value of all session frames. timeout is the time to wait for number to read frame values to become available. The timeout is a LabVIEW relative time, represented as 64-bit floating-point in units of seconds. XNET Read (Frame LIN).vi number to waits for If timeout is positive, If the values do not arrive prior read frame values, then returns that number. to the timeout, an error is returned. 4-193 © National Instruments NI-XNET Hardware and Software Manual

259 Chapter 4 NI-XNET API for LabVIEW—XNET Read (Frame LIN).vi If timeout is negative, XNET Read (Frame LIN).vi waits indefinitely for number to read frame values. If timeout is zero, XNET Read (Frame LIN).vi does not wait and immediately returns all available frame values up to the limit number to specifies. read This input is optional. The default value is 0.0. timeout If the session mode is Frame Input Single-Point, you must leave unwired (0.0). Because this mode reads the most r ecent value of each frame, timeout does not apply. error in is the error cluster input (refer to Error Handling ). Outputs , provided for use with subsequent VIs. session out is the same as session in data returns an array of LabVIEW clusters. Each array element corresponds to a frame the session receives. For a Frame Input Single-Point session mode, the order of frames in the array corresponds to the order in the session list. The elements of each cluster are speci fic to the LIN protocol. For more information, refer to Appendix C, Summary of the LIN Standard , or the LIN protocol specification. For the Frame Input Stream session mo de, LIN frames are read in their raw form, without interpretation of their elements using the database. For the Frame Input Single-point and Fr ame Input Queued session modes, information from the database is used to interpret the LIN frames for ease of use. The following cluster description applies to session modes Frame Input Single-point and Frame e modes, the cluster Input Queued. For thes elements are: identifier is the LIN frame identifier. The identifier is a number from 0 to 63. This number identifies the content of the data contained within payload . The location of this ID within the frame depends on the value of event slot? . If event slot? is false, this ID is taken from the frame’s header. If event slot? is true, this ID is taken from the first 4-194 NI-XNET Hardware and Software Manual ni.com

260 Chapter 4 W—XNET Read (Frame LIN).vi NI-XNET API for LabVIE payload byte. This ensures that the number identifies the payload, regardless of how it was scheduled. Regardless of its location, this is the unprotected ID, without parity applied. For more information about LIN ID protection, refer to Appendix C, Summary of the LIN Standard . event slot? is a Boolean value that specifies whether the frame was received within an event-triggered schedule entry (slot). If the ved within an event-triggered value is true, the frame was recei e frame was received within an slot. If the value is false, th unconditional or sporadic slot. When this value is true, event ID contains the ID from the frame’s header. event ID is the identifier for an event-triggered slot ( event slot? true). is the ID from the frame’s When event slot? is true, event ID is a number from 0 to 63. This is the event ID header. The unprotected ID, without parity applied. event slot? is false, this value does not apply (it is 0). When echo? is a Boolean value that determines whether the frame was an echo of a successful transmit (true), or received from the network (false). This value is true only when you enable echo of transmitted frames by setting the XNET Session Interface:Echo Transmit? property to True. is the frame type (decimal value in parentheses): type LIN Data (64) The LIN data frame contains payload data. Log Trigger (225) A Log Trigger frame. This frame is generated when a trigger occurs on an n (for example, external connectio PXI_Trig0). For information about this frame, including the other frame fields, refer to Special Frames . Start Trigger (226) A Start Trigger frame is generated when Start the interface is started (refer to Interface for more information). For 4-195 © National Instruments NI-XNET Hardware and Software Manual

261 Chapter 4 NI-XNET API for LabVIEW—XNET Read (Frame LIN).vi information about this frame, including the other frame fields, refer to Special Frames . LIN Bus Error (65) A LIN Bus Error frame is generated when a bus error is detected on the LIN bus. For information about this frame, including the other fr ame fields, refer to . Special Frames timestamp represents the absolute time when the XNET interface received the frame (end of frame) , accurate to microseconds. The timestamp uses the LabVIEW absolute timestamp type. payload is the array of data byt es for the LIN data frame. The array size indicates the received frame’s payload length. According to the LIN protocol, this payload is 0–8 bytes in length. If the frame payload is used within an event-triggered schedule entry (slot), the first byte of payload is the identifier of the frame in its protected form (checksum applied). This is required by the LIN standard even if the frame transmits in an unconditional or sporadic slot. For this type of LIN frame, the actual data (for example, signal values) is limited to 7 bytes. For example, assume that frame ID 5 is received in an unconditional slot and an event-triggered slot of ID 9. When you is 5, identifier event slot? receive from the unconditional slot, is false, event ID is 0, and the first payload byte contains 5 with ve from the event-triggered checksum applied. When you recei is 5, event slot? slot, identifier is 9, and the first event ID is true, payload byte contains 5 with checksum applied. Regardless of how the frame is received, you can use the identifier to determine the contents of the actual payl oad data contents in bytes 2–8. The following cluster description applies to session mode Frame Input Stream. For this mode, the cluster elements are: identifier is the identifier received within the frame’s header. The identifier is a number from 0 to 63. unconditional or sporadic, this If the schedule entry (slot) is identifies the payload data (LIN frame). If the schedule entry is event triggered, this identifies the schedule entry itself, and the 4-196 NI-XNET Hardware and Software Manual ni.com

262 Chapter 4 W—XNET Read (Frame LIN).vi NI-XNET API for LabVIE protected ID contained in the fi rst payload byte identifies the payload. event slot? is not used. This element is false. event ID is not used. This element is 0. uses the same semantics as the previous description for echo? Frame Input Queued. uses the same semantics as the previous description for type Frame Input Queued. uses the same semantics as the previous description timestamp for Frame Input Queued. payload uses the same semantics as the previous description for Frame Input Queued. For an example of how this data applies to network traffic, refer to Frame , or Frame Input Input Stream Mode , Frame Input Queued Mode . Single-Point Mode is the error cluster output (refer to Error Handling ). error out Description Each LIN frame uses a LabVIEW cluster with The data represents an array of LIN frames. LIN-specific elements. The LIN frames are associated to the session’s list of frames as follows: : Array of all frame values received (list ignored). • Frame Input Stream Mode • Frame Input Queued Mode : Array of frame values received for the single frame specified in the list. • Frame Input Single-Point Mode : Array of single frame values, one for each frame specified in the list. Due to issues with LabVIEW memory alloca tion for clusters with an array, this XNET Read.vi instance can introduce jitter to a high-pr iority loop on LabVIEW Real-Time (RT) for more information). The XNET Read (Frame Raw).vi (refer to High Priority Loops instance provides optimal performance for high-priority loops. 4-197 © National Instruments NI-XNET Hardware and Software Manual

263 Chapter 4 NI-XNET API for LabVIEW—XNET Read (Frame Raw).vi XNET Read (Frame Raw).vi Purpose Reads data from a session as an array of raw bytes. Format Inputs session in on is selected from the LabVIEW is the session to read. This sessi project or returned from XNET Create Session.vi . The session mode must Frame Input Stream Mode be Frame Input , Frame Input Queued Mode , or . Single-Point Mode number to read is the number of bytes (U8) desired. This number does not represent the numb er of frames to read. As encoded in raw data, each frame can vary in length. Therefor e, the number read, not the number of frames. represents the maximum raw bytes to 24 bytes in length. If you want Standard CAN and LIN frames are always ames, multiply that number by 24. to read a specific number of fr CAN FD and FlexRay frames vary in length. For example, if you pass might return 80 bytes, within which the number to read of 91, the data first 24 bytes encode the first frame, and the next 56 bytes encode the second frame. array size is no greater than If number to read is positive (or 0), the data this number. The minimum size fo r a single frame is 24 bytes. number to read is negative (typically –1), all available raw data is If timeout returned. If number to read is negative, you must use a of 0. This input is optional. The default value is –1. If the session mode is Frame Input Single-Point, set number to read to –1. XNET Read (Frame Raw).vi can return the current This ensures that value of all session frames. 4-198 NI-XNET Hardware and Software Manual ni.com

264 Chapter 4 W—XNET Read (Frame Raw).vi NI-XNET API for LabVIE timeout is the time to wait for number to read frame bytes to become available. To avoid returning a partial frame, even when number to read bytes are available from the hardware, this read may return fewer bytes in data . For of 70 bytes and of timeout example, assume you pass number to read are received, the first 24 bytes in 10 seconds. During the read, two frames size, and the second 56 bytes in size, for a total of 80 bytes. The read returns y the first frame is copied to data. after the two frames are received, but onl If the read copied 46 bytes of the second frame (up to the limit of 70), that frame would be incomplete and therefore difficult to interpret. To avoid this problem, the read always returns complete frames in data. The timeout is a LabVIEW relative time, represented as 64-bit floating-point in units of seconds. waits for XNET Read (Frame Raw).vi number to If timeout is positive, frame bytes to be received, then returns complete frames up to that read number. If the bytes do not arrive prior to the timeout, an error is returned. is negative, XNET Read (Frame Raw).vi waits indefinitely for timeout If number to read frame bytes. timeout is zero, If XNET Read (Frame Raw).vi does not wait and immediately returns all available frame bytes up to the limit number to read specifies. This input is optional. The default value is 0.0. timeout If the session mode is Frame Input Single-Point, you must leave ecent value of each reads the most r unwired (0.0). Because this mode timeout does not apply. frame, ). error in is the error cluster input (refer to Error Handling Outputs session out is the same as session in , provided for use with subsequent VIs. data returns an array of bytes. Raw Frame Format . The raw bytes encode one or more frames using the and write of raw data, and it is also This frame format is the same for read used for log file examples. The data always returns complete frames. 4-199 © National Instruments NI-XNET Hardware and Software Manual

265 Chapter 4 NI-XNET API for LabVIEW—XNET Read (Frame Raw).vi For information about which elements of the raw frame are applicable, refer to the frame read fo XNET Read (Frame r the protocol in use ( , XNET Read (Frame FlexRay).vi ), or XNET Read (Frame CAN).vi . For example, when you read Fl exRay frames for a Frame Input LIN).vi Queued session, the only frame type is FlexRay Data (other types apply to Frame Input Stream only). For an example of how this data applies to network traffic, refer to Frame Input Stream Mode , Frame Input Queued Mode , or Frame Input Single-Point Mode . error out is the error cluster output (refer to Error Handling ). Description The raw bytes encode one or more frames using the Raw Frame Format . The session must use Frame Input Stream Mode , Frame Input Queued Mode , Frame Input Single-Point Mode , Frame Input Queued Mode PDU Input Queued Mode (similar to ), or PDU Input Single-Point Mode (similar to ). The raw frame format is protocol Frame Input Single-Point Mode independent, so the session can use eith er a CAN, FlexRay, or LIN interface. The raw frame format matches the format of data transferred to/from the XNET hardware. Because it is not converted to/from LabVIEW clusters for ease of use, it is more efficient with regard to performance. This XNET Read.vi instance typically is used to read raw frame data from the interface and log the data to a file for later analysis. The NI-XNET examples provide code to read the raw frame data from the log file and convert the raw data into protocol-specific LabVIEW clusters. The raw frames are associated to the session’s list of frames as follows: • Frame Input Stream Mode : Array of all frame values received (list ignored). • : Array of frame values received for the single frame specified Frame Input Queued Mode in the list. • Frame Input Single-Point Mode : Array of single frame values, one for each frame specified in the list. • PDU Input Queued Mode: Array of frame (P DU payload) values received for the single PDU specified in the list. This mode is similar to Frame Input Queued Mode . • PDU Input Single-Point Mode: Array of single frame (P DU payload) values, one for each PDU specified in the list. This mode is similar to . Frame Input Single-Point Mode 4-200 NI-XNET Hardware and Software Manual ni.com

266 Chapter 4 ET Read (Signal Single-Point).vi NI-XNET API for LabVIEW—XN XNET Read (Signal Single-Point).vi Purpose Reads data from a session of Signal Input Single-Point Mode . Format Inputs session in is the session to read. This sessi on is selected from the LabVIEW . The session mode must project or returned from XNET Create Session.vi Signal Input Single-Point Mode . be Error Handling error in is the error cluster input (refer to ). Outputs , provided for use with subsequent VIs. session out is the same as session in returns a one-dimensional array of si data gnal values. Each signal value is scaled, 64-bit floating point. signal configured for the session. The Each array element corresponds to a order of signals in the array correspo nds to the order in the session list. The data returns the most recent value received for each signal. If multiple frames for a signal are receive d since the previous call to XNET Read (Signal Single-Point).vi (or session start), only si gnal data from the most recent frame is returned. If no frame is received for the corres ponding signals sin ce you started the session, the XNET Signal is returned. Default Value For an example of how this data applies to network traffic, refer to Signal Input Single-Point Mode . A trigger signal returns a value of 1.0 or 0.0, depending on whether its frame arrived since the last Read (or Start) or not. For more information about trigger signals, refer to Signal Input Single-Point Mode . is the error cluster output (refer to error out ). Error Handling 4-201 © National Instruments NI-XNET Hardware and Software Manual

267 Chapter 4 W—XNET Read (Signal Waveform).vi NI-XNET API for LabVIE XNET Read (Signal Waveform).vi Purpose Signal Input Waveform Mode . Reads data from a session of The data represents a waveform of resampled values for each signal in the session. You can wire the data directly to a La bVIEW Waveform Graph for display. Format Inputs session in on is selected from the LabVIEW is the session to read. This sessi project or returned from XNET Create Session.vi . The session mode must be Signal Input Waveform. is the number of samples desired. number to read If number to read is positive (or 0), the number of samples returned (size timeout is nonzero, the of Y arrays) is no greater than this number. If number returned is exactly this number on success. If is negative (typically –1), the maximum number of number to read samples is returned. If number to read is negative, you must use a timeout of zero. This input is optional. The default value is –1. timeout is the time to wait for number to read samples to become available. The timeout is a LabVIEW relative time, represented as 64-bit floating-point in units of seconds. timeout is positive, XNET Read (Signal Waveform).vi waits for If number to read samples, then returns that number. If the samples do not arrive prior to the timeout, an error is returned. If timeout is negative, XNET Read (Signal Waveform).vi waits number to read samples. indefinitely for 4-202 NI-XNET Hardware and Software Manual ni.com

268 Chapter 4 XNET Read (Signal Waveform).vi NI-XNET API for LabVIEW— If timeout is zero, XNET Read (Signal Waveform).vi does not wait and immediately returns all available samples up to the limit number to read specifies. Because time determines sample avai lability, typical values for this are 0 (return available) or a large positive value such as 100.0 (wait timeout number to read ). This input is optional. The default value for a specific is 0.0. ). error in is the error cluster input (refer to Error Handling Outputs session out is the same as session in , provided for use with subsequent VIs. data returns a one-dimensional array of LabVIEW waveforms. signal configured for the session. The Each array element corresponds to a nds to the order in the session list. order of signals in the array correspo The waveform elements are: is the waveform start time. This is a LabVIEW absolute t0 timestamp that specifies the tim e for the first sample in the Y array. dt is the waveform delta time. This is a LabVIEW relative time that specifies the time be tween each sample in the Y array. LabVIEW relative time is represented as 64-bit floating point in units of seconds. The waveform dt always is the inverse of the XNET Session Resample Rate property. Y is the array of resampled signal values. Each signal value is scaled, 64-bit floating point. Y array size is the same for all waveforms returned, because The it is determined based on time, and not the number of frames received. If no frame is received for the corresponding signals since you started the session, the XNET Signal Default Value is returned. For an example of how this data applies to network traffic, refer to Signal Input Waveform Mode . ). Error Handling error out is the error cluster output (refer to 4-203 © National Instruments NI-XNET Hardware and Software Manual

269 Chapter 4 IEW—XNET Read (Signal XY).vi NI-XNET API for LabV XNET Read (Signal XY).vi Purpose Reads data from a session of Signal Input XY Mode . Format Inputs session in is the session to read. This sessi on is selected from the LabVIEW project or returned from XNET Create Session.vi . The session mode must be Signal Input XY. is the number of values desired. number to read If number to read is positive (or 0), the size of value arrays is no greater than this number. If number to read is negative (typically –1), the maximum number of values is returned. This input is optional. The default value is –1. XNET Read (Signal values are received for any signal, number to read If XY).vi time limit has not occurred. returns those values, even if the Therefore, to read values up to the time limit, leave number to read unwired (–1). time limit is the timestamp to wait for before returning signal values. If time limit is valid, XNET Read (Signal XY).vi waits for the timestamp to occur, then returns available values (up to number to read ). If you increment by a fixed number of seconds for each call to XNET time limit Read (Signal XY).vi , you effectively obtain a moving window of signal values. If time limit is unwired (invalid), XNET Read (Signal XY).vi returns number to immediately all available values up to the current time (up to ). read 4-204 NI-XNET Hardware and Software Manual ni.com

270 Chapter 4 IEW—XNET Read (Signal XY).vi NI-XNET API for LabV This input is optional. The default value is an invalid timestamp. The of other XNET Read.vi instances specifies the maximum timeout number to read amount time to wait for a specific time limit values. The of XNET Read (Signal XY).vi does not specify a worst-case timeout value, but rather a specific absolute timestamp to wait for. error in is the error cluster input (refer to Error Handling ). Outputs is the same as session in , provided for use with subsequent VIs. session out data returns an array of LabVIEW clusters. Each array element corresponds to a signal configured for the session. The order of signals in the array correspo nds to the order in the session list. Each cluster contains two arrays, one for timestamp and one for value . For timestamp arrays always is the same, value and each signal, the size of the array of timestamp/value pairs. such that it represents a single Each timestamp/value pair represents a value from a received frame. When signals exist in differen t frames, the array sizes may be different from one cluster (signal) to another. The cluster elements are: timestamp is the array of LabVIEW timestamps, one for each frame received that contains the signal. Each timestamp represents the absolute time when the XNET interface received the frame (e nd of frame), accurate to microseconds. one for each frame received that value is the array of signal values, contains the signal. Each signal value is scaled, 64-bit floating point. value array size is the same as the timestamp array size. The For an example of how this data applies to network traffic, refer to Signal . Input XY Mode When you use this inst ance with a session of Signal Input Single-Point and timestamp are ignored, and the Mode , time limit and number to read arrays always contain only one el value ement per signal. This effectively returns a single pair of timestamp and value for every signal. 4-205 © National Instruments NI-XNET Hardware and Software Manual

271 Chapter 4 IEW—XNET Read (Signal XY).vi NI-XNET API for LabV ). Error Handling error out is the error cluster output (refer to Description , You also can use this instance to read data from a session of Signal Input Single-Point Mode although XNET Read (Signal Single-Point).vi is more common for that mode. lue pairs for each signal in the session. You The data represents an XY plot of timestamp/va can wire the data directly to a LabVIEW XY Graph for display. 4-206 NI-XNET Hardware and Software Manual ni.com

272 Chapter 4 NI-XNET API for LabVIEW— XNET Read (State CAN Comm).vi XNET Read (State CAN Comm).vi Purpose Reads the state of CAN communi cation using an XNET session. Format Inputs on is selected from the LabVIEW is the session to read. This sessi session in project or returned from XNET Create Session.vi . is the error cluster input (refer to error in Error Handling ). Outputs , provided for use with subsequent VIs. session in is the same as session out returns a LabVIEW cluster containing the communication CAN comm elements. The elements are: communication state specifies the CAN interface state with respect to error confinement (d ecimal value in parentheses): Error Active (0) This state reflects normal communication, with few errors detected. The CAN interface remains in this state as long as receive error counter and transmit error counter are both below 128. Error Passive (1) receive error counter or If either the transmit error counter increment above 127, the CAN interface transitions into this state. Although commun ication proceeds, the CAN device generally is assumed to have problems with receiving frames. When a CAN interface is in error passive state, acknowledgement errors do not increment the . transmit error counter 4-207 © National Instruments NI-XNET Hardware and Software Manual

273 Chapter 4 W—XNET Read (State CAN Comm).vi NI-XNET API for LabVIE Therefore, if the CAN interface transmits a frame with no other device (ECU) connected, it eventually enters error passive state due to retransmissions, but does not enter bus off state. increments Bus Off (2) If the transmit error counter above 255, the CAN interface transitions into this state. Communication immediately stops under the assumption that the CAN interface must be isolated from other devices. When a CAN interface tr ansitions to the bus off state, communi cation stops for the interface. All NI-XNET sessions for the interface no longer receive or transmit frame values. To restart the CAN interface and all its . sessions, call XNET Start.vi This is the CAN interface initial state on Init (3) power-up. The interface is essentially off, in that it is not attempting to communicate with other nodes (ECUs). When the start trigger occurs for the CAN interface, it transitions from the Init state to the Error Active state. When the interface stops due to a call to XNET Stop.vi , the CAN interface transitions from either Error Active or Error Passive to the Init state. When the interface stops due to the Bus Off state, it remains in that state until you restart. transceiver error? indicates whether an error condition exists on the physical transceiver. This is typically referred to as the transceiver chip NERR pin. Fa lse indicates normal operation (no error), and true indicates an error. sceiver and communication sleep? indicates whether the tran controller are in their sleep stat e. False indicates normal operation (awake), and true indicates sleep. last attempt to receive or last error specifies the status of the transmit a frame (decimal value in parentheses): The last receive or transmit was successful. None (0) 4-208 NI-XNET Hardware and Software Manual ni.com

274 Chapter 4 XNET Read (State CAN Comm).vi NI-XNET API for LabVIEW— Stuff (1) More than 5 equal bits have occurred in sequence, which the CAN specification does not allow. Form (2) A fixed format part of the received frame used the wrong format. Ack (3) Another node (ECU) did not acknowledge the frame transmit. and do not have a cable XNET Write.vi If you call connected, or the cable is co nnected to a node that is not communicating, you see this error repeatedly. communication state eventually The CAN transitions to Error Passive, and the frame transmit retries indefinitely. Bit 1 (4) During a frame transmit (w ith the exception of the arbitration ID field), the interface wanted to send a recessive bit (logical 1), but the monitored bus value was dominant (logical 0). ith the exception of the During a frame transmit (w Bit 0 (5) arbitration ID field), the interface wanted to send a dominant bit (logical 0), but the monitored bus value was recessive (logical 1). The CRC contained within a received frame does CRC (6) not match the CRC calculated for the incoming bits. The receive error counter begins at 0 when communication starts on the CAN interface. The counter increments when an error is detected for a received frame an d decrements when a frame is received successfully. The counter increases more for an error than it is decreased for success. This ensures that the counter ratio of frames (roughly 1/8) generally increases when a certain encounter errors. The en communication begins at 0 wh transmit error counter unter increments when an error starts on the CAN interface. The co is detected for a transmitted fr ame and decrements when a frame transmits successfully. The counte r increases more for an error than it is decreased for success. This ensures that the counter generally increases when a certain ratio of frames (roughly 1/8) encounter errors. transmit transitions to Bus Off, the When communication state error counter no longer is valid. 4-209 © National Instruments NI-XNET Hardware and Software Manual

275 Chapter 4 W—XNET Read (State CAN Comm).vi NI-XNET API for LabVIE indicates that a fault occurred, and its code is available as fault? . fault code fault code returns a numeric code you can use to obtain a description of the fault. If is false, the fault code is 0. fault? A fault is an error that occurs asynchronously to the NI-XNET VIs your application calls. The fault cause may be related to CAN communication, but it also can be related to XNET hardware, such as a fault in the onboard processor. Although faults are extremely XNET Read (State CAN Comm).vi provides a detection rare, method distinct from the error out of NI-XNET VIs, yet easy to use alongside the common practice of checking the communication state. To obtain a fault description, wire the fault code into the LabVIEW Simple Error Handler.vi error code input and view fault code . You also can bundle the into a the resulting message LabVIEW error cluster as the element and use front panel code features to view the error description. error out is the error cluster output (refer to Error Handling ). Description You can use XNET Read (State CAN Comm).vi with any XNET session mode, as long as the session interface is CAN. B ecause the state reflects the CA N interface, it can apply to multiple sessions. Your application can use XNET Read (State CAN Comm).vi to check for problems on the CAN network independently from other aspects of your application. For example, you intentionally may introduce noise into the CAN cables to test how your ECU behaves under error out of NI-XNET VIs to return these conditions. When you do this, you do not want the errors, because this may cause your appli cation to stop. Your application can use XNET Read (State CAN Comm).vi to read the CAN network state quickly as data, so that it does not introduce errors into the flow of your LabVIEW VIs. Alternately, to log bus errors, you can set the Interface:Bus Error Fram es to Input Stream? for property to cause CAN bus errors to be logged as a special frame (refer to Special Frames Frame Stream Input queue. more information) into a 4-210 NI-XNET Hardware and Software Manual ni.com

276 Chapter 4 NI-XNET API for LabVIEW—XN ET Read (State FlexRay Comm).vi XNET Read (State FlexRay Comm).vi Purpose Reads the state of FlexRay comm unication using an XNET session. Format Inputs session in is the session to read. This sessi on is selected from the LabVIEW project or returned from XNET Create Session.vi . error in is the error cluster input (refer to Error Handling ). Outputs is the same as session out , provided for use with subsequent VIs. session in FlexRay comm returns a LabVIEW cluster containing the communication elements. The elements are: POC state specifies the FlexRay interface state (decimal value in parentheses): This is the FlexRay interface initial state on Default Config (0) power-up. The interface is essentially off, in that it is not configured and is not attempting to communicate with other nodes (ECUs). Ready (1) When the interface starts, it first enters Config state to validate the FlexRay cluster and interface properties. Assuming the properties are valid, the interface transitions to this Ready state. In the Ready state, the FlexRay interface attempts to integrate (synchronize) with other nodes in the network cluster. This integration process can take several 4-211 © National Instruments NI-XNET Hardware and Software Manual

277 Chapter 4 XNET Read (State FlexRay Comm).vi NI-XNET API for LabVIEW— FlexRay cycles, up to 200 ms. If the integration succeeds, the interface transitions to Normal Active. You can use XNET Read (State Time Start).vi to read the time when the FlexRay interface entered Ready. If integration XNET Read (State succeeds, you can use to read the time when the Time Comm).vi FlexRay entered Normal Active. Normal Active (2) This is the normal operation state. The NI-XNET interface is adequately synchronized to the cluster to allow continued frame transmission without disrupting the transmissions of other nodes (ECUs). If synchronization problems transition from this occur, the interface can state to Normal Passive. Normal Passive (3) Frame reception is allowed, but frame transmission is disabled due to degraded synchronization with the cluster remainder. If synchronization improves, the interface can transition to Normal Active. If synchronization continues to degrade, the interface transitio ns to Halt. Halt (4) Communication halted due to synchronization problems. When the FlexRay interface is in Halt state, all NI-XNET sessions for the interface stop, and no frame values are received or transmitted. To restart the FlexRay interface, you must restart the NI-XNET sessions. If you clear (close) all NI-XNET sessions ansitions from Halt to for the interface, it tr Default Config state. Config (15) This state is transitional when configuration is valid. If you detect this interface, it typically state after starting the the configuration. indicates a problem with 4-212 NI-XNET Hardware and Software Manual ni.com

278 Chapter 4 ET Read (State FlexRay Comm).vi NI-XNET API for LabVIEW—XN Check the fault? output for a fault. If no fault is returned, check your FlexRay cluster and interface properties. You can check the validity of these properties using the NI-XNET Database Editor , which displays invalid configuration properties. In the FlexRay specification, this value is referred to as the Protocol Operation Control (POC) state. For more information about the FlexRay POC state, refer to Appendix B, Summary of the FlexRay Standard . clock correction failed returns the number of consecutive even/odd cycle pairs that have occurred without successful clock synchronization. If this count reaches the value in the XNET Cluster FlexRay:Max property, the FlexRay interface Without Clock Correction Passive POC state transitions from Normal Active to Normal Passive state. If this count reaches the value in the XNET cluster FlexRay:Max Without Clock Correction Fatal property, the FlexRay interface POC state trans itions from Norm al Passive to Halt state. In the FlexRay specification, th is value is referred to as vClockCorrectionFailed . passive to active count returns the number of consecutive even/odd cycle pairs that have occurred with successful clock synchronization. This count increments while the FlexRay interface is in POC state Error Passive. If the count reaches the value in the XNET Session Interface:FlexRay:Allow Passive to Active property, the interface POC state transitions to Normal Active. In the FlexRay specification, th is value is referred to as vAllowPassiveToActive . fault? indicates that a fault occurred, and its code is available is fault code. returns a numeric code you can use to obtain a fault fault code is false, the fault code is 0. fault? description. If 4-213 © National Instruments NI-XNET Hardware and Software Manual

279 Chapter 4 XNET Read (State FlexRay Comm).vi NI-XNET API for LabVIEW— asynchronously to A fault is an error that occurs the NI-XNET VIs your application calls. The fault cause may be related to FlexRay communication, but it also can be related to XNET hardware, such as a fault in the onboard processor. Although faults are extremely XNET Read (State FlexRay Comm).vi provides a rare, detection method distinct from the error out of NI-XNET VIs, yet easy to use alongside the common practice of checking the communication state. fault code into the To obtain a fault description fault, wire the LabVIEW Simple Error Handler.vi error code input and view the resulting message . You also can bundle the fault code into a LabVIEW error cluster as the element and use front panel code features to view the error description. channel A sleep? indicates whether channel A currently is asleep. indicates whether channe channel B sleep? l B currently is asleep. is the error cluster output (refer to Error Handling error out ). Description You can use XNET Read (State FlexRay Comm).vi with any XNET session mode, as long as the session interface is FlexRay. Because th e state reflects the FlexRay interface, it can apply to multiple sessions. XNET Read (State FlexRay Comm).vi to check for problems on Your application can use the FlexRay network independently from the other aspects of your application. For example, you intentionally may introduce noise into the FlexRay cables to test how your ECU behaves under these conditions. When you do this, you do not want the error out of NI-XNET VIs to return errors, because this ma y cause your application to st op. Your application can use XNET Read (State FlexRay Comm).vi to read the FlexRay network state quickly as data, so that it does not introduce errors into the flow of your LabVIEW VIs. 4-214 NI-XNET Hardware and Software Manual ni.com

280 Chapter 4 XNET Read (State LIN Comm).vi NI-XNET API for LabVIEW— XNET Read (State LIN Comm).vi Purpose Reads the state of LIN communi cation using an XNET session. Format Inputs session in is the session to read. This sessi on is selected from the LabVIEW project or returned from XNET Create Session.vi . The session must use a LIN interface. error in is the error cluster input (refer to Error Handling ). Outputs session out is the same as session in , provided for use with subsequent VIs. returns a LabVIEW cluster LIN comm communication containing the elements. The elements are: communication state specifies the LIN interface state (decimal value in parentheses): ace initial state on power-up. Idle (0): This is the LIN interf The interface is essentially off, in that it is not attempting to communicate with other nodes (ECUs). When the start trigger occurs for the LIN interface, it transitions fr om the Idle state to the Active state. When the interface stops due to a call to XNET Stop, the LIN in terface transitions from either Active or Inactive to the Idle state. (1): This state reflects normal communication. The Active is state as long as bus LIN interface remains in th activity is detected (frame headers received or transmitted). 4-215 © National Instruments NI-XNET Hardware and Software Manual

281 Chapter 4 NI-XNET API for LabVIEW—XNET Read (State LIN Comm).vi (2): Inactive This state indicates that no bus activity has been detected in the past four seconds. Regardless of whether the interface acts as a master or slave, it transitions to this state after four seconds of bus inactivity. As soon as bus activity is detected (break or fr ame header), the interface transitions to the Active state. The LIN interface does not go to sleep automatically when it tran sitions to Inactive. To place the interface into sleep mode, set the XNET property when you Session Interface:LIN:Sleep detect the Inactive state. indicates whether the tran sceiver and communication sleep? controller are in their sleep stat e. False indicates normal operation (awake), and true indicates sleep. This Boolean value changes from fa lse to true only when you set the XNET Session Interface:LIN:Sleep property to Remote Sleep . or Local Sleep true to false when one of the This Boolean value changes from following occurs: You set the XNET Session Interface:LIN:Sleep property to • Remote Wake or Local Wake . • The interface receives a remote wakeup pattern (break). In addition to this XNET Read VI, you can wait for a remote wakeup event using XNET Wait (LIN Remote Wakeup).vi . transceiver ready? indicates whether the LIN transceiver is powered from the bus. True indicates the bus power exists, so it is safe to start communication on the LIN interface. If this value is false, you canno t start communication successfully. Wire power to the LIN transceive r and run your application again. last error specifies the status of the last attempt to receive or transmit a frame. It is an enumeration (ring data type). For a table of all values for last error , refer to the Description section. returns the value received from the network when last received occurred. last error 4-216 NI-XNET Hardware and Software Manual ni.com

282 Chapter 4 XNET Read (State LIN Comm).vi NI-XNET API for LabVIEW— last expected returns the value that the LIN interface expected to ). see (instead of last received last identifier returns the frame identifier in which the last error occurred. indicates that a fault occurred, and its code is available as fault? fault code . returns a numeric code you can use to obtain a fault code description of the fault. If fault? is false, the fault code is 0. A fault is an error that occurs asynchronously to the NI-XNET VIs your application calls. The fault cause may be related to LIN communication, but it also can be related to XNET hardware, such as a fault in the onboard processor. Although faults are extremely rare, the provides a detection XNET Read (State LIN Comm).vi method distinct from the error out of NI-XNET VIs, yet easy to use alongside the common practice of checking the communication state. To obtain a fault description, wire the into the fault code LabVIEW Simple Error Handler.vi error code input and view the resulting message . You also can bundle the fault code into a LabVIEW error cluster as the code element and use front panel features to view the error description. For more information, refer to Fault Handling . schedule index indicates the LIN schedule that the interface is currently running. This index refers to a LIN schedule that you requested using XNET Write (State LIN Schedule Change).vi . It indexes the array of schedules that are re presented in the XNET Session Interface:LIN:Schedules property. This index applies only when the LIN interface is running as a master. If the LIN interface is runn ing as a slave only, this element should be ignored. is the error cluster output (refer to ). Error Handling error out 4-217 © National Instruments NI-XNET Hardware and Software Manual

283 Chapter 4 NI-XNET API for LabVIEW—XNET Read (State LIN Comm).vi Description You can use with any XNET session mode, as long as XNET Read (State LIN Comm).vi the session interface is LIN. Because the stat e reflects the LIN interface, it can apply to multiple sessions. Your application can use to check for problems on the XNET Read (State LIN Comm).vi LIN network independently from other aspects of your application. For example, you intentionally may introduce noise into the LIN cables to test how your ECU behaves under these conditions. When you do this, you do not want the error out of NI-XNET VIs to return errors, because this may cause your appli cation to stop. Your application can use XNET Read (State LIN Comm).vi ly as data, so that it does not to read the LIN network state quick introduce errors into the flow of your LabVIEW VIs. The following table lists each value for last error , along with a description, and applicable use of last received , last expected , and last identifier . In the last error column, the decimal value is shown in parentheses after the string name. Last Last Last Received Expected Identifier Last Error Description 0 (N/A) 0 (N/A) None (0) No bus error has occurred since 0 (N/A) the previous communication state read. 0 (N/A) 0 (N/A) Unknown ID (1) Received a frame identifier that 0 (N/A) is not valid (0–63). 0 (N/A) Form (2) The form of a received frame is Received 0 (N/A) frame ID incorrect. For example, the database specifies 8 bytes of payload, but you receive only 4 bytes. 0 (N/A) Framing (3) The byte framing is incorrect 0 (N/A) Received (for example, a missing stop frame ID bit). Received The interface transmitted a Readback (4) Va l u e Value read byte, but the value read back frame ID back transmitted from the transceiver was different. This often is caused by a cabling problem, such as noise. 4-218 ni.com NI-XNET Hardware and Software Manual

284 Chapter 4 XNET Read (State LIN Comm).vi NI-XNET API for LabVIEW— Last Last Last Received Expected Identifier Description Last Error Received Receiving the frame took 0 (N/A) 0 (N/A) Timeout (5) longer than the LIN-specified frame ID timeout. The received checksum was Calculated Received Received Checksum (6) frame ID checksum different than the expected checksum checksum. last at time when no frame ID is received (such as wakeup), If the bus error is detected uses the special value 64. identifier errors, you can set the Interface:Bus Error Fram es to Input Stream? Alternately, to log bus for logged as a special frame (refer to property to cause LIN bus errors to be Special Frames more information) into a Frame Stream Input queue. NI-XNET Hardware and Software Manual 4-219 National Instruments ©

285 Chapter 4 NI-XNET API for LabVIEW—XNET Re ad (State FlexRay Cycle Macrotick).vi XNET Read (State Flex Ray Cycle Macrotick).vi Purpose Reads the current FlexRay global time using an XNET session. Format Inputs ion is selected from a LabVIEW session in is the session to read. This sess project or returned from . XNET Create Session.vi error in is the error cluster input (refer to Error Handling ). Outputs session out is the same as session in , provided for use with subsequent VIs. returns the current FlexRay cycle counter. The cycle counter range is cycle current cycle counter is referred to 0–63. In the FlexRay specification, the as . vCycleCounter The XNET Cluster FlexRay:Cycle property returns the cycle length in microseconds. macrotick returns the current FlexRay macrotick. In the FlexRay specification, the current macr otick is referred to as vMacrotick . FlexRay:Macro Per Cycle The XNET Cluster property returns the number of macroticks in the cycle. The cu XNET rrent macrotick returned from this Read.vi instance ranges from 0 to ( FlexRay:Macro Per Cycle – 1). The XNET Cluster FlexRay:Macrotick property returns the macrotick length in floating-point seconds. ). Error Handling is the error cluster output (refer to error out 4-220 NI-XNET Hardware and Software Manual ni.com

286 Chapter 4 NI-XNET API for LabVIEW—XNET Read (State FlexRay Cycle Macrotick).vi Description Global time represents the timebase that all EC Us on the FlexRay network cluster share. You onents are the current me. The global time comp use sync frames to synchronize the global ti cycle counter and macrotick within the cycle. For more information about global time, refer to Appendix B, Summary of the FlexRay Standard . You can use this instance with any XNET session mode, as long as the session XNET Read.vi the FlexRay interface, it can apply to multiple interface is FlexRay. Because the state reflects sessions. For this VI to operate prop erly, you must connect FlexRay global time as the FlexRay interface timebase source. To do this, you must call XNET Connect Terminals.vi with a source of FlexRay Macrotick and destination of Master Timebase. If the terminals are not connected in this manner, this XNET Read.vi instance returns an error. When using LabVIEW Real-Time, this VI often is useful in conjunction with XNET Create Timing Source (FlexRay Cycle).vi . The FlexRay Cycle timing source enables a LabVIEW ithin the cycle. Only one FlexRay Cycle timing timed loop to execute at a specific macrotick w source is allowed within the cycle. Within th e timed loop, you can read the current FlexRay global time to measur e performance or synchronize LabVIE W code to additional macroticks in the cycle. 4-221 © National Instruments NI-XNET Hardware and Software Manual

287 Chapter 4 NI-XNET API for LabVIEW—XNET Read (State FlexRay Statistics).vi XNET Read (State Fl exRay Statistics).vi Purpose Reads statistics for FlexRay comm unication using an XNET session. Format Inputs is the session to read. This sess ion is selected from a LabVIEW session in project or returned from XNET Create Session.vi . Error Handling error in is the error cluster input (refer to ). Outputs , provided for use with subsequent VIs. session in session out is the same as returns a LabVIEW cluster that contains the statistical FlexRay statistics elements. The elements are: num syntax error ch A is the number of syntax errors that have occurred on channel A si nce communication started. A syntax error occurs if: • A node starts transmitting while the channel is not in the idle state. • There is a decoding error. • A frame is decoded in the symbol window or in the network idle time. • atic segment, dynamic segment, A symbol is decoded in the st or network idle time. • A frame is received within the slot after reception of a semantically correct frame (t wo frames in one slot). • Two or more symbols are recei ved within the symbol window. is the number of syntax errors that have num syntax error ch B ce communication started. occurred on channel B sin 4-222 NI-XNET Hardware and Software Manual ni.com

288 Chapter 4 Read (State FlexRay Statistics).vi NI-XNET API for LabVIEW—XNET num content error ch A is the number of content errors that have occurred on channel A si nce communication started. A content error occurs if: • In a static segment, the payload length of a frame does not match the global cluster property. p indicator (bit) is 1 while the In a static segment, the Startu • Sync indicator is 0. • A frame ID encoded in the frame header does not match the current slot. • frame’s header does not match A cycle count encoded in the the current cycle count. • In a dynamic segment, the Sync indicator is 1. Startup indicator is 1. In a dynamic segment, the • In a dynamic segment, the Null indicator is 0. • num content error ch B is the number of content errors that have ce communication started. occurred on channel B sin num slot boundary violation ch A is the number of slot boundary violations that have occurred on channel A since communication started. A slot boundary violation error occurs if the interface does not consider the channel to be idle at the boundary of a slot (either beginning or end). num slot boundary violation ch B is the number of slot boundary on channel B since communication violations that have occurred started. For more information about these statistics, refer to Appendix B, . Summary of the FlexRay Standard ). error out is the error cluster output (refer to Error Handling Description You can use this XNET Read.vi instance with any XNET session mode, as long as the ecause the state reflects the FlexRay interface, it can apply to session’s interface is FlexRay. B multiple sessions. instances, this VI executes quickly, so it is appropriate for XNET Read.vi Like other real-time loops. The statistical information is updated during the Network Idle Time (NIT) of each FlexRay cycle. 4-223 © National Instruments NI-XNET Hardware and Software Manual

289 Chapter 4 NI-XNET API for LabVIEW—XNET Read (State Time Comm).vi XNET Read (State Time Comm).vi Purpose Reads the time at which the session’s interface completed its integration with the network cluster. This represents the time at which communication began. Format Inputs session in is the session to read. This sess ion is selected from a LabVIEW project or returned from XNET Create Session.vi . error in Error Handling ). is the error cluster input (refer to Outputs session out is the same as session in , provided for use with subsequent VIs. time communicating returns the communication time of the interface as a LabVIEW absolute timestamp. If the interface is not communicat time ing when this read is called, communicating returns an invalid time (0). is the error cluster output (refer to Error Handling ). error out Description XNET Read.vi instance with any XNET session mode. Because the time is You can use this associated with the interface, it can apply to multiple sessions. This XNET Read.vi instance returns time as a LabVIEW absolute timestamp data type. After your application starts the XNET interface hardware, the communicatio n controller begins to integrate with ECUs in the network. The timestamp at which this integration starts is available using XNET Read (State Time Start).vi . Once the XNET interface is fully integrated and communicating on the network (t ransmitting and receiving frames), this VI captures and returns the time. For the CAN prot ocol, the time difference between Start and y protocol, the time di Communicating is very small. For the FlexRa fference can be many milliseconds due to factors such as cl ock synchronization and cycle length. 4-224 NI-XNET Hardware and Software Manual ni.com

290 Chapter 4 LabVIEW—XNET Read (Sta NI-XNET API for te Time Current).vi XNET Read (State Time Current).vi Purpose Reads the current interface times tamp using an XNET session. Format Inputs session in is the session to read. This sessi on is selected from the LabVIEW project or returned from XNET Create Session.vi . error in Error Handling ). is the error cluster input (refer to Outputs session out is the same as session in , provided for use with subsequent VIs. time current returns the current interface timestamp as a LabVIEW absolute time. If the interface is not started when XNET Read (State Time time current returns is called, Current).vi an invalid time (0). is the error cluster output (refer to Error Handling ). error out Description You can use XNET Read (State Time Current).vi with any XNET session mode. Because the time is associated with the interf ace, it can apply to multiple sessions. returns time as a LabVIEW absolute timestamp data XNET Read (State Time Current).vi type. The timestamp repr esents absolute time that the interface timebase source drives. You use the timebase source to time stamp frames the interface recei ves. For a CAN interface, you use the timebase source to schedule cyclic frame transmit. The interface timebase source is not necessarily connected to the LabVIEW CPU clock, so this timestamp can drift relative to the LabVIEW time used for internally sourced timed loops and Get Date/Time in Seconds.vi . XNET Connect terface timebase source, refer to For more information about the in Terminals.vi . 4-225 © National Instruments NI-XNET Hardware and Software Manual

291 Chapter 4 NI-XNET API for LabVIEW—XNET Read (State Time Start).vi XNET Read (State Time Start).vi Purpose terface started its integration. Reads the time when the session in Format Inputs session in on is selected from the LabVIEW is the session to read. This sessi project or returned from XNET Create Session.vi . error in is the error cluster input (refer to Error Handling ). Outputs is the same as session in , provided for use with subsequent VIs. session out time start returns the interface start time as a LabVIEW absolute timestamp. If the interface is not started when XNET Read (State Time Start).vi is returns an invalid time (0). time start called, is the error cluster output (refer to Error Handling ). error out Description You can use XNET Read (State Time Start).vi with any XNET session mode. Because the time is associated with the interface, it can apply to multiple sessions. returns time as a LabVIEW absolute timestamp data type. XNET Read (State Time Start).vi ts the interface simply by calling XNET Read.vi Your application typically star XNET or Auto Write.vi , because the XNET Session Auto Start? property is true by default. If you set Start? to false, you start the interface using XNET Start.vi . If you use XNET Connect all sessions for that interface wait for to import a start trigger for the interface, Terminals.vi the trigger to occur before starting the interface. 4-226 NI-XNET Hardware and Software Manual ni.com

292 Chapter 4 NI-XNET API for LabVIEW—XNET Read (State Time Start).vi d returns the time. Unless you connect a start Once the interface starts, this VI captures an trigger, this time generally is known, so this VI may not be useful. After the XNET interface starts, the communication controller begins to integrate with ECUs lete, the time is captured and available using in the network. After this integration is comp . That time often is useful for FlexRay, because it XNET Read (State Time Comm).vi indicates the time when true communication began. NI-XNET Hardware and Software Manual © National Instruments 4-227

293 Chapter 4 XNET Read (State Session Info).vi NI-XNET API for LabVIEW— XNET Read (State Session Info).vi Purpose Returns the current state for the session provided. Format Inputs session in is the session to read. This sessi on is selected from the LabVIEW project or returned from . XNET Create Session.vi is the error cluster input (refer to Error Handling ). error in Outputs session out is the same as session in , provided for use with subsequent VIs. returns the state of the provided session. session info state Stopped (0) All frames in the session are stopped. Started (1) session are started. All frames in the Mix (2) Some frames in the session ar e started while other frames are stopped. error out is the error cluster output (refer to Error Handling ). Description You can use XNET Read (State Session Info).vi with any XNET session mode. returns the state of the se ssion’s objects. A mixed state XNET Read (State Session Info).vi XNET Start.vi may occur when using or with the Session Only option. By XNET Stop.vi es in the session have started or reading this state, your application can ensure that all fram stopped. Session Only, the state is known, so this VI If the session is started with any option other than may not be useful. 4-228 NI-XNET Hardware and Software Manual ni.com

294 Chapter 4 NI-XNET API fo r LabVIEW—XNET Write.vi XNET Write.vi Purpose Writes data to the network using an XNET session. Description The instances of this polymorphic VI specify the type of data provided. XNET Read.vi XNET Write.vi are optimized for r eal-time performance. XNET and resources that can induce jitter on other Write.vi executes quickly and avoids access to shared VI priorities. XNET Write.vi instances are asynchronous, in that data is written to a hardware buffer, The but the XNET Write.vi returns before the corresponding frames are transmitted onto the XNET Write.vi to transmit onto the network. If you need to wait for the data provided to XNET Wait (Transmit Complete).vi network, use . XNET Write There are two categories of instance VIs: Signal : Use when the sessio • XNET Write. vi in n mode is Signal Output. The stance must match the mode exactly (for example, the inst ance is Signal Waveform when the mo de is Signal Output Waveform). Frame : Use instance Write.vi • XNET t. Th when the session mode is Frame Outpu e an specifies th fram es and is not related to th e mode. For pe for e desired data ty easy-to-use data ty pe, us e the CAN, FlexRay, or LIN instance. • State : Use to change the session’s interface state. You can use these instances in addition to Signal or Frame instances, and they are not related to the mode. These instances are optimized for performance. Although property nodes may provide write access to similar runtime data, those properties are not necessarily optimized for real-time loops. The XNET Write instance VIs are: • XNET Write (Signal Single-Point).vi : The session mode is Signal Output Single-Point. : The session mode is Signal Output Waveform. XNET Write (Signal Waveform).vi • • XNET Write (Signal XY).vi : The session mode is Signal Output XY. • XNET Write (Frame CAN).vi : The session uses a CAN interface, and the mode is Frame Output Stream Mode , Frame Output Single-Point Mode, or Frame Output Queued Mode . Additionally, XNET Write (Frame CAN).vi can be called on any signal or frame input session if it contains one or more Event Remote frames (refer to CAN:Timing Type ). In this case, it signals an event to transmit those remote frames. : The session uses a FlexRay interface, and the mode • XNET Write (Frame FlexRay).vi , Frame Output Queued Mode is Frame Output Single-Point Mode , PDU Output 4-229 © National Instruments NI-XNET Hardware and Software Manual

295 Chapter 4 NI-XNET API for LabVIEW—XNET Write.vi Frame Output Si ), or PDU Output Single-Point Mode (similar to ngle-Point Mode Frame Output Queued Mode Queued Mode (similar to ). • XNET Write (Frame LIN).vi : The session uses a LIN interface, and the mode is Frame Frame Output Single-Point Mode . Frame Output Queued Mode Output Stream Mode , , or • XNET Write (Frame Raw).vi : A data type for frame output that is protocol independent N, FlexRay, and LIN instances. and more efficient than the CA • e FlexRay interface to : Writes a request for th XNET Write (State FlexRay Symbol).vi transmit a symbol on the FlexRay bus. XNET Write (State LIN Schedule Change).vi : Submits a request for the LIN interface • to change the running schedule. 4-230 NI-XNET Hardware and Software Manual ni.com

296 Chapter 4 NI-XNET API for LabVIEW—XN ET Write (Signal Single-Point).vi XNET Write (Signal Single-Point).vi Purpose Writes data to a session of Signal Output Single-Point Mode . Format Inputs is the session to write. This session is selected from the session in XNET Create Session.vi . The session LabVIEW project or returned from mode must be Signal Output Single-Point. provides a one-dimensional array data of signal values. Each signal value is scaled, 64-bit floating point. Each array element corresponds to a signal configured for the session. The nds to the order in the session list. order of signals in the array correspo XNET e next transmit of each signal. If The data provides the value for th Write (Signal Single-Point).vi is called twice before the next transmit, the transmitted frame uses signal values from the second call to XNET Write (Signal Single-Point).vi . For an example of how this data applies to network traffic, refer to Signal Output Single-Point Mode . A trigger signal written a value of 0.0 suppresses writing of its frame’s data; writing a value not equal to 0.0 enables it. For more information about trigger signals, refer to . Signal Output Single-Point Mode error in is the error cluster input (refer to Error Handling ). Outputs session out is the same as session in , provided for use with subsequent VIs. ). Error Handling is the error cluster output (refer to error out 4-231 © National Instruments NI-XNET Hardware and Software Manual

297 Chapter 4 W—XNET Write (Signal Waveform).vi NI-XNET API for LabVIE XNET Write (Signal Waveform).vi Purpose Writes data to a session of Signal Output Waveform Mode . The data represents a waveform of resampled values for each signal in the session. Format Inputs is the session to write. This session is selected from the session in LabVIEW project or returned from XNET Create Session.vi . The session mode must be Signal Output Waveform. data provides a one-dimensional array of LabVIEW waveforms. The data you write is queued up for transmit on the network. Using the default queue configuration for this mode, and assuming a 1000 Hz resample rate, you can safely write 64 frames if you have a sufficiently long timeout. To write more data, refer to the XNET Session Number of Values Unused l amount of queue space available property to determine the actua for writing. For an example of how this data applies to network traffic, refer to Signal Output Waveform Mode . Each array element corresponds to a signal configured for the session. The order of signals in the array correspo nds to the order in the session list. The waveform elements are: t0 is the waveform start time. This is a LabVIEW absolute timestamp. This start time is unused (reserve d) for Signal Output Waveform mode. If you change it from its default value of 0 (invalid), XNET Write (Signal Waveform).vi returns an error. dt is the waveform delta time. This is a LabVIEW relative time tween each sample in the array. Y that specifies the time be 4-232 NI-XNET Hardware and Software Manual ni.com

298 Chapter 4 W—XNET Write (Signal Waveform).vi NI-XNET API for LabVIE LabVIEW relative time is represented as 64-bit floating point in units of seconds. This delta time is unused (reserved) for Signal Output Waveform mode. If you change it from its default value of 0, XNET Write returns an error. (Signal Waveform).vi Y values. Each signal value is is the array of resampled signal scaled, 64-bit floating point. The Y array size must be the same for all waveforms, because the size determines the total timeline for XNET Write (Signal Waveform).vi Y array sizes are not the same, XNET . If the Write (Signal Waveform).vi returns an error. timeout is the time to wait for the data to be queued for transmit. The timeout does not wait for frames to be transmitted on the network (refer to XNET Wait (Transmit Complete).vi ). The timeout is a LabVIEW relative time, represented as 64-bit floating-point in units of seconds. timeout waits up to that XNET Write (Signal Waveform).vi is positive, If timeout for space to become availabl e in queues. If the space is not available prior to the timeout, a timeout error is returned. If timeout is negative, XNET Write (Signal Waveform).vi waits indefinitely for space to become available in queues. If timeout is 0, XNET Write (Signal Waveform).vi does not wait and immediately returns an error if all data cannot be queued. Regardless of the timeout used, if a timeout error occurs, none of the data is queued, so you can attempt to call again at a later XNET Write (Signal Waveform).vi time with the same data. This input is optional. The default value is 10.0 (10 seconds). error in is the error cluster input (refer to Error Handling ). Outputs session out is the same as session in , provided for use with subsequent VIs. error out ). Error Handling is the error cluster output (refer to 4-233 © National Instruments NI-XNET Hardware and Software Manual

299 Chapter 4 NI-XNET API for LabV IEW—XNET Write (Signal XY).vi XNET Write (Signal XY).vi Purpose Writes data to a session of Signal Output XY Mode . The data represents a sequence of signal s timing as the database specifies. values for transmit using each frame’ Format Inputs session in is the session to write. This session is selected from the XNET Create Session.vi LabVIEW project or returned from . The session mode must be Signal Output XY. data provides an array of LabVIEW clusters. signal configured for the session. The Each array element corresponds to a nds to the order in the session list. order of signals in the array correspo The data you write is queued up for transmit on the network. Using the default queue configuration for this mode, you can safely write 64 elements if you have a sufficiently long timeout. To write more data, refer to the Number of Values Unused property to determine the actual XNET Session amount of queue space available for writing. For an example of how this data applies to network traffic, refer to Signal Output XY Mode . Each cluster contains two arrays, on e for value, and on e for timestamp. Each value is mapped to a frame fo r transmit. When signals exist in different frames, the array sizes may be different from one cluster (signal) to another. The cluster elements are: timestamp is the array of LabVIEW timestamps. The timestamp array is unused (reserved) for Signal Output XY. If you change it from its default value of empty, XNET Write (Signal XY).vi returns an error. 4-234 NI-XNET Hardware and Software Manual ni.com

300 Chapter 4 NI-XNET API for LabVIEW—XNET Write (Signal XY).vi value is the array of signal values, one for each frame that contains the signal. Frame transmission is timed according to the frame properties in the database. Each signal value is scaled, 64-bit floating point. timeout is the time to wait for the data to be queued for transmit. The timeout does not wait for frames to be transmitted on the network (refer to ). XNET Wait (Transmit Complete).vi The timeout is a LabVIEW relative time, represented as 64-bit floating-point in units of seconds. If timeout is positive, XNET Write (Signal XY).vi waits up to that e in queues. If the space is not timeout for space to become availabl available prior to the timeout, a timeout error is returned. If timeout is negative, waits indefinitely for XNET Write (Signal XY).vi space to become available in queues. If timeout is 0, XNET Write (Signal XY).vi does not wait and immediately returns with a timeout error if all data cannot be queued. Regardless of the timeout used, if a timeout error occurs, none of the data XNET Write (Signal XY).vi is queued, so you can attempt to call again at a later time with the same data. This input is optional. The default value is 10.0 (10 seconds). error in is the error cluster input (refer to Error Handling ). Outputs session out is the same as session in , provided for use with subsequent VIs. error out is the error cluster output (refer to ). Error Handling 4-235 © National Instruments NI-XNET Hardware and Software Manual

301 Chapter 4 IEW—XNET Write (Frame CAN).vi NI-XNET API for LabV XNET Write (Frame CAN).vi Purpose Writes data to a session as an array of CA N frames. The session must use a CAN interface Frame Output Stream Mode , Frame Output Queued Mode , or Frame Output Single-Point and . Mode Format Inputs session in is the session to write. This session is selected from the XNET Create Session.vi . The session LabVIEW project or returned from mode must be Frame Ou tput Stream, Frame Outp ut Queued, or Frame Output Single-Point. provides the array of LabVIEW clusters. data Each array element corresponds to a frame value to transmit. mode, the order of frames in the For a Frame Output Single-Point session array corresponds to the order in the session list. The data you write is queued up for transmit on the network. Using the default queue configuration for this mode, you can safely write 64 frames if you have a sufficiently long timeout. To write more data, refer to the Number of Values Unused XNET Session property to determine the actual amount of queue space available for write. Frame For an example of how this data applies to network traffic, refer to Frame Output Queued Mode , or Output Stream Mode , Frame Output . Single-Point Mode can be called on any signal Additionally, XNET Write (Frame CAN).vi or frame input session if it contains one or more Event Remote frames (refer to CAN:Timing Type ). In this case, it sign als an event to transmit parameter is ignored in this case, and you data those remote frames. The can set it to an empty array. 4-236 NI-XNET Hardware and Software Manual ni.com

302 Chapter 4 IEW—XNET Write (Frame CAN).vi NI-XNET API for LabV The elements of each cluster are spec ific to the CAN protocol. For more , or the information, refer to Appendix A, Summary of the CAN Standard CAN protocol specification. The cluster elements are: identifier is the CAN frame arbitration identifier. is false, the identifier uses standard format, so 11 bits If extended? of this identifier are valid. extended? is true, the identifier uses extended format, so 29 bits If of this identifier are valid. is a Boolean value that extended? determines whether the identifier uses extended format (tru e) or standard format (false). echo? is not used for transmit. You must set this element to false. type is the frame type (decimal value in parentheses): payload data. CAN Data (0) The CAN data frame contains This is the most commonly used frame type for CAN. CAN remote frame. Your application CAN Remote (1) transmits a CAN remote frame to request data identifier . A remote for the corresponding ECU should respond with a CAN data frame identifier , which you can obtain using for the XNET Read.vi . timestamp represents absolute time using the LabVIEW absolute is not used for transmit. You must set timestamp type. timestamp this element to the default value, invalid (0). es for a CAN data frame. payload is the array of data byt The array size indicates the payloa d length of the frame value to transmit. According to the CAN protocol, the payload length range is 0–8. For CAN FD, the range can be 0–8, 12, 16, 20, 24, 32, 48, or 64. When the session mode is Fram e Output Single-Point or Frame Output Queued, the number of bytes in the payload array must be Payload Length property of the less than or equal to the e all other CAN frame cluster corresponding frame. You can leav formation, refer to the section elements uninitialized. For more in for each mode. 4-237 © National Instruments NI-XNET Hardware and Software Manual

303 Chapter 4 IEW—XNET Write (Frame CAN).vi NI-XNET API for LabV CAN Remote type ), the payload For a transmitted remote frame ( length in the frame value specifi es the number of payload bytes requested. Your application provides this payload length by filling payload with the requested number of bytes. This enables your application to specify the fram e payload length, but the actual values in the payload bytes are ignored (not contained in the transmitted frame). is the time to wait for the CAN frame data to be queued up for timeout transmit. The timeout is a LabVIEW relative time, represented as 64-bit floating-point in units of seconds. If timeout is positive, XNET Write (Frame CAN).vi waits up to that timeout for space to become availabl e in queues. If the space is not available prior to the timeout, a timeout error is returned. XNET Write (Frame CAN).vi is negative, waits indefinitely If timeout for space to become available in queues. timeout is 0, XNET Write (Frame CAN).vi does not wait and If immediately returns with a timeout error if all data cannot be queued. Regardless of the timeout used, if a timeout error occurs, none of the data is queued, so you can attempt to call XNET Write (Frame CAN).vi again at a later time with the same data. This input is optional. The default value is 10.0 (10 seconds). timeout If the session mode is Frame Output Single-Point, you must set to 0.0. Because this mode writes th timeout e most recent value of each frame, does not apply. error in is the error cluster input (refer to Error Handling ). Outputs session out is the same as session in , provided for use with subsequent VIs. is the error cluster output (refer to Error Handling ). error out 4-238 NI-XNET Hardware and Software Manual ni.com

304 Chapter 4 IEW—XNET Write (Frame CAN).vi NI-XNET API for LabV Description The data represents an array of CAN frames. Each CAN frame uses a LabVIEW cluster with CAN-specific elements. session’s list of frames as follows: The CAN frames are associated to the : Array of all frame values for transmit (list ignored). Frame Output Stream Mode • • Frame Output Queued Mode : Array of frame values to transmit for the single frame specified in the list. • values, one for each frame : Array of single frame Frame Output Single-Point Mode specified in the list. Any signal or frame input mode: The parameter is ignored, and you can set it to an data • empty array. The VI transmits an event remote frame. 4-239 © National Instruments NI-XNET Hardware and Software Manual

305 Chapter 4 NI-XNET API for LabVIE W—XNET Write (Frame FlexRay).vi XNET Write (Frame FlexRay).vi Purpose Writes data to a session as an array of Fl exRay frames. The session must use a FlexRay . interface and Frame Output Queued Mode or Frame Output Single-Point Mode Format Inputs session in is the session to write. This session is selected from the LabVIEW project or returned from XNET Create Session.vi . The session Output Single-Point. mode must be Frame Ou tput Queued or Frame Frame Output Stream mode is not supported for FlexRay. provides the array of LabVIEW clusters. data Each array element corresponds to a frame value to transmit. For a Frame Input Single-Point session mode, the order of frames in the array corresponds to the order in the session list. The data you write is queued up for transmit on the network. Using the default queue configuration for this mode, and assuming frames with 8 bytes of payload, you can safely write 64 frames if you have a sufficiently long timeout. To write more data, refer to the XNET Session Number of Values Unused property to determine the actual amount of queue space available for write. Frame For an example of how this data applies to network traffic, refer to Frame Output Single-Point Mode Output Queued Mode or . The elements of each cluster are specifi c to the FlexRay protocol. For more , or the information, refer to Appendix B, Summary of the FlexRay Standard . FlexRay Protocol Specification 4-240 NI-XNET Hardware and Software Manual ni.com

306 Chapter 4 NI-XNET API for LabVIEW—XNET Write (Frame FlexRay).vi The cluster elements are: slot within the FlexRay cycle. specifies the slot number cycle count specifies the cycle number. The FlexRay cycle count increments from 0 to 63, then rolls over back to 0. startup? is a Boolean value that specifies whether the frame is a startup frame (true) or not (false). sync? is a Boolean value that specifies whether the frame is a sync frame (true) or not (false). is a Boolean value that specifies the value of the preamble? payload preamble indicator in the frame header. If the frame is in the static segment, preamble? being true indicates the presence of a netw ork management vector at the beginning of the payload. The XNET Cluster FlexRay:Network Management Vector Length property specifies the number of bytes at the beginning. the dynamic segment, If the frame is in being true preamble? indicates the presence of a messag e ID at the beginning of the payload. The message ID is always 2 bytes in length. If preamble? is false, the payload does not contain a network management vector or a message ID. chA is a Boolean value that specifies whether to transmit the frame on channel A (tru e) or not (false). chB is a Boolean value that specifies whether to transmit the frame on channel B (tru e) or not (false). echo? is not used for transmit. You must set this element to false. type type is not used for transmit, so you must is the frame type. All frame values are assumed to leave this element uninitialized. type. Frames of be the FlexRay Data FlexRay Data type contain payload data. type is not transmitted based on this type. As The FlexRay Null property, the specified in the XNET Frame FlexRay:Timing Type when a cyclically timed frame FlexRay null frame is transmitted does not have new data. 4-241 © National Instruments NI-XNET Hardware and Software Manual

307 Chapter 4 W—XNET Write (Frame FlexRay).vi NI-XNET API for LabVIE represents absolute time using the LabVIEW absolute timestamp timestamp is not used for transmit. You must set timestamp type. this element to the default value, invalid (0). The slot and cycle count specify when the frame transmits in FlexRay global time. payload is the array of data bytes for FlexRay frames of type FlexRay Data . The array size indicates the payloa d length of the frame value to transmit. According to the FlexRay protocol, the length range is 0–254. For PDU output session mode, the payload is the array of data bytes for the specific PDU, not the entire frame. When the session mode is Fram e Output Single-Point, Frame Output Queued, PDU Output Single-Point, or PDU Output Queued, the number of bytes in the payload array must match the Payload Length property of the corresponding frame. You can leave all other FlexRay frame clus ter elements uninitialized. For the section for each mode. more information, refer to timeout is the time to wait for the FlexRay frame data to be queued up for transmit. time, represented as 64-bit The timeout is a LabVIEW relative floating-point in units of seconds. is positive, timeout XNET Write (Frame FlexRay).vi If waits up to that timeout for space to become availabl e in queues. If the space is not available prior to the timeout, a timeout error is returned. waits If timeout is negative, XNET Write (Frame FlexRay).vi indefinitely for space to become available in queues. timeout is 0, XNET Write (Frame FlexRay).vi does not wait and If immediately returns with a timeout error if all data cannot be queued. Regardless of the timeout used, if a timeout error occurs, none of the data is queued, so you can attempt to call XNET Write (Frame FlexRay).vi again at a later time with the same data. This input is optional. The default value is 10.0 (10 seconds). If the session mode is Frame Output Single-Point, you must set timeout to timeout 0.0. Because this mode writes th e most recent value of each frame, does not apply. 4-242 NI-XNET Hardware and Software Manual ni.com

308 Chapter 4 NI-XNET API for LabVIEW—XNET Write (Frame FlexRay).vi error in is the error cluster input (refer to Error Handling ). Outputs session out , provided for use with subsequent VIs. session in is the same as error out is the error cluster output (refer to Error Handling ). Description es. Each FlexRay frame uses a LabVIEW cluster The data represents an array of FlexRay fram with FlexRay-specific elements. The FlexRay frames are associated to th e session’s list of frames as follows: Frame Output Queued Mode : Array of frame values to transmit for the single frame • specified in the list. values, one for each frame • Frame Output Single-Point Mode : Array of single frame specified in the list. • PDU Output Queued Mode: Array of frame (PDU payload) values to transmit for the single PDU specified in the list. This mode is similar to Frame Output Queued Mode . • PDU Output Single-Point Mode: Array of single frame (PDU payload) values, one for . Frame Output Single-Point Mode This mode is similar to each PDU specified in the list. 4-243 © National Instruments NI-XNET Hardware and Software Manual

309 Chapter 4 NI-XNET API for LabVIEW—XNET Write (Frame LIN).vi XNET Write (Frame LIN).vi Purpose Writes data to a session as an array of LIN frames. The session must use a LIN interface and Frame Output Single-Point Frame Output Stream Mode , Frame Output Queued Mode , or . Mode Format Inputs is the session to write. This session is selected from the session in LabVIEW project or returned from XNET Create Session.vi . The session ut Queued, or Frame mode must be Frame Ou tput Stream, Frame Outp Output Single-Point. data provides the array of LabVIEW clusters. Each array element corresponds to a frame value to transmit. For a Frame Input Single-Point session mode, the order of frames in the array corresponds to the order in the session list. For Frame Output Queued session mode, the data you write is queued up for transmit on the network. Using the default queue configuration for this mode, you can safely write 64 frames if you have a sufficiently long timeout. To write more data, refer to the XNET Session Number of Values l amount of queue space available Unused property to determine the actua for write. For an example of how this data applies to network traffic, refer to Frame Frame Output Output Stream Mode , Frame Output Queued Mode , or Single-Point Mode . The elements of each cluster are speci fic to the LIN protocol. For more Summary of the LIN Standard , or the information, refer to Appendix C, LIN protocol specification. 4-244 NI-XNET Hardware and Software Manual ni.com

310 Chapter 4 W—XNET Write (Frame LIN).vi NI-XNET API for LabVIE The cluster elements are: identifier is not used for transmit. You must set this element to 0. Each frame is identified based on the list of frames or signals provided for the session. The actual identifier to transmit is taken Therefore, this from the database (frame and sche dule properties). in the frame value is ignored. identifier is not used for transmit. You must set this element to event slot? false. The currently running schedule is used to map the specific frame to a corresponding schedule entry (slot). The schedule entry itself determines whether the slot is unconditional, sporadic, or event triggered. event ID is not used for transmit. You must set this element to 0. echo? is not used for transmit. You must set this element to false. type is the frame type (decimal value in parentheses): data. payload The LIN data frame contains LIN Data (64) This is currently the only frame type for LIN. timestamp represents absolute time using the LabVIEW absolute timestamp type. timestamp is not used for transmit. You must set this element to the default value, invalid (0). payload is the array of data byt es for a LIN data frame. The array size indicates the payloa d length of the frame value to transmit. According to the LIN protocol, the payload length range is 0–8. payload The number of bytes in the array must match the Payload property of the corresponding frame. You can leave all Length other LIN frame cluster elemen ts uninitialized. For more the topic for each mode. information, refer to If you use the frame payload with in an event-triggered schedule entry (slot), the first byte of data on the network is the frame’s payload identifier. The LIN standard requires this even if the frame transmits in an unconditional or sporadic slot. For this type or example, signal values) is of LIN frame, the actual data (f limited to 7 bytes. For this type of frame, you must write the first of 8 bytes even if only the last 7 are used), but payload byte ( 4-245 © National Instruments NI-XNET Hardware and Software Manual

311 Chapter 4 NI-XNET API for LabVIEW—XNET Write (Frame LIN).vi NI-XNET ignores the value and fills in the first byte for you, using the known frame ID from the session’s configuration. timeout is the time to wait for the LIN frame data to be queued up for transmit. The timeout is a LabVIEW relative time, represented as 64-bit floating-point in units of seconds. If timeout is positive, XNET Write (Frame LIN).vi waits up to that timeout for space to become availabl e in queues. If the space is not available prior to the timeout, a timeout error is returned. If timeout is negative, XNET Write (Frame LIN).vi waits indefinitely for space to become available in queues. If timeout is 0, XNET Write (Frame LIN).vi does not wait and immediately returns with a timeout error if all data cannot be queued. Regardless of the timeout used, if a timeout error occurs, none of the data again is queued, so you can attempt to call XNET Write (Frame LIN).vi at a later time with the same data. This input is optional. The default value is 10.0 (10 seconds). to timeout If the session mode is Frame Output Single-Point, you must set 0.0. Because this mode writes th e most recent value of each frame, timeout does not apply. error in is the error cluster input (refer to Error Handling ). Outputs , provided for use with subsequent VIs. session out is the same as session in error out ). Error Handling is the error cluster output (refer to Description The data represents an array of LIN frames. Each LIN frame uses a LabVIEW cluster with LIN-specific elements. session’s list of frames as follows: The LIN frames are associated to the • Frame Output Stream Mode : Array of all frame values for transmit (list ignored). If the is transmitted. If the part of the LIN frame payload is an empty array, only the header and response parts of the LIN frame are payload is not an empty array, the header transmitted. 4-246 NI-XNET Hardware and Software Manual ni.com

312 Chapter 4 W—XNET Write (Frame LIN).vi NI-XNET API for LabVIE transmit for the single frame : Array of frame values to Frame Output Queued Mode • specified in the list. • Frame Output Single-Point Mode : Array of single frame values, one for each frame specified in the list. NI-XNET Hardware and Software Manual 4-247 National Instruments ©

313 Chapter 4 NI-XNET API for LabVIEW—XNET Write (Frame Raw).vi XNET Write (Frame Raw).vi Purpose Writes data to a session as an array of raw bytes. Format Inputs is the session to write. This session is selected from the session in LabVIEW project or returned from XNET Create Session.vi . The session , mode must be Frame Output Stream Mode , Frame Output Queued Mode or Frame Output Single-Point Mode . data provides the array of bytes, representing frames to transmit. . The raw bytes encode one or more frames using the Raw Frame Format This frame format is the same for read and write of raw data and also is used for log file examples. ial frame. For example, if a complete If needed, you can write data for a part raw frame is 24 bytes, you can write 12 bytes, then write the next 12 bytes. You typically do this when you are r eading raw frame data from a logfile and want to avoid iterating through the data to detect the start and end of each frame. For information about which elements of the raw frame are applicable, instance for the protocol in use ( XNET Write.vi XNET Write refer to the (Frame CAN).vi , XNET Write (Frame FlexRay).vi , or XNET Write (Frame LIN).vi ). The data you write is queued up for transmit on the network. Using the default queue configuration for this mode, you can safely write 1536 frames if you have a sufficiently long timeout. To write more data, Number of Values Unused refer to the XNET Session property to determine the actual amount of qu eue space available for writing. 4-248 NI-XNET Hardware and Software Manual ni.com

314 Chapter 4 W—XNET Write (Frame Raw).vi NI-XNET API for LabVIE Frame For an example of how this data applies to network traffic, refer to , Frame Output Queued Mode , or Frame Output Output Stream Mode Single-Point Mode . timeout is the time to wait for the raw data to be queued up for transmit. The timeout is a LabVIEW relative time, represented as 64-bit floating-point in units of seconds. waits up to that If timeout is positive, XNET Write (Frame Raw).vi timeout for space to become availabl e in queues. If the space is not available prior to the timeout, a timeout error is returned. If timeout is negative, XNET Write (Frame Raw).vi waits indefinitely for space to become available in queues. If timeout is 0, XNET Write (Frame Raw).vi does not wait and immediately returns with a timeout error if all data cannot be queued. Regardless of the timeout used, if a timeout error occurs, none of the data is queued, so you can attempt to call again XNET Write (Frame Raw).vi at a later time with the same data. This input is optional. The default value is 10.0 (10 seconds). If the session mode is Frame Output Single-Point, you must set timeout to 0.0. Because this mode writes th e most recent value of each frame, timeout does not apply. error in is the error cluster input (refer to Error Handling ). Outputs is the same as session in , provided for use with subsequent VIs. session out error out Error Handling ). is the error cluster output (refer to Description The raw bytes encode one or more frames using the Raw Frame Format . The session must use a mode of Frame Output Stream, Frame Output Queued, or Frame Outp ut Single-Point. The raw frame format is protocol independent, so the session can use either a CAN, FlexRay, or LIN interface. The raw frame format matches the format of data transferred to/from the XNET hardware. for ease of use, it is more efficient with Because it is not converted to/from LabVIEW clusters regard to performance. This instance typically is used to read raw frame data from a log file and write the data to the interface for transmit (replay). 4-249 © National Instruments NI-XNET Hardware and Software Manual

315 Chapter 4 NI-XNET API for LabVIEW—XNET Write (Frame Raw).vi The raw frames are associated to the session’s list of frames as follows: • Frame Output Stream Mode : Array of all frame values for transmit (list ignored). For LIN, if the payload element is an empty arra y, only the header part of the LIN frame is transmitted. If the payload el ement is not an empty array, the header and response parts of the LIN frame are transmitted. Frame Output Queued Mode transmit for the single frame : Array of frame values to • specified in the list. • Frame Output Single-Point Mode : Array of single frame values, one for each frame specified in the list. • PDU Output Queued Mode: Array of frame (PDU payload) values to transmit for the single PDU specified in the list. This mode is similar to Frame Output Queued Mode . • PDU Output Single-Point Mode: Array of single frame (PDU payload) values, one for Frame Output Single-Point Mode . This mode is similar to each PDU specified in the list. 4-250 NI-XNET Hardware and Software Manual ni.com

316 Chapter 4 NI-XNET API for LabVIEW—XN ET Write (State FlexRay Symbol).vi XNET Write (State FlexRay Symbol).vi Purpose Writes a request for the FlexRay interface to tr ansmit a symbol on the FlexRay bus. You can use this XNET Write VI with any input or output session for FlexRay. Format Inputs session in is the session to use for the symbol write. This session is selected from the LabVIEW project or returned from XNET Create Session.vi . The session must use a FlexRay interface. ). Error Handling is the error cluster input (refer to error in Outputs session out is the same as session in , provided for use with subsequent VIs. ). error out is the error cluster output (refer to Error Handling Description with any XNET session mode, as long XNET Write (State FlexRay Symbol).vi You can use as the session interface is FlexRay. Because th e symbol write applies to the FlexRay interface, it can apply to multiple sessions. After calling XNET Write (State FlexRay Symbol).vi , the XNET interface transmits the symbol during the symbol window of the FlexRay cycle following the currently executing cycle. If you call multiple times, only the most XNET Write (State FlexRay Symbol).vi recent symbol is transmitted. 4-251 © National Instruments NI-XNET Hardware and Software Manual

317 Chapter 4 Write (State LIN Sc NI-XNET API for LabVIEW—XNET hedule Change).vi N Schedule Change).vi XNET Write (State LI Purpose Write a request for the LIN interface to chan XNET ge the running schedule. You can use this Write VI with any input or output session for LIN. Format Inputs is the session to use for the schedule change. This session is session in selected from the LabVIEW XNET Create project or returned from Session.vi . The session must use a LIN interface. data is the XNET LIN schedule. Although the data type for this input is the XNET LIN Schedule I/O Name , you also can wire a string. The data input supports the following options: : You can use the complete I/O name. • XNET LIN Schedule I/O Name This provides features such as the ability to choose from LIN schedules in a selected database. String with XNET LIN short name : If you prefer to use the XNET • LIN Schedule Name (Short) property, you can wire in the property as a string. • String with decimal number : This is interpreted as an index into the XNET Cluster LIN:Schedules property used for this session. If you are editing your database file to add/remo ve LIN schedules, this index may change, in which case the name is the recommended option. error in is the error cluster input (refer to Error Handling ). Outputs session out is the same as session in , provided for use with subsequent VIs. Error Handling is the error cluster output (refer to ). error out 4-252 NI-XNET Hardware and Software Manual ni.com

318 Chapter 4 LabVIEW—XNET Write (State LIN Schedule Change).vi NI-XNET API for Description You can use XNET Write (State LIN Schedule Change).vi with any XNET session mode, se the schedule change applies to the LIN as long as the session interface is LIN. Becau interface, it can apply to multiple sessions. According to the LIN protocol, only the master executes schedules, not slaves. If the XNET property is false (slave), this Interface:LIN:Master? Session write function implicitly sets that property to true (master). If the interface currently is running as a slave, this write returns an error, because it cannot chan ge to master while running. XNET Write (State LIN Schedule Change).vi The behavior depends on the Run Mode property of the XNET LIN schedule that you wire in as data: hedule for the interface. single run-continuous sc • Continuous : This mode changes the l its entries (slots) repetitively, starting The single run-continuous schedule executes al after running the last entry. over with the first entry The run-continuous schedule is handled as if it is lowest priority. If you write a run-once schedule in the middle of a run-continuous execution, the run-continuous schedule is interrupted after the current slot finishes. The schedule r switches to the run-once schedule, and when all run-once schedules are done, the scheduler returns to the slot in the run-continuous schedule where it left off. For example, if run-continuous schedule A has 4 slots, and it is executing slot 2 when a run-once schedule B is written, slot 2 of A finishes, then all slots of schedule B run, then the scheduler returns to slot 3 of schedule A. Only one run-continuous schedule exists at a time. If you change from one run-continuous schedule to another in the middle of a run, the current schedule completes all of its slots, then the scheduler changes to the new run-continuous schedule. • : This mode writes a request for a run-once schedule. Multiple run-once schedules Once ach run-once schedule executes all its entries (slots), and can be pending for execution. E then it is considered done. Each run-once schedule has a priority from 1 to 254. Lower values correspond to higher priority (1 is highest). The LIN interface’ s scheduler maintains a priority queue of run-once schedule requests. This means the highest-priority run-once schedule executes first, followed by the next run-once in pr iority, and when no run-once schedules are continuous schedule. pending, the interface returns to the run- her run-once schedule. For example, if A run-once schedule cannot interrupt anot run-once schedule X has 3 slots and is executing slot 0 when a run-once schedule Y with higher priority is written, slots 0, 1, and 2 of X finish, then all slots of schedule Y run. 4-253 © National Instruments NI-XNET Hardware and Software Manual

319 Chapter 4 hedule Change).vi NI-XNET API for LabVIEW—XNET Write (State LIN Sc • Null : This mode stops scheduler execution after th e current slot is fi nished. The queue of run-once schedules is flushed (all elements discarded). The null schedule is considered the highest priority schedule. It overrides the single run-continuous schedule, thus acting as the default scheduling behavior. For example, if you write a null schedule, then write a run- once schedule, the run-once schedule executes all its slots, then communication stops (returns to null schedule). XNET Write (State LIN Schedule Change).vi does not wait for the requested schedule to finish execution prior to return. The VI does not wait for the schedule to begin execution, because in the case of run-once schedules, that may take a long time (depending on priority). a schedule request and returns, it Because this VI simply writes is safe to use within a high-priority loop in LabVIEW Real-Time. Node configuration is handled using XNET Write (State LIN Schedule Change).vi instead of XNET Write (State LIN Diagnostic Schedule Change).vi . Wire the node configuration XNET Write (State LIN Schedule Change).vi so schedule defined for the LIN cluster into that it is the first schedule executed for the LI N, with a run mode of once. The data for each node configuration service request entry in the node configuration schedule is automatically transmitted by the master. After the node configuration schedule has completed, use XNET Write (State LIN Diagnost ic Schedule Change).vi to write master request messages and to run XNET Write (State LIN Schedule Change).vi query for slave response messages, or normal schedules. 4-254 NI-XNET Hardware and Software Manual ni.com

320 Chapter 4 W—XNET Write (State LIN Diagnostic Schedule Change).vi NI-XNET API for LabVIE le Change).vi XNET Write (State LIN Diag nostic Schedu Purpose Write a request for the LIN interface to cha nge the diagnostic schedule. You can use this XNET Write VI with any input or output session for LIN. Format Inputs session in is the session to use for the diagnostic schedule change. This session is selected from the La bVIEW project or returned from XNET Create Session.vi . The session must use a LIN interface. diagnostic schedule is a ring (enumerated list) with the following values: Va l u e String Null 0 Master Request 1 2 Slave Response This specifies which diagnostic schedule the master executes: diagnostic schedule. No master Null: • The master does not execute any request or slave response headers are transmitted on the LIN. The master executes a diagnostic master request Master Request: • schedule (transmits a master request LIN) if it can. header onto the First, a master request schedule must be defined for the LIN cluster in the imported or in-memory database. Otherwise, error nxErrDiagnosticScheduleNotDefined is returned when attempting to set this value. Second, the master must have a frame output queued session created for the master reques t frame, and there must be one or more new master request frames pending in the queue. If no new e, no master request header is frames are pending in the output queu transmitted. This allows the timing of master request header NI-XNET Hardware and Software Manual 4-255 National Instruments ©

321 Chapter 4 (State LIN Diagnostic Schedule Change).vi NI-XNET API for LabVIEW—XNET Write transmission to be controlled by the timing of master request frame writes to the output queue. If there are no normal schedules pending, the master is effectively in diagnostics-only mode, and master request headers are transmitted at a rate determined by the slot delay defined for the master request frame slot in the master request schedule or the nxPropSession_IntfLINDiag STmin time, whichever is greater, and the output queue as described above. state of the master request frame If there are normal schedules pendin g, the master is effectively in diagnostics-interleaved mode, and a master request header transmission is inserted between each complete execution of a run-once or run-continuous schedule. This happens as long as the nxPropSession_IntfLINDiag STmin time has been met, and there are one or more new master request fram es pending in the master request frame output queue. The master executes a diagnostic slave response • Slave Response: e header onto the LIN) if it schedule (transmits a slave respons can. A slave response schedule must be defined for the LIN cluster in the imported or in-memory database. Otherwise, error nxErrDiagnosticScheduleNotDefined is returned when attempting to set this value. If there are no normal schedules pe nding, the master is effectively in diagnostics-only mode, and slave res ponse headers are transmitted at the rate of the slot delay defined for the slave response frame slot in the slave response schedule. The addressed slave may or may not respond to each header, depending on its specified P2min and STmin timings. If there are normal schedules pendin g, the master is effectively in diagnostics-interleaved mode, and a slave response header transmission is inserted between each complete execution of a run-once or run-continuous schedule. Here again, the addressed slave may or may not respond to each header, depending on its specified P2min and STmin timings. error in is the error cluster input (refer to Error Handling ). Outputs session out is the same as session in , provided for use with subsequent VIs. ). is the error cluster output (refer to Error Handling error out 4-256 NI-XNET Hardware and Software Manual ni.com

322 Chapter 4 NI-XNET API for LabVIE W—XNET Write (State LIN Diagnostic Schedule Change).vi Description You can use XNET Write (State LIN Diagnostic Schedule Change).vi with any XNET session mode, as long as the se ssion interface is LIN. Because the schedule change applies to the LIN interface, it can apply to multiple sessions. According to the LIN protocol, only the master executes schedules, not slaves. If the XNET Interface:LIN:Master? Session write function implicitly sets that property is false (slave), this property to true (master). If the interface currently is running as a slave, this write returns an error, because it cannot chan ge to master while running. XNET Write (State LIN Diagno to transmit master request stic Schedule Change).vi Use messages and query for slave response messages after node configuration has been performed. Node configuration should be handled using XNET Write (State LIN Schedule Change).vi . Wire the node configuration schedule defined for the LIN cluster into that VI so XNET Write that it is the first schedule executed for the LIN. Refer to the description for for more information about using it to perform node (State LIN Schedule Change).vi configuration. 4-257 © National Instruments NI-XNET Hardware and Software Manual

323 Chapter 4 NI-XNET API for La bVIEW—Database Subpalette Database Subpalette This subpalette includes functions for accessing databases that specify the embedded network configuration, including frame and signal data th at is transferred. You can use these functions to retrieve information from database files, create new database objects in LabVIEW, and edit and save new database files. XNET Database Property Node Format Description Property node used to read/write properties for an . XNET Database I/O Name Pull down this node to add properties. Right-click to change direction between read and write. Right-click each property name to creat e a constant, control, or indicator. For help on a specific property, open the LabVIEW context help window () and move your cursor over the property name. For more information about LabVIEW property nodes, open the main LabVIEW help (select topic in Property Nodes Search the LabVIEW Help from the Help menu) and look for the the index. 4-258 NI-XNET Hardware and Software Manual ni.com

324 Chapter 4 NI-XNET API for LabVIE W—XNET Database Property Node Clusters Data Type Direction Required? Default N/A Read Only N/A Property Class XNET Database Short Name Clsts Description Returns an array of I/O names of XNET Clusters in this database. uster object is created. A cluster is assigned to a database when the cl You cannot change this assignment afterwards. You can use an array element to read or write the cluster properties (for example, cluster protocol or cluster frames). Refer to XNET Cluster I/O Name for information about using XNET I/O names. FIBEX files can contain any number of clus ters, and each cluster uses a unique name. For CANdb ( ) files, the file contains only one cluster, .dbc ), LDF ( .ldf ), or NI-CAN ( .ncd and no cluster name is stored in the file. For these database formats, NI-XNET uses the name Cluster for the single cluster. 4-259 © National Instruments NI-XNET Hardware and Software Manual

325 Chapter 4 NI-XNET API for LabVIEW—XNET Database Property Node ShowInvalidFromOpen? Required? Default Data Type Direction Read/Write No False Property Class XNET Database Short Name ShowInvalid? Description e invalid at database open time. Shows frames and signals that ar After opening a database, this property always is set to false, meaning that invalid clusters, frames, and signals are not retu rned in properties that return XNET I/O Names for the database (for example, XNET Cluster Frames ). Invalid clusters, and XNET Frame Signals frames, and signals are incorrectly defined and therefore cannot be used in the bus communication. The false setting is recommended when you use the database to create XNET sessions. lid configuration (for example, in a database In case the database was opened to correct inva editor), you must set the property to true prior to reading properties that return XNET I/O Names for the database (for example, XNET Cluster and XNET Frame Signals ). Frames For invalid objects, the XNET Cluster Configuration Status , XNET Frame Configuration Status , and XNET Signal Configuration Status properties return an error code that explains the problem. For valid objects, Configuration Status returns success (no error). Clusters, frames, and sign als that became invalid after the data base is opened ar e still returned from the XNET Database , XNET Cluster Frames , and XNET Frame Signals Clusters properties, even if ShowInvalidFromOpen? is fa lse and Configuration Status returns an error code. For example, if you open the frame with valid properties, then you set the Start Bit beyond the payload length, the Configuration Status returns an error, but the frame is returned from XNET Cluster Frames . 4-260 NI-XNET Hardware and Software Manual ni.com

326 Chapter 4 NI-XNET API for LabV IEW—XNET Database Constant XNET Database Constant This constant provides the constant form of the XNET Database I/O name. You drag a constant to the block diagram of your VI, then select a database. You can change constants only during configuration, prior to running th e VI. For a complete description, refer to XNET . Database I/O Name XNET Cluster Property Node Format Description Property node used to read/write properties for an XNET Cluster I/O Name . to change direction between read and write. Pull down this node to add properties. Right-click Right-click each property name to creat e a constant, control, or indicator. For help on a specific property, open the LabVIEW context help window () and move your cursor over the property name. For more information about LabVIEW property nodes, open the main LabVIEW help (select Property Nodes topic in menu) and look for the Search the LabVIEW Help from the Help the index. 4-261 © National Instruments NI-XNET Hardware and Software Manual

327 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node FlexRay Properties This section includes the XNET Cluster FlexRay properties. FlexRay:Action Point Offset Data Type Direction Required? Default Read from Database Read/Write Yes Property Class XNET Cluster Short Name FlexRay.ActPtOff Description This property specifies the number of macroticks (MT) that the action point is offset from the beginning of a static slot or symbol window. in the This property corresponds to the global cluster parameter gdActionPointOffset . FlexRay Protocol Specification The action point is that point within a given ansmission of a frame slot where the actual tr starts. This is slightly later than the start of the slot, to allow for a clock drift between the network nodes. The range for this property is 1–63 MT. This property is required. If the property doe s not contain a valid value, and you create an XNET session that uses this cluster, the session returns an error. To en sure that the property contains a valid value, you can do one of the following: Use a database file (or alias) to create the session. • The file formats require a valid value in the text for this property. • Set a value in LabVIEW using the property node. This is needed when you create your own in-memory database ( :memory: ) rather than use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session. For more information about using database files and in-memory databases, refer to . Databases 4-262 NI-XNET Hardware and Software Manual ni.com

328 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node FlexRay:CAS Rx Low Max Data Type Direction Required? Default Read from Database Yes Read/Write Property Class XNET Cluster Short Name FlexRay.CASRxLMax Description This property specifies the upper limit of the collision avoidance symbol (CAS) acceptance window. The CAS symbol is transmitted by the FlexRay interface (node) during the symbol ion cycle. A receiving FlexRa window within the communicat y interface considers the CAS cdCASRxLowMin ) and CAS Rx to be valid if the pattern’s low level is within 29 gdBit ( Low Max. gdCASRxLowMax in the FlexRay This property corresponds to the global cluster parameter . Protocol Specification The values for this property are in the range 67–99 gdBit. This property is required. If the property doe s not contain a valid value, and you create an sure that the property XNET session that uses this cluster, the session returns an error. To en contains a valid value, you can do one of the following: • Use a database file (or alias) to create the session. The file formats require a valid value in the text for this property. Set a value in LabVIEW using the property node. • ) rather than This is needed when you create your own in-memory database ( :memory: use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session. For more information about using database files and in-memory databases, refer to Databases . 4-263 © National Instruments NI-XNET Hardware and Software Manual

329 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node FlexRay:Channels Direction Data Type Required? Default Read/Write Yes Read from Database Property Class XNET Cluster Short Name FlexRay.Channels Description This property specifies the FlexRay channels used in the cluster. Frames defined in this cluster operty specifies. Refer to the XNET Frame are expected to use the channels this pr FlexRay:Channel Assignment property. FlexRay Protocol in the This property corresponds to the global cluster parameter gChannels . Specification A FlexRay cluster supports two independent network wires (channels A and B). You can choose to use both or only one in your cluster. The values (enumeration) for this property are: 1 Channel A only 2 Channel B only 3 Channels A and B This property is required. If the property doe s not contain a valid value, and you create an XNET session that uses this cluster, the session returns an error. To en sure that the property contains a valid value, you can do one of the following: Use a database file (or alias) to create the session. • The file formats require a valid value in the text for this property. • Set a value in LabVIEW using the property node. This is needed when you create your own in-memory database ( :memory: ) rather than use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session. For more information about using database files and in-memory databases, refer to . Databases 4-264 NI-XNET Hardware and Software Manual ni.com

330 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node FlexRay:Cluster Drift Damping Data Type Direction Required? Default Read/Write Yes Read from Database Property Class XNET Cluster Short Name FlexRay.ClstDriftDmp Description This property specifies the clus ter drift damping factor, based on the longest microtick used in the cluster. Use this global FlexRay parameter to compute the local cluster drift damping factor for each cluster node. You can access th e local cluster drift for the XNET FlexRay property. interface from the XNET Session Interface:FlexRay:Cluster Drift Damping in the gdClusterDriftDamping This property corresponds to the global cluster parameter FlexRay Protocol Specification . The values for this property are in the range 0–5 MT. This property is required. If the property doe s not contain a valid value, and you create an XNET session that uses this cluster, the session returns an error. To en sure that the property can do one of the following: contains a valid value, you • Use a database file (or alias) to create the session. The file formats require a valid value in the text for this property. • Set a value in LabVIEW using the property node. This is needed when you create your own in-memory database ( :memory: ) rather than use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session. For more information about using database files and in-memory databases, refer to Databases . 4-265 © National Instruments NI-XNET Hardware and Software Manual

331 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node FlexRay:Cold Start Attempts Data Type Direction Required? Default Read/Write Yes Read from Database Property Class XNET Cluster Short Name FlexRay.ColdStAts Description This property specifies the maximum number of times a node in this cluster can start the cluster by initiating schedule synchronization. This global cluster parameter is applicable to all cluster notes that can perform a coldstart (send startup frames). in the This property corresponds to the global cluster parameter gColdStartAttempts FlexRay Protocol Specification . The values for this property are in the range 2–31. s not contain a valid value, and you create an This property is required. If the property doe XNET session that uses this cluster, the session returns an error. To en sure that the property contains a valid value, you can do one of the following: • Use a database file (or alias) to create the session. The file formats require a valid value in the text for this property. • Set a value in LabVIEW using the property node. This is needed when you create your own in-memory database ( :memory: ) rather than use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session. For more information about using database files and in-memory databases, refer to Databases . 4-266 NI-XNET Hardware and Software Manual ni.com

332 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node FlexRay:Cycle Data Type Direction Required? Default Read/Write Read from Database Yes Property Class XNET Cluster Short Name FlexRay.Cycle Description FlexRay communication cycle, expressed in This property specifies the duration of one microseconds. This property corresponds to the global cluster parameter gdCycle in the FlexRay Protocol Specification . All frame transmissions complete within a cycle. After this time, the frame transmissions restart with the first frame in the next cycle. ement from e counts incr The communication cycl count resets back to 0. 0–63, after which the cycle The range for this property is 10–16000 s.  This property is required. If the property doe s not contain a valid value, and you create an sure that the property XNET session that uses this cluster, the session returns an error. To en contains a valid value, you can do one of the following: • Use a database file (or alias) to create the session. The file formats require a valid value in the text for this property. Set a value in LabVIEW using the property node. • ) rather than This is needed when you create your own in-memory database ( :memory: use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session. For more information about using database files and in-memory databases, refer to Databases . 4-267 © National Instruments NI-XNET Hardware and Software Manual

333 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node FlexRay:Dynamic Segment Start Data Type Direction Required? Default Other Cluster Properties Calculated from Read Only N/A Property Class XNET Cluster Short Name FlexRay.DynSegStart Description This property specifies the start of the dy namic segment, expressed as the number of macroticks (MT) from the start of the cycle. The range for this property is 8–15998 MT. erties. It is based on the total static segment This property is calculated from other cluster prop size. It is set to 0 if the FlexRay:Number of Minislots property is 0 (no dynamic segment exists). 4-268 NI-XNET Hardware and Software Manual ni.com

334 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node FlexRay:Dynamic Slot Idle Phase Data Type Direction Required? Default Read from Database Yes Read/Write Property Class XNET Cluster Short Name FlexRay.DynSlotIdlPh Description This property specifies the dy namic slot idle phase duration. gdDynamicSlotIdlePhase in the This property corresponds to the global cluster parameter FlexRay Protocol Specification . The values for this property are in the range 0–2 minislots. This property is required. If the property doe s not contain a valid value, and you create an XNET session that uses this cluster, the session returns an error. To en sure that the property contains a valid value, you can do one of the following: • Use a database file (or alias) to create the session. The file formats require a valid value in the text for this property. • Set a value in LabVIEW using the property node. This is needed when you create your own in-memory database ( :memory: ) rather than use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session. For more information about using database files and in-memory databases, refer to Databases . 4-269 © National Instruments NI-XNET Hardware and Software Manual

335 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node FlexRay:Latest Guaranteed Dynamic Slot Data Type Direction Required? Default Read Only N/A Calculated from Other Cluster Properties Property Class XNET Cluster Short Name FlexRay.LatestGuarDyn Description the dynamic segment that This property specifies the highest slot ID in still can transmit a full-length (for example, Payload Length Dyna mic Maximum) frame, provided all previous slots in the dynamic segment have transmitted full-length frames also. A larger slot ID cannot be guaranteed to tran smit a full-length frame in each cycle (although on the dynamic segment load). a frame might go out depending The range for this property is 2–2047 slots. This read-only property is calculated from other cluster properties. If th e Number of Minislots is zero, no dynamic slots exist, and this property returns 0. Otherwise, the Number of Minislots is used along with Payload Length Dynamic Maximum to determine the latest dynamic slot guaranteed to tran smit in the next cycle. In ot her words, when all preceding dynamic slots transmit with Payload Length Dynamic Maximum, this dynamic slot also can transmit with Payload Length Dynamic Maximum, and its frame ends prior to the end of the dynamic segment. 4-270 NI-XNET Hardware and Software Manual ni.com

336 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node FlexRay:Latest Usable Dynamic Slot Data Type Direction Required? Default Calculated from Other Cluster Properties Read N/A Property Class XNET Cluster Short Name FlexRay.LatestUsableDyn Description can still transmit a the dynamic segment that This property specifies the highest slot ID in full-length (that is, Payload Length Dynamic Maximum) frame, provided no other frames have been sent in the dynamic segment. A larger slot ID cannot transmit a full-length frame (but could probably still transmit a shorter frame). The range for this property is 2–2047. cluster properties. If th This read-only property is calculated from other e Number of Minislots ty returns 0. Otherwise, Number of Minislots is zero, no dynamic slots exist, and this proper is used along with Payload Length Dynamic Maximum to determine the latest dynamic slot that can be used when all pr eceding dynamic slots are empty ( zero payload length). In other words, this property is calculated under the assumption that all other dynamic slots use only one minislot, and this dynamic slot uses the number of minislots required to deliver the maximum payload. The frame for this dynamic slot must end prior to the end of the dynamic mic slot is likely to preclude this slot’s segment. Any frame transmitted in a preceding dyna frame. 4-271 © National Instruments NI-XNET Hardware and Software Manual

337 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node FlexRay:Listen Noise Data Type Direction Required? Default Read/Write Yes Read from Database Property Class XNET Cluster Short Name FlexRay.LisNoise Description This property specifies the upper limit for th e startup and wakeup listen timeout in the presence of noise. It is used as a multiplier for the Interface:FlexRay: Listen Timeout property. FlexRay in the gListenNoise This property corresponds to the global cluster parameter Protocol Specification . The values for this property are in the range 2–16. This property is required. If the property doe s not contain a valid value, and you create an XNET session that uses this cluster, the session returns an error. To en sure that the property contains a valid value, you can do one of the following: • Use a database file (or alias) to create the session. The file formats require a valid value in the text for this property. • Set a value in LabVIEW using the property node. This is needed when you create your own in-memory database ( :memory: ) rather than use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session. For more information about using database files and in-memory databases, refer to Databases . 4-272 NI-XNET Hardware and Software Manual ni.com

338 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node FlexRay:Macro Per Cycle Data Type Direction Required? Default Yes Read from Database Read/Write Property Class XNET Cluster Short Name FlexRay.MacroPerCycle Description This property specifies the numb er of macroticks in a communi cation cycle. For example, if the FlexRay cycle has a duration of 5 ms (5000  s), and the duration of a macrotick is 1  s, the XNET Cluster FlexRay:Macro Per Cycle property is 5000. in the gMacroPerCycle This property corresponds to the global cluster parameter FlexRay . Protocol Specification The macrotick (MT) is the basic timing unit in the FlexRay cluster. Nearly all timing dependent properties are expressed in terms of macroticks. The range for this property is 10–16000 MT. This property is required. If the property doe s not contain a valid value, and you create an sure that the property XNET session that uses this cluster, the session returns an error. To en contains a valid value, you can do one of the following: • Use a database file (or alias) to create the session. The file formats require a valid value in the text for this property. Set a value in LabVIEW using the property node. • ) rather than This is needed when you create your own in-memory database ( :memory: use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session. For more information about using database files and in-memory databases, refer to Databases . 4-273 © National Instruments NI-XNET Hardware and Software Manual

339 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node FlexRay:Macrotick Data Type Direction Required? Default Read N/A Calculated from Other Cluster Parameters Property Class XNET Cluster Short Name FlexRay.Macrotick Description otick, expressed in clusterwide nominal macr This property specifies the duration of the microseconds. This property corresponds to the global cluster parameter gdMacrotick in the FlexRay . Protocol Specification The macrotick (MT) is the basic timing unit in the FlexRay cluster. Nearly all timing-dependent properties are expressed in terms of macroticks. The range for this property is 1–6  s. properties FlexRay:Macro Per Cycle This property is calculated from the FlexRay:Cycle and and rounded to the nearest permitted value. 4-274 NI-XNET Hardware and Software Manual ni.com

340 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node FlexRay:Max Without Cl ock Correction Fatal Data Type Direction Required? Default Read/Write Read from Database Yes Property Class XNET Cluster Short Name FlexRay.MaxWoClkCorFat Description ve even/odd cycle pairs with missing clock This property defines the number of consecuti ansition from the Protocol Operation Control correction terms that cause the controller to tr the Halt state. Use this global parameter as a status of Normal Active or Normal Passive to threshold for testing the clock correction failure counter. This property corresponds to the global cluster parameter in the FlexRay Protocol Specification . gMaxWithoutClockCorrectionFatal The values for this property are in the range 1–15 even/odd cycle pairs. This property is required. If the property doe s not contain a valid value, and you create an sure that the property XNET session that uses this cluster, the session returns an error. To en contains a valid value, you can do one of the following: • Use a database file (or alias) to create the session. The file formats require a valid value in the text for this property. Set a value in LabVIEW using the property node. • ) rather than This is needed when you create your own in-memory database ( :memory: use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session. For more information about using database files and in-memory databases, refer to Databases . 4-275 © National Instruments NI-XNET Hardware and Software Manual

341 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node FlexRay:Max Without Cl ock Correction Passive Data Type Direction Required? Default Read from Database Read/Write Yes Property Class XNET Cluster Short Name FlexRay.MaxWoClkCorPas Description This property defines the numb er of consecutive even/odd cy cle pairs with missing clock correction terms that cause the controller to tr ansition from the Protocol Operation Control rmal Passive. Use this global parameter as a threshold for status of Normal Active to No testing the clock correction failure counter. This property, Max Without Clock Correction Passive, <= Max Without Clock Note Correction Fatal <= 15. This property corresponds to the global cluster parameter in the FlexRay Protocol Specification . gMaxWithoutClockCorrectionPassive The values for this property are in the range 1–15 even/odd cycle pairs. This property is required. If the property doe s not contain a valid value, and you create an XNET session that uses this cluster, the session returns an error. To en sure that the property contains a valid value, you can do one of the following: Use a database file (or alias) to create the session. • The file formats require a valid value in the text for this property. • Set a value in LabVIEW using the property node. This is needed when you create your own in-memory database ( :memory: ) rather than use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session. For more information about using database files and in-memory databases, refer to . Databases 4-276 NI-XNET Hardware and Software Manual ni.com

342 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node FlexRay:Minislot Action Point Offset Data Type Direction Required? Default Read/Write Yes Read from Database Property Class XNET Cluster Short Name MinislotActPt Description This property specifies the number of macroticks (MT) the minislot action point is offset from the beginning of a minislot. This property corresponds to the global cluster parameter gdMinislotActionPointOffset in . the FlexRay Protocol Specification ansmission of a frame slot where the actual tr The action point is that point within a given starts. This is slightly later than the start of the slot to allow for a clock drift between the network nodes. The range for this property is 1–31 MT. This property is required. If the property doe s not contain a valid value, and you create an XNET session that uses this cluster, the session returns an error. To en sure that the property can do one of the following: contains a valid value, you • Use a database file (or alias) to create the session. The file formats require a valid value in the text for this property. • Set a value in LabVIEW using the property node. This is needed when you create your own in-memory database ( :memory: ) rather than use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session. For more information about using database files and in-memory databases, refer to Databases . 4-277 © National Instruments NI-XNET Hardware and Software Manual

343 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node FlexRay:Minislot Data Type Required? Default Direction Yes Read/Write Read from Database Property Class XNET Cluster Short Name FlexRay.Minislot Description This property specifies the duration of a minislot, expressed in macroticks (MT). This property corresponds to the global cluster parameter gdMinislot in the FlexRay Protocol Specification . In the dynamic segment of the FlexRay cycle, frames can have variable payload length. Minislots are the dynamic segmen t time increments. In a minisl ot, a dynamic frame can start its, the slot counter ots. If no frame transm transmission, but it usually spans several minisl (slot ID) is incremented to allow for the next frame. The total dynamic segment length is determined by multiplying this property by the Number Of Minislots property. The total dynamic segment length must be shorter than the Macro Per Cycle property minus the total static segment length. The range for this property is 2–63 MT. This property is required. If the property doe s not contain a valid value, and you create an XNET session that uses this cluster, the session returns an error. To en sure that the property contains a valid value, you can do one of the following: Use a database file (or alias) to create the session. • The file formats require a valid value in the text for this property. • Set a value in LabVIEW using the property node. This is needed when you create your own in-memory database ( :memory: ) rather than use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session. For more information about using database files and in-memory databases, refer to . Databases 4-278 NI-XNET Hardware and Software Manual ni.com

344 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node FlexRay:Network Management Vector Length Data Type Direction Required? Default Yes Read/Write Read from Database Property Class XNET Cluster Short Name FlexRay.NMVecLen Description This property specifies the length of the Network Management vector (NMVector) in a cluster. Only frames transmitted in the static segmen t of the communication cycle use the NMVector. The NMVector length specifies the number of bytes in the payload segment of the FlexRay frame transmitted in the status segmen t that can be used as the NMVector. This property corresponds to the global cluster parameter in the FlexRay Protocol Specification . gNetworkManagementVectorLength The range for this property is 0–12 bytes. This property is required. If the property doe s not contain a valid value, and you create an sure that the property XNET session that uses this cluster, the session returns an error. To en contains a valid value, you can do one of the following: • Use a database file (or alias) to create the session. The file formats require a valid value in the text for this property. Set a value in LabVIEW using the property node. • ) rather than This is needed when you create your own in-memory database ( :memory: use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session. For more information about using database files and in-memory databases, refer to Databases . 4-279 © National Instruments NI-XNET Hardware and Software Manual

345 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node FlexRay:NIT Start Direction Data Type Required? Default Read N/A Calculated from Other Cluster Properties Property Class XNET Cluster Short Name FlexRay.NITStart Description This property specifies the star t of the Network Idle Time (NIT), expressed as the number of macroticks (MT) from the start of the cycle. The NIT is a period at the end of a Flex Ray communication cycle where no frames are transmitted. The network nodes use it to re-sync their clocks to the common network time. The range for this property is 8–15998 MT. the total size of the static and This property is calculated from other cluster properties. It is dynamic segments plus the symbol window length, which is optional in a FlexRay communication cycle. 4-280 NI-XNET Hardware and Software Manual ni.com

346 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node FlexRay:NIT Data Type Direction Required? Default Read from Database Read/Write Yes Property Class XNET Cluster Short Name FlexRay.NIT Description This property is the Network Idle Time (N IT) duration, expressed in macroticks (MT). FlexRay Protocol in the This property corresponds to the global cluster parameter gdNIT . Specification The NIT is a period at the end of a Flex Ray communication cycle where no frames are transmitted. The network nodes use it to re-sync their clocks to the common network time. Configure the NIT to be the Macro Per Cycle property minus the total static and dynamic segment lengths minus the optional symbol window duration. The range for this property is 2–805 MT. This property is required. If the property doe s not contain a valid value, and you create an XNET session that uses this cluster, the session returns an error. To en sure that the property contains a valid value, you can do one of the following: • Use a database file (or alias) to create the session. The file formats require a valid value in the text for this property. Set a value in LabVIEW using the property node. • ) rather than This is needed when you create your own in-memory database ( :memory: use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session. For more information about using database files and in-memory databases, refer to . Databases 4-281 © National Instruments NI-XNET Hardware and Software Manual

347 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node FlexRay:Number of Minislots Data Type Direction Required? Default Read/Write Read from Database Yes Property Class XNET Cluster Short Name FlexRay.NumMinislt Description This property specifies the number of minislots in the dynamic segment. This property corresponds to the global cluster parameter gNumberOfMinislots in the FlexRay Protocol Specification . In the FlexRay cycle dynamic segment, fr ames can have variable payload lengths. Minislots are the dynamic segmen t time increments. In a minisl ot, a dynamic frame can start transmission, but it usually spans several minisl its, the slot counter ots. If no frame transm (slot ID) is incremented to allow for the next frame. The total dynamic segment length is determined by multiplying this property by the Minislot property. The total dynamic segment length must be shorter than the Macro Per Cycle property minus the total static segment length. The range for this property is 0–7986. This property is required. If the property doe s not contain a valid value, and you create an XNET session that uses this cluster, the session returns an error. To en sure that the property contains a valid value, you can do one of the following: Use a database file (or alias) to create the session. • The file formats require a valid value in the text for this property. • Set a value in LabVIEW using the property node. This is needed when you create your own in-memory database ( :memory: ) rather than use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session. For more information about using database files and in-memory databases, refer to . Databases 4-282 NI-XNET Hardware and Software Manual ni.com

348 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node FlexRay:Number of Static Slots Data Type Direction Required? Default Read from Database Yes Read/Write Property Class XNET Cluster Short Name FlexRay.NumStatSlt Description This property specifies the number of static slots in th e static segment. gNumberOfStaticSlots in the This property corresponds to the global cluster parameter . FlexRay Protocol Specification Each static slot is used to transmit one (static) frame on the bus. The total static segment length is determined by multiplying this property by the Static Slot property. The total static segment length must be shorter than the Macro Per Cycle property. The range for this property is 2–1023. This property is required. If the property doe s not contain a valid value, and you create an XNET session that uses this cluster, the session returns an error. To en sure that the property contains a valid value, you can do one of the following: • Use a database file (or alias) to create the session. The file formats require a valid value in the text for this property. Set a value in LabVIEW using the property node. • ) rather than This is needed when you create your own in-memory database ( :memory: use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session. For more information about using database files and in-memory databases, refer to . Databases 4-283 © National Instruments NI-XNET Hardware and Software Manual

349 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node FlexRay:Offset Correction Start Data Type Direction Required? Default Read/Write Yes Read from Database Property Class XNET Cluster Short Name FlexRay.OffCorSt Description This property specifies the start of the offset correction phase within the Network Idle Time er of macroticks (MT) from (NIT), expressed as the numb the start of the cycle. This property corresponds to the global cluster parameter gOffsetCorrectionStart in the . FlexRay Protocol Specification Ray communication cycle where no frames are The NIT is a period at the end of a Flex transmitted. The network nodes use it to re-sync their clocks to the common network time. to be NITStart + 1, bu t can deviate from that The Offset Correction Start is usually configured value. The range for this property is 9–15999 MT. This property is required. If the property doe s not contain a valid value, and you create an XNET session that uses this cluster, the session returns an error. To en sure that the property contains a valid value, you can do one of the following: Use a database file (or alias) to create the session. • The file formats require a valid value in the text for this property. • Set a value in LabVIEW using the property node. This is needed when you create your own in-memory database ( :memory: ) rather than use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session. For more information about using database files and in-memory databases, refer to . Databases 4-284 NI-XNET Hardware and Software Manual ni.com

350 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node FlexRay:Payload Length Dynamic Maximum Data Type Direction Required? Default N/A Read/Write Read from Database Property Class XNET Cluster Short Name FlexRay.PayldLenDynMax Description This property specifies the maximum of the payload lengths of all dynamic frames. In the FlexRay cycle dynamic segment, fr ames can have variable payload length. The range for this property is 0–254 bytes (even numbers only). The value returned for this property is the maximum of the payload lengths of all frames defined for the dynamic segment in the database. able Dynamic Slot and Latest Guaranteed Use this property to calculate the Latest Us Dynamic Slot properties. You may temporarily set this to a larger value (if it is not yet the maximum), and then this ting is lost once the database is closed, and after value is returned for this property. But this set anged value is returned from a reopen, the maximum of the fram es is returned again. The ch the FlexRay:Payload Length Dynamic Maximum property until the database is closed. This property is required. If the property doe s not contain a valid value, and you create an sure that the property XNET session that uses this cluster, the session returns an error. To en contains a valid value, you can do one of the following: • Use a database file (or alias) to create the session. The file formats require a valid value in the text for this property. Set a value in LabVIEW using the property node. • ) rather than This is needed when you create your own in-memory database ( :memory: use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session. For more information about using database files and in-memory databases, refer to . Databases 4-285 © National Instruments NI-XNET Hardware and Software Manual

351 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node FlexRay:Payload Length Maximum Data Type Direction Required? Default N/A Read Calculated from Other Cluster Properties Property Class XNET Cluster Short Name FlexRay.PayldLenMax Description This property returns the payload length of any frame (static or dynamic) in this cluster with es that the frame transfers the data. the longest payload. The payload specifi The range for this property is 0–254 bytes (even numbers only). 4-286 NI-XNET Hardware and Software Manual ni.com

352 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node FlexRay:Payload Length Static Data Type Direction Required? Default Read from Database Yes Read/Write Property Class XNET Cluster Short Name FlexRay.PayldLenSt Description This property specifies the payload length of a sta tic frame. All static frames in a cluster have the same payload length. gPayloadLengthStatic in the This property corresponds to the global cluster parameter . FlexRay Protocol Specification The range for this property is 0–254 bytes (even numbers only). This property is required. If the property doe s not contain a valid value, and you create an XNET session that uses this cluster, the session returns an error. To en sure that the property contains a valid value, you can do one of the following: • Use a database file (or alias) to create the session. The file formats require a valid value in the text for this property. • Set a value in LabVIEW using the property node. This is needed when you create your own in-memory database ( :memory: ) rather than use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session. For more information about using database files and in-memory databases, refer to Databases . 4-287 © National Instruments NI-XNET Hardware and Software Manual

353 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node FlexRay:Static Slot Data Type Required? Default Direction Yes Read/Write Read from Database Property Class XNET Cluster Short Name FlexRay.StatSlot Description This property specifies the duration of a slot in the static segment in macroticks (MT). This property corresponds to the global cluster parameter gdStaticSlot in the FlexRay Protocol Specification . Each static slot is used to transmit one (static) frame on the bus. The static slot duration takes into account the Payload Length Static and Action Point Offset properties, as well as maximum propagation delay. same payload length; therefore, ent, all frames must have the In the FlexRay cycle static segm the duration of a static frame is the same. The total static segment length is determined by multiplying this property by the Number Of ngth must be shorter th an the Macro Per Cycle Static Slots property. The total static segment le property. The range for this property is 4–661 MT. s not contain a valid value, and you create an This property is required. If the property doe XNET session that uses this cluster, the session returns an error. To en sure that the property contains a valid value, you can do one of the following: • Use a database file (or alias) to create the session. The file formats require a valid value in the text for this property. • Set a value in LabVIEW using the property node. This is needed when you create your own in-memory database ( :memory: ) rather than use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session. For more information about using database files and in-memory databases, refer to Databases . 4-288 NI-XNET Hardware and Software Manual ni.com

354 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node FlexRay:Symbol Window Start Data Type Direction Required? Default Calculated from Other Cluster Properties N/A Read Property Class XNET Cluster Short Name FlexRay.SymWinStart Description This property specifies the macrotick offset at which the symbol window begins from the start of the cycle. During the symbol window, a cha nnel sends a single Media Test Access Symbol (MTS). The range for this property is 8–15998 MT. other cluster properties. It is based on the total static and This property is calculated from dynamic segment size. It is set to zero if the Symbol Window property is 0 (no symbol window exists). 4-289 © National Instruments NI-XNET Hardware and Software Manual

355 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node FlexRay:Symbol Window Data Type Direction Required? Default Read/Write Yes Read from Database Property Class XNET Cluster Short Name FlexRay.SymWin Description This property specifies the symbol window duration, expressed in macroticks (MT). This property corresponds to the global cluster parameter gdSymbolWindow in the FlexRay . Protocol Specification ter the static and dynamic segment, and is used to transmit The symbol window is a slot af Collision Avoidance symbols (CAS) and/or Media Access Test symbol (MTS). The symbol window is optional for a given cluster (the Symbol Window property can be zero). A symbol transmission starts at the action point offset within the symbol window. The range for this property is 0–142 MT. This property is required. If the property doe s not contain a valid value, and you create an XNET session that uses this cluster, the session returns an error. To en sure that the property contains a valid value, you can do one of the following: • Use a database file (or alias) to create the session. The file formats require a valid value in the text for this property. • Set a value in LabVIEW using the property node. This is needed when you create your own in-memory database ( :memory: ) rather than use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session. For more information about using database files and in-memory databases, refer to Databases . 4-290 NI-XNET Hardware and Software Manual ni.com

356 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node FlexRay:Sync Node Max Data Type Direction Required? Default Read/Write Yes Read from Database Property Class XNET Cluster Short Name FlexRay.SyncNodeMax Description This property specifies the ma ximum number of nodes that may send frames with the sync frame indicator bit set to one. This property corresponds to the global cluster parameter gSyncNodeMax in the FlexRay . Protocol Specification tup frames are special drift measurement. Star Sync frames define the zero points for the clock sync frames transmitted first after a network st artup. There must be at least two startup nodes in a network. The range for this property is 2–15. This property is required. If the property doe s not contain a valid value, and you create an XNET session that uses this cluster, the session returns an error. To en sure that the property contains a valid value, you can do one of the following: • Use a database file (or alias) to create the session. The file formats require a valid value in the text for this property. Set a value in LabVIEW using the property node. • ) rather than This is needed when you create your own in-memory database ( :memory: use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session. For more information about using database files and in-memory databases, refer to . Databases 4-291 © National Instruments NI-XNET Hardware and Software Manual

357 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node FlexRay:TSS Transmitter Data Type Direction Required? Default Read/Write Read from Database Yes Property Class XNET Cluster Short Name FlexRay.TSSTx Description the Transmission Start Sequence (TSS). A frame This property specifies the number of bits in transmission may be truncated at the beginning. The amount of truncation depends on the nodes involved and the channel topology layout. For example, the purpose of the TSS is to “open the gates” of an active star (that is, to cause the star to properly set up input and output connections). During this setup, an active star truncates a number of bits at the beginning of a communication elem ent. The TSS prevents the frame or symbol content from being truncated.You must set this property to be gr worst case truncation of eater than the expected a frame. gdTSSTransmitter in the FlexRay This property corresponds to the global cluster parameter Protocol Specification . The range for this property is 3–15 bit. This property is required. If the property doe s not contain a valid value, and you create an XNET session that uses this cluster, the session returns an error. To en sure that the property contains a valid value, you can do one of the following: Use a database file (or alias) to create the session. • The file formats require a valid value in the text for this property. • Set a value in LabVIEW using the property node. This is needed when you create your own in-memory database ( :memory: ) rather than use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session. For more information about using database files and in-memory databases, refer to . Databases 4-292 NI-XNET Hardware and Software Manual ni.com

358 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node FlexRay:Use Wakeup Data Type Direction Required? Default False Read/Write No Property Class XNET Cluster Short Name FlexRay.UseWakeup? Description This property indicates whether the FlexRay cluster supports wakeup. This value is set to True if the WAKE-UP tree is present in the FIBEX file. This value is set to False if the WAKE-UP tree is not present in the FIBEX file. When this property is True, the FlexRay clus ter uses wakeup functionality; otherwise, the FlexRay cluster does not use wakeup functionality. When creating a new database, the default value of this property is False. However, if you set ), this property is set any wakeup parameter (for example, FlexRay:Wakeup Symbol Rx Low to True automatically, and the WAKE-UP tree is saved in the FIBEX file when saved. 4-293 © National Instruments NI-XNET Hardware and Software Manual

359 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node FlexRay:Wakeup Symbol Rx Idle Data Type Direction Required? Default Read/Write Yes Read from Database Property Class XNET Cluster Short Name FlexRay.WakeSymRxIdl Description This property specifies the number of bits the n ode uses to test the idle portion duration of a received wakeup symbol. Collisions, clock diff erences, and other eff ects can deform the transmitted wakeup pattern. in the gdWakeupSymbolRxIdle This property corresponds to the global cluster parameter FlexRay Protocol Specification . The range for this property is 14–59 gdBit (bit duration). This property is required. If the property doe s not contain a valid value, and you create an XNET session that uses this cluster, the session returns an error. To en sure that the property contains a valid value, you can do one of the following: • Use a database file (or alias) to create the session. The file formats require a valid value in the text for this property. • Set a value in LabVIEW using the property node. This is needed when you create your own in-memory database ( :memory: ) rather than use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session. For more information about using database files and in-memory databases, refer to Databases . 4-294 NI-XNET Hardware and Software Manual ni.com

360 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node FlexRay:Wakeup Symbol Rx Low Data Type Direction Required? Default Read/Write Yes Read from Database Property Class XNET Cluster Short Name FlexRay.WakeSymRxLow Description This property specifies the number of bits the node uses to test the low portion duration of a received wakeup symbol. This lower limit of zer o bits must be received for the receiver to detect the low portion. Active starts, clock differences, and other effects can deform the transmitted wakeup pattern. in the gdWakeupSymbolRxLow This property corresponds to the global cluster parameter FlexRay Protocol Specification . The range for this property is 10–55 gdBit (bit duration). This property is required. If the property doe s not contain a valid value, and you create an XNET session that uses this cluster, the session returns an error. To en sure that the property can do one of the following: contains a valid value, you • Use a database file (or alias) to create the session. The file formats require a valid value in the text for this property. • Set a value in LabVIEW using the property node. This is needed when you create your own in-memory database ( :memory: ) rather than use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session. For more information about using database files and in-memory databases, refer to Databases . 4-295 © National Instruments NI-XNET Hardware and Software Manual

361 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node FlexRay:Wakeup Symbol Rx Window Data Type Direction Required? Default Read/Write Yes Read from Database Property Class XNET Cluster Short Name FlexRay.WakeSymRxWin Description This property specifies the size of the window us ed to detect wakeups. Detection of a wakeup requires a low and idle period from one WUS (wakeup symbol) and a low period from another WUS, to be detected entirely within a window of this size. Clock differences and other effects can deform the transmitted wakeup pattern. in gdWakeupSymbolRxWindow This property corresponds to the global cluster parameter the . FlexRay Protocol Specification The range for this property is 76–301 gdBit (bit duration). This property is required. If the property doe s not contain a valid value, and you create an XNET session that uses this cluster, the session returns an error. To en sure that the property contains a valid value, you can do one of the following: • Use a database file (or alias) to create the session. The file formats require a valid value in the text for this property. • Set a value in LabVIEW using the property node. This is needed when you create your own in-memory database ( :memory: ) rather than use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session. For more information about using database files and in-memory databases, refer to . Databases 4-296 NI-XNET Hardware and Software Manual ni.com

362 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node FlexRay:Wakeup Symbol Tx Idle Data Type Direction Required? Default Read from Database Yes Read/Write Property Class XNET Cluster Short Name FlexRay.WakeSymTxIdl Description This property specifies the number of bits the node uses to transmit the wakeup symbol idle portion. gdWakeupSymbolTxIdle in the This property corresponds to the global cluster parameter FlexRay Protocol Specification . The range for this property is 45–180 gdBit (bit duration). This property is required. If the property doe s not contain a valid value, and you create an XNET session that uses this cluster, the session returns an error. To en sure that the property contains a valid value, you can do one of the following: • Use a database file (or alias) to create the session. The file formats require a valid value in the text for this property. • Set a value in LabVIEW using the property node. This is needed when you create your own in-memory database ( :memory: ) rather than use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session. For more information about using database files and in-memory databases, refer to Databases . 4-297 © National Instruments NI-XNET Hardware and Software Manual

363 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node FlexRay:Wakeup Symbol Tx Low Data Type Direction Required? Default Read from Database Read/Write Yes Property Class XNET Cluster Short Name FlexRay.WakeSymTxLow Description This property specifies the number of bits the node uses to transmit the wakeup symbol low phase. in the This property corresponds to the global cluster parameter gdWakeupSymbolTxLow FlexRay Protocol Specification . The range for this property is 15–60 gdBit (bit duration). s not contain a valid value, and you create an This property is required. If the property doe XNET session that uses this cluster, the session returns an error. To en sure that the property contains a valid value, you can do one of the following: • Use a database file (or alias) to create the session. The file formats require a valid value in the text for this property. • Set a value in LabVIEW using the property node. This is needed when you create your own in-memory database ( :memory: ) rather than use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session. For more information about using database files and in-memory databases, refer to Databases . 4-298 NI-XNET Hardware and Software Manual ni.com

364 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node Baud Rate Data Type Direction Required? Default No Read/Write 0 Property Class XNET Cluster Short Name BaudRate Description The Baud Rate property sets the baud rate all cl uster nodes use. This baud rate represents the om the session. Use a session interface property rate from the database, so it is read-only fr (for example, Interface:Baud Rate ) to override the database baud rate with an application-specific baud rate. CAN For CAN, this rate can be 33333, 40000, 50000, 62500, 80000, 83333, 100000, 125000, 160000, 200000, 250000, 400000, 500000, 800000, or 1000000. Some transceivers may only support a subset of these values. If you need values other than these, use the custom settings as described in the Interface:Baud Rate property. FlexRay For FlexRay, this rate can be 2500000, 5000000, or 10000000. LIN For LIN, this rate can be 2400–20000 inclusive. Interface:Baud If you need values other than these, use the custom settings as described in the property. Rate 4-299 © National Instruments NI-XNET Hardware and Software Manual

365 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node CAN:FD Baud Rate Data Type Direction Required? Default 0 Read/Write No Property Class XNET Cluster Short Name CAN.FdBaudRate Description CAN:I/O The FD Baud Rate property sets the fast data baud rate for the CAN FD + BRS property. This property represents the database fast data baud rate for the CAN FD + Mode CAN:I/O Mode property for a description of this mode. Use a BRS I/O Mode. Refer to the session interface property (for example, Interface:CAN:FD Baud Rate ) to override the database fast baud rate with an application-specific fast baud rate. NI-XNET CAN hardware currently accepts th e following numeric baud rates: 200000, 250000, 400000, 500000, 800000, 1000000, 1250000, 1600000, 2000000, 2500000, 4000000, 5000000, and 8000000. Some transceive rs may support only a subset of these values. an these, use the custom settings as described in the If you need values other th property. Interface:CAN:FD Baud Rate 4-300 NI-XNET Hardware and Software Manual ni.com

366 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node CAN:I/O Mode Data Type Direction Required? Default Read/Write Read from Database No Property Class XNET Cluster Short Name CAN.IoMode Description N I/O Mode of the cluster. It is a ring of three values: This property specifies the CA Enumeration Va l u e Meaning CAN 0 This is the default CAN 2.0 A/B standard I/O mode as defined in ISO 11898-1:2003. A fixed baud rate is used for transfer, and the payload length is limited to 8 bytes. CAN FD as specified in the This is the CAN FD mode 1 specification, CAN with Flexible Data-Rate version 1.0. Payload lengths up to 64 are allowed, but they are transmitted at a single fixed baud rate (defined by the XNET Cluster Baud Rate or XNET Session Interface:Baud properties). Rate CAN FD + BRS 2 CAN This is the CAN FD as specified in the with Flexible Data-Rate specification, version 1.0, with the optional Baud Rate Switching enabled. The same payload lengths as CAN FD mode are allowed; additionally, the data portion of the CAN frame is transferred at a different (higher) baud rate (defined by the CAN:FD Baud Rate or XNET Session Interface:CAN:FD Baud Rate properties). 4-301 © National Instruments NI-XNET Hardware and Software Manual

367 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node Comment Data Type Direction Required? Default Read/Write No Empty String Property Class XNET Cluster Short Name Comment Description A comment describing the cluster object. A comment is a string containing up to 65535 characters. Configuration Status Data Type Direction Required? Default N/A Read Only N/A Property Class XNET Cluster Short Name ConfigStatus Description The cluster object co nfiguration status. code. You can pass the value to the error code Configuration Status returns an NI-XNET error Simple Error Handler.vi to convert it to a text description (on message output) of input of the configuration problem. By default, incorrectly configured clusters in the database are not returned from the XNET Database Clusters property because they cannot be used in the bus communication. You can change this behavior by setting the XNET Database ShowInvalidFromOpen? property to true. When the configuration status of a cluster beco mes invalid after the database has been opened, Clusters the cluster still is returned from the XNET Database property even if ShowInvalidFromOpen? is false. 4-302 NI-XNET Hardware and Software Manual ni.com

368 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node Database Direction Data Type Required? Default N/A Read Only N/A Property Class XNET Cluster Short Name Database Description I/O name of the cluster parent database. The parent database is defined when the cluster object is created. You cannot change it afterwards. ECUs Required? Default Direction Data Type Read Only N/A N/A Property Class XNET Cluster Short Name ECUs Description ECUs in this cluster. Returns an array of I/O names of all ECUs defined in this cluster. An ECU is assigned to a cluster when the ECU object is created. You cannot change this assignment afterwards. XNET Database Create (ECU).vi To add an ECU to a cluster, use . To remove an ECU from the cluster, use . XNET Database Delete (ECU).vi 4-303 © National Instruments NI-XNET Hardware and Software Manual

369 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node Frames Direction Data Type Required? Default Read Only N/A N/A Property Class XNET Cluster Short Name Frms Description Frames in this cluster. Returns an array of I/O names of all frames defi ned in this cluster. A frame is assigned to a cluster when the frame object is created. Yo u cannot change this assignment afterwards. To add a frame to a cluster, use XNET Database Create (Frame).vi . To remove a frame from . a cluster, use XNET Database Delete (Frame).vi 4-304 NI-XNET Hardware and Software Manual ni.com

370 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node LIN:Schedules Direction Data Type Required? Default Read Only N/A N/A Property Class XNET Cluster Short Name LIN.Schedules Description Array of LIN schedules defined in this cluster. A LIN schedule is assigned to a cluster when the LIN schedule object is created. You cannot change this assignment afterwards. The schedules in this array are sorted alphabetically by schedule name. While the XNET interface is running, you can use XNET Write (State LIN Schedule Change).vi to change the running schedule. No sche dule runs by default, so you must write a schedule request at least once in your application. , if you use an index to specify the For XNET Write (State LIN Schedule Change).vi schedule, that index is the position in this array (starting at 0). 4-305 © National Instruments NI-XNET Hardware and Software Manual

371 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node LIN:Tick Direction Data Type Required? Default Read/Write Yes N/A Property Class XNET Cluster Short Name LIN.Tick Description Relative time between LIN ticks (f64, relative time in seconds). The XNET LIN Schedule Delay property must be a multiple of this tick. Entry This tick is referred to as the “timebase” in the LIN specification. The XNET ECU LIN:Master? property defines the LIN:Tick property in this cluster. You no LIN:Master? property defined in this cannot use the LIN:Tick property when there is cluster. 4-306 NI-XNET Hardware and Software Manual ni.com

372 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node Name (Short) Data Type Direction Required? Default Defined in Create Object Yes Read/Write Property Class XNET Cluster Short Name NameShort Description String identifying the cluster object. Lowercase letters, uppercase letters, numbers, a nd the underscore (_) are valid characters for riod (.), and other sp the short name. The space ( ), pe t supported within ecial characters are no the name. The short name must begin with a le case) or underscore, tter (uppercase or lower is limited to 128 characters. and not a number. The short name If you use a FIBEX file, the short name comes from the file. If you use a CANdb ( .dbc ), LDF ( .ldf ), or NI-CAN ( .ncd ) file, no cluster name is stored in the file, so NI-XNET uses the Name . If you create the cluster yourself, it comes from Cluster XNET name input of . Database Create (Cluster).vi A cluster name must be unique for all clusters in a database. unique, such as the This short name does not include qualifiers to ensure that it is database name. It is for display purposes. The fully qualified name is available by using the XNET Cluster I/O name as a string. You can write this property to change the cluster’s short name. When you do this, then use the original XNET Cluster that contains the old na me, errors can result because the old name cannot be found. Follow these steps to avoid this problem: 1. Get the old Name (Short) property using the property node. 2. Set the new Name (Short) property for the object. close all? Close the object using XNET Database Close.vi . Wire the 3. input as false to close the renamed object only. 4. Wire the XNET Cluster as the input string to Search and Replace String Function.vi as the replacement string. This as the search string and the new Name with the old Name while retaining the other text that ensures replaces the short name in the XNET Cluster, a unique name. 4-307 © National Instruments NI-XNET Hardware and Software Manual

373 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node The following diagram demonstrates steps 1 through 4 for an XNET Frame I/O name: NI-XNET Hardware and Software Manual 4-308 ni.com

374 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node PDUs Data Type Direction Required? Default N/A N/A Read Only Property Class XNET Cluster Short Name PDUs Description PDUs in this cluster. Returns an array of I/O names of all PDUs defined in this cluster. A PDU is assigned to a cluster when the PDU object is created. You cannot change this assignment afterwards. . To remove a PDU from a To add a PDU to a cluster, use XNET Database Create (PDU).vi . XNET Database Delete (PDU).vi cluster, use the 4-309 © National Instruments NI-XNET Hardware and Software Manual

375 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node PDUs Required? Data Type Direction Required? Default N/A Read Only N/A Property Class XNET Cluster Short Name PDUsReqd? Description Determines whether using PDUs in the database API is required for this cluster. If this property returns false, it is safe to use signals as child objects of a frame without PDUs. This behavior is compatible with NI-XNET 1.1 or earlier. Clusters from .dbc , .ncd , or FIBEX 2 files always return false for this prope rty, so using PDUs from those files is not required. If this property returns true, the cluster cont ains PDU configuration, which requires reading the PDUs as frame child objects and then si gnals as PDU child objects, as shown in the following figure. Internally, the database always uses PDUs, but shows the same signal objects also as children of a frame. Frame1 PDU1 Signal1 Signal2 4-310 NI-XNET Hardware and Software Manual ni.com

376 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node The following conditions must be fulfilled for all frames in the cluster to return false from the PDUs Required? property: • Only one PDU is mapped to the frame. • This PDU is not mapped to other frames. The PDU Start Bit in the frame is 0. • The PDU Update Bit is not used. • If the conditions are not fulfilled for a given fr ame, signals from the fr ame are still returned, ty returns a warning. but reading the proper The NI-XNET session supports frames requiring PDUs only for FlexRay. For frames property requiring PDUs on a CAN or LIN cluster, the XNET Frame Configuration Status and return an error. XNET Create Session.vi 4-311 © National Instruments NI-XNET Hardware and Software Manual

377 Chapter 4 NI-XNET API for LabVIEW—XNET Cluster Property Node Protocol Data Type Direction Required? Default CAN No Read/Write Property Class XNET Cluster Short Name Protocol Description Determines the cluster protocol. The values (enumeration) for this property are: CAN 0 1FlexRay 2LIN Signals Data Type Direction Required? Default Read Only N/A N/A Property Class XNET Cluster Short Name Sigs Description This property returns an array of I/O names of all XNET Signals defined in this cluster. A signal is assigned to a cluster when the si gnal object is created. You cannot change this assignment afterwards. To add a signal to a cluster, use XNET Database Create (Signal).vi . To remove a signal from XNET Database Delete (Signal).vi . a cluster use 4-312 NI-XNET Hardware and Software Manual ni.com

378 Chapter 4 NI-XNET API for La bVIEW—XNET Cluster Constant XNET Cluster Constant This constant provides the constant form of the XNET Cluster I/O name. You drag a constant to the block diagram of your VI, then select a cluster. You can change constants only during configuration, prior to running the VI. For a complete description, refer to XNET Cluster I/O . Name XNET ECU Property Node Format Description Property node used to read/write properties for an XNET ECU I/O Name . to change direction between read and write. Pull down this node to add properties. Right-click Right-click each property name to creat e a constant, control, or indicator. For help on a specific property, open the LabVIEW context help window () and move your cursor over the property name. For more information about LabVIEW property nodes, open the main LabVIEW help (select Property Nodes topic in menu) and look for the Search the LabVIEW Help from the Help the index. 4-313 © National Instruments NI-XNET Hardware and Software Manual

379 Chapter 4 NI-XNET API for LabVIEW—XNET ECU Property Node Cluster Data Type Direction Required? Default Read Only N/A N/A Property Class XNET ECU Short Name Cluster Description I/O name of the parent cluster to which the ECU is connected. The parent cluster is determined when th e ECU object is created. You cannot change it afterwards. FlexRay:Coldstart? Data Type Required? Default Direction Read Only N/A N/A Property Class XNET ECU Short Name FlexRay.Coldstart? Description Indicates that the ECU is sending a startup frame. This property is valid only for ECUs connected to a FlexRay bus. It returns true when one of the frames this ECU transmits (refer to the XNET ECU Frames Transmitted property) has the XNET Frame FlexRay:Startup? property set to true. You can determine the frame property. An ECU can FlexRay:Startup Frame transmitting the startup using the XNET ECU send only one startup frame on the FlexRay bus. 4-314 NI-XNET Hardware and Software Manual ni.com

380 Chapter 4 NI-XNET API for LabVIEW—XNET ECU Property Node FlexRay:Connected Channels Data Type Direction Required? Default Read/Write No Calculated from Cluster Settings Property Class XNET ECU Short Name FlexRay.ConnectedChs Description This property specifies the channel(s) that the FlexRay ECU (node) is physically connected to. The default value of this property is connect ed to all channels available on the cluster. FlexRay Protocol node parameter in the pChannels This property corresponds to the Specification . The values supported for this property (enu meration) are A = 1, B = 2, and A and B = 3. FlexRay:Startup Frame Data Type Direction Required? Default N/A N/A Read Only Property Class XNET ECU Short Name FlexRay.StartupFrm Description Returns the I/O name of the startup frame the ECU sends. This property is valid only for ECUs connect ed to a FlexRay bus. If the ECU transmits a property) with the XNET Frame Frames Transmitted frame (refer to the XNET ECU FlexRay:Startup? property set to true, this property returns this frame. Otherwise, it is empty. 4-315 © National Instruments NI-XNET Hardware and Software Manual

381 Chapter 4 NI-XNET API for LabVIEW—XNET ECU Property Node FlexRay:Wakeup Channels Data Type Direction Required? Default Read/Write No None Property Class XNET ECU Short Name FlexRay.WakeupChs Description This property specifies the channel(s) on wh ich the FlexRay ECU (node) is allowed to generate the wake-up pattern. The default value of this property is not to be a wakeup node. rameter corresponds to a WAKE-UP-CHANNEL When importing from a FIBEX file, this pa being set to True for each connected channel. The values supported for this property (enumeration) are A = 1, B = 2, A and B = 3, and None = 4. FlexRay:Wakeup Pattern Data Type Direction Required? Default Read/Write No 2 Property Class XNET ECU Short Name FlexRay.WakeupPtrn Description This property specifies the number of repetitions of the wakeup symbol that are combined to form a wakeup pattern when the FlexRay ECU (node) enters the POC:WAKEUP_SEND state. The POC:WAKEUP_SEND state is one of the FlexRay controlle r state transitions during the wakeup process. In this state, the controller sends the wakeup pattern on the specified Wakeup Channel and ch ecks for collisions on the bus. 4-316 NI-XNET Hardware and Software Manual ni.com

382 Chapter 4 NI-XNET API for LabVIEW—XNET ECU Property Node is set to a value other than This property is relevant only when FlexRay:Wakeup Channels is True. FlexRay:Use Wakeup None and pWakeupPattern This property corresponds to the FlexRay Protocol node parameter in the . Specification The supported values for this property are 2–63. 4-317 © National Instruments NI-XNET Hardware and Software Manual

383 Chapter 4 NI-XNET API for LabVIEW—XNET ECU Property Node Comment Data Type Direction Required? Default Read/Write No Empty String Property Class XNET ECU Short Name Comment Description Comment describing the ECU object. A comment is a string containing up to 65535 characters. Configuration Status Data Type Direction Required? Default N/A N/A Read Only Property Class XNET ECU Short Name ConfigStatus Description The ECU object conf iguration status. ET error code. You can pass the value to Configuration Status returns an NI-XN Simple Error Handler.vi error code input to convert the value to a text description (on message output) of the configuration problem. the database are not returned from the XNET By default, incorrectly configured ECUs in Cluster in the bus communication. You can property because they cannot be used ECUs change this behavior by setting the XNET Database ShowInvalidFromOpen? property to true. When the configuration status of an ECU becam e invalid after the database is opened, the ShowInvalidFromOpen? ECU still is returned from the XNET Cluster ECUs property even if is false. 4-318 NI-XNET Hardware and Software Manual ni.com

384 Chapter 4 NI-XNET API for LabVIEW—XNET ECU Property Node Frames Received Direction Required? Default Data Type Read/Write No Empty Array Property Class XNET ECU Short Name FrmsRx Description Returns an array of I/O names of frames the ECU receives. This property defines all fram es the ECU receives. All frames an ECU receives in a given cluster must be defined in the same cluster. Frames Transmitted Data Type Direction Required? Default No Read/Write Empty Array Property Class XNET ECU Short Name FrmsTx Description Returns an array of I/O names of frames the ECU transmits. es the ECU transmits. All frames an ECU transmits in a given This property defines all fram cluster must be defined in the same cluster. 4-319 © National Instruments NI-XNET Hardware and Software Manual

385 Chapter 4 NI-XNET API for LabVIEW—XNET ECU Property Node LIN:Master? Data Type Direction Required? Default Read/Write No False Property Class XNET ECU Short Name LIN.Master? Description Determines whether the ECU is a LI N master (true) or slave (false). LIN:Protocol Version Required? Default Direction Data Type Read/Write N/A Yes Property Class XNET ECU Short Name LIN.ProtclVer Description The LIN standard version this ECU uses. This property is a ring (enumerated list) with the following values: String Va l u e 1.2 2 1.3 3 2.0 4 2.1 5 4-320 NI-XNET Hardware and Software Manual ni.com

386 Chapter 4 NI-XNET API for LabVIEW—XNET ECU Property Node LIN:Initial NAD Data Type Direction Required? Default N/A N/A Read Only Property Class XNET ECU Short Name InitialNAD Description Initial NAD of a LIN slave node. NAD is the address of a slave node and is used in diagnostic ed NAD with node c onfiguration services. services. Initial NAD is replaced by configur Caution This property is not saved in the FIBEX database. You can import it only from an LDF file. LIN:Configured NAD Data Type Direction Required? Default N/A N/A Read Only Property Class XNET ECU Short Name ConfigNAD Description e address of a slave node and is used in Configured NAD of a LIN slave node. NAD is th diagnostic services. Initial NAD is replaced by configured NAD with node configuration services. This property is not saved in the FIBEX database. You can import it only from an Caution LDF file. 4-321 © National Instruments NI-XNET Hardware and Software Manual

387 Chapter 4 NI-XNET API for LabVIEW—XNET ECU Property Node LIN:Supplier ID Data Type Direction Required? Default N/A Read Only N/A Property Class XNET ECU Short Name SupplierID Description ng the supplier of the LIN node (ECU). Supplier ID is a 16-bit value identifyi This property is not saved in the FIBEX database. You can import it only from an Caution LDF file. LIN:Function ID Data Type Direction Required? Default N/A N/A Read Only Property Class XNET ECU Short Name FunctionID Description Function ID is a 16-bit value identifying the function of the LIN node (ECU). This property is not saved in the FIBEX database. You can import it only from an Caution LDF file. 4-322 NI-XNET Hardware and Software Manual ni.com

388 Chapter 4 NI-XNET API for LabVIEW—XNET ECU Property Node LIN:P2min Data Type Direction Required? Default N/A Read Only N/A Property Class XNET ECU Short Name P2min Description of the last frame of the diagnostic request The minimum time in seconds between reception and the response sent by the node. Caution This property is not saved in the FIBEX database. You can import it only from an LDF file. LIN:STmin Data Type Direction Required? Default N/A Read Only N/A Property Class XNET ECU Short Name STmin Description The minimum time in seconds the node requir es to prepare for the next frame of the diagnostic service. Caution This property is not saved in the FIBEX database. You can import it only from an LDF file. 4-323 © National Instruments NI-XNET Hardware and Software Manual

389 Chapter 4 NI-XNET API for LabVIEW—XNET ECU Property Node Name (Short) Data Type Direction Required? Default Read/Write Yes Defined in Create Object Property Class XNET ECU Short Name NameShort Description String identifying the ECU object. nd the underscore (_) are valid characters for Lowercase letters, uppercase letters, numbers, a the short name. The space ( ), period (.), and ot her special characters ar e not supported within the name. The short name must begin with a le tter (uppercase or lower case) or underscore, and not a number. The short name is limited to 128 characters. An ECU name must be unique for all ECUs in a cluster. , such as the database This short name does not include qualifiers to en sure that it is unique and cluster name. It is for display purposes. The fully qualified name is available by using the XNET ECU I/O name as a string. You can write this property to change the ECU’ s short name. When you do this and then use me, errors can result because the old name the original XNET ECU that contains the old na cannot be found. Follow these steps to avoid this problem: 1. Get the old Name (Short) property using the property node. Set the new Name (Short) property for the object. 2. . Wire the close all? 3. Close the object using XNET Database Close.vi input as false to close the renamed object only. with 4. Wire the XNET ECU as the input string to Search and Replace String Function.vi the old Name as the search st ring and the new Name as the replacement string. This text that ensures a ile retaining the other replaces the short name in the XNET ECU, wh unique name. 4-324 NI-XNET Hardware and Software Manual ni.com

390 Chapter 4 NI-XNET API for LabVIEW—XNET ECU Property Node The following diagram demonstrates steps 1 through 4 for an XNET Frame I/O name: © National Instruments 4-325 NI-XNET Hardware and Software Manual

391 Chapter 4 NI-XNET API for LabVIEW—XNET ECU Constant XNET ECU Constant This constant provides the constant form of the XNET ECU I/O name. You drag a constant to the block diagram of your VI, then select an ECU. You can change constants only during configuration, prior to running the VI. For a complete description, refer to XNET ECU I/O Name . XNET Frame Property Node Format Description Property node used to read/write properties for an XNET Frame I/O Name . to change direction between read and write. Pull down this node to add properties. Right-click e a constant, control, or indicator. Right-click each property name to creat For help on a specific property, open the LabVIEW context help window () and move your cursor over the property name. For more information about LabVIEW property nodes, open the main LabVIEW help (select Search the LabVIEW Help from the Help menu) and look for the Property Nodes topic in the index. CAN:Extended Identifier? Direction Required? Default Data Type Read/Write No False Property Class XNET Frame Short Name CAN.ExtID? Description Identifier property in a CAN cluster This property determines whether the XNET Frame represents a standard 11-bit (false) or extended 29-bit (true) arbitration ID. 4-326 NI-XNET Hardware and Software Manual ni.com

392 Chapter 4 NI-XNET API for LabVIEW—XNET Frame Property Node CAN:Timing Type Data Type Direction Required? Default Read/Write No Event Data (If Not in Database) Property Class XNET Frame Short Name CAN.TimingType Description Specifies the CAN frame timing. within the embedded the frame’s transfer Because this property specifies the behavior of system (for example, a vehicle), it describes the transfer between ECUs in the network. In the following description, transmitting ECU refers to the ECU that transmits the CAN data frame (and possibly receives the asso ciated CAN remote frame). Receiving ECU refers to an ECU CAN remote frame). that receives the CAN data frame (and possibly transmits the associated When you use the frame with output session acts as the in an NI-XNET session, an transmitting ECU, and an ECU. For a description of how input session acts as a receiving these CAN timing types apply to the NI-XNET session mode, refer to CAN Timing Type and Session Mode . The CAN timing types (decimal value in parentheses) are: Cyclic Data (0) The transmitting ECU transmits the CAN data frame in a cyclic (periodic) manner . The XNET Frame CAN:Transmit Time property defines the time between cycles. The transmitting ECU ignores CAN remote frames received for this frame. The transmitting ECU transmits the CAN data frame in an Event Data (1) CAN:Transmit Time event-driven manner. The XNET Frame property defines the minimum interval. For NI-XNET, the event occurs when you call . The transmitting ECU XNET Write.vi ignores CAN remote frames received for this frame. Cyclic Remote (2) The receiving ECU transmits the C AN remote frame in a cyclic CAN:Transmit Time . The XNET Frame (periodic) manner property defines the time between cycles. The transmitting ECU responds to each CAN remote frame by transmitting the associated CAN data frame. 4-327 © National Instruments NI-XNET Hardware and Software Manual

393 Chapter 4 NI-XNET API for LabV IEW—XNET Frame Property Node e CAN remote frame in an The receiving ECU transmits th Event Remote (3) event-driven manner. The XNET Frame CAN:Transmit Time property defines the minimum interval. For NI-XNET, the event occurs when you call XNET Write.vi . The transmitting ECU responds to each CAN remote frame by transmitting the associated CAN data frame. If you are using a FIBEX database, this property is a required part of the XML schema for a frame, so the default (initial) value is obtained from the file. If you are using a CANdb ( .dbc ) database, this property is an optional attribute in the file. If NI-XNET finds an attribute named GenMsgSendType , that attribute is the default value of this property. If the GenMsgSendType attribute begins with cyclic, this property’s default value is Cyclic Data; otherwise, it is Event Data. If the CANdb file does not use the GenMsgSendType attribute, this property uses a default value of Event Data, which you can change in your application. If you are using an database or an in-memory database (XNET Create Frame), this .ncd property uses a default value of Event Data. Within your application, change this property to the desired timing type. 4-328 NI-XNET Hardware and Software Manual ni.com

394 Chapter 4 NI-XNET API for LabVIEW—XNET Frame Property Node CAN:Transmit Time Data Type Direction Required? Default Read/Write No 0.1 (If Not in Database) Property Class XNET Frame Short Name CAN.TxTime Description frames from th e transmitting ECU. Specifies the time between consecutive The data type is 64-bit floating point (DBL). The units are in seconds. Although the fractional part of the DBL data t ype can provide resolutio n of picoseconds, the NI-XNET CAN transmit supports an accuracy of 500  s. Therefore, when used within an NI-XNET output session, this property is rounded to the nearest 500 s increment (0.0005).  CAN:Timing Type For a of Cyclic Data or Cyclic Remote, this property specifies the time between consecutive data/remote frames. A time of 0.0 is invalid. For a CAN:Timing Type of Event Data or Event Remote, this property specifies the minimum ote frames when the event oc time between consecutive data/rem curs quickly. This is also known as the debounce time or minimum interval. The time is measured from the end of e. A time of 0.0 specifies no previous frame (acknowledgment) to the start of the next fram minimum (back to back frames allowed). If you are using a FIBEX database, this property is a required part of the XML schema for a frame, so the default (initial) value is obtained from the file. If you are using a CANdb ( .dbc ) database, this property is an optional attribute in the file. If NI-XNET finds an attribute named GenMsgCycleT ime, that attribute is interpreted as a number of milliseconds and used as the default value of this property. If the CANdb file does not use the GenMsgCycleTime attribute, this property uses a default value of 0.1 (100 ms), which you can change in your application. If you are using a .ncd database or an in-memory data base (XNET Create Frame), this property uses a default value of 0.1 (100 ms). W ithin your application, change this property to the desired time. 4-329 © National Instruments NI-XNET Hardware and Software Manual

395 Chapter 4 NI-XNET API for LabV IEW—XNET Frame Property Node Cluster Required? Default Data Type Direction Read Only N/A N/A Property Class XNET Frame Short Name Cluster Description nt cluster in which the frame has been created. This property returns the I/O name of the pare You cannot change the parent cluster af ter the frame object has been created. Comment Required? Default Data Type Direction Read/Write Empty String No Property Class XNET Frame Short Name Comment Description Comment describing the frame object. A comment is a string containing up to 65535 characters. 4-330 NI-XNET Hardware and Software Manual ni.com

396 Chapter 4 NI-XNET API for LabVIEW—XNET Frame Property Node Configuration Status Required? Default Data Type Direction Read Only N/A N/A Property Class XNET Frame Short Name ConfigStatus Description iguration status. The frame object conf Configuration Status returns an NI-XN ET error code. You can pass the value to Simple Error error code input to convert the value to a text description (on message output) of Handler.vi the configuration problem. By default, incorrectly config ured frames in the database are not returned from the XNET Cluster Frames property because they cannot be used in the bus communication. You can property to true. ShowInvalidFromOpen? change this behavior by setting the XNET Database When a frame configuration status became invalid after the database is opened, the frame still Frames property even if ShowInvalidFromOpen? is false. is returned from the XNET Cluster Examples of invalid frame configuration: • A required property of the frame or an object contained in this frame has not been defined. For example, Frame Payload Length. e is incorrect. CAN frames must use 0 to • The number of bytes specified for this fram 8 bytes. FlexRay frames must use 0 to 254 bytes (even numbers only). The CAN arbitration ID is invalid. The standard ID is greater than 0x7FF (11 bits) or the • extended ID is greater than 0x1FFFFFFF (29 bits). • The FlexRay frame is specified to use channe ls not defined in the cluster. For example, FlexRay:Channels the XNET Cluster property is set to Channel A only, but the XNET Frame FlexRay:Channel Assignment property is set to Channel A and B. FlexRay:Channel Assignment property in this dynamic FlexRay The XNET Frame • frame is set to Channel A and B, but dynami c frames can be sent on only one channel (A or B). 4-331 © National Instruments NI-XNET Hardware and Software Manual

397 Chapter 4 IEW—XNET Frame Property Node NI-XNET API for LabV Default Payload Data Type Required? Default Direction No Array of All 0 Read/Write Property Class XNET Frame Short Name DefaultPayload Description The frame default payload, specifi ed as an array of bytes (U8). The number of bytes in the ar ray must match the XNET Frame Payload Length property. This property’s initial value is an array of al l 0. For the database formats NI-XNET supports, this property is not provided in the database file. When you use this frame within an NI-XNET session, this property’s use varies depending on the session mode. The following sections describe this proper ty’s behavior for each session mode. Frame Output Single-Point and Frame Output Queued Modes Use this property when a frame transmits prior to a call to XNET Write.vi . This can occur property to false and call prior XNET Start.vi when you set the XNET Session Auto Start? to . When Auto Start? is true (default), the first call to XNET Write.vi also XNET Write.vi starts frame transmit, so th is property is not used. The following frame configurations potentially can transmit prior to a call to XNET Write.vi : • CAN:Timing Type of Cyclic Data • of Cyclic Remote (for example, CAN:Timing Type a remote frame received prior to a call to ) XNET Write.vi • CAN:Timing Type of Event Remote (for example, a remote frame received prior to a call to XNET Write.vi ) • FlexRay:Timing Type of Cyclic hedule entry of Type unconditional • LIN frame in a sc 4-332 NI-XNET Hardware and Software Manual ni.com

398 Chapter 4 NI-XNET API for LabVIEW—XNET Frame Property Node The following frame configurations cannot transmit prior to a call to XNET Write.vi , so this property is not used: • CAN:Timing Type of Event Data • FlexRay:Timing Type of Event • Type sporadic or event triggered LIN frame in a schedule entry of Frame Output Stream Mode This property is not used. Transmit is limited to frames provided to XNET Write.vi . Signal Output Single-Po int, Signal Output Waveform, and Signal Output XY Modes . Refer to XNET Write.vi transmits prior to a call to Frame Use this property when a frame Output Single-Point and Frame Output Queued Modes for a list of applicable frame configurations. This property is used as the initial payload, then each XNET Signal Default Value is mapped into that payload, and the result is used for the frame transmit. Frame Input Stream and Frame Input Queued Modes not return data prior to receiving frames. This property is not used. These modes do Frame Input Single-Point Mode eceiving the first frame. This property is used for frames XNET Read.vi returns prior to r Signal Input Single-Point, Signal Input Waveform, and Signal Input XY Modes is XNET Read.vi is used when This property is not used. Each XNET Signal Default Value called prior to receiving the first frame. 4-333 © National Instruments NI-XNET Hardware and Software Manual

399 Chapter 4 IEW—XNET Frame Property Node NI-XNET API for LabV FlexRay:Base Cycle Data Type Required? Default Direction Yes N/A Read/Write Property Class XNET Frame Short Name FlexRay.BaseCycle Description The first communication cycle in which a frame is sent. In FlexRay, a communication cycl e contains a number of slots in which a frame can be sent. Every node on the bus provides a 6-bit cycle coun ter that counts the cycles from 0 to 63 and then restarts at 0. The cycle numbe r is common for all nodes on the bus. NI-XNET has two mechanisms for changing the frame sending frequency: • If the frame should be sent faster than the cycle period, use In-Cycle Repetition (refer to the XNET Frame FlexRay:In Cycle Repetitions:Identifiers property). use this property and the XNET slower than the cycle period, If the frame should be sent • Frame property. FlexRay:Cycle Repetition The second method is called cycle multiplexing. It allows sending multiple frames in the same slot, but on different cycle counters. If a frame should be sent in every cycle, set this proper ty to 0 and the XNET Frame FlexRay:Cycle Repetition property to 1. For cycle multiplexing, set the XNET Frame FlexRay:Cycle Repetition property to 2, 4, 8, 16, 32, or 64. Example: • FrameA and FrameB are both sent in slot 12. FrameA : The XNET Frame FlexRay:Base Cycl e property is 0 and XNET Frame • property is 2. This frame is FlexRay:Cycle Repetition sent when the cycle counter has the value 0, 2, 4, 6, ... • FrameB : The XNET Frame FlexRay:Base Cycl e property is 1 and XNET Frame sent when the cycle counter has property is 2. This frame is FlexRay:Cycle Repetition the value 1, 3, 5, 7, ... 4-334 NI-XNET Hardware and Software Manual ni.com

400 Chapter 4 NI-XNET API for LabVIEW—XNET Frame Property Node This property is required. If the property doe s not contain a valid value, and you create an XNET session that uses this frame, the session re turns an error. To ensu re that the property can do one of the following: contains a valid value, you • Use a database file (or alias) to create the session. The file formats require a valid value in the text for this property. • Set a value in LabVIEW using the property node. your own in-memory database ( This is needed when you create :memory: ) rather than use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session. For more information about using database files and in-memory databases, refer to Databases . 4-335 © National Instruments NI-XNET Hardware and Software Manual

401 Chapter 4 IEW—XNET Frame Property Node NI-XNET API for LabV FlexRay:Channel Assignment Data Type Direction Required? Default Read/Write Yes N/A Property Class XNET Frame Short Name FlexRay.ChAssign Description This property determines on which FlexRay chan nels the frame must be transmitted. A frame can be transmitted only on existing FlexRay channels, configured in the XNET Cluster FlexRay:Channels property. Frames in the dynamic FlexRay segment cannot be sent on both channels; they must use ynamic segment use slot IDs greater than either channel A or B. Frames in the d the number of static slots cluster parameter. This property is required. If the property doe s not contain a valid value, and you create an XNET session that uses this frame, the session re turns an error. To ensure that the property contains a valid value, you can do one of the following: • Use a database file (or alias) to create the session. The file formats require a valid value in the text for this property. • Set a value in LabVIEW using the property node. This is needed when you create your own in-memory database ( :memory: ) rather than use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session. For more information about using database files and in-memory databases, refer to Databases . 4-336 NI-XNET Hardware and Software Manual ni.com

402 Chapter 4 NI-XNET API for LabVIEW—XNET Frame Property Node FlexRay:Cycle Repetition Data Type Direction Required? Default Read/Write Yes N/A Property Class XNET Frame Short Name FlexRay.CycleRep Description The number of cycles after which a frame is sent again. In FlexRay, a communication cycl e contains a number of slots in which a frame can be sent. Every node on the bus provides a 6-bit cycle coun ter that counts the cycles from 0 to 63 and then restarts at 0. The cycle numbe r is common for all nodes on the bus. NI-XNET has two mechanisms for changing the frame sending frequency: cycle period, use In-Cycle Repetition (refer to • If the frame should be sent faster than the property). FlexRay:In Cycle Repetitions:Identifiers the XNET Frame If the frame should be sent slower than the cycle period, use the XNET Frame • FlexRay:Base Cycle property and this property. The second method is called cycle multiplexing. It allows sending multiple frames in the same slot, but on different cycle counters. If a frame should be sent in every cycle, set the XNET Frame FlexRay:Base Cycle property ng, set this property to 2, 4, 8, 16, 32, or 64. to 0 and this property to 1. For cycle multiplexi Examples: • FrameA and FrameB are both sent in slot 12. • FrameA: The XNET Frame FlexRay:Base Cycle property is set to 0 and XNET Frame FlexRay:Cycle Repetition property is set to 2. This fram e is sent when the cycle counter has the value 0, 2, 4, 6, ... property is set to 1 and XNET Frame FlexRay:Base Cycle FrameB: The XNET Frame • FlexRay:Cycle Repetition property is set to 2. This fram e is sent when the cycle counter has the value 1, 3, 5, 7, ... 4-337 © National Instruments NI-XNET Hardware and Software Manual

403 Chapter 4 IEW—XNET Frame Property Node NI-XNET API for LabV This property is required. If the property doe s not contain a valid value, and you create an XNET session that uses this frame, the session re turns an error. To ensure that the property can do one of the following: contains a valid value, you Use a database file (or alias) to create the session. • The file formats require a valid value in the text for this property. • Set a value in LabVIEW using the property node. your own in-memory database ( This is needed when you create :memory: ) rather than use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session. For more information about using database files and in-memory databases, refer to Databases . 4-338 NI-XNET Hardware and Software Manual ni.com

404 Chapter 4 NI-XNET API for LabVIEW—XNET Frame Property Node FlexRay:Payload Preamble? Data Type Direction Required? Default False No Read/Write Property Class XNET Frame Short Name FlexRay.Preamble? Description This property determines whether payloa d preamble is used in a FlexRay frame: • For frames in the static segment, it indi cates that the network management vector is transmitted at the beginning of the payload. For frames in the dynamic segm ge ID is transmitted at the ent, it indicates that the messa • beginning of the payload. 4-339 © National Instruments NI-XNET Hardware and Software Manual

405 Chapter 4 NI-XNET API for LabV IEW—XNET Frame Property Node FlexRay:Startup? Data Type Direction Required? Default Read/Write No False Property Class XNET Frame Short Name FlexRay.Startup? Description This property determines whet her the frame is a FlexRay st artup frame. FlexRay startup frames always are FlexRay sync frames also. FlexRay:Sync? When this property is set to true, the XNET Frame property • automatically is set to true. • When this property is set to false, the XNET Frame FlexRay:Sync? property is not changed. FlexRay:Sync? • When the XNET Frame property is set to false, this property automatically is set to false. • When the XNET Frame FlexRay:Sync? property is set to true, this property is not changed. An ECU can send only one startup frame. The startup frame, if an ECU transmits it, is returned from the XNET ECU FlexRay:Startup Frame property. 4-340 NI-XNET Hardware and Software Manual ni.com

406 Chapter 4 NI-XNET API for LabVIEW—XNET Frame Property Node FlexRay:Sync? Direction Data Type Required? Default False Read/Write No Property Class XNET Frame Short Name FlexRay.Sync? Description r the frame is a FlexRay sync frame. FlexRay startup frames This property determines whethe always are FlexRay sync frames also: • When this property is set to false, the XNET Frame FlexRay:Startup? property is automatically set to false. FlexRay:Startup? When this property is set to true, the XNET Frame property is not • changed. When the XNET Frame • FlexRay:Startup? property is set to true, this property is set to true. property is set to false, this property is not FlexRay:Startup? • When the XNET Frame changed. An ECU can send only one sync frame. 4-341 © National Instruments NI-XNET Hardware and Software Manual

407 Chapter 4 IEW—XNET Frame Property Node NI-XNET API for LabV FlexRay:Timing Type Data Type Direction Required? Default Read/Write No Cyclic in Static Segment, Event in Dynamic Segment Property Class XNET Frame Short Name FlexRay.TimingType Description Specifies the FlexRay frame timing (decimal value in parentheses): Cyclic (0) Payload data transmits on every occurrence of the frame’s slot. Event (1) Payload data transmits in an event-driven manner. Within the ECU that is associated with the availability transmits the frame, the event typically of new data. This property’s behavior depends on the Flex Ray segment where the frame is located: static or dynamic. If the frame’s Identi fier (slot) is less than or equal to the cluster’s Number Of Static Slots, the frame is static. Static Cyclic means no null frame is tran smitted. If new data is not provided for the cycle, the previous payload data transmits again. Event means a null frame is transmitted when no event is pending for the cycle. This property’s default value for the static segment is Cyclic. Dynamic means the frame transmits in its minislot on every cycle. Cyclic Event means the frame transmits in the minislot when the ev ent is pending for the cycle. This property’s default value fo r the dynamic segment is Event. For a description of how these FlexRay timing types apply to the NI-XNET session mode, refer to . FlexRay Timing Type and Session Mode 4-342 NI-XNET Hardware and Software Manual ni.com

408 Chapter 4 NI-XNET API for LabVIEW—XNET Frame Property Node FlexRay:In Cycle Repetitio ns:Channel Assignments Data Type Direction Required? Default Read/Write No Empty Array Property Class XNET Frame Short Name FlexRay.InCycRep.ChAssigns Description FlexRay channels for in-cycle frame repetition. A FlexRay frame can be sent multiple times per cycle. The XNET Frame FlexRay:Channel Assignment property defines the first channel assignment in the cycle. This property defines subsequent channel assign FlexRay:In Cycle Repetitions:Identifiers ments. The XNET Frame property defines the corresponding slot IDs. Both properties are arrays of maximum three values, determining the slot ID and channel a ssignments for the frame. Values at the same array position are correspondi ng; therefore, both arrays must have the same size. property before setting this property. You must set the FlexRay:Channel Assignment FlexRay:Channel Assignment undefined when a new frame is is a required property that is created. When FlexRay:Channel Assignment is undefined, setting FlexRay:In Cycle Repetitions:Channel Assignments returns an error. For convenience, you can set both FlexRay:Channel Assignment first properties in one XNET Fram e property node, setting the (the properties in a property node are set starting from top position to bottom). 4-343 © National Instruments NI-XNET Hardware and Software Manual

409 Chapter 4 NI-XNET API for LabV IEW—XNET Frame Property Node FlexRay:In Cycle Repetitions:Enabled? Data Type Direction Required? Default No Read Only False Property Class XNET Frame Short Name FlexRay.InCycRep.Enabled? Description FlexRay in-cycle frame repetition is enabled. property A FlexRay frame can be sent multiple times per cycle. The XNET Frame Identifier defines the first slot ID in the cycle. The XNET Frame FlexRay:In Cycle Repetitions:Identifiers property can define the subseque nt slot IDs, and the XNET Frame FlexRay:In Cycle Repetitions:Channel Assignments property defines the corresponding FlexRay channels. Both properti es are arrays of maximum three values determining the slot e frame. Values at the same array position are corresponding; ID and FlexRay channels for th therefore, both arrays must have the same size. This property returns true when at least one in -cycle repetition has been defined, which means that both the FlexRay:In Cycle Repetitions:Identifiers and FlexRay:In Cycle Repetitions:Channel Assignments arrays are not empty. This property returns false when at least one of the previously mentioned arrays is empty. In this case, in-cycle-repetition is not used. 4-344 NI-XNET Hardware and Software Manual ni.com

410 Chapter 4 NI-XNET API for LabVIEW—XNET Frame Property Node FlexRay:In Cycle Re petitions:Identifiers Data Type Direction Required? Default No Empty Array Read/Write Property Class XNET Frame Short Name FlexRay.InCycRep.IDs Description FlexRay in-cycle repetition slot IDs. Identifier property A FlexRay frame can be sent multip le times per cycle. The XNET Frame exRay:In Cycle Repetitions:Identifiers property defines the first slot ID in the cycle. The Fl defines subsequent slot IDs. The XNET Frame FlexRay:In Cycle Repetitions:Channel Assignments property defines the corresponding FlexRay channel assignments. Both properties are arrays of maximum three values, determining the subsequent slot IDs and channel assignments for the frame. Values at the same array position are corresponding; therefore, both arrays must have the same size. You must set the XNET Frame property before setting the FlexRay:In Cycle Identifier Repetitions:Identifiers property. Identifier is a required property that is undefined when a new frame is created. When Identifier is undefined, setting in-cycle repetition slot IDs returns an error. For your convenience, you can set both properties in one XNET Frame property node, node are set starting from top position first (the properties in a property Identifier setting the to bottom). 4-345 © National Instruments NI-XNET Hardware and Software Manual

411 Chapter 4 NI-XNET API for LabV IEW—XNET Frame Property Node Identifier Data Type Direction Required? Default Read/Write Yes N/A Property Class XNET Frame Short Name ID Description Determines the frame identifier. This property is required. If the property doe s not contain a valid value, and you create an XNET Session that uses this frame, the session returns an error. To ensure that the property can do one of the following: contains a valid value, you • Use a database file (or alias) to create the session. The file formats require a valid value in the text for this property. • Set a value in LabVIEW using the property node. This is needed when you create your own in-memory database ( :memory: ) rather than use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session. iles and in-memory databases, refer to Databases For more information on using database f . CAN For CAN frames, this is the Arbitration ID. property is set to false, this is the standard When the XNET Frame CAN:Extended Identifier? CAN identifier with a size of 11 bits, which results in allowed range of 0–2047. However, the CAN standard disallows identifiers in which the first 7 bits are all recessive, so the working range of identifiers is 0–2031. CAN:Extended Identifier? property is set to true, this is the extended When the XNET Frame CAN identifier with a size of 29 bits, which results in allowed range of 0–536870911. 4-346 NI-XNET Hardware and Software Manual ni.com

412 Chapter 4 NI-XNET API for LabVIEW—XNET Frame Property Node FlexRay For FlexRay frames, this is the Slot ID in wh ich the frame is sent. The valid value range for a FlexRay Slot ID is 1–2047. You also can send a FlexRay frame in multiple sl ots per cycle. You can define subsequent slot IDs for the frame in the XNET Frame FlexRay:In Cycle Repetitions:Identifiers property. Use this concept to increase a frame’s sending fre quency. To decrease a frame’s sending frequency and share the same slot for different frames de pending on the cycle counter, refer to the XNET FlexRay:Cycle Repetition and FlexRay:Base Cycle properties. Frame The slot ID determines whether a FlexRay frame is sent in a static or dynamic segment. If the property, slot ID is less than or equal to the XNET Cluster FlexRay:Number of Static Slots the frame is sent in the communication cycle static segment; otherwise, it is sent in the dynamic segment. If the frame identifier is not in the allowed ra nge, this is reported as an error in the XNET Frame Configuration Status property. LIN ected). The valid range for a LIN frame ID is For LIN frames, this is the frame’s ID (unprot 0–63 (inclusive). 4-347 © National Instruments NI-XNET Hardware and Software Manual

413 Chapter 4 NI-XNET API for LabV IEW—XNET Frame Property Node LIN:Checksum Data Type Direction Required? Default Enhanced Read Only N/A Property Class XNET Frame Short Name LIN.Checksum Description Determines whether the LIN frame transmitted checksum is classic or enhanced. The enhanced checksum consider s the protected identifier when it is generated. This property is a ring (enumerated list) with the following values: String Va l u e Classic 0 1 Enhanced itting and r rsion of ECUs transm The checksum is determined from the LIN ve eceiving the frame. The lower version of both ECUs is significant. If the LIN version of both ECUs is 2.0 or higher, the checksum type is enhanced; otherwise, the checksum type is classic. Diagnostic frames (with decimal identifier 60 or 61) always use classic checksum, even on . x LIN 2. 4-348 NI-XNET Hardware and Software Manual ni.com

414 Chapter 4 NI-XNET API for LabVIEW—XNET Frame Property Node Mux:Data Multiplexer Signal Data Type Direction Required? Default N/A N/A Read Only Property Class XNET Frame Short Name DataMuxSig Description Data multiplexer signal in the frame. This property returns an I/O name of the data multiplexer signal. If the data multiplexer is not rol is empty. Use the XNET Frame Mux:Is Data defined in the frame, the I/O cont Multiplexed? property to determine whether the frame contains a multiplexer signal. You can create a data multiplexer signal by creating a signal and then setting the XNET Signal Mux:Data Multiplexer? property to true. A frame can contain only one data multiplexer signal. Mux:Is Data Multiplexed? Data Type Direction Required? Default Read Only No False Property Class XNET Frame Short Name Mux.IsMuxed? Description Frame is data multiplexed. ains a multiplexer signa This property returns true if the frame cont l. Frames containing a multiplexer contain subframes that allow usin g bits of the frame payload for different information (signals) depending on the multiplexer value. 4-349 © National Instruments NI-XNET Hardware and Software Manual

415 Chapter 4 NI-XNET API for LabV IEW—XNET Frame Property Node Mux:Static Signals Data Type Direction Required? Default N/A Read Only N/A Property Class XNET Frame Short Name Mux.StatSigs Description Static signals in the frame. Returns an array of I/O names of signals in the frame that do not depend on the multiplexer value. Static signals are contained in every fram e transmitted, as opposed to dynamic signals, which are transmitted depending on the multiplexer value. You can create static signals by specifying th e frame as the parent object. You can create dynamic signals by specifying a subframe as the parent. If the frame is not multiplexed, this proper ty returns the same array as the XNET Frame Signals property. Mux:Subframes Data Type Direction Required? Default Read Only N/A N/A Property Class XNET Frame Short Name Mux.Subframes Description Returns an array of I/O names of subframes in the frame. A subframe defines a group of signals transmitted using the same multiplexer value. Only one subframe at a time is transmitted in the frame. ubframe object as a child of a frame. A subframe is defined by creating a s 4-350 NI-XNET Hardware and Software Manual ni.com

416 Chapter 4 NI-XNET API for LabVIEW—XNET Frame Property Node Name (Short) Data Type Direction Required? Default Read/Write Yes Defined in Create Object Property Class XNET Frame Short Name NameShort Description String identifying a frame object. nd the underscore (_) are valid characters for Lowercase letters, uppercase letters, numbers, a the short name. The space ( ), pe riod (.), and other sp ecial characters are no t supported within the name. The short name must begin with a le tter (uppercase or lower case) or underscore, and not a number. The short name is limited to 128 characters. for all frames in a cluster. A frame name must be unique This short name does not include qualifiers to ensu such as the database re that it is unique, fully qualified name is available by using the and cluster name. It is for display purposes. The XNET Frame I/O name as a string. You can write this property to change the frame’ s short name. When you do this and then use the original XNET Frame that co ntains the old name, errors can result because the old name cannot be found. Follow these steps to avoid this problem: 1. Get the old Name (Short) property using the property node. Set the new Name (Short) property for the object. 2. 3. Close the object using input as false to close all? . Wire the XNET Database Close.vi close the renamed object only. Search and Replace String Function.vi 4. Wire the XNET Frame as the input string to as the replacement string. This Name as the search string and the new with the old Name XNET Frame, while retaining the other text that ensures a replaces the short name in the unique name. 4-351 © National Instruments NI-XNET Hardware and Software Manual

417 Chapter 4 NI-XNET API for LabV IEW—XNET Frame Property Node The following diagram demonstrates steps 1 through 4 for an XNET Frame I/O name: NI-XNET Hardware and Software Manual 4-352 ni.com

418 Chapter 4 NI-XNET API for LabVIEW—XNET Frame Property Node Payload Length Data Type Direction Required? Default N/A Yes Read/Write Property Class XNET Frame Short Name PayldLen Description Number of bytes of data in the payload. For CAN or LIN, this is 0–8. For FlexRay, this is 0–254. As encoded on the FlexRay bus, all frames use an even payload (16-bit words), and the payload of all static slot s must be the same. Nevertheless, this property specifies the number of payload bytes used w ithin the frame, so its value can be odd. For example, if a FlexRay cluster uses static slots of 18 bytes, it is valid for this property to be 15, which specifies that the last 3 bytes are unused. This property is required. If the property doe s not contain a valid value, and you create an XNET session that uses this frame, the session re turns an error. To ensu re that the property can do one of the following: contains a valid value, you • Use a database file (or alias) to create the session. The file formats require a valid value in the text for this property. • Set a value in LabVIEW using the property node. This is needed when you create your own in-memory database ( :memory: ) rather than use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session. For more information about using database files and in-memory databases, refer to Databases . 4-353 © National Instruments NI-XNET Hardware and Software Manual

419 Chapter 4 IEW—XNET Frame Property Node NI-XNET API for LabV PDU_Mapping Data Type Direction Required? Default No Empty Array Read/Write Property Class XNET Frame Short Name PDU_Mapping Description This property maps existing PDUs to a frame. A mapped PDU is transmitted inside the frame payload when the frame is transmitted. You can map one or more PDUs to a frame and one PDU to multiple frames. One PDU_Mapping cluster (a LabVIEW cluster, as opposed to a database cluster object) from the array assigns one PDU to the frame. Th e cluster contains the following elements: • PDU : A string using the PDU I/O name syntax. If you wire an I/O name input to a string output, LabVIEW converts the I/O name to a string. • : Defines the start bit of the PDU inside the frame. Start Bit • : Defines the update bit for the PDU inside the frame. If the update bit is not Update Bit used, set the value to –1. (Refer to Update Bit for more information.) Databases imported from FIBEX prior to versio n 3.0 from DBC, NCD, or LDF files have a strong one-to-one relationship between frames and PDUs. Every frame has exactly one PDU mapped, and every PDU is mapped to exactly one frame. ty to an empty array. A frame without mapped To unmap PDUs from a frame, set this proper PDUs contains no signals. NI-XNET supports advanced PDU configuration (multiple PDUs in one frame or one PDU used in multiple frames) only for FlexRay. Refer to the XNET Cluster PDUs Required? property. For CAN and LIN, NI-XNET supports only a one-to-one relationship between frames and PDUs. For those interfaces, advanced PDU conf iguration returns an error from the XNET . If you do not use XNET Create Session.vi Frame Configuration Status property and advanced PDU configuration, you can avoid using PDUs in the database API and create signals and subframes directly on a frame. 4-354 NI-XNET Hardware and Software Manual ni.com

420 Chapter 4 NI-XNET API for LabVIEW—XNET Frame Property Node Signals Data Type Direction Required? Default N/A N/A Read Only Property Class XNET Frame Short Name Sigs Description I/O names of all signals in the frame. This property returns an array referencing a ll signals in the frame, including static and dynamic signals and the multiplexer signal. This property is read only. You can add signals to a frame using XNET Database Create XNET Database Delete Object.vi and remove them using . Object.vi 4-355 © National Instruments NI-XNET Hardware and Software Manual

421 Chapter 4 NI-XNET API for LabVIEW—XNET Frame Constant XNET Frame Constant This constant provides the constant form of the XNET Frame I/O name. You drag a constant a frame. You can change constants only during to the block diagram of your VI, then select configuration, prior to running the VI. For a complete description, refer to XNET Frame I/O Name . XNET PDU Property Node Format Description Property node used to read/write properties for an XNET PDU I/O Name . Pull down this node to add properties. Right-click to change direction between read and write. e a constant, control, or indicator. Right-click each property name to creat For help on a specific property, open the LabVIEW context help window () and move your cursor over the property name. For more information about LabVIEW property nodes, open the main LabVIEW help (select topic in Property Nodes Search the LabVIEW Help from the Help menu) and look for the the index. 4-356 NI-XNET Hardware and Software Manual ni.com

422 Chapter 4 NI-XNET API for LabV IEW—XNET PDU Property Node Cluster Required? Default Data Type Direction Read Only N/A N/A Property Class XNET PDU Short Name Cluster Description e PDU has been created. nt cluster in which th This property returns the I/O name to the pare You cannot change the parent clus ter after creating the PDU object. Comment Direction Data Type Required? Default Empty String No Read/Write Property Class XNET PDU Short Name Comment Description Comment describing the PDU object. A comment is a string containing up to 65535 characters. 4-357 © National Instruments NI-XNET Hardware and Software Manual

423 Chapter 4 NI-XNET API for La bVIEW—XNET PDU Property Node Configuration Status Data Type Direction Required? Default N/A Read Only N/A Property Class XNET PDU Short Name ConfigStatus Description The PDU object’s co nfiguration status. Simple Configuration Status returns an NI-XNET er ror code. The value can be passed to the Error Handler.vi error code input to convert it to a text description (on message output) of the configuration problem. By default, incorrectly configured PDUs in the database are not returned from the XNET Cluster PDUs property because they cannot be used in the bus communication. You can ShowInvalidFromOpen? property to true. change this behavior by setting the XNET Database When a PDU’s configuration stat us became invalid after the database has been opened, the PDU still is returned from the Cluster PDUs property even if ShowInvalidFromOpen? is false. Examples of invalid PDU configuration: • You have not defined a required property of the PDU (for example, PDU Payload Length). PDU is incorrect. CAN PDUs must use 0 to The number of bytes specified for this • 8 bytes. FlexRay PDUs must use 0 to 254 bytes (PDUs payload must fit into a frame). 4-358 NI-XNET Hardware and Software Manual ni.com

424 Chapter 4 NI-XNET API for LabV IEW—XNET PDU Property Node Frames Data Type Direction Required? Default N/A Read Only N/A Property Class XNET PDU Short Name Frms Description I/O names of all frames to which the PDU is mapped. A PDU is transmitted within the frames to which it is mapped. To map a PDU to a frame, use the XNET Frame PDU_Mapping property. You can map one PDU to multiple frames. Mux:Data Multiplexer Signal Data Type Direction Required? Default Read Only N/A N/A Property Class XNET PDU Short Name DataMuxSig Description Data multiplexer signal in the PDU. This property returns the data multiplexer signal I/O name. If the data multiplexer is not defined in the PDU, the I/O control is empty. Use the XNET PDU Mux:Is Data Multiplexed? DU contains a multiplexer signal. property to determine whether the P You can create a data multiplexer signal by creating a signal and then setting the XNET Signal property to true. Mux:Data Multiplexer? A PDU can contain only one data multiplexer signal. 4-359 © National Instruments NI-XNET Hardware and Software Manual

425 Chapter 4 NI-XNET API for La bVIEW—XNET PDU Property Node Mux:Is Data Multiplexed? Data Type Direction Required? Default False No Read Only Property Class XNET PDU Short Name Mux.IsMuxed? Description PDU is data multiplexed. al. PDUs containing a ains a multiplexer sign This property returns true if the PDU cont multiplexer contain subframes that allow using bits of the payload for different information (signals), depending on the multiplexer value. Mux:Static Signals Data Type Direction Required? Default Read Only N/A N/A Property Class XNET PDU Short Name Mux.StatSigs Description Static signals in the PDU. Returns an array of I/O names of signals in the PDU that do not depend on the multiplexer DU transmitted, as opposed to dynamic signals, value. Static signals are contained in every P which are transmitted depending on the multiplexer value. You can create static signals by specifying th e PDU as the parent object. You can create dynamic signals by specifying a subframe as the parent. Signals If the PDU is not multiplexed, this property returns the same array as the XNET PDU property. 4-360 NI-XNET Hardware and Software Manual ni.com

426 Chapter 4 IEW—XNET PDU Property Node NI-XNET API for LabV Mux:Subframes Required? Default Data Type Direction N/A Read Only N/A Property Class XNET PDU Short Name Mux.Subframes Description the PDU. A subframe defines a group of signals Returns an array of I/O names of subframes in transmitted using the same multiplexer value. Only one subframe is transmitted in the PDU at a time. You can define a subframe by creating a subframe object as a child of a PDU. 4-361 © National Instruments NI-XNET Hardware and Software Manual

427 Chapter 4 bVIEW—XNET PDU Property Node NI-XNET API for La Name (Short) Data Type Direction Required? Default Read/Write Yes Defined in Create Object Property Class XNET PDU Short Name NameShort Description String identifying a PDU object. nd the underscore (_) are valid characters for Lowercase letters, uppercase letters, numbers, a the short name. The space ( ), period (.), and ot her special characters ar e not supported within case) or underscore, the name. The short name must begin with a le tter (uppercase or lower and not a number. The short name is limited to 128 characters. A PDU name must be unique for all PDUs in a cluster. s short name. When you do this and then use You can write this property to change the PDU’ the original XNET PDU that contains the old na me, errors can result because the old name cannot be found. Follow these steps to avoid this problem: Get the old Name (Short) property using the property node. 1. Set the new Name (Short) property for the object. 2. 3. Wire the XNET PDU as the input string to Search and Replace String Function.vi with the old Name as the search string and the new Name as the replace string. This replaces the short name in the XNET PDU, while retaining the other text that ensures a unique name. to 4. Wire the result from Search and Replace String Function.vi XNET String to IO Name.vi . This casts the string back to a valid XNET PDU. 4-362 NI-XNET Hardware and Software Manual ni.com

428 Chapter 4 NI-XNET API for LabV IEW—XNET PDU Property Node Payload Length Direction Required? Default Data Type Read/Write Yes N/A Property Class XNET PDU Short Name PayldLen Description Determines the size of the PDU data in bytes. This property is required. If the property doe s not contain a valid value, and you create an XNET session that uses this PDU, the session re turns an error. To ensure that the property contains a valid value, you can do one of the following: • Use a database file (or alias) to create the session. The file formats require a valid value in the text for this property. • Set a value in LabVIEW using the property node. This is needed when you create your own in-memory database ( :memory: ) rather than use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session. For more information about using database files and in-memory databases, refer to Databases . 4-363 © National Instruments NI-XNET Hardware and Software Manual

429 Chapter 4 NI-XNET API for LabVIEW—XNET PDU Constant Signals Direction Required? Default Data Type Read Only N/A N/A Property Class XNET PDU Short Name Sigs Description I/O names of all signals in the PDU. This property returns an array referencing to all signals in the PDU, including static and dynamic signals and the multiplexer signal. This property is read only. You can add signals to a PDU using XNET Database Create XNET Database Delete Object.vi Object.vi and remove them using . XNET PDU Constant This constant provides the constant form of the XNET PDU I/O name. You drag a constant to the block diagram of your VI, then select a PDU. You can change constants only during XNET PDU I/O configuration, prior to running the VI. For a complete description, refer to . Name 4-364 NI-XNET Hardware and Software Manual ni.com

430 Chapter 4 W—XNET Subframe Property Node NI-XNET API for LabVIE XNET Subframe Property Node Format Description . XNET Subframe I/O Name Property node used to read/write properties for an to change direction between read and write. Pull down this node to add properties. Right-click Right-click each property name to creat e a constant, control, or indicator. For help on a specific property, open the LabVIEW context help window () and move your cursor over the property name. For more information about LabVIEW property nodes, open the main LabVIEW help (select topic in Property Nodes menu) and look for the Search the LabVIEW Help from the Help the index. 4-365 © National Instruments NI-XNET Hardware and Software Manual

431 Chapter 4 NI-XNET API for LabVIEW—XNET Subframe Property Node Dynamic Signals Data Type Required? Default Direction Read Only N/A N/A Property Class XNET Subframe Short Name DynSig Description Dynamic signals in the subframe. This property returns an array of I/O names of dynamic signals in the subframe. Those signals are transmitted when the multiplexer signal in the frame has the multiplexer value defined in the subframe. by specifying a reate Object.vi XNET Database C Dynamic signals are created with subframe as the parent. Frame Data Type Direction Required? Default N/A Read Only N/A Property Class XNET Subframe Short Name Frame Description parent frame is defined when the subframe is Returns the I/O name of the parent frame. The ange it afterwards. created, and you cannot ch 4-366 NI-XNET Hardware and Software Manual ni.com

432 Chapter 4 NI-XNET API for LabVIE W—XNET Subframe Property Node Multiplexer Value Data Type Direction Required? Default N/A Read/Write Yes Property Class XNET Subframe Short Name MuxValue Description Multiplexer value for this subframe. This property specifies the multiplexer signal value used when the dynamic signals in this ansmitted at a time in the frame. subframe are transmitted in the frame. Only one subframe is tr operty. It reflects the object as a read-only pr There is also a multiplexer value for a signal value set on the parent subframe object. This property is required. If the property doe s not contain a valid value, and you create an XNET session that uses this subframe, the session re turns an error. To ensu re that the property contains a valid value, you can do one of the following: • Use a database file (or alias) to create the session. The file formats require a valid value in the text for this property. • Set a value in LabVIEW using the property node. This is needed when you create your own in-memory database ( :memory: ) rather than use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session. For more information about using database files and in-memory databases, refer to Databases . 4-367 © National Instruments NI-XNET Hardware and Software Manual

433 Chapter 4 NI-XNET API for LabVIEW—XNET Subframe Property Node Name (Short) Data Type Direction Required? Default Read/Write Yes Defined in Create Object Property Class XNET Subframe Short Name NameShort Description String identifying a subframe object. nd the underscore (_) are valid characters for Lowercase letters, uppercase letters, numbers, a the short name. The space ( ), period (.), and ot her special characters ar e not supported within the name. The short name must begin with a le tter (uppercase or lower case) or underscore, and not a number. The short name is limited to 128 characters. A subframe name must be unique for all subframes in a frame. , such as the database, This short name does not include qualifiers to en sure that it is unique cluster, and frame name. It is for display purpo ses. The fully qualified name is available by using the XNET Subframe I/O name as a string. You can write this property to change the su bframe’s short name. When you do this and then result because the old use the original XNET Subframe that contains the old name, errors can name cannot be found. Follow these steps to avoid this problem: 1. Get the old Name (Short) property using the property node. Set the new Name (Short) property for the object. 2. XNET Database Close.vi . Wire the 3. Close the object using input as false to close all? close the renamed object only. String Function.vi 4. Wire the XNET Subframe as the input string to Search and Replace Name as the replacement string. This with the old Name as the search string and the new me, while retaining the other text that replaces the short name in the XNET Subfra ensures a unique name. 4-368 NI-XNET Hardware and Software Manual ni.com

434 Chapter 4 NI-XNET API for LabVIE W—XNET Subframe Property Node The following diagram demonstrates steps 1 through 4 for an XNET Frame I/O name: © National Instruments 4-369 NI-XNET Hardware and Software Manual

435 Chapter 4 NI-XNET API for LabVIEW—XNET Subframe Property Node PDU Data Type Direction Required? Default N/A Read Only N/A Property Class XNET Subrame Short Name PDU Description I/O name of the subframe’s parent PDU. me’s parent PDU. The parent PDU is defined This property returns the I/O name of the subfra when the subframe object is created . You cannot change it afterwards. 4-370 NI-XNET Hardware and Software Manual ni.com

436 Chapter 4 W—XNET Signal Property Node NI-XNET API for LabVIE XNET Signal Property Node Format Description . XNET Signal I/O Name Property node used to read/write properties for an to change direction between read and write. Pull down this node to add properties. Right-click Right-click each property name to creat e a constant, control, or indicator. For help on a specific property, open the LabVIEW context help window () and move your cursor over the property name. For more information about LabVIEW property nodes, open the main LabVIEW help (select topic in Property Nodes menu) and look for the Search the LabVIEW Help from the Help the index. 4-371 © National Instruments NI-XNET Hardware and Software Manual

437 Chapter 4 NI-XNET API for LabV IEW—XNET Signal Property Node Byte Order Direction Data Type Required? Default Read/Write Yes N/A Property Class XNET Signal Short Name ByteOrdr Description Signal byte order in the frame payload. This property defines how signal bytes are ordered in the frame payload when the frame is loaded in memory. • Little Endian : Higher significant si gnal bits are placed on higher byte addresses. In NI-CAN, this was called Intel Byte Order. Figure 4-8. Little Endian Signal with Start Bit 12 4-372 NI-XNET Hardware and Software Manual ni.com

438 Chapter 4 NI-XNET API for LabVIE W—XNET Signal Property Node placed on lower byte addresses. In : Higher significant signal bits are • Big Endian NI-CAN, this was called Motorola Byte Order. Figure 4-9. Big Endian Signal with Start Bit 12 This property is required. If the property doe s not contain a valid value, and you create an XNET session that uses this signal, the session re turns an error. To ensure that the property contains a valid value, you can do one of the following: • Use a database file (or alias) to create the session. The file formats require a valid value in the text for this property. • Set a value in LabVIEW using the property node. This is needed when you create your own in-memory database ( :memory: ) rather than use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session. For more information about using database files and in-memory databases, refer to Databases . 4-373 © National Instruments NI-XNET Hardware and Software Manual

439 Chapter 4 IEW—XNET Signal Property Node NI-XNET API for LabV Comment Data Type Direction Required? Default No Read/Write Empty String Property Class XNET Signal Short Name Comment Description Comment describing the signal object. A comment is a string containing up to 65535 characters. ni.com 4-374 NI-XNET Hardware and Software Manual

440 Chapter 4 W—XNET Signal Property Node NI-XNET API for LabVIE Configuration Status Data Type Direction Required? Default No N/A Read Only Property Class XNET Signal Short Name ConfigStatus Description The signal object configuration status. Configuration Status returns an NI-XN ET error code. You can pass the value to Simple Error Handler.vi error code input to convert the value to a text description (on message output) of the configuration problem. By default, incorrectly configur ed signals in the database ar e not returned from the XNET Signals Frame in the bus communication. You can property because they cannot be used change this behavior by setting the XNET Database ShowInvalidFromOpen? property to true. When a signal configuration stat us becomes invalid after the database is opened, the signal still is returned from the XNET Frame Signals property even if the XNET Database property is false. ShowInvalidFromOpen? Examples of invalid signal configuration: • The signal is specified using bits outside the frame payload. The signal overlaps another signal in the fr • ame. For example, tw o multiplexed signals with the same multiplexer value are using the same bit in the frame payload. The signal with integer data type (signed or unsigned) is specified with more than 52 bits. • This is not allowed due to internal limitation of the double data type that NI-XNET uses for signal values. The frame containing the signal is invalid (for example, a CAN frame is defined with • more than 8 payload bytes). 4-375 © National Instruments NI-XNET Hardware and Software Manual

441 Chapter 4 IEW—XNET Signal Property Node NI-XNET API for LabV Data Type Data Type Direction Required? Default Read/Write Yes N/A Property Class XNET Signal Short Name DataType Description The signal data type. This property determines how the bits of a sign al in a frame must be interpreted to build a value. • Signed : Signed integer with positive and negative values. Unsigned • : Unsigned integer with no negative values. • : Float value with 7 or 15 significant decimal digits (32 bit or 64 bit). IEEE Float This property is required. If the property doe s not contain a valid value, and you create an XNET session that uses this sign al, the session returns an error. To ensure that the property contains a valid value, you can do one of the following: • Use a database file (or alias) to create the session. The file formats require a valid value in the text for this property. • Set a value in LabVIEW using the property node. This is needed when you create your own in-memory database ( :memory: ) rather than use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session. For more information about using database files and in-memory databases, refer to Databases . 4-376 NI-XNET Hardware and Software Manual ni.com

442 Chapter 4 NI-XNET API for LabVIE W—XNET Signal Property Node Default Value Direction Data Type Required? Default Read/Write No 0.0 (If Not in Database) Property Class XNET Signal Short Name Default Description The signal default value, specified as scaled floating-point units. The data type is 64-bit floating point (DBL). The initial value of this property comes from the database. If the database does not provide a value, this property uses a default value of 0.0. For all three signal output sessions, this property is used when a frame transmits prior to a call Default Payload property is used as the initial payload, . The XNET Frame to XNET Write.vi this property, and the then the default value of each signal is mapped into that payload using result is used for the frame transmit. XNET For all three signal input sessions, this pr operty is returned for each signal when Read.vi is called prior to receiving the first frame. is used, refer to the discussion of Read/Write For more information about when this property for each session mode. 4-377 © National Instruments NI-XNET Hardware and Software Manual

443 Chapter 4 NI-XNET API for LabV IEW—XNET Signal Property Node Mux:Dynamic? Direction Data Type Required? Default Read Only No False Property Class XNET Signal Short Name Mux.Dynamic? Description Use this property to determine if a signal is st atic or dynamic. Dynamic signals are transmitted in the frame when the multiplexer signal in the frame has a given value specified in the subframe. Use the Multiplexer Value property to determine with which multiplexer value the dynamic signal is transmitted. This property is read only. To create a dynamic signal, create the signal object as a child of a The dynamic signal cannot be changed to a static signal subframe instead of a frame. afterwards. In NI-CAN, dynamic signals were called mode-dependent signals. 4-378 NI-XNET Hardware and Software Manual ni.com

444 Chapter 4 NI-XNET API for LabVIE W—XNET Signal Property Node Frame Direction Required? Default Data Type Read Only N/A Parent Frame Property Class XNET Signal Short Name Frame Description I/O name of the signal’s parent frame. This property returns the I/O name of the signal’s parent frame. The parent frame is defined is created. You cannot change it afterwards. when the signal object Maximum Value Data Type Direction Required? Default Read/Write No 1000.0 Property Class XNET Signal Short Name Max Description The scaled signal value maximum. do not limit the signal value to a maximum value. Use XNET Read.vi and XNET Write.vi this database property to set the maximum value. In LabVIEW, you can use this property to set th e limits of front panel controls and indicators. 4-379 © National Instruments NI-XNET Hardware and Software Manual

445 Chapter 4 NI-XNET API for LabV IEW—XNET Signal Property Node Minimum Value Data Type Direction Required? Default 0.0 Read/Write No Property Class XNET Signal Short Name Min Description The scaled signal value minimum. do not limit the signal value to a minimum value. Use XNET Read.vi and XNET Write.vi this database property to set the minimum value. e limits of front panel controls and indicators. In LabVIEW, you can use this property to set th Mux:Multiplexer Value Data Type Direction Required? Default Read Only N/A N/A Property Class XNET Signal Short Name Mux.MuxValue Description The multiplexer value applies to dynamic signals only (the XNET Signal Mux:Dynamic? property returns true). This property defines which multiplexer value is transmitted in the multiplexer signal when this dynamic signal is transmitted in the frame. that are children of The multiplexer value is determined in the sub frame. All dynamic signals the same subframe object use the same multiplexer value. Dynamic signals with the same multiplexer valu e may not overlap each other, the multiplexer signal, or static signals. 4-380 NI-XNET Hardware and Software Manual ni.com

446 Chapter 4 NI-XNET API for LabVIE W—XNET Signal Property Node Mux:Data Multiplexer? Direction Data Type Required? Default Read/Write No False Property Class XNET Signal Short Name Mux.Muxer? Description This property defines the signal that is a multi plexer signal. A frame containing a multiplexer value is called a multiplexed frame. A multiplexer defines an area within the frame to contain different information (dynamic signals) depending on the multiplexer signal value. Dynamic signals with a different multiplexer value (defined in a different subframe) can shar e bits in the frame payload. The multiplexer signal value determines which dynamic signals are transmitted in the given frame. To define dynamic signals in the frame transmitted with a given multiplexer value, you first must create a subframe in this frame and set the multiplexer value in the subframe. Then you must create dynamic signals using to create XNET Database Create (Dynamic Signal).vi child signals of this subframe. Multiplexer signals may not overlap other static or dynamic signals in the frame. Dynamic signals may overlap other dynamic signa ls when they have a different multiplexer value. one multiplexer signal. A frame may contain only The multiplexer signal is not scaled. Scaling factor and offset do not apply. gnal was called mode channel. In NI-CAN, the multiplexer si 4-381 © National Instruments NI-XNET Hardware and Software Manual

447 Chapter 4 IEW—XNET Signal Property Node NI-XNET API for LabV Name (Short) Data Type Direction Required? Default Yes Defined in Create Object Read/Write Property Class XNET Signal Short Name NameShort Description String identifying a signal object. Lowercase letters, uppercase letters, numbers, a nd the underscore (_) are valid characters for the short name. The space ( ), period (.), and ot her special characters ar e not supported within the name. The short name must begin with a le tter (uppercase or lower case) or underscore, and not a number. The short name is limited to 128 characters. A signal name must be unique for all signals in a frame. , such as the database, sure that it is unique This short name does not include qualifiers to en ses. The fully qualified name is available by cluster, and frame name. It is for display purpo using the XNET Signal I/O name as a string. You can write this property to change the signal’s short name. When you do this and then use ntains the old name, errors can the original XNET Signal that co result because the old name cannot be found. Follow these steps to avoid this problem: 1. Get the old Name (Short) property using the property node. Set the new Name (Short) property for the object. 2. Close the object using XNET Database Close.vi 3. input as false to close all? . Wire the close the renamed object only. 4. Wire the XNET Signal as the input string to Search and Replace String Function.vi as the replacement string. This Name with the old Name as the search string and the new ile retaining the other text that ensures a replaces the short name in the XNET Signal, wh unique name. 4-382 NI-XNET Hardware and Software Manual ni.com

448 Chapter 4 NI-XNET API for LabVIE W—XNET Signal Property Node The following diagram demonstrates steps 1 through 4 for an XNET Frame I/O name: © National Instruments 4-383 NI-XNET Hardware and Software Manual

449 Chapter 4 NI-XNET API for LabV IEW—XNET Signal Property Node Number of Bits Data Type Direction Required? Default N/A Read/Write Yes Property Class XNET Signal Short Name NumBits Description The number of bits the signal uses in the frame payload. IEEE Float numbers are limited to 32 bit or 64 bit. mited to 1–52 bits. NI-XNET converts all Integer (signed and unsigned) numbers are li integers to doubles (64-bit IEEE Float). Integer numbers with more than 52 bits (the size of converted exactly to double, and vice versa; the mantissa in a 64-bit IEEE Float) cannot be therefore, NI-XNET does not support this. s not contain a valid value, and you create an This property is required. If the property doe XNET session that uses this sign al, the session returns an error. To ensure that the property contains a valid value, you can do one of the following: • Use a database file (or alias) to create the session. The file formats require a valid value in the text for this property. • Set a value in LabVIEW using the property node. This is needed when you create your own in-memory database ( :memory: ) rather than use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session. For more information about using database files and in-memory databases, refer to Databases . 4-384 NI-XNET Hardware and Software Manual ni.com

450 Chapter 4 W—XNET Signal Property Node NI-XNET API for LabVIE PDU Required? Default Data Type Direction N/A Read Only N/A Property Class XNET Signal Short Name PDU Description I/O name of the signal’s parent PDU. This property returns the I/O name of the signal’s parent PDU. The parent PDU is defined ange it afterwards. is created. You cannot ch when the signal object 4-385 © National Instruments NI-XNET Hardware and Software Manual

451 Chapter 4 NI-XNET API for LabV IEW—XNET Signal Property Node Scaling Factor Data Type Direction Required? Default Read/Write No 1.0 Property Class XNET Signal Short Name ScaleFac Description Factor a for linear scaling ax+b . Linear scaling is applied to all signals with the IEEE Float data type, unsigned and signed. g routines do not perform the +0.0, NI-XNET optimized scalin x For identical scaling 1.0 multiplication and addition. Scaling Offset Data Type Direction Required? Default Read/Write No 0.0 Property Class XNET Signal Short Name ScaleOff Description for linear scaling Offset b ax+b . Linear scaling is applied to all signals with the IEEE Float data type, unsigned and signed. +0.0, NI-XNET optimized scalin g routines do not perform the For identical scaling 1.0 x multiplication and addition. 4-386 NI-XNET Hardware and Software Manual ni.com

452 Chapter 4 NI-XNET API for LabVIE W—XNET Signal Property Node Start Bit Direction Required? Default Data Type Read/Write Yes N/A Property Class XNET Signal Short Name StartBit Description position in the frame payload. The least significant signal bit This property determines the signal starting point in the frame. For the integer data type (signed and unsigned), it means the binary signal representation least significant bit position. For IEEE Float signals, it means the mantissa least significant bit. the frame. It enumerates The NI-XNET Database Editor shows a graphical overview of the frame bytes on the left and mber in the frame is calculated the byte bits on top. The bit nu as byte number  8 + bit number. The maximum bit nu mber in a CAN or LIN frame is 63 (7 × 8 + 7); the maximum bit number in a FlexRay frame is 2031 (253 × 8 + 7). Figure 4-10. Editor with a Signal Starting in Bit 12 Frame Overview in the NI-XNET Database 4-387 © National Instruments NI-XNET Hardware and Software Manual

453 Chapter 4 IEW—XNET Signal Property Node NI-XNET API for LabV This property is required. If the property doe s not contain a valid value, and you create an XNET session that uses this sign al, the session returns an error. To ensure that the property can do one of the following: contains a valid value, you • Use a database file (or alias) to create the session. The file formats require a valid value in the text for this property. • Set a value in LabVIEW using the property node. your own in-memory database ( This is needed when you create :memory: ) rather than use a file. The property does not contain a default in this case, so you must set a valid value prior to creating a session. For more information about using database files and in-memory databases, refer to Databases . 4-388 NI-XNET Hardware and Software Manual ni.com

454 Chapter 4 NI-XNET API for LabVIE W—XNET Signal Property Node Mux:Subframe Direction Data Type Required? Default Read Only N/A Parent Subframe Property Class XNET Signal Short Name Mux.Subfrm Description I/O name of the subframe parent. This property is valid only for dynamic signals that have a subframe parent. For static signals or the multiplexer signal, this I/O name is empty. Unit Data Type Direction Required? Default Read/Write No Empty String Property Class XNET Signal Short Name Unit Description This property describes the signal value unit. NI-XNET does not use the unit internally for the unit on the front calculations. You can use the string to display th e signal value along with panel. 4-389 © National Instruments NI-XNET Hardware and Software Manual

455 Chapter 4 bVIEW—XNET Signal Constant NI-XNET API for La XNET Signal Constant This constant provides the constant form of the XNET Signal I/O name. You drag a constant to the block diagram of your VI, then select a signal. You can change constants only during XNET Signal I/O For a complete description, refer to configuration, prior to running the VI. Name . XNET Database Open.vi Purpose Opens an object from a database file. Description This VI is not required for LabVIEW 2009 or newer. It is provided only for backward compatibility of VIs written in LabVIEW versions prior to 2009. Newer versions of e as a refnum and open it automatically. LabVIEW can detect the I/O name’s first us In addition to opening the refnum automatically, LabVIEW also closes it automatically. 4-390 NI-XNET Hardware and Software Manual ni.com

456 Chapter 4 NI-XNET API for La bVIEW—XNET Database Close.vi XNET Database Close.vi Purpose Closes an object from a database, or all database objects. Description The instances of this polymorphic VI specify which objects to close: • XNET Database Close (Cluster).vi XNET Database Close (Database).vi • • XNET Database Close (ECU).vi • XNET Database Close (Frame).vi • XNET Database Close (PDU).vi • XNET Database Close (Signal).vi • XNET Database Close (Subframe).vi XNET Database Close (LIN Schedule).vi • • XNET Database Close (LIN Schedule Entry).vi 4-391 © National Instruments NI-XNET Hardware and Software Manual

457 Chapter 4 NI-XNET API for LabVIEW—XNET Database Close.vi XNET Database Close (Cluster).vi Purpose Closes a cluster from a database, or all database objects. Format Inputs cluster in is the cluster to close. close all? indicates that all open database ob jects will be closed. This is the default. is the error cluster input (refer to ). Error Handling error in Outputs error out is the error cluster output (refer to Error Handling ). Description (or all database objects). It is an instance of This VI closes a cluster object from a database the poly VI. XNET Database Close To simplify the task of closing all database objects you opened, use the close all? parameter set to true (default); otherwise, only the single database object wired in is closed. matically when the top-level VI terminates, so using this VI Database objects are closed auto is optional. However, you may want to close database objects to free their memory prior to starting a session. You can use this VI to do this. 4-392 NI-XNET Hardware and Software Manual ni.com

458 Chapter 4 NI-XNET API for La bVIEW—XNET Database Close.vi XNET Database Cl ose (Database).vi Purpose Closes an XNET database, or all database objects. Format Inputs database in is the database to close. close all? indicates that all open database ob jects will be closed. This is the default. error in is the error cluster input (refer to Error Handling ). Outputs Error Handling is the error cluster output (refer to error out ). Description This VI closes an XNET database (or all da tabase objects). It is an instance of the XNET poly VI. Database Close close all? To simplify the task of closing all database objects you opened, you can use the parameter set to true (default); otherwise, only the single database object wired in is closed. Note Even if the database has been closed (using close all? set to false), all database objects retrieved from this database must be closed separately. Database objects are closed auto matically when the top-level VI terminates, so using this VI is optional. However, you may want to close database objects to free their memory prior to starting a session. You can use this VI to do this. 4-393 © National Instruments NI-XNET Hardware and Software Manual

459 Chapter 4 NI-XNET API for LabVIEW—XNET Database Close.vi XNET Database Close (ECU).vi Purpose Closes an ECU from a database, or all database objects. Format Inputs ECU in is the ECU to close. close all? indicates that all open database ob jects will be closed. This is the default. is the error cluster input (refer to ). Error Handling error in Outputs error out is the error cluster output (refer to Error Handling ). Description This VI closes an ECU object from a database (or all database objects). It is an instance of the XNET Database Close poly VI. To simplify the task of closing all database objects you opened, you can use the close all? parameter set to true (default); otherwise, only the single database object wired in is closed. matically when the top-level VI terminates, so using this VI Database objects are closed auto is optional. However, you may want to close database objects to free their memory prior to starting a session. You can use this VI to do this. 4-394 NI-XNET Hardware and Software Manual ni.com

460 Chapter 4 NI-XNET API for La bVIEW—XNET Database Close.vi XNET Database Close (Frame).vi Purpose Closes a frame from a databa se, or all database objects. Format Inputs frame in is the frame to close. close all? indicates that all open database ob jects will be closed. This is the default. ). Error Handling is the error cluster input (refer to error in Outputs error out is the error cluster output (refer to Error Handling ). Description This VI closes a frame object from a database (or all database objects). It is an instance of the XNET Database Close poly VI. To simplify the task of closing all database objects you opened, you can use the close all? parameter set to true (default); otherwise, only the single database object wired in is closed. matically when the top-level VI terminates, so using this VI Database objects are closed auto is optional. However, you may want to close database objects to free their memory prior to starting a session. You can use this VI to do this. 4-395 © National Instruments NI-XNET Hardware and Software Manual

461 Chapter 4 NI-XNET API for LabVIEW—XNET Database Close.vi XNET Database Close (PDU).vi Purpose Closes a PDU from a database, or all database objects. Format Inputs PDU in is the PDU to close. close all? indicates that all open database ob jects will be closed. This is the default. is the error cluster input (refer to ). Error Handling error in Outputs error out is the error cluster output (refer to Error Handling ). Description This VI closes a PDU object from a database (or all database objects). It is an instance of the XNET Database Close poly VI. To simplify the task of closing all database objects you opened, you can use the close all? parameter set to true (default); otherwise, only the single database object wired in is closed. matically when the top-level VI terminates, so using this VI Database objects are closed auto is optional. However, you may want to close database objects to free their memory prior to starting a session. You can use this VI to do this. 4-396 NI-XNET Hardware and Software Manual ni.com

462 Chapter 4 NI-XNET API for La bVIEW—XNET Database Close.vi XNET Database Close (Signal).vi Purpose Closes a signal from a database, or all database objects. Format Inputs signal in is the signal to close. close all? indicates that all open database ob jects will be closed. This is the default. error in ). Error Handling is the error cluster input (refer to Outputs error out is the error cluster output (refer to Error Handling ). Description This VI closes a signal object from a database (o r all database objects). It is an instance of the XNET Database Close poly VI. To simplify the task of closing all database objects you opened, you can use the close all? parameter set to true (default); otherwise, only the single database object wired in is closed. matically when the top-level VI terminates, so using this VI Database objects are closed auto is optional. However, you may want to close database objects to free their memory prior to starting a session. You can use this VI to do this. 4-397 © National Instruments NI-XNET Hardware and Software Manual

463 Chapter 4 NI-XNET API for LabVIEW—XNET Database Close.vi XNET Database Close (Subframe).vi Purpose Closes a subframe from a database, or all database objects. Format Inputs subframe in is the subframe to close. close all? indicates that all open database ob jects will be closed. This is the default. Error Handling ). error in is the error cluster input (refer to Outputs error out is the error cluster output (refer to Error Handling ). Description objects). It is an instance of This VI closes a subframe object from a database (or all database the poly VI. XNET Database Close To simplify the task of closing all database objects you opened, you can use the close all? parameter set to true (default); otherwise, only the single database object wired in is closed. matically when the top-level VI terminates, so using this VI Database objects are closed auto is optional. However, you may want to close database objects to free their memory prior to starting a session. You can use this VI to do this. 4-398 NI-XNET Hardware and Software Manual ni.com

464 Chapter 4 NI-XNET API for La bVIEW—XNET Database Close.vi XNET Database Clos e (LIN Schedule).vi Purpose Closes a LIN schedule object from a database, or all database objects. Format Inputs LIN schedule in is the schedule to close. close all? indicates that all open database ob jects will be closed. This is the default. ). Error Handling is the error cluster input (refer to error in Outputs error out is the error cluster output (refer to Error Handling ). Description This VI closes a LIN schedule object from a databa se (or all database objects). It is an instance of the XNET Database Close poly VI. To simplify the task of closing all database objects you opened, you can use the close all? parameter set to true (default); otherwise, only the single database object wired in is closed. matically when the top-level VI terminates, so using this VI Database objects are closed auto is optional. However, you may want to close database objects to free their memory prior to starting a session. You can use this VI to do this. 4-399 © National Instruments NI-XNET Hardware and Software Manual

465 Chapter 4 NI-XNET API for LabVIEW—XNET Database Close.vi XNET Database Close (L IN Schedule Entry).vi Purpose Closes a LIN schedule entry from a database, or all database objects. Format Inputs LIN schedule entry in is the schedule entry to close. close all? indicates that all open database ob jects will be closed. This is the default. ). Error Handling is the error cluster input (refer to error in Outputs error out is the error cluster output (refer to Error Handling ). Description a database (or all database objects). It is an This VI closes a LIN schedule entry object from instance of the poly VI. XNET Database Close To simplify the task of closing all database objects you opened, you can use the close all? parameter set to true (default); otherwise, only the single database object wired in is closed. matically when the top-level VI terminates, so using this VI Database objects are closed auto is optional. However, you may want to close database objects to free their memory prior to starting a session. You can use this VI to do this. 4-400 NI-XNET Hardware and Software Manual ni.com

466 Chapter 4 NI-XNET API for LabVIEW— XNET Database Create Object.vi XNET Database Create Object.vi Purpose Creates a new database object. Description The instances of this polymorphic VI specify which database objects to create: • XNET Database Create (Cluster).vi XNET Database Create (Dynamic Signal).vi • • XNET Database Create (ECU).vi • XNET Database Create (Frame).vi • XNET Database Create (PDU).vi • XNET Database Create (Signal).vi • XNET Database Create (Subframe).vi XNET Database Create (LIN Schedule).vi • • XNET Database Create (LIN Schedule Entry).vi 4-401 © National Instruments NI-XNET Hardware and Software Manual

467 Chapter 4 NI-XNET API for LabVIEW—XNET Database Create Object.vi XNET Database Cr eate (Cluster).vi Purpose Creates a new XNET cluster. Format Inputs database in is the parent database object. database in can be an existing for file. You can create a new database in memory by specifying :memory: database in of objects in memory, without and create an entire hierarchy using a file on the disk. cluster name is the name of the cluster to create. The name must be unique for all clusters in a database. Lower case letters, uppercase letters, numbers, and the underscore (_) are valid ch aracters for the name. The space ( ), period (.), and other special characters are not supported within the name. or underscore, The name must begin with a letter (uppe rcase or lowercase) limited to 128 characters. and not a number. The name is error in ). Error Handling is the error cluster input (refer to Outputs is a copy of the database in parameter. You can use this database out output to wire the VI to subsequent VIs. cluster out is I/O name of the newl y created cluster object. is the error cluster output (refer to Error Handling error out ). Description r object. It is an instance of XNET Database Create This VI creates an XNET cluste Object.vi . eated object. This is cluster name input becomes the Name (Short) property of the cr The cluster out distinct from the string contained within , which uses the syntax described in XNET Cluster I/O Name . 4-402 NI-XNET Hardware and Software Manual ni.com

468 Chapter 4 XNET Database Create Object.vi NI-XNET API for LabVIEW— The cluster object is created and remains in memo ry until the database is closed. This VI does save the newly created object to the file, use not change the open database file on disk. To XNET Database Save.vi . 4-403 National Instruments © NI-XNET Hardware and Software Manual

469 Chapter 4 NI-XNET API for LabVIEW—XNET Database Create Object.vi (Dynamic Signal).vi XNET Database Create Purpose Creates a new XNET dynamic signal. Format Inputs subframe in is the subframe parent object. signal name is the name of the signal to create. The name must be unique for all signals in a frame in which the subframe parent was defined, including the static signals and the mu ltiplexer signal. Lowercase letters, uppercase letters, numbers, and the underscore (_) are valid characters for the name. The space ( ), period (.), and other special characters are not supported within the name. The name must begin with a letter (uppercase or lowercase) or underscore, and not a number. The name is limited to 128 characters. Error Handling is the error cluster input (refer to ). error in Outputs is a copy of the subframe in parameter. You can use this subframe out parameter to wire the VI to subsequent VIs. signal out is the I/O name of the ne wly created signal object. is the error cluster output (refer to Error Handling ). error out Description This VI creates an XNET dynamic si gnal object. It is an instance of XNET Database Create Object.vi . The signal name input becomes the Name (Short) property of the created object. This is , which uses the syntax described in distinct from the string contained within signal out XNET Signal I/O Name . 4-404 NI-XNET Hardware and Software Manual ni.com

470 Chapter 4 XNET Database Create Object.vi NI-XNET API for LabVIEW— remains in memory until the database is closed. This VI does The signal object is created and not change the open database file on disk. To save the newly created object to the file, use XNET Database Save.vi . e when the multiplexer signal contains the Dynamic Signal is transmitted in the fram multiplexer value defined in the subframe. In NI-CAN, dynamic signals were called mode-dependent channels. NI-XNET Hardware and Software Manual © National Instruments 4-405

471 Chapter 4 NI-XNET API for LabVIEW—XNET Database Create Object.vi Create (ECU).vi XNET Database Purpose Creates a new XNET ECU. Format Inputs cluster in is the cluster parent object. ECU name is the name of the ECU to create. The name must be unique for all ECUs in a cluster. Lowercase lette rs, uppercase letters, numbers, and the underscore (_) are valid characters for the name. The space ( ), period (.), and other special character s are not supported within the name. The name must begin with a letter (uppercase or lowercase) or underscore, and not a number. The name is lim ited to 128 characters. error in is the error cluster input (refer to Error Handling ). Outputs is a copy of the parameter. You can use this output to cluster in cluster out wire the VI to subsequent VIs. is the I/O name of the newly created ECU object. ECU out error out is the error cluster output (refer to Error Handling ). Description This VI creates an XNET ECU object. It is an instance of XNET Database Create Object.vi . The ECU name rty of the created object. This is input becomes the Name (Short) prope XNET ng contained within ECU out , which uses the syntax described in distinct from the stri ECU I/O Name . The ECU object is created and remains in memory until the database is closed. This VI does save the newly created object to the file, use not change the open database file on disk. To . XNET Database Save.vi 4-406 NI-XNET Hardware and Software Manual ni.com

472 Chapter 4 XNET Database Create Object.vi NI-XNET API for LabVIEW— XNET Database Create (Frame).vi Purpose Creates a new XNET frame. Format Inputs cluster in is the cluster parent object. frame name is the name of the frame to create. The name must be unique for all frames in a cluster. Lowercase letters, uppercase letters, numbers, and the underscore (_) are valid ch aracters for the name. The space ( ), period (.), and other special characters are not supported within the name. The name must begin with a letter (uppe rcase or lowercase) or underscore, and not a number. The name is limited to 128 characters. error in is the error cluster input (refer to Error Handling ). Outputs cluster out parameter. You can use this output to cluster in is a copy of the wire the VI to subsequent VIs. frame out is the I/O name of the newly created frame object. Error Handling error out is the error cluster output (refer to ). Description XNET Database Create This VI creates an XNET fram e object. It is an instance of Object.vi . The frame name input becomes the Name (Short) prope rty of the created object. This is frame out distinct from the string contained within , which uses the syntax described in XNET Frame I/O Name . ry until the database is closed. This VI does The frame object is created and remains in memo not change the open database file on disk. To save the newly created object to the file, use . XNET Database Save.vi 4-407 © National Instruments NI-XNET Hardware and Software Manual

473 Chapter 4 NI-XNET API for LabVIEW—XNET Database Create Object.vi Create (PDU).vi XNET Database Purpose Creates a new XNET PDU. Format Inputs cluster in is the cluster parent object. PDU name is the name of the PDU to create. The name must be unique for all PDUs in a cluster. Lowercase lette rs, uppercase letters, numbers, and the underscore (_) are valid characters for the name. The space ( ), period (.), and other special character s are not supported within the name. The name must begin with a letter (uppercase or lowercase) or underscore, and not a number. The name is lim ited to 128 characters. error in is the error cluster input (refer to Error Handling ). Outputs is a copy of the parameter. You can use this output to cluster in cluster out wire the VI to subsequent VIs. PDU out is the reference to the newly created PDU object. is the error cluster output (refer to Error Handling ). error out Description This VI creates an XNET PDU object. It is an instance of XNET Database Create Object.vi . The PDU name input becomes the Name (Short) property of the cr eated object. This is distinct from the string contained within PDU out , which uses the syntax described in XNET PDU I/O Name . The PDU object is created and remains in memory until the database is closed. This VI does not change the open database file on disk. To save the new created object to the file, use XNET Database Save.vi . 4-408 NI-XNET Hardware and Software Manual ni.com

474 Chapter 4 XNET Database Create Object.vi NI-XNET API for LabVIEW— XNET Database Create (Signal).vi Purpose Creates a new XNET signal. Format Inputs frame in is the frame parent object. signal name is the name of the signal to create. Lowercase letters, uppercase letters, numbers, and the underscore (_) are valid characters for the name. The space ( ), period (.), and other special characters are not supported within the name. The name must begin with a letter (uppercase or lowercase) or underscore, and not a number. The name is limited to 128 characters. error in is the error cluster input (refer to Error Handling ). Outputs parameter. You can use this parameter frame in is a copy of the frame out to wire the VI to subsequent VIs. is the I/O name of the newly created signal object. signal out error out is the error cluster output (refer to Error Handling ). Description This VI creates an XNET signa l object. It is an instance of XNET Database Create . Object.vi The property of the created object. This is Name (Short) signal name input becomes the distinct from the string contained within signal out , which uses the syntax described in XNET Session I/O Name . The signal object is created and remains in memory until the database is closed. This VI does not change the open database file on disk. To save the newly created object to the file, use XNET Database Save.vi . 4-409 © National Instruments NI-XNET Hardware and Software Manual

475 Chapter 4 NI-XNET API for LabVIEW—XNET Database Create Object.vi XNET Database Create (Subframe).vi Purpose Creates a new XNET subframe. Format Inputs frame in is the frame parent object. subframe name is the name of the subframe to create. The name must be unique for all subframes in a frame. Lo wercase letters, uppercase letters, numbers, and the underscore (_) are valid characters for the name. The space ( ), period (.), and other special characters are not supported within the name. The name must begin with a letter (uppercase or lowercase) or underscore, and not a number. The na me is limited to 128 characters. ). Error Handling is the error cluster input (refer to error in Outputs is a copy of the frame in para meter. You can use this parameter frame out to wire the VI to subsequent VIs. subframe out is the I/O name of the newly created subframe object. error out is the error cluster output (refer to Error Handling ). Description This VI creates an XNET subframe object. It is an instance of XNET Database Create Object.vi . The subframe name input becomes the Name (Short) property of the created object. The subframe object is created and remains in memory until the database is closed. This VI does not change the open database file on disk. To save the newly created object to the file, use . XNET Database Save.vi 4-410 NI-XNET Hardware and Software Manual ni.com

476 Chapter 4 XNET Database Create Object.vi NI-XNET API for LabVIEW— A subframe defines the multiplexer value for all dynamic signals in this subframe. Dynamic signals within a subframe inherit the multiplexer value from the subframe parent. In NI-CAN, a subframe was called a mode. NI-XNET Hardware and Software Manual National Instruments © 4-411

477 Chapter 4 NI-XNET API for LabVIEW—XNET Database Create Object.vi (LIN Schedule).vi XNET Database Create Purpose Creates a new XNET LIN schedule. Format Inputs is the cluster parent object. cluster in LIN schedule name is the name of the schedule to create. The name must be unique for all schedules in a cluster. Lowercase letters, uppercase letters, numbers, and the underscore (_) are valid characters for the name. The space ( ), period (.), and other special supported within characters are not the name. The name must begin with a letter (uppercase or lowercase) or underscore, and not a number. The na me is limited to 128 characters. error in is the error cluster input (refer to Error Handling ). Outputs is a copy of the parameter. You can use this output to cluster in cluster out wire the VI to subsequent VIs. is the I/O name of the newly created LIN schedule LIN schedule out object. error out is the error cluster output (refer to Error Handling ). Description This VI creates an XNET LIN schedul e object. It is an instance of XNET Database Create Object.vi . The input becomes the Name (Short) property of the created object. This LIN schedule name is distinct from the string contained within LIN schedule out , which uses the syntax described in XNET LIN Schedule I/O Name . The schedule object is created and remains in me mory until the database is closed. This VI does not change the open database file on disk. To save the newly created object to the file, XNET Database Save.vi . use 4-412 NI-XNET Hardware and Software Manual ni.com

478 Chapter 4 NI-XNET API for LabVIEW— XNET Database Create Object.vi XNET Database Create (LIN Schedule Entry).vi Purpose Creates a new XNET LIN schedule entry object. Format Inputs LIN schedule in is the schedule parent object. LIN schedule entry name is the name of the schedule entry to create. The name must be unique for all entries in a schedule. Lowercase letters, are valid characters for uppercase letters, numbers, and the underscore (_) and other special characters are not the name. The space ( ), period (.), supported within the name. The name must begin with a letter (uppercase or lowercase) or underscore, and not a number. The name is limited to 128 characters. is the error cluster input (refer to Error Handling ). error in Outputs LIN schedule out is a copy of the LIN schedule in parameter. You can use this parameter to wire the VI to subsequent VIs. LIN schedule entry out is the I/O name of the newly created LIN schedule entry object. ). error out is the error cluster output (refer to Error Handling Description This VI creates an XNET schedule entry object. It is an instance of XNET Database Create Object.vi . Schedule entries is an ordered array in a schedule. The schedule is being processed in the order of this array. A newly created entry alwa ys is added to the last position of the array. 4-413 © National Instruments NI-XNET Hardware and Software Manual

479 Chapter 4 NI-XNET API for LabVIEW—XNET Database Create Object.vi The LIN schedule entry name input becomes the Name (Sho rt) property of the created LIN schedule entry out object. This is distinct from the string contained in , which uses the syntax described in XNET LIN Schedule Entry I/O Name . The schedule object is created and remains in me mory until the database is closed. This VI does not change the open database file on disk. To save the newly created object to the file, use XNET Database Save.vi . 4-414 NI-XNET Hardware and Software Manual ni.com

480 Chapter 4 NI-XNET API for LabVIEW—XNET Database Delete Object.vi XNET Database Delete Object.vi Purpose Deletes a database object. Description The instances of this polymorphic VI specify which database objects to delete: XNET Database Delete (Cluster).vi • • XNET Database Delete (ECU).vi • XNET Database Delete (Frame).vi • XNET Database Delete (PDU).vi • XNET Database Delete (Signal).vi • XNET Database Delete (Subframe).vi XNET Database Delete (LIN Schedule).vi • • XNET Database Delete (LIN Schedule Entry).vi 4-415 © National Instruments NI-XNET Hardware and Software Manual

481 Chapter 4 NI-XNET API for LabVIEW— XNET Database Delete Object.vi lete (Cluster).vi XNET Database De Purpose Deletes an XNET cluster and all child objects in this cluster. Format Inputs cluster in is the I/O name of the cluster to delete. error in is the error cluster input (refer to Error Handling ). Outputs Error Handling is the error cluster output (refer to error out ). Description This VI deletes an XNET cluster object with all frames, PDUs, signals, subframes, and ECUs . in this cluster. It is an instance of XNET Database Delete Object.vi Upon deletion, the I/O names of all deleted ob jects are closed and no longer can be used. The objects are deleted from a database in memory . The change is in force until the database is closed. This VI does not change the open database file on disk. To save the changed database to the file, use . XNET Database Save.vi 4-416 NI-XNET Hardware and Software Manual ni.com

482 Chapter 4 NI-XNET API for LabVIEW—XNET Database Delete Object.vi XNET Database Delete (ECU).vi Purpose Deletes an XNET ECU. Format Inputs ECU in is the I/O name of the ECU to delete. ). Error Handling is the error cluster input (refer to error in Outputs error out is the error cluster output (refer to Error Handling ). Description This VI deletes an XNET ECU . object. It is an instance of XNET Database Delete Object.vi Upon deletion, the I/O name of the ECU is closed and no longer can be used. The ECU object is deleted from a database in memory and is in force until the database is closed. This VI does not change the open database file on disk. To save the changed database . XNET Database Save.vi to the file, use 4-417 © National Instruments NI-XNET Hardware and Software Manual

483 Chapter 4 NI-XNET API for LabVIEW— XNET Database Delete Object.vi XNET Database Delete (Frame).vi Purpose Deletes an XNET frame and all child objects in the frame. Format Inputs frame in is the I/O name of the frame to delete. error in is the error cluster input (refer to Error Handling ). Outputs Error Handling is the error cluster output (refer to ). error out Description This VI deletes an XNET frame object wi th all mapped PDUs, including signals and subframes in those PDUs. It is an instance of XNET Database Delete Object.vi . To avoid unmap the PDUs from the frame deleting PDUs with the frame, before deleting the frame (set the XNET Frame PDU_Mapping property to an empty array). Upon deletion, the I/O names of all deleted ob jects are closed and no longer can be used. The objects are deleted from a database in memory . The change is in force until the database is closed. This VI does not change the open database file on disk. To save the changed XNET Database Save.vi . database to the file, use 4-418 NI-XNET Hardware and Software Manual ni.com

484 Chapter 4 NI-XNET API for LabVIEW—XNET Database Delete Object.vi XNET Database Delete (PDU).vi Purpose Delete an XNET PDU and all child objects in this PDU. Format Inputs PDU in references the PDU to delete. ). Error Handling is the error cluster input (refer to error in Outputs error out is the error cluster output (refer to Error Handling ). Description This VI deletes an XNET PDU object with all signals and subframes in this PDU. It is an instance of XNET Database Delete Object.vi . Upon deletion, the I/O names to all deleted objects are closed and no longer can be used. The objects are deleted from a database in memory. The change is in force until the database is closed. This VI does not change the open database file on disk. To save the changed . XNET Database Save.vi database to the file, use 4-419 © National Instruments NI-XNET Hardware and Software Manual

485 Chapter 4 NI-XNET API for LabVIEW— XNET Database Delete Object.vi lete (Signal).vi XNET Database De Purpose Deletes an XNET signal. Format Inputs signal in is the I/O name of the signal to delete. Error Handling ). error in is the error cluster input (refer to Outputs is the error cluster output (refer to Error Handling ). error out Description object. It is an instance of This VI deletes an XNET signal XNET Database Delete Object.vi . Upon deletion, the I/O name of the signal is closed and no lo nger can be used. The signal object is deleted from a database in memory and is in force until the database is closed. This VI does not change the open database file on disk. To save the changed database . to the file, use XNET Database Save.vi 4-420 NI-XNET Hardware and Software Manual ni.com

486 Chapter 4 NI-XNET API for LabVIEW—XNET Database Delete Object.vi XNET Database Delete (Subframe).vi Purpose Deletes an XNET subframe and all dynamic signals in the subframe. Format Inputs subframe in is the I/O name of the subframe to delete. error in is the error cluster input (refer to Error Handling ). Outputs ). Error Handling is the error cluster output (refer to error out Description This VI deletes an XNET subframe object and all dynamic signals in this subframe. It is an XNET Database Delete Object.vi instance of . Upon deletion, the I/O names of the subframe and related dynamic signals are closed and no longer can be used. The objects are deleted from a database in memory. The change is in force until the database is closed. This VI does not change the open database file on disk. To save the changed XNET Database Save.vi database to the file, use . 4-421 © National Instruments NI-XNET Hardware and Software Manual

487 Chapter 4 NI-XNET API for LabVIEW— XNET Database Delete Object.vi XNET Database Delete (LIN Schedule).vi Purpose Deletes an XNET LIN schedule and all LIN sc hedule entry objects in this schedule. Format Inputs LIN schedule in is the I/O name of the LIN schedule to delete. Error Handling ). error in is the error cluster input (refer to Outputs is the error cluster output (refer to Error Handling ). error out Description the entries it contains. This VI deletes an XNET LIN schedule object and It is an instance of XNET Database Delete Object.vi . Upon deletion, the I/O names of all deleted ob jects are closed, and you no longer can use them. The LIN schedule object is deleted from a database in memory and is in force until the database is closed. This VI does not change the open database file on disk. To save the . changed database to the file, use XNET Database Save.vi 4-422 NI-XNET Hardware and Software Manual ni.com

488 Chapter 4 NI-XNET API for LabVIEW—XNET Database Delete Object.vi XNET Database Delete (LIN Schedule Entry).vi Purpose Deletes an XNET schedule entry object. Format Inputs LIN schedule entry in is the I/O name of the LIN schedule entry to delete. ). Error Handling is the error cluster input (refer to error in Outputs is the error cluster output (refer to Error Handling ). error out Description This VI deletes an XNET LIN schedule entry object. It is an instance of XNET Database Delete Object.vi . Upon deletion, the I/O name of the deleted object is closed, and you no longer can use it. The objects are deleted from a database in memory. The change is in force until the database is closed. This VI does not change the open database file on disk. To save the changed XNET Database Save.vi database to the file, use . 4-423 © National Instruments NI-XNET Hardware and Software Manual

489 Chapter 4 NI-XNET API for LabVIEW—XNET Database Merge.vi XNET Database Merge.vi Purpose Merges database objects and related child objects from the source to the destination cluster. Description The instances of this polymorphic VI specify which database objects to merge: • XNET Database Merge (Frame).vi • XNET Database Merge (PDU).vi • XNET Database Merge (ECU).vi XNET Database Merge (LIN Schedule).vi • • XNET Database Merge (Cluster).vi 4-424 NI-XNET Hardware and Software Manual ni.com

490 Chapter 4 NI-XNET API for LabV IEW—XNET Database Merge.vi XNET Database Merge (Frame).vi Purpose all child objects into the destination cluster. Merges a frame object with Format Inputs wait for complete? Use this input only if the source object is a cluster XNET Database Merge (Cluster).vi (refer to ). target cluster in is the I/O name of the cluster where the source frame is merged. is the I/O name of the frame to be merged into the target source frame cluster. defines the merging behavior if the target cluster already copy mode contains a frame with the same name. prefix is added to the source frame name if a frame with the same name exists in the target cluster. error in is the error cluster input (refer to Error Handling ). Outputs percent complete is used when wait for complete? is false. (This output does not apply to th e frame instance.) target cluster out is a copy of target cluster in . You can use this output to wire the VI to subsequent VIs. is the error cluster output (refer to ). error out Error Handling 4-425 © National Instruments NI-XNET Hardware and Software Manual

491 Chapter 4 NI-XNET API for LabVIEW—XNET Database Merge.vi Description This VI merges a frame with al l dependent child objects (PDUs, subframes, and signals) to the target cluster. If the source frame name was not used in the ta rget cluster, this VI copies the source frame . If a frame with the same name with the child objects to the target exists in the target cluster, you can avoid name collisions by specifying the prefix to be added to the name. If a frame with the same name exists in the ta rget cluster, the merge behavior depends on the copy mode input: • Copy using source : The target frame with all depe ndent child objects is removed from the target cluster and replaced by the source objects. Copy using destination : The source frame is ignored (the target cluster frame with child • objects remains unchanged). • Merge using source : This adds child objects from the source frame to ch ild objects from the destination frame. If the target frame contains a child object with the same name, it is replaced by the child object from the sour ame properties (for ce frame. The source fr example, payload length) replace the target frame properties. • Merge using destination : This adds child objects from th e source frame to child objects from the destination frame. If the target fr ame contains a child ob ject with the same name, it remains unchanged. The target frame properties remain unchanged (for example, payload length). Example Target frame F1(v1) has signals S1 and S2(v 1). Source frame F1(v2) has signals S2(v2) and S3. (v1) and (v2) are two versions of one object with same name, but with different properties. • Result of Copy using source : F1(v2), S2(v2), S3. • Result of Copy using destination : F1(v1), S1, S2(v1). • Result of Merge using source : F1(v2), S1, S2(v2), S3. Result of Merge using destination : F1(v1), S1, S2(v1), S3. • 4-426 NI-XNET Hardware and Software Manual ni.com

492 Chapter 4 NI-XNET API for LabV IEW—XNET Database Merge.vi XNET Database Merge (PDU).vi Purpose objects into the destination cluster. Merges a PDU object with all child Format Inputs wait for complete? Use this input only if the source object is a cluster (refer to XNET Database Merge (Cluster).vi ). is the I/O name of the cluster where the source PDU is target cluster in merged. is the I/O name of the PDU to be merged into the target cluster. source PDU copy mode defines the merging behavior if the target cluster already contains a PDU with the same name. prefix is added to the source PDU name if a PDU with the same name exists in the target cluster. error in is the error cluster input (refer to Error Handling ). Outputs percent complete is used when wait for complete? is false. (This output does not apply to the PDU instance.) target cluster out is a copy of target cluster in . You can use this output to wire the VI to subsequent VIs. Error Handling is the error cluster output (refer to error out ). 4-427 © National Instruments NI-XNET Hardware and Software Manual

493 Chapter 4 NI-XNET API for LabVIEW—XNET Database Merge.vi Description This VI merges a PDU with all dependent child objects (subframes and signals) to the target cluster. cluster, this VI copi es the source PDU with If the source PDU name was not used in the target the child objects to the target. If a PDU with the same name exists in the target cluster, you can avoid name collisions by specifying the prefix to be added to the name. If a PDU with the same name exists in the target cluster, the merge behavior depends on the copy mode input: • Copy using source : The target PDU with all dependent child objects is removed from the target cluster and replaced by the source objects. • Copy using destination : The source PDU is ignored (the target cluster PDU with child objects remains unchanged). • Merge using source : This adds child objects from th e source PDU to child objects from the destination PDU. If the target PDU contains a child object with the same name, it is replaced by the child object from the sour U properties (for ce PDU. The source PD ace the target PDU properties. example, payload length) repl Merge using destination : This adds child objects from the source PDU to child objects • from the destination PDU. If the target PDU contains a child object with the same name, it remains unchanged. The target PDU prop erties remain unchanged (for example, payload length). Example Target PDU Pdu1(v1) has signals S1 and S2( v1). Source PDU Pdu1(v2) has signals S2(v2) and S3. (v1) and (v2) are two versions of one object with same name but with different properties. • Copy using source : Pdu1(v2), S2(v2), S3. Result of • Result of Copy using destination : Pdu1(v1), S1, S2(v1). • Result of Merge using source : Pdu1(v2), S1, S2(v2), S3. : Pdu1(v1), S1, S2(v1), S3. Result of Merge using destination • 4-428 NI-XNET Hardware and Software Manual ni.com

494 Chapter 4 NI-XNET API for LabV IEW—XNET Database Merge.vi XNET Database Merge (ECU).vi Purpose Merges an ECU object with Tx/Rx frames into the destination cluster. Format Inputs wait for complete? Use this input only if the source object is a cluster XNET Database Merge (Cluster).vi (refer to ). target cluster in is the I/O name of the cluster where the source ECU is merged. is the I/O name of the ECU to be merged into the target source ECU cluster. copy mode defines the merging behavior if the target cluster already contains an ECU with the same name. prefix is added to the source ECU name if an ECU with the same name exists in the target cluster. error in is the error cluster input (refer to Error Handling ). Outputs percent complete is used when wait for complete? is false. (This output does not apply to the ECU instance.) target cluster out is a copy of target cluster in . You can use this output to wire the VI to subsequent VIs. Error Handling is the error cluster output (refer to error out ). 4-429 © National Instruments NI-XNET Hardware and Software Manual

495 Chapter 4 NI-XNET API for LabVIEW—XNET Database Merge.vi Description This VI merges an ECU with al l Tx/Rx frames to the target cl uster. It does not merge the frames itself, but only the tran formation. This happe ns based on frame smitting or receiving in names. If the source cluster defines new frames not contained in the destination cluster, they should be merged before merging the ECU; otherwise, the Tx/Rx information is removed. If the source ECU name was not used in the targ et cluster, this VI c opies the source ECU to the target. If an ECU with the same name exis ts in the target cluster, you can avoid name collisions by specifying the prefix to be added to the name. If an ECU with the same name exists in the target cluster, the merge behavior depends on the copy mode input: • Copy using source : The target ECU with all Tx/Rx information is removed from the target cluster and replaced by the source objects. • Copy using destination : The source ECU is ignored (the target cluster ECU with child objects remains unchanged). : This adds Tx/Rx frames from the source ECU to Tx/Rx from the Merge using source • destination ECU. The source EC comment) replace the target U properties (for example, ECU properties. • Merge using destination : This adds Tx/Rx frames from the source ECU to Tx/Rx from the destination ECU. The target ECU properties remain unchanged (for example, comment). Example Target ECU Ecu1(v1) has Tx frames F1 and F2. Source ECU Ecu1(v2) has Tx frames F2 and F3. (v1) and (v2) are two versions of one object with same name but with different properties. • Copy using source : Ecu1(v2), F2, F3. Result of • Result of Copy using destination : Ecu1(v1), F1, F2. • Result of Merge using source : Ecu1(v2), F1, F2, F3. Merge using destination Result of : Ecu1(v1), F1, F2, F3. • 4-430 NI-XNET Hardware and Software Manual ni.com

496 Chapter 4 NI-XNET API for LabV IEW—XNET Database Merge.vi XNET Database Mer ge (LIN Schedule).vi Purpose Merges a LIN schedule object with all ch ild objects into the destination cluster. Format Inputs Use this input only if the source object is a cluster wait for complete? (refer to XNET Database Merge (Cluster).vi ). is the I/O name of the cluster where the source LIN target cluster in schedule is merged. source LIN schedule is the I/O name of the LIN schedule to be merged into the target cluster. defines the merging behavior if the target cluster already copy mode contains a LIN schedule with the same name. prefix is added to the source LIN schedule name if a LIN schedule with the same name exists in the target cluster. ). error in is the error cluster input (refer to Error Handling Outputs percent complete is used when wait for complete? is false. (This output does not apply to the LIN schedule instance.) target cluster out is a copy of target cluster in . You can use this output to wire the VI to subsequent VIs. ). error out Error Handling is the error cluster output (refer to 4-431 © National Instruments NI-XNET Hardware and Software Manual

497 Chapter 4 NI-XNET API for LabVIEW—XNET Database Merge.vi Description This VI merges a LIN schedule with all schedule entries to the target cluster. Frames referenced in the schedule entries should be merged before merging the LIN schedule; otherwise, the reference get lost. the target cluster, this If the source LIN schedule name was not used in VI copies the source LIN schedule with the entries to the target. If a LIN schedule with the same name exists in the target cluster, you can avoid name collisions by specifying the prefix to be added to the name. If a LIN schedule with the same name exists in the target cluster, the merge behavior depends copy mode on the input: • : The target LIN schedule with entries is removed from the target Copy using source cluster and replaced by the source objects. • Copy using destination : The source LIN schedule is ignored (the target cluster schedule with entries remains unchanged). • Merge using source : This adds schedule entries from the source schedule at the end of tries become new names, so all entry names the destination schedule table. The copied en dule properties replace the target schedule in the schedule are unique. The source sche properties (comment, priority, run mode). Merge using destination : This adds schedule entries from the source schedule at the end • of the destination schedule table. The copi ed entries become new names, so all entry names in the schedule are unique. The target schedule properties (comment, priority, run mode) remain unchanged. Example Target LIN schedule LS1(v1) has entries e1, e2. Source LIN schedule LS1(v2) has entries e3, e4. (v1) and (v2) are two versions of one object with same name but with different properties. • Copy using source : LS1(v1), e1, e2. Result of • Result of Copy using destination : LS1(v2), e3, e4. • Result of Merge using source : LS1(v2),e1, e2, e3, e4. Merge using destination Result of : LS1(v1), e1, e2, e3, e4. • 4-432 NI-XNET Hardware and Software Manual ni.com

498 Chapter 4 NI-XNET API for LabV IEW—XNET Database Merge.vi XNET Database Me rge (Cluster).vi Purpose d objects into the destination cluster. Merges a source cluster with all chil Format Inputs wait for complete? Use this input to split the merging process into parts (for example, to display a progress bar). target cluster in is the I/O name of the clus ter where the source cluster is merged. is the I/O name of the cluster to be merged into the target source cluster cluster. copy mode defines the merging behavior if the target cluster already contains elements with the same name. prefix is added to the source cluster name if an element with the same name exists in the target cluster. error in is the error cluster input (refer to Error Handling ). Outputs percent complete is used when wait for complete? is false. target cluster out is a copy of target cluster in . You can use this output to wire the VI to subsequent VIs. ). Error Handling is the error cluster output (refer to error out 4-433 © National Instruments NI-XNET Hardware and Software Manual

499 Chapter 4 NI-XNET API for LabVIEW—XNET Database Merge.vi Description This VI merges all objects contained in the source cluster into the target cluster. The following VIs merge the object s with dependent-child objects: • XNET Database Merge (Frame).vi • XNET Database Merge (PDU).vi • XNET Database Merge (ECU).vi • XNET Database Merge (LIN Schedule).vi Copy mode and prefix are passed to the appropriate VI for the merging process. or , all cluster properties Merge using source If the copy mode is set to Copy using source the source to the target cluster. including the name are copied from Depending on the number of contained objects in the source and destination clusters, the execution can take longer. If wait for complete? is true, this VI waits until the merging returns process gets completed. If the execution completes without errors, percent complete 100. If wait for complete? is false, the function returns quickly and percent complete returns values less than 100. You must call XNET Database Merge.vi repeatedly until percent complete returns 100. You can use the time between calls to update a progress bar. 4-434 NI-XNET Hardware and Software Manual ni.com

500 Chapter 4 NI-XNET API for La bVIEW—XNET Database Save.vi XNET Database Save.vi Purpose Saves the open database to a FIBEX 3.1.1 file. Format Inputs database in is the I/O name of the database. filepath contains the pathname to the FIBEX file or is empty (saves to the original filepath). is the error cluster input (refer to Error Handling ). error in Outputs database out is a copy of the database in parameter. You can use this parameter to wire the VI to subsequent VIs. ). Error Handling is the error cluster output (refer to error out Description This VI saves the XNET database current state to a FIBEX 3.1.1 file. The file extension must be .xml . If the target file exists, it is overwritten. XNET saves to the FIBEX file only features that XNET sessions us e to communicate on the network. If the original file was created us ing non-XNET software, the target file may be missing details from the original file. For exam ple, NI-XNET supports only linear scaling. If the original FIBEX file used a rational equation that cannot be expressed as a linear scaling, XNET converts this to a linear scalin g with factor 1.0 and offset 0.0. If filepath is empty, the file is saved to the same FIBEX file specified when opened. If opened as a file path, it uses that file path. If opened as an alias, it uses the file path registered for that alias. Saving a database is not supported in LabVIEW Real-Time, but you can deploy and use a database saved on Windows in ). XNET Database Deploy.vi LabVIEW Real-Time (refer to 4-435 © National Instruments NI-XNET Hardware and Software Manual

501 Chapter 4 W—File Management Subpalette NI-XNET API for LabVIE File Management Subpalette This subpalette includes VIs to manage database aliases and deploy or undeploy a database file to LabVIEW Real-Time (RT). XNET Database Add Alias.vi Purpose Adds a new alias to a database file. Format Inputs default baud rate provides the default baud rate, used when filepath refers to a CANdb database ( .dbc ) or an NI-CAN database ( .ncd ). These database formats are specific to CAN a nd do not specify a cluster baud rate. Use this default baud rate to specify a default CAN baud rate to use with this alias. If refers to a FIBEX database ( filepath ) or LIN LDF file, .xml the default baud rate parameter is ignored. The FIBEX and LDF database formats require a valid baud rate for ev ery cluster, and NI-XNET uses that baud rate as the default. provides the desired alias name. Unlike the name of other XNET alias use special characters such as space database objects, the alias name can and dash. If the alias name already exists, this VI changes the previous filepath to the specified filepath. filepath provides the path to the CANdb, FIBEX, or LDF file. error in is the error cluster input (refer to Error Handling ). Outputs Error Handling ). is the error cluster output (refer to error out 4-436 NI-XNET Hardware and Software Manual ni.com

502 Chapter 4 W—File Management Subpalette NI-XNET API for LabVIE Description NI-XNET uses alias names for database files. The alias names provide a shorter name for display, allow for changes to the file system pplication, and enable without changing the a efficient deployment to LabVIEW Real-Time (RT) targets. This VI is supported on Windows only. For LabVIEW RT, you can pass the new alias to image of the database to the to transfer an optimized binary XNET Database Deploy.vi LabVIEW RT target. After deploying the database, you can use the alias name in any VI for the Windows host and the LabVIEW RT target. 4-437 © National Instruments NI-XNET Hardware and Software Manual

503 Chapter 4 W—File Management Subpalette NI-XNET API for LabVIE XNET Database Remove Alias.vi Purpose Removes a database alias from the system. Format Inputs alias is the name of the alias to delete. Error Handling is the error cluster input (refer to ). error in Outputs ). error out is the error cluster output (refer to Error Handling Description This VI removes the alias from NI-XNET, but does not affect the database text file. It just removes the alias association to the database filepath. This VI is supported on Windows only, and the alias is removed from Windows only (not to remove an alias from a XNET Database Undeploy.vi LabVIEW RT targets). Use LabVIEW Real-Time (RT) target. 4-438 NI-XNET Hardware and Software Manual ni.com

504 Chapter 4 NI-XNET API for LabVIE W—File Management Subpalette XNET Database Get List.vi Purpose Gets the current list of databases on a system. Format Inputs IP address is the target IP address. If IP address is unwired (empty), this VI retrieves aliases and file paths for the local Windows system. is a valid IP address, this VI retrieves aliases and file paths If IP address for the remote LabVIEW RT target. Y ou can find this IP address using MAX or VIs in the LabVIEW Real-Time palettes. is the error cluster input (refer to Error Handling ). error in Outputs array of alias returns an array of strings, on e for every alias registered in the system. If no aliases are re gistered, the array is empty. array of filepath returns an array of strings th at contain the file paths and filenames of the databases assigned to the aliases, one for every alias registered in the system. If no aliases are registered, the array is empty. This parameter applies to Windows targets only; on RT targets, this array always is empty. ). Error Handling is the error cluster output (refer to error out 4-439 © National Instruments NI-XNET Hardware and Software Manual

505 Chapter 4 W—File Management Subpalette NI-XNET API for LabVIE Description For a local Windows call (IP address empty), array of filepath returns an array of file paths. array of alias The size of this array is the same as . It provides the Windows file path for each corresponding alias. is empty. NI-XNET handles the file For a remote call to LabVIEW RT, array of filepath system on the LabVIEW RT target automati cally, so that only the alias is needed. bVIEW RT database deployments are managed This VI is supported on Windows only. La remotely from Windows. 4-440 NI-XNET Hardware and Software Manual ni.com

506 Chapter 4 NI-XNET API for LabVIE W—File Management Subpalette XNET Database Deploy.vi Purpose Deploys a database to a remote LabVIEW Real-Time (RT) target. Format Inputs IP address is the target IP address. alias provides the database alias name. To deploy a database text file, XNET Database Add Alias.vi first add an alias using . wait for complete? determines whether the VI returns directly or waits until the entire transmission is completed. Error Handling ). is the error cluster input (refer to error in Outputs percent complete indicates the deployment progress. error out is the error cluster output (refer to Error Handling ). Description This VI transfers an optimized binary image of the database to the LabVIEW RT target. After deploying the database, you can use the alias name in any VI for the Windows host and the LabVIEW RT target. This VI is supported on Windows only. La bVIEW RT database deployments are managed remotely from Windows. This VI must access the remote LabVIEW RT target from Windows, so IP address must specify a valid IP address for the LabVIEW RT target. You can find this IP address using MAX or VIs in the LabVIEW Real-Time palettes. owing syntax for the If the LabVIEW RT target access is password protected, use the foll [user:[email protected]]IPaddress IP address to deploy an alias: . 4-441 © National Instruments NI-XNET Hardware and Software Manual

507 Chapter 4 NI-XNET API for LabVIE W—File Management Subpalette Remote file transfer can take a few seconds, especially when the RT target is far away. If wait for complete? is true, this VI waits for the entire transfer to complete, then returns. error out reflects the deployment status, and percent complete is 100. is false, this VI transfers a portion of the database and returns before it wait for complete? If error out returns success, and percent complete is is complete. For an incomplete transfer, percent complete less than 100. You can use to display transfer prog ress on your front panel. You must call XNET Database Deploy.vi in a loop until percent complete is returned as error out reflects the entire deployment status. 100, at which time 4-442 NI-XNET Hardware and Software Manual ni.com

508 Chapter 4 NI-XNET API for LabVIE W—File Management Subpalette XNET Database Undeploy.vi Purpose Undeploys a database from a remote LabVIEW Real-Time (RT) target. Format Inputs IP address is the target IP address. alias provides the database alias name. is the error cluster input (refer to Error Handling ). error in Outputs error out Error Handling ). is the error cluster output (refer to Description This VI completely deletes the database file and its alias from the LabVIEW RT target. This VI is supported on Windows only. La bVIEW RT database deployments are managed remotely from Windows. This VI must access the remote LabVIEW RT target from Windows, so IP address must specify a valid IP address for the LabVIEW RT target. You can find this IP address using MAX or VIs in the LabVIEW Real-Time palettes. If the LabVIEW RT target access is password protected, you can use the following syntax for . [user:[email protected]]IPaddress the IP address to deploy an alias: 4-443 © National Instruments NI-XNET Hardware and Software Manual

509 Chapter 4 NI-XNET API for LabVIE W—XNET LIN Schedule Property Node XNET LIN Schedule Property Node Format Description Property node used to read/write properties for an XNET LIN Schedule I/O Name . Pull down this node to add properties. Right-click to change direction between read and write. Right-click each property name to creat e a constant, control, or indicator. For help on a specific property, open the LabVIEW context help window () and move your cursor over the property name. For more information about LabVIEW property nodes, open the main LabVIEW help (select Property Nodes menu) and look for the from the Search the LabVIEW Help topic in Help the index. Cluster Data Type Direction Required? Default Read Only N/A N/A Property Class XNET LIN Schedule Short Name Cluster Description This property returns the I/O name to the parent cluster in which the schedule has been created. You cannot change the parent clus ter after creating the schedule object. 4-444 NI-XNET Hardware and Software Manual ni.com

510 Chapter 4 ET LIN Schedule Property Node NI-XNET API for LabVIEW—XN Comment Direction Data Type Required? Default Read/Write No Empty String Property Class XNET LIN Schedule Short Name Comment Description Comment describing the schedule object. A comment is a string containing up to 65535 characters. 4-445 © National Instruments NI-XNET Hardware and Software Manual

511 Chapter 4 NI-XNET API for LabVIE W—XNET LIN Schedule Property Node Configuration Status Data Type Direction Required? Default Read Only N/A N/A Property Class XNET LIN Schedule Short Name ConfigStatus Description The LIN schedule object configuration status. Configuration Status returns an NI-XNET erro r code. The value can be passed to the error to convert it to a text description (on message output) Simple Error Handler.vi code input of of the configuration problem. By default, the XNET Cluster LIN:Schedules property does not return incorrect configured schedules in the database because you cannot use them in the bus communication. You can change this behavior by setting the XNET Database ShowInvalidFromOpen? property to true. When a schedule’s configuration status becomes invalid after the database is opened, the XNET Cluster LIN:Schedules property still returns the schedule even if ShowInvalidFromOpen? is false. An example of an invalid schedule configurati on is when a required schedule property is not defined (for example, a schedule entry within this schedule has an undefined delay time). 4-446 NI-XNET Hardware and Software Manual ni.com

512 Chapter 4 ET LIN Schedule Property Node NI-XNET API for LabVIEW—XN Entries Required? Default Data Type Direction N/A Read Only N/A Property Class XNET LIN Schedule Short Name Entries Description Array of entries for this LIN schedule. Each entry’s position in this array specifies the position in the schedule. The database file ies at runtime determine the position. and/or the order that you create entr 4-447 © National Instruments NI-XNET Hardware and Software Manual

513 Chapter 4 W—XNET LIN Schedule Property Node NI-XNET API for LabVIE Name (Short) Data Type Direction Required? Default Read/Write Yes Defined in Create Object Property Class XNET LIN Schedule Short Name NameShort Description String identifying the XNET LIN schedule object. nd the underscore (_) are valid characters for Lowercase letters, uppercase letters, numbers, a the short name. The space ( ), period (.), and ot her special characters ar e not supported within case) or underscore, the name. The short name must begin with a le tter (uppercase or lower and not a number. The short name is limited to 128 characters. A schedule name must be unique for all schedules in a cluster. You can write this property to change the schedules’s short name. When you do this and then ns the old name, errors can result because the use the original XNET LIN schedule that contai old name cannot be found. Follow these steps to avoid this problem: 1. Get the old Name (Short) property using the property node. Set the new Name (Short) property for the object. 2. 3. Search and Replace String Wire the XNET LIN schedule as the input string to Function.vi with the old Name as the search string and the new Name as the replace string. This replaces the short name in the XNET LIN schedule, while retaining the other text that ensures a unique name. to the 4. Wire the result from Search and Replace String Function.vi XNET String to IO Name.vi . This casts the string back to a valid XNET LIN schedule. 4-448 NI-XNET Hardware and Software Manual ni.com

514 Chapter 4 NI-XNET API for LabVIEW—XN ET LIN Schedule Property Node Priority Data Type Direction Required? Default No Read/Write 42 Property Class XNET LIN Schedule Short Name Priority Description multiple run-once schedules are pending for Priority of this run-once LIN schedule when execution. The valid range for this property is 1–254. Lo wer values correspond to higher priority. This property applies only when the Run Mode property is Once. Run-once schedule requests are queued for execution based on this property. When all run-once schedules have completed, the master returns to the previ ously running continuous schedule (or null). ecent run-continuous Run-continuous schedule requests are not queu ed. Only the most r schedule is used, and it executes only if no run-once schedule is pending. Therefore, a run-continuous schedule has an effective prior ity of 255, but this property is not used. Null schedule requests take effect immedi ately and supercede an y running run-once or run-continuous schedule. The queue of pending run-once schedule requests is flushed (emptied without running them). Therefore, a null schedule has an effective priority of 0, but this property is not used. This property is not read from the database, but is handled like a database property. After opening the database, the default value is returned, and you can change the property. But similar to database properties, you cannot change it after a session is created. 4-449 © National Instruments NI-XNET Hardware and Software Manual

515 Chapter 4 NI-XNET API for LabVIE W—XNET LIN Schedule Property Node Run Mode Data Type Direction Required? Default Read/Write No See Description Property Class XNET LIN Schedule Short Name RunMode Description This property is a ring (enumerated list) with the following values: Va l u e String 0 Continuous 1 Once 2 Null This property specifies how the master runs this schedule: • Continuous : The master runs the schedule continuously. When the last entry executes, the schedule starts again with the first entry. • : The master runs the schedule once (all entries), then returns to the previously Once running continuous schedule (or null). If requests are submitted for multiple run-once , then the master schedules, each run-once executes in succession based on its Priority returns to the continuous schedule (or null). Null : All communication stops immediately. A schedule with this run mode is called a • null schedule. This property is not read from the database, but is handled like a database property. After opening the database, the default value is returned, and you can change the property. But similar to database properties, you cannot change it after a session is created. Usually, the default value for the run mode is Continuous. If the schedule is configured to be triggered entry, the default is Once. a collision resolving table for an event- ni.com 4-450 NI-XNET Hardware and Software Manual

516 Chapter 4 ET LIN Schedule Entry Property Node NI-XNET API for LabVIEW—XN XNET LIN Schedule Entry Property Node Format Description . XNET LIN Schedule Entry I/O Name Property node used to read/write properties for an Pull down this node to add properties. Right-click to change direction between read and write. Right-click each property name to creat e a constant, control, or indicator. For help on a specific property, open the LabVIEW context help window () and move your cursor over the property name. For more information about LabVIEW property nodes, open the main LabVIEW help (select topic in Property Nodes menu) and look for the Search the LabVIEW Help from the Help the index. 4-451 © National Instruments NI-XNET Hardware and Software Manual

517 Chapter 4 NI-XNET API for LabVIEW—XNET LIN Schedule Entry Property Node Collision Resolving Schedule Direction Required? Default Data Type Read/Write No Empty I/O Name Property Class XNET LIN Schedule Entry Short Name CollResSched Description LIN schedule that resolves a collision for this event-triggered entry. This property applies only when the entry Type is event triggered. Wh en a collision occurs for the event-triggered entry in this schedule, the master must switch to the collision resolving schedule to transfer the unconditional frames su ccessfully. If the XNET interface is acting as the master on the LIN cluster, NI-XNET automa tically writes a schedule request for this collision resolving schedule. The collision resolving schedule Run Mode must be Once. ent triggered, this property returns an empty When the entry type is any value other than ev entry (invalid). 4-452 NI-XNET Hardware and Software Manual ni.com

518 Chapter 4 NI-XNET API for LabVIEW—XN ET LIN Schedule Entry Property Node Delay Direction Data Type Required? Default Read/Write Yes N/A Property Class XNET LIN Schedule Entry Short Name Delay Description Time from the start of this entry (slot) to the start of the next entry. The property uses a double value in seconds, with the fractional part used for milliseconds or microseconds. Event Identifier Data Type Direction Required? Default N/A Read/Write Yes Property Class XNET LIN Schedule Entry Short Name EventID Description (NI-XNET handles the The event-triggered entry identifier. This id entifier is unprotected protection). This property applies only when the entry type is event triggered. This identifier is for the ected identifier of the event-triggered entry itself, and the first payloa d byte is for the prot contained unconditional frame. 4-453 © National Instruments NI-XNET Hardware and Software Manual

519 Chapter 4 NI-XNET API for LabVIEW—XNET LIN Schedule Entry Property Node Frames Data Type Direction Required? Default Read/Write No Empty Array Property Class XNET LIN Schedule Entry Short Name Frames Description Array of frames for th is LIN schedule entry. If the entry is unconditional, this array contains one element, which is the single Type unconditional frame for this entry. If the entry Type is sporadic, this array contains one or more frames for this entry. When multiple frames are pending for this entry, the order in the array determines the priority to transmit. If the entry Type is event triggered, this array contains one or more frames for this entry. When multiple frames are pending for this entry, a collision typically occurs on the bus. When the XNET interface is acting as master, and a co llision occurs, the master automatically writes Collision Resolving Schedule . This resolves the collision a schedule request for the automatically so that your application can proceed. 4-454 NI-XNET Hardware and Software Manual ni.com

520 Chapter 4 NI-XNET API for LabVIEW—XN ET LIN Schedule Entry Property Node Name (Short) Data Type Direction Required? Default Defined in Create Object Read/Write Yes Property Class XNET LIN Schedule Entry Short Name NameShort Description String identifying the LIN schedule entry object. Lowercase letters, uppercase letters, numbers, a nd the underscore (_) are valid characters for the short name. The space ( ), pe riod (.), and other sp ecial characters are no t supported within case) or underscore, tter (uppercase or lower the name. The short name must begin with a le is limited to 128 characters. and not a number. The short name A schedule entry name must be unique for all entries in the same schedule. You can write this property to change the schedule entry’s short name. When you do this and then use the original XNET LIN schedule entry that contains the old na me, errors can result because the old name cannot be found. Fo llow these steps to avoid this problem: 1. Get the old Name (Short) property using the property node. 2. Set the new Name (Short) property for the object. Wire the XNET LIN schedule entry as the input string to 3. Search and Replace String as the replace with the old Name as the search string and the new Name Function.vi string. This replaces the short name in the XNET LIN schedule entry, while retaining the other text that ensures a unique name. XNET String to IO 4. Wire the result from Search and Replace String Function.vi to Name.vi a valid XNET LIN schedule entry. . This casts the string back to 4-455 © National Instruments NI-XNET Hardware and Software Manual

521 Chapter 4 NI-XNET API for LabVIEW—XNET LIN Schedule Entry Property Node Node Configuration:Free Format:Data Bytes Data Type Direction Required? Default N/A Read/Write Yes Property Class XNET LIN Schedule Entry Short Name NodeConfFFDataBytes Description An array of 8 bytes containing raw data for LIN node configuration. Node configuration defines a set of services used to configure slave nodes in the cluster. Every service has a specific set of parameters coded in this byte array. In the LDF file, those parameters are stored, for example, in the node (ECU) or the frame object. NI-XNET LDF reader composes those parameters to the byte values like they are sent on the bus. The LIN specification document describes the node conf iguration services an d the mapping of the parameters to the raw format bytes. The node configuration service is executed only if the Schedule Entry Type is set to Node Configuration. Caution This property is not saved to the FIBEX file. If you write this property, save the database, and reopen it, the node configurati on services are not contained in the database. Writing this property is useful only in the NI-XNET session immediately following. 4-456 NI-XNET Hardware and Software Manual ni.com

522 Chapter 4 ET LIN Schedule Entry Property Node NI-XNET API for LabVIEW—XN Schedule Required? Default Data Type Direction N/A Read Only N/A Property Class XNET LIN Schedule Entry Short Name Schedule Description LIN schedule that uses this entry. This LIN schedule is considered this entry’s parent. You define the parent schedule when cannot change it afterwards. creating the entry object. You 4-457 © National Instruments NI-XNET Hardware and Software Manual

523 Chapter 4 NI-XNET API for LabVIEW—XNET LIN Schedule Entry Property Node Type Data Type Required? Default Direction No Unconditional Read/Write Property Class XNET LIN Schedule Entry Short Name Ty p e Description The LIN schedule entry type determines the mech anism used to transfer frames in this entry (slot). The values (enumeration) for this property are: Unconditional : A single frame transfers in this entry (slot). 0 1 Sporadic : The master transmits in this entry (slot). The master selects among multiple frames to transmit. Only upda ted frames are transmitted. Wh en more than one frame has been updated, the master decides by priority which frame to transmit. The other updated frames remain pending and can be sent when this schedule entry executes again. The property (the first frame has the Frames order of frames in the LIN Schedule Entry highest priority) determines the frame priority. Event triggered : Multiple slaves can transmit a fram e in this entry (slot). Each slave 2 transmits when the frame’s data has been u pdated. When a collis ion occurs (multiple slaves try to transmit in the same slot), this is detected and resolved using a different schedule specified in the LIN Schedule Entry Collision Resolving Schedule property. The resolving schedule runs once, starting in th e subsequent slot afte r the collision, and automatically turns back to the previous schedule at the position where the collision occurred. Node configuration : The schedule entry contains a node configuration service. The 3 node configuration service is defined as raw data bytes in the XNET LIN Schedule Entry Node Configuration:Fr ee Format:Data Bytes property. A LIN frame can exist in multiple schedules and multiple schedule entries. For example, if a frame exists in an event-triggered entry in schedule A, it also exists in an unconditional entry of a different schedule B, so that event-triggered collisions in schedule A can be resolved by switching to schedule B. For information about how LIN frame timing compares to the Timing Type property of CAN Cyclic and Event Timing . and FlexRay frames, refer to 4-458 NI-XNET Hardware and Software Manual ni.com

524 Chapter 4 XNET Database Get DBC Attribute.vi NI-XNET API for LabVIEW— XNET Database Ge t DBC Attribute.vi Purpose Reads the attribute value, attrib ute enumeration, defined attributes, or signal value table from a DBC file. Format Inputs is the mode specification of this VI. Depending on this value, the VI mode returns the following data: Mode 0: Get Attribute Value : For a given object (for example, a • signal), the VI returns the attrib ute value assigned to the object. The attribute values always ar e returned as text in attribute text . The DBC specification also allows defining other data types, such as integer or float. If necessary, you can convert the data to a number by using, for palette. If the String example, the Scan From String VI in the n of text strings, the attribute value attribute is defined as an enumeratio e enumeration list, which you can returned here is the index to th retrieve using Mode 1 of the VI. : For a given attribute name, the VI returns • Mode 1: Get Enumeration the enumeration text table as a comma-separated string in attribute text . Because for a given attribute name, the enumeration is the same can point to any object with for all objects of the same type, object in If no enumeration is the given class ( specifies the class). object in defined for an attribute, the VI returns an empty string. : Returns all attribute names • Mode 2: Get Attribute Name List defined for the given object type as a comma-separated string. object in can point to any object in th e database of the given class attribute name is ignored (it specifies the object class). ( object in should be set to empty string). 4-459 © National Instruments NI-XNET Hardware and Software Manual

525 Chapter 4 NI-XNET API for LabVIEW—XNET Database Get DBC Attribute.vi Mode 3: Get Signal Value Table object in • : This is valid only when attribute name points to a signal. is ignored (it should be set to empty string). If the given signal contains a value table, the function returns a comma-separated list in the form [value,string]{,,} . The list contains any number of corresponding value,string pairs. If no value table is defined for the signal, the result is an empty string. is the database object (cluster, frame, signal, or ECU). object in attribute name is the attribute name. error in is the error cluster input (refer to Error Handling ). Outputs object out is a copy of the object in parameter. You can use this output to wire the VI to subsequent VIs. attribute text is the attribute value. used instead of a specific value indicates that a default value is is default? for this object. DBC files define a default value for an attribute with the r particular objects. If the specific given name, and then specific values fo value for an object is not defined, the default value is returned. is default? has no meaning if the mode parameter is not 0 (refer to the mode description above). ). error out is the error cluster output (refer to Error Handling Description Depending on the parameter, this VI reads an attribute value, attribute enumeration, list mode a signal from a DBC file. Refer to the mode input of existing attributes, or value table of description above for details. Attributes are supported for the following object types: • Cluster (DBC file: network attribute) • Frame (DBC file: message attribute) • Signal (DBC file: signal attribute) • ECU (DBC file: node attribute) es. Attributes are not saved to a FIBEX file Databases other than DBC do not support attribut when you open and save a DBC file. 4-460 NI-XNET Hardware and Software Manual ni.com

526 Chapter 4 NI-XNET API for LabVIEW—Notify Subpalette Notify Subpalette This subpalette includes functions for waiting on events from XNET hardware, including creation of a LabVIEW timing source. XNET Wait.vi Purpose Waits for an event to occur. Description The instances of this polymorphic VI specify the event to wait for: XNET Wait (Transmit Complete).vi • • XNET Wait (Interface Communicating).vi XNET Wait (CAN Remote Wakeup).vi • XNET Wait (LIN Remote Wakeup).vi • 4-461 © National Instruments NI-XNET Hardware and Software Manual

527 Chapter 4 NI-XNET API for LabVIEW—XNET Wait.vi XNET Wait (Transmit Complete).vi Purpose Waits for previously written data to be transmitted on the cluster. Format Inputs session in is the session to apply the wait. timeout specifies the maximum amount of time in seconds to wait. error in is the error cluster input (refer to Error Handling ). Outputs session out is the same as session in , provided for use with subsequent VIs. ). Error Handling is the error cluster output (refer to error out Description Waits for all data provided to XNET Write.vi before this XNET Wait.vi call to be transmitted on the CAN, FlexRay, or LIN ne twork. Depending on the bus or configuration Shot Transmit? , the data may or may not have been properties such as Interface:CAN:Single successfully transmitted; however, if this wait re turns successfully, it indicates that the session is making no more attempts to transmit the data. This wait applies to only the current XNET r sessions used for the same interface. session, and not othe After using XNET Write.vi to provide data for this session, you can use this VI to wait for that data to transmit to remote ECUs. You can use this VI to guarantee that all frames have been transmitted before stopping this session. timeout parameter provides the maximum number of seconds to wait. The default value The is 10 (10 seconds). 4-462 NI-XNET Hardware and Software Manual ni.com

528 Chapter 4 NI-XNET API for LabVIEW—XNET Wait.vi XNET Wait (Interface Communicating).vi Purpose Waits for the interface to begi n communication on the cluster. Format Inputs session in is the session to apply the wait. specifies the maximum amount of time in seconds to wait. timeout error in is the error cluster input (refer to Error Handling ). Outputs session out is the same as session in , provided for use with subsequent VIs. is the error cluster output (refer to ). error out Error Handling Description the cluster. After the interface is started, Waits for the interface to begin communication on the controller connects to the cluster and starts communication. This wait returns after communication with the clus ter has been established. e communication may occur within a few Note For some buses (for example, CAN), th microseconds of starting the interface. For other buses, this could be delayed. An example of a bus where the comm unication time is delayed from the start time is FlexRay, where tup routine that may take several cycles to complete. A the interface must perform a star e remaining nodes in the cluster when it is FlexRay interface attempts integration with th started. If the FlexRay interface can coldstart, it sends out startup frames when started and synchronizes its clock with other startup nodes in the cluster. Once the FlexRay interface has successfully integrated, the interface is ready to start tr ansmitting and r eceiving frames. state (refer to the eration Control (POC) Reading the XNET FlexRay interface Protocol Op XNET Read (State FlexRay Comm).vi description), once the interface has successfully integrated, returns Normal-Active. 4-463 © National Instruments NI-XNET Hardware and Software Manual

529 Chapter 4 NI-XNET API for LabVIEW—XNET Wait.vi ace start occurs after the start ed for the interface, the interf If a start trigger is configur Note trigger is received. The timeout parameter provides the maximum number of seconds to wait. The default value is 10 (10 seconds). ni.com 4-464 NI-XNET Hardware and Software Manual

530 Chapter 4 NI-XNET API for LabVIEW—XNET Wait.vi XNET Wait (CAN Remote Wakeup).vi Purpose Waits for the CAN interface to wake up due to activity by a remote ECU on the network. Format Inputs session in is the session to apply the wait. timeout specifies the maximum amount of time in seconds to wait. error in is the error cluster input (refer to Error Handling ). Outputs session out , provided for use with subsequent VIs. session in is the same as error out is the error cluster output (refer to Error Handling ). Description This wait is used when you set the XNET Session Interface:CAN:Transceiver State property to Sleep. When asleep, the interface and transcei ver go into a low-powered mode. If a remote and both the controller ects this transmission, CAN ECU transmits a frame, the transceiver det and transceiver wake up. This wait detects that remote wakeup. Note The interface neither receives nor acknowl edges the transmission that caused the wakeup. However, after the interface wakes up, the transceiver automatically is placed into normal mode, and communication is restored. The parameter provides the maximum number of seconds to wait. This value must timeout be 1.0 (one second) or greater. The default value is 10 (10 seconds). 4-465 © National Instruments NI-XNET Hardware and Software Manual

531 Chapter 4 NI-XNET API for LabVIEW—XNET Wait.vi XNET Wait (LIN Remote Wakeup).vi Purpose Waits for the LIN interface to wake up due to activity by a remote ECU on the network. Format Inputs session in is the session to apply the wait. The wait applies to the LIN interface, so you can use any session. timeout specifies the maximum amount of time in seconds to wait. error in is the error cluster input (refer to Error Handling ). Outputs session in is the same as , provided for use with subsequent VIs. session out error out is the error cluster output (refer to Error Handling ). Description Remote This wait is used when you set the XNET Session Interface:LIN:Sleep property to Sleep ECU transmits the wakeup pattern . When asleep, if a remote LIN or Local Sleep (break), the XNET LIN interface detects this transmi ssion and wakes up. This wait detects that remote wakeup. timeout parameter provides the maximum number of seconds to wait. This value must The be 1.0 (one second) or greater. The default value is 10 (10 seconds). 4-466 NI-XNET Hardware and Software Manual ni.com

532 Chapter 4 NI-XNET API for LabVIEW—XNET Create Timing Source.vi XNET Create Timing Source.vi Purpose Creates a timing source for a LabVIEW Timed Loop. Description specify the timing source to create: The instances of this polymorphic VI • XNET Create Timing Sou rce (FlexRay Cycle).vi XNET Create Timing Sour ce (FlexRay Cycle).vi Purpose Creates a timing source for a LabVIEW Timed Loop. timing source sends a The timing source is based on the FlexRay comm unication cycle. The tick to the Timed Loop at a specific offset in tim e within the FlexRay cycle. The offset within the cycle is specified in FlexRay macroticks. Format Inputs timing source name is the timing source name, returned as timing source out if this VI succeeds. This input is optional. If you leave timing source name unwired (empty), timing source out uses the session name (session in). session in is the session to use for creating the timing source. use a FlexRay interface, because the You must configure the session to timing source is based on that inte rface’s communication cycle. You can create only one FlexRay cycle ti ming source for each interface. XNET LabVIEW project or returned from This session is selected from the . Create Session.vi 4-467 © National Instruments NI-XNET Hardware and Software Manual

533 Chapter 4 IEW—XNET Create Timing Source.vi NI-XNET API for LabV is the offset within each Fl exRay cycle that you want the macrotick offset timing source to tick. (0), which specifies a tick at the start of every The minimum value is zero FlexRay cycle. The value cannot be equal to or greater than the number of macroticks in the cycle, which you can read from the XNET Cluster the property. session uses, from the FlexRay:Macro Per Cycle selecting a value, refer to Macrotick For further recommendations about Offset . is the error cluster input (refer to error in Error Handling ). Outputs , provided for use with subsequent VIs. session out is the same as session in timing source out is the timing source name. You wire this name to the Source Name of the input node outside the Timed Loop. Using the For more information about the Timed Loop nodes, refer to . Timed Loop status true in If this VI returns an error ( ), timing source out is error out empty, which indicates to the Timed Loop that no valid timing source exists. error out is the error cluster output (refer to Error Handling ). Description Use this VI to synchronize your LabVIEW Real-Time application to the deterministic FlexRay cycle. Because the FlexRay cycle repeats every few milliseconds, real-time execution is required, and therefore this VI is not supported on Windows. You can create only one Flex Ray Cycle timing source for each FlexRay interface. You can wire a single timing source to multiple Timed Loops. The following sections include more detailed information about using this VI: • Using the Timed Loop • Session Start and Stop • Macrotick Offset 4-468 NI-XNET Hardware and Software Manual ni.com

534 Chapter 4 NI-XNET API for LabVIEW—XNET Create Timing Source.vi Using the Timed Loop This section includes guidelines for usi ng the LabVIEW Timed Loop with the NI-XNET FlexRay Cycle timing source. For complete information, refer to the LabVIEW help topics for the Timed Loop. The Timed Loop contains the nodes described below. 1 4 3 2 a t a Right D 3 t Node u 1Inp Node a 2 Left D u Node a t 4O u tp t Node Figure 4-11. Timed Loop Nodes Input Node Source Name : Wire the timing source name output of this VI to this terminal on the Timed Loop input node. This specifies the XNET timing source and overrides the default built-in timing source (1 kHz). Period : For most applications, you wire the constant 1 to this terminal, which overrides the specifies the number of timing so Period default of 1000. The urce ticks that must occur for the loop to iterate. A value of 1 iterates the Time d Loop on every FlexRay cycle. Higher values skip FlexRay cycles (for example, 2 itera tes the loop every other FlexRay cycle). : For most applications, you wire the constant 300 to this terminal, which overrides Timeout of milliseconds to wait for a specifies the maximum number Timeout the default of –1. The tick. For this FlexRay cycle timing source, this timeout primarily applies to the first loop iteration. According to the FlexRay specification, the process of fully synchronizing the NI-XNET Hardware and Software Manual 4-469 National Instruments ©

535 Chapter 4 IEW—XNET Create Timing Source.vi NI-XNET API for LabV 200 ms. This network clock synchronization is distributed network clocks can take as long as e first FlexRay cycle and send a tick to the required for the NI-XNET interface to detect th Timed Loop. If network communication problems o ccur (for example, noise on the cable), the first tick does not occur. Using a value of 300 for this terminal ensures that if problems occur Wake-Up Reason on the FlexRay network, the Timed Loop can recover (refer to Left Data in Node ). Error : Use this terminal to propagate errors through the Timed Loop. The Timed Loop does not execute if this terminal receives an error condition. You typically wire the error out from this to this terminal. This avoids the need XNET Create Timing Source (FlexRay Cycle).vi for alternate error propagation tech niques, such as a shift register. Left Data Node Error : Propagates errors through the structure. Wire this terminal to error in of the first VI within the subdiagram. Wake-Up Reason : If the first Timed Loop iteration encounters a Timeout due to problems on the FlexRay network, this terminal returns a value of 5 ( ). When the timeout Timeout occurs, the Timed Loop does not return an error condition from . The timeout causes Error the iteration to execute untimed, th en try again on the next iterat ion. If the FlexRay tick occurs as expected, Wake-Up Reason returns a value of 0 (Normal). Right Data Node Error : Propagates errors from the subdiagram out of the Timed Loop. If Error receives an error condition, the Timed Loop finishes executing the current iteration untimed, exits the loop, and returns the error condition on the Output Node. If you want the Timed Loop to exit on error, wire error out from the last VI in the subdiagram to this terminal. Output Node Error : Propagates errors the Timed Loop receive s and returns errors from the subdiagram. Session Start and Stop When the Timed Loop input node executes, the XNET session for the timing source is started automatically. This auto-start is equivalent to calling XNET Start.vi (Normal). This property is false. Because the Timed auto-start is performed even if the session’s Auto Start? Loop uses an execution priority that typically is higher than the VIs that precede it, starting FlexRay communication within the Timed Loop ensures that you do not miss the first FlexRay cycle. Due to th ese factors, do not call XNET Start.vi prior to the Timed Loop (use the Timed Loop auto-start instead). is used to wait for Timeout After the initial session and inte rface auto-start, the Timed Loop communication to begin. 4-470 NI-XNET Hardware and Software Manual ni.com

536 Chapter 4 NI-XNET API for LabVIEW—XNET Create Timing Source.vi When the Timed Loop exits to its output node, the XNET session remains in its current state. The Timed Loop does not stop or clear the session, so you can continue to use the session in VIs that follow. Macrotick Offset macrotick offset , it helps to understand some NI -XNET implementa tion aspects. To s e t t h e When the FlexRay Communication Controller (CC) receives a frame, the NI-XNET hardware immediately transfers th T). This transfer is performed at frame to LabVIEW Real-Time (R using DMA (Direct Memory Access) on the PXI back plane, so that it occu rs quickly and with negligible jitter to your LabVIEW RT execution. Figure 4-12 shows the effects of this im plementation. In th is example, the macrotick offset XNET Read.vi The subdiagram in the Timed Loop calls is set to occur at the end of slot 1. to read the value received from slot 1. For better visibility in Figures 4-12, 4-13, and 4-14, the NI-XNET blocks (Read/Write, DMA than actual performance. When using a PXI controller for I/O, an dCC I/O) are longer LabVIEW Real-Time, your results typically will be faster. This is especially true if your application does not transfer data on the PXI backplane continuously (f or example, streaming of transfer can adversely impact the NI-XNET analog, vision, or TCP/IP data), as this sort DMA latencies. VIs in Timed Loop R1 (Your Application) CC Input IN1 and DMA Input (Cycle 2) Slot 1 Slot 2 Time Start of Cycle 3 Macrotick Offset FlexRay Frame Timed Read Figure 4-12. © 4-471 National Instruments NI-XNET Hardware and Software Manual

537 Chapter 4 NI-XNET API for LabV IEW—XNET Create Timing Source.vi Figure 4-12 shows that the DMA input transfer fo r slot 1 (IN1) occurs at the same time as XNET Read.vi for slot 1 (R1). Depending on which one completes first, XNET Read.vi may evious cycle (2). cle (3) or the pr return a value from the current cy macrotick offset must be large enough to ensure that the frame To prevent this uncertainty, macrotick offset DMA input is complete. Relative to Figure 4-12, setting to the end of slot 2 would suffice. , the frame values are transferred When your LabVIEW RT application calls XNET Write.vi are transferred to the NI-XNET hardware immediately using DMA. The frame values onboard processor memory. For efficiency reasons, this onboard processor waits until the FlexRay cycle Network Idle Time (NIT) to transfer the frame values from its memory to the FlexRay Communication Controller (CC). The FlexRay Communication Controller transmits each frame value according to its sl ot configuration in the cycle. Figure 4-13 shows the effects of this implementation. This example expands on Figure 4-12 XNET Write.vi by calling with a value for slot 8. XNET Write.vi (W8) is called well in e value of slot 8 (D8) occurs advance of slot 8 in the cycle. The DMA output transfer for th immediately after XNET Write.vi . Nevertheless, the value for slot 8 is not placed into the FlexRay Communication Controller until the NIT time, shown as C8. This means that although XNET Write.vi was called before slot 8’s occurrence in the current cycle 3, that value does not transmit un til the subsequent cycle 4. This implementation fo r output means that it is not necessarily urgent to call XNET Write.vi and the related XNET Write.vi before the relevant slot. You merely need to provide time for DMA output to complete prior to the NIT. 4-472 NI-XNET Hardware and Software Manual ni.com

538 Chapter 4 NI-XNET API for LabVIEW—XNET Create Timing Source.vi VIs in Timed Loop (Your Application) R1 W8 DMA Output D8 CC Output C8 CC Input and DMA Input IN1 NIT (Cycle 4) Dynamic 12345678910 (Cycle 2) Time Macrotick Start of Cycle 3 Offset Figure 4-13. FlexRay Frame Timed Write account, the typical n considerations into goal Taking these implementatio macrotick offset e last cycle input DMA and prior to the NIT. is a value that executes the Timed Loop after th , Ideally, the macrotick offset provides sufficient time for input DMA, XNET Read.vi LabVIEW code within the Timed Loop (for example, a simulation model), XNET Write.vi , and DMA output. macrotick offset To find a value for , you can use the XNET Cluster property node. The macrotick offset for the start of NIT, which is your property provides the FlexRay:NIT Start upper limit. To determine the lower limit, the FlexRay:Static Slot property provides the number of macroticks for each static slot. Static slot num bers begin at 1. Assuming is X is the last slot that you read, the lower limit for macrotick offset static slot X  FlexRay:Static Slot ). ( macrotick offset es a technique for calculating . The The following example demonstrat example uses a simple FlexRay cluster configured as follows: • —5000000 bps (5 Mbps) Baud Rate Macrotick —1 (1 μs duration) • • —1000 (1 ms) Macro Per Cycle • —10 Number of Static Slots • —80 Number of Minislots —58 MT (16 byte payload) Static Slot • 4-473 National Instruments © NI-XNET Hardware and Software Manual

539 Chapter 4 NI-XNET API for LabV IEW—XNET Create Timing Source.vi • NIT Start —900 MT offset • NIT —100 MT (duration) example does the following: Within the Timed Loop, the • Reads a Signal Input Single-Point session fo r frames in static slots 2, 3, and 4. • Executes a simulation model (passes in inputs and obtains outputs). • Writes a Signal Output Single-Point sessio n for frames in static slots 8, 9, and 10. Assume that you test the simulation model performance and determine that it takes 100 μs (including jitter). Using the cluster configuration and the time required for the simulation e simulation model at the midpoint between the model, select a macrotick offset that locates th end of slot 4 (the last input frame) and the start of NIT. This provides the maximum time possible for XNET Read.vi / XNET Write.vi , DMA input/output, and CC input/output. Static_Slot) EndOfSlot4 = (4  = (4 58)  = 232 Midpoint = EndOfSlot4 + ((NIT_Start – EndOfSlot4) / 2) = 232 + ((900 – 232) / 2) = 232 + 334 = 566 = (Midpoint – (SimModelTime / 2)) macrotick offset = (566 – (100 / 2)) = 516 4-474 NI-XNET Hardware and Software Manual ni.com

540 Chapter 4 NI-XNET API for LabVIEW—XNET Create Timing Source.vi Figure 4-14 shows the Timed Loop timing diagram. Notice that the simulation model is synchronized deterministically with the FlexRay cycle. The Timed Loop code reads inputs tes outputs, and then writes the output for the next cycle. from the current cycle, calcula VIs in Timed Loop SIM (Your Application) R2,3,4 W8,9,10 DMA Output D8,9,10 CC Output C8,9,10 IN3 CC Input and DMA Input IN4 IN2 Dynamic NIT (Cycle 4) 12345678910 (Cycle 2) Time Start of Macrotick Offset (516) Cycle 3 Figure 4-14. Timing Source Example Reading from the FlexRay Communication Controller (and performing the corresponding XNET Read.vi DMA) for frames 2, 3, and 4 is sh for own as blocks IN2, IN3, and IN4. . The simulation model execution is shown as frames 2, 3, and 4 is shown as block R2,3,4 XNET block SIM. The start of SIM is halfway between the end of slot 4 and the start of NIT. for frames 8, 9, and 10 is shown as block W8,9,10. The corresponding DMA output Write.vi for these frames is shown as block D8,9,10. The FlexRay Communication Controller update during the NIT is shown as block C8,9,10. As with any performance-sensitive configuration, you should measure using your own macrotick offset hardware and application to calculate the best value. To determine the current cycle and macrotick within the Ti med Loop for measurement purposes, use XNET Read (State FlexRay Cycle Macrotick).vi . NI-XNET Hardware and Software Manual 4-475 National Instruments ©

541 Chapter 4 NI-XNET API for LabVIEW—Advanced Subpalette Advanced Subpalette This subpalette includes advanced functions fo r controlling the state of NI-XNET sessions, connecting hardware terminals, and retrieving information about the XNET hardware in your system. XNET Start.vi Purpose Starts communication for the specified XNET session. Format Inputs session in is the session to start. This session is selected from the LabVIEW project or returned from XNET Create Session.vi . scope describes the impact of this operation on the underlying state models for the session and its interface. The session is started followed by starting the (0) Normal interface. This is equivalent to calling XNET Start.vi scope followed by calling the Session Only with XNET Start.vi with the Interfa ce Only scope. scope This is the default value for if it is unwired. Session Only The session is placed into the Started state (refer to (1) e Stopped state th If the interface is in ). State Models before this VI runs, the interface remains in the n occurs with the Stopped state, and no communicatio on bus. To h ave m ultiple sessi xactly the same s start at e time, start each sessio sc ope. Session Only n with the n you are ready for all sessions to start Whe communicating on the associated interface, call e Interface Only scope. with th XNET Start.vi Starting a previou sly started session is consid ered the command to is operation sends start the a no-op. Th 4-476 NI-XNET Hardware and Software Manual ni.com

542 Chapter 4 r LabVIEW—XNET Start.vi NI-XNET API fo session, but does not wait for the session to be started. It is ideal for a real-time application where performance is critical. Interface Only (2) If the underlying interface is not previously started, the interface is placed into th e Started state (refer to State Models ). After the interface star ts communicating, all previously started sessions can transfer data to and eviously started interface is from the bus. Starting a pr considered a no-op. (3) The session is placed into the Started state Session Only Blocking ). If the interface is in (refer to State Models the Stopped state before this VI runs, the interface remains in the Stopped state, and no communication occurs with the bus. To have multiple sessions start at exactly the same time, start each session with the Session Only y for all sessions to scope. When you are read start communicating on the associated interface, call with the XNET Start.vi Interface Only scope. Starting a previously started session is considered a no-op. This operation waits for the session to start before completing. is the error cluster input (refer to Error Handling ). error in Outputs session out is the same as session in , for use with subsequent VIs. error out is the error cluster output (refer to Error Handling ). Description optional. This VI is for more Because the session is started automatically by default, this VI is advanced applications to start multiple sessio ns in a specific order. For more information about the automatic start feature, refer to the Auto Start? property. For each physical interface, the NI-XNET hardware is divided into two logical units: signals Sessions • : You can create one or more sessions, each of which contains frames or s. to be tr ansmitted (or received) on the bu The interface physically connects to th e bus and transmits (or receive s) data • Interface : fo r the sessions. 4-477 © National Instruments NI-XNET Hardware and Software Manual

543 Chapter 4 NI-XNET API for LabVIEW—XNET Start.vi You can start each logical unit se parately. When a session is started, all contained frames or signals are placed in a state where they are ready to communicate. When the interface is started, it takes data from all started sessions to communicate with othe r nodes on the bus. For . State Models r the session and interface, refer to a specification of the state models fo If an output session starts before you write data, or you read an input session before it receives a frame, default data is used. For more information, refer to the XNET Frame Default Payload Default Value properties. and XNET Signal 4-478 NI-XNET Hardware and Software Manual ni.com

544 Chapter 4 NI-XNET API for LabVIEW—XNET Stop.vi XNET Stop.vi Purpose Stops communication for the specified XNET session. Format Inputs session in is the session to stop. This session is selected from the LabVIEW . project or returned from XNET Create Session.vi describes the impact of this operation on the underlying state models scope for the session and its interface. Normal (0) The session is stopped. If this is the last session stopped on the interface, the interface is also stopped. If any other sessions are runn ing on the in terface, this scope, to avoid call is treated just like the Session Only disruption of communication on the other sessions. if it is unwired. scope This is the default value for (1) The session is placed in the Stopped state (refer to Session Only State Models ). If the interface was in the Started or Running state before this VI is called, the interface remains in that state an d communication continues, but data from this session does not transfer. This scope generally is not necessary, as the scope only Normal stops the interface if there are no other running sessions. This operation sends the command to stop the session, but does not wait for the session to be stopped. It is ideal for a real-time application where performance is critical. Interface Only (2) The underlying interface is placed in the Stopped state ). This prevents all State Models (refer to communication on the bus, for all sessions. This allows you to modify certain properties that require the interface to be stopped (for example, CAN baud rate). 4-479 © National Instruments NI-XNET Hardware and Software Manual

545 Chapter 4 NI-XNET API for LabVIEW—XNET Stop.vi All sessions remain in the Started state. To have multiple sessions stop at exactly the same time, first Interface Only scope and stop the interface with the then stop each session with either the Normal or Session Only scope. Session Only Blocking (3) The session is placed in the Stopped state (refer to State Models ). If the interface was in the Started or Running state before this VI is ins in that state and called, the interface rema communication continues, but data from this session does not transfer. This scope generally is not necessary, as the Normal scope stops the interface only if there are no other running sessions. This operation waits for the session to stop before completing. error in is the error cluster input (refer to Error Handling ). Outputs session in is the same as , for use with subsequent VIs. session out error out ). Error Handling is the error cluster output (refer to Description Because the session is stopped automatically when cleared (closed), this VI is optional. For each physical interface, the NI-XNET hardware is divided into two logical units: Sessions : You can create one or more sessions, each of which contains frames or signals • to be transmitted (or received) on the bus. • Interface : The interface physically connects to th e bus and transmits (or receives) data for the sessions. You can stop each logical unit se parately. When a session is st opped, all contained frames or signals are placed in a state where they are no longer ready to co mmunicate. When the interface is stopped, it no longer takes data from sessions to communicate with other nodes dels for the session and interface, refer to on the bus. For a specification of the state mo State Models . 4-480 NI-XNET Hardware and Software Manual ni.com

546 Chapter 4 NI-XNET API for LabVIEW—XNET Clear.vi XNET Clear.vi Purpose Clears (closes) the XNET session. Format Inputs session in session is selected from the is the session to clear. This LabVIEW project or returned from XNET Create Session.vi . error in is the error cluster input (refer to Error Handling ). Outputs error out is the error cluster output (refer to Error Handling ). Description This VI stops communication fo r the session and releases al l resources the session uses. with normal scope, so if this is the last session XNET Stop.vi internally calls XNET Clear.vi using the interface, communication stops. ed (the top-level VI is idle ), LabVIEW automatically clears When your application is finish all XNET sessions within that VI and its subVIs. Therefore, XNET Clear.vi is rarely needed in your application. You typically use XNET Clear.vi when you need to clear the existing session to create a new session that uses the same objects. For exampl e, if you create a session for a frame named frameA using Frame Output Sing le-Point mode, then you creat e a second session for frameA using Frame Output Queued XNET Create Session.vi returns an mode, the second call to error, because frameA can be accessed using only one output mode. If you call the XNET Clear.vi before the second XNET Create Session.vi call, you can close the previous use of frameA to create the new session. XNET Connect Terminals.vi This VI disconnects terminal s that you connected using . 4-481 © National Instruments NI-XNET Hardware and Software Manual

547 Chapter 4 NI-XNET API for LabVIEW—XNET Flush.vi XNET Flush.vi Purpose Flushes (empties) all XNET session queues. Format Inputs session in is the session to flush. This session is selected from the LabVIEW project or returned from . XNET Create Session.vi error in is the error cluster input (refer to Error Handling ). Outputs session out is the same as session in , provided for use with subsequent VIs. error out Error Handling ). is the error cluster output (refer to Description With the exception of single-point modes, all sessions use queues to store frames. For input modes, the queues store fram e values (or corresponding signal values) that have been received, but not obtained by calling XNET Read.vi . For output sessions, the queues store frame values provided to XNET Write.vi , but not transmit ted successfully. have no effect on these queues. Use to XNET Flush.vi XNET Start.vi and XNET Stop.vi discard all values in the session’s queues. XNET Write.vi to write three frames, then immediately call XNET For example, if you call Stop.vi , then call XNET Start.vi a few seconds later, the thr ee frames transmit. If you call XNET Flush.vi between XNET Stop.vi and XNET Start.vi , no frames transmit. eceive three frames, then call As another example, if you r , the three frames XNET Stop.vi remains in the queue. If you call a few seconds later, then call XNET Read.vi , XNET Start.vi you obtain the three frames r eceived earlier, potentially follo wed by other frames received XNET XNET Start.vi . If you call XNET Flush.vi between XNET Stop.vi and after calling . returns only frames received after the calling XNET Start.vi Start.vi , XNET Read.vi 4-482 NI-XNET Hardware and Software Manual ni.com

548 Chapter 4 NI-XNET API for LabV IEW—XNET Connect Terminals.vi XNET Connect Terminals.vi Purpose Connects terminals on the XNET interface. Format Inputs session in ection. This session is selected is the session to use for the conn . from the LabVIEW project or returned from XNET Create Session.vi source terminal is the connection source. destination terminal is the connection destination. is the error cluster input (refer to Error Handling ). error in Outputs session out is a duplicate of the session in, provided for simpler wiring. error out is the error cluster output (refer to Error Handling ). Description source terminal destination terminal on the interface hardware. The This VI connects a to a XNET terminal represents an external or inte rnal hardware connectio n point on a National Instruments XNET hardware product. External terminals include PXI_Trigger lines for a PXI card, RTSI terminals for a PCI card, or the sing le external terminal for a C Series module. Internal terminals include timebases (clocks) and logical entities such as a start trigger. The terminal inputs use the XNET Terminal I/O name, so you can select from possible values using the drop-down list. Typically, one of the pair is an internal and the other an external. 4-483 © National Instruments NI-XNET Hardware and Software Manual

549 Chapter 4 NI-XNET API for LabV IEW—XNET Connect Terminals.vi Valid Combinations of Source/Destination source terminal destination The following table lists all valid combinations of and terminal . Destination FrontPanel0 Log Master Start Trigg er FrontPanel1 Timebase Trigger PXI_Trig Source x x X X    PXI_Trig X    FrontPanel0 X FrontPanel1 1 X X  X X PXI_Star 1 X X PXI_Clk10 X  X StartTrigger  X X X  CommTrigger   X X X 2 X X  FlexRayStartCycle X  2    X FlexRayMacrotick X 1MHzTimebase   X X X X X X X 10MHzTimebase  1 Valid only on PXI hardware. 2 Valid only on FlexRay hardware. Source Terminals The following table describes the valid source terminals. NI-XNET Hardware and Software Manual 4-484 ni.com

550 Chapter 4 IEW—XNET Connect Terminals.vi NI-XNET API for LabV Source Terminal Description PXI_Trig x Selects a general-purpose trigger line as the connection so urce (input), where x is a number from 0 to 7. For PCI car ds, these are the RTSI lines. For PXI cards, these are the PXI Trigger lin es. For C Series modules in a modules in the chassis automatically share a CompactDAQ chassis, all common timebase. For information ab out routing the StartTrigger for Interface:Source Te CompactDAQ, refer to the XNET Session rminal:Start Trigger property. FrontPanel0 Selects a general-purpose Front Panel Trigger line as the connection source FrontPanel1 (input). Selects the PXI star trigger signal. PXI_Star can source star trigger from Slot 2 Within a PXI chassis, some PXI products enables the PXI XNET hardware to to all higher-numbered slots. PXI_Star receive the star trigger when it is in Slot 3 or higher. Note : You cannot use this terminal with a PCI device. PXI_Clk10 Selects the PXI 10 MHz backpl ane clock. The only valid destination terminal for this source is MasterTimebase. This routes the 10 MHz PXI backplane clock for use as the XNET card timebase. When you use PXI_Clk10 as the XNET card timebase, you also must use PXI_Clk10 as the timebase for other PXI cards to perform synchronized input/output. Note : You cannot use this terminal with a PCI device. Selects the start trigger, which is the event set when the when the Start StartTrigger Interface transition occurs. Th e start trigger is the sa me for all sessions using a given interface. XNET card to the star You can route the start trigger of this t trigger of other XNET or DAQ cards to ensure that sampling begins at the same time on both cards. For example, you can synchronize two XNET cards by routing StartTrigger as the source terminal on one XNET card and then routing destination terminal on the other XNET card, with both StartTrigger as the line for the connections. cards using the same RTSI 4-485 © National Instruments NI-XNET Hardware and Software Manual

551 Chapter 4 IEW—XNET Connect Terminals.vi NI-XNET API for LabV Source Terminal Description CommTrigger Selects the communicating trigger, wh ich is the event set when the Comm tion occurs. The communicating trigger is the State Communicating transi same for all sessions using a given interface. You can route the communi cating trigger of this XNET card to the start trigger of other XNET or DAQ cards to ensure that sampling begins at the same time on both cards. The communicating trigger is similar to a start trigger, but is used if your clock source is the FlexRayMacrotick, which is not available until the interface is properly integrated into th e bus. Because you cannot generate a start trigger to another interface until the synchronization clock is also available, you can use this trigger to allow for the clock under this special circumstance. FlexRayStartCycle Selects the FlexRay Start of Cycles as an advanced trigger source. This generates a repeating pulse that external hardware can use to ent or other action with each FlexRay cycle. synchronize a measurem Note : You can use this terminal only with a FlexRay device. FlexRayMacrotick Selects the FlexRay Macrotick as a t iming source. The FlexRay Macrotick is the basic unit of time in a FlexRay network. You can use this source terminal to synchronize other measurements to the is scenario, you would configure the actual time on the FlexRay bus. In th FlexRayMacrotick as the source terminal and route it to a RTSI or front panel terminal. After the interface is co mmunicating to the FlexRay network, the Macrotick signal becomes available. You also can connect the FlexRayMacr otick to the MasterTimebase. This configures the counter that timestamps received frames to run synchronized to FlexRay time, and also allows you to read the FlexRay cycle macrotick to do additional synchronization with the FlexRay bus in your application. Note : You can use this terminal only with a FlexRay device. 4-486 NI-XNET Hardware and Software Manual ni.com

552 Chapter 4 IEW—XNET Connect Terminals.vi NI-XNET API for LabV Source Terminal Description 1MHzTimebase MHz oscillator. The only valid destination Selects the XNET card’s local 1 terminals for this source are PXI Trigger0–PXI Trigger7. This source terminal routes the XNET card local 1 MHz clock so that other NI cards can use it as a timebase. For example, you can synchronize two XNET cards by connecting 1MHzTimebase to PXI_Trig on one XNET card x and then connecting PXI_Trig x to MasterTimebase on the other XNET card. 10MHzTimebase Selects the XNET card’s local 10 MHz os cillator. This routes the XNET card local 10 MHz clock for use as a timebase by other NI cards. For example, you can synchronize two XNET cards by connecting 10MHzTimebase to x PXI_Trig to x on one XNET card and then connecting PXI_Trig MasterTimebase on the other XNET card. Destination Terminals . The following table describes the valid destination terminals Destination Terminal Description PXI_Trig x Selects a general-purpose trigger line as the connection destination (output), where x is a number from 0 to 7. For PCI cards, these are the RTSI lines. For PXI cards, these are the PXI Trigger lines. For C Series modules in a CompactDAQ chassis, all modules in the chassis automatically share a common timebase. For information ab out routing the StartTrigger for CompactDAQ, refer to the XNET Session Interface:Source Te rminal:Start Trigger property. FrontPanel0 Selects a general-purpose Front Panel Trigger line as the connection FrontPanel1 destination (output). National Instruments NI-XNET Hardware and Software Manual © 4-487

553 Chapter 4 IEW—XNET Connect Terminals.vi NI-XNET API for LabV Destination Terminal Description StartTrigger Selects the start trigger, which is the event that allows the interface to begin ger occurs on the first source terminal communication. The start trig low-to-high transition. The start trigger is the same for all sessions using a art Interface transition to occur. given interface. This causes the St You can route the start trigger of anot her XNET or DAQ card to ensure that sampling begins at the same time on both cards. For example, you can synchronize with an M-Series DAQ MIO card by routing the AI start trigger of the MIO card to a RTSI line and then routing the same RTSI line with destination terminal StartTrigger as the on the XNET card. The default (disconnected) state of this destination means the start trigger XNET Start.vi occurs when is invoked with the scope set to either Normal or Auto Start? is enabled, reading or writing to a Interface Only. Alternately, if session may start the interface. MasterTimebase MasterTimebase instructs the XNET card to use the connection source terminal as the master timebase. The XNET card uses this master timebase for input sampling (includi ng timestamps of received messages) as well as periodic output sampling. Your XNET hardware supports incoming frequencies of 1 MHz, 10 MHz, and 20 MHz, and automatically detects the frequency without any additional configuration. For example, you can synchronize a CAN and DAQ M Series MIO card by cillator (board clock) of the DAQ card to a connecting the 10 MHz os the same PXI_Trig line as the source PXI_Trig line, and then connecting terminal . For PXI form factor hardware, yo u also can use PXI_Clk10 as the source terminal . This receives the PXI 10 MHz backplane clock for use as the master timebase. MasterTimebase applies separately to each port of a multiport XNET card, meaning you could run each port off of a separate incoming (or onboard) timebase signal. If you are using a PCI boar d, the default connection to the Master Timebase is the local oscillator. If you are using a PXI board, the default connection to the MasterTimebase is the PXI_Clk10 sign al, if it is available. Some chassis allow PXI_Clk10 to be turned off. In this case, the hardware automatically uses the local oscillator as the default MasterTimebase. 4-488 NI-XNET Hardware and Software Manual ni.com

554 Chapter 4 IEW—XNET Connect Terminals.vi NI-XNET API for LabV Destination Terminal Description The Log Trigger terminal generates a fr ame when it detects a rising edge. Log Trigger When connected, this frame is transf erred into the Frame Stream Input d. For information about this frame, session’s queue if the session is starte including the frame payload interpretation, refer to Special Frames . 4-489 National Instruments © NI-XNET Hardware and Software Manual

555 Chapter 4 IEW—XNET Disconnect Terminals.vi NI-XNET API for LabV XNET Disconnect Terminals.vi Purpose Disconnects terminals on the XNET interface. Format Inputs is the session to use for the conn session in ection. This session is selected from the LabVIEW project or returned from XNET Create Session.vi . is the connection source. source terminal is the connection destination. destination terminal error in is the error cluster input (refer to Error Handling ). Outputs session out is a duplicate of the session in, provided for simpler wiring. ). error out is the error cluster output (refer to Error Handling Description This VI disconnects a specific pair of source/de stination terminals previously connected with XNET Connect Terminals.vi . When the final session for a given interface is cleared (either by the VI going idle or by explicit calls to XNET Clear.vi ), NI-XNET automatically disconnects all terminal connections for that interface. Therefore, XNET Disconnect Terminals.vi is not required for most applications. This VI typically is used to change terminal connections dynamically wh ile an application is first must stop the interface using XNET Stop.vi with running. To disconnect a terminal, you XNET Disconnect Terminals.vi the Interface Only scope. Then you can call and XNET Connect T erminals.vi to adjust terminal connections. Finally, you can call XNET Start.vi with the Interface Only scope to restart the interface. s been previously connected. Attempting to You can disconnect only a terminal that ha disconnect a nonconnected terminal results in an error. 4-490 NI-XNET Hardware and Software Manual ni.com

556 Chapter 4 NI-XNET API for LabV IEW—XNET Terminal Constant XNET Terminal Constant This constant provides the constant form of the XNET Terminal I/O name. You drag a constant to the block diagram of your VI, then select a terminal. You can change constants only during configuration, prior to running th e VI. For a complete description, refer to XNET . Terminal I/O Name XNET System Property Node Format Description The XNET System property node provides info rmation about all NI-XNET hardware in your system, including all devices and interfaces. to change direction between read and write. Pull down this node to add properties. Right-click Right-click each property name to creat e a constant, control, or indicator. For help on a specific property, open the LabVIEW context help window () and move your cursor over the property name. For more information about LabVIEW property nodes, open the main LabVIEW help (select Property Nodes topic in menu) and look for the Search the LabVIEW Help from the Help the index. 4-491 © National Instruments NI-XNET Hardware and Software Manual

557 Chapter 4 NI-XNET API for LabV IEW—XNET System Property Node Devices Data Type Direction Required? Default N/A No Read Only Property Class XNET System Short Name Devices Description Returns an array of physical XNET devices in the system. Each physical XNET board is a hardware product such as a PCI/PXI board. The system refers to the execution target of this property node. If this property is run on an RT target, it reports the RT system hardware. You can wire the XNET Device I/O name to the XNET Device prop erty node to access properties of the device. Interfaces (FlexRay) Data Type Direction Required? Default Read Only No N/A Property Class XNET System Short Name IntfFlexRay Description Returns an array of all available interfaces on the system that support the FlexRay protocol. target of this property node. If this property node executes The system refers to the execution on an RT target, it reports interfaces physically on the RT target. 4-492 NI-XNET Hardware and Software Manual ni.com

558 Chapter 4 NI-XNET API for LabVIE W—XNET System Property Node Interfaces (All) Data Type Direction Required? Default N/A Read Only No Property Class XNET System Short Name IntfAll Description Returns an array of all available interfaces on the system. target of this property node. The system refers to the execution If this property node executes on an RT target, it reports interfaces physically on the RT target. Interfaces (CAN) Data Type Direction Required? Default No Read Only N/A Property Class XNET System Short Name IntfCAN Description Returns an array of all available interfaces on the system that support the CAN Protocol. target of this property node. If this property node executes The system refers to the execution on an RT target, it reports interfaces physically on the RT target. 4-493 © National Instruments NI-XNET Hardware and Software Manual

559 Chapter 4 IEW—XNET System Property Node NI-XNET API for LabV Interfaces (LIN) Data Type Direction Required? Default No Read Only N/A Property Class XNET System Short Name IntfLIN Description Returns an array of all available interfaces on the system that support the LIN Protocol. If this property node executes target of this property node. The system refers to the execution on an RT target, it reports interfaces physically on the RT target. 4-494 NI-XNET Hardware and Software Manual ni.com

560 Chapter 4 NI-XNET API for LabVIE W—XNET System Property Node Version:Build Direction Data Type Required? Default Read Only No N/A Property Class XNET System Short Name Ve r. B u i l d Description Returns the driver version [Build] as a u32. Remarks The driver version is specified in the following format: [Major].[Minor].[Update][Phase][Build] . For example, 1.2.3f4 returns: •[Major] = 1 • [Minor] = 2 • [Update] = 3 • [Phase] = Final/Release • [Build] = 4 A larger version number implie s a newer XNET driver version. Use this property for: Determining driver functionality or release date. • • Determining upgrade availability. 4-495 © National Instruments NI-XNET Hardware and Software Manual

561 Chapter 4 NI-XNET API for LabV IEW—XNET System Property Node Version:Major Data Type Direction Required? Default N/A Read Only No Property Class XNET System Short Name Ve r. M a j o r Description Returns the driver version [Major] as a u32. Remarks ed in the following format: The driver version is specifi . [Major].[Minor].[Update][Phase][Build] For example, 1.2.3f4 returns: •[Major] = 1 • [Minor] = 2 [Update] = 3 • • [Phase] = Final/Release • [Build] = 4 A larger version number implie s a newer XNET driver version. Use this property for: Determining driver functionality or release date. • Determining upgrade availability. • 4-496 NI-XNET Hardware and Software Manual ni.com

562 Chapter 4 NI-XNET API for LabVIE W—XNET System Property Node Version:Minor Direction Data Type Required? Default Read Only No N/A Property Class XNET System Short Name Ver.Minor Description Returns the driver version [Minor] as a u32. Remarks The driver version is specified in the following format: [Major].[Minor].[Update][Phase][Build] . For example, 1.2.3f4 returns: •[Major] = 1 • [Minor] = 2 • [Update] = 3 • [Phase] = Final/Release • [Build] = 4 A larger version number implie s a newer XNET driver version. Use this property for: Determining driver functionality or release date. • • Determining upgrade availability. 4-497 © National Instruments NI-XNET Hardware and Software Manual

563 Chapter 4 NI-XNET API for LabV IEW—XNET System Property Node Version:Phase Data Type Direction Required? Default Read Only No N/A Property Class XNET System Short Name Ve r. P h a s e Description [Phase] as an enumeration. Returns the driver version Enumeration Value Development 0 1 Alpha 2 Beta Release 3 Note The driver’s official version al ways has a phase of Release. Remarks The driver version is specifi ed in the following format: [Major].[Minor].[Update][Phase][Build] . For example, 1.2.3f4 returns: •[Major] = 1 • [Minor] = 2 [Update] = 3 • • [Phase] = Final/Release • [Build] = 4 A larger version number implie s a newer XNET driver version. Use this property for: Determining driver functionality or release date. • Determining upgrade availability. • 4-498 NI-XNET Hardware and Software Manual ni.com

564 Chapter 4 NI-XNET API for LabVIE W—XNET System Property Node Version:Update Direction Data Type Required? Default Read Only No N/A Property Class XNET System Short Name Ver.Update Description Returns the driver version [Update] as a u32. Remarks The driver version is specified in the following format: [Major].[Minor].[Update][Phase][Build] . For example, 1.2.3f4 returns: •[Major] = 1 • [Minor] = 2 • [Update] = 3 • [Phase] = Final/Release • [Build] = 4 A larger version number implie s a newer XNET driver version. Use this property for: Determining driver functionality or release date. • • Determining upgrade availability. 4-499 © National Instruments NI-XNET Hardware and Software Manual

565 Chapter 4 NI-XNET API for LabVIEW—XNET Device Property Node XNET Device Property Node Format Description Property node used to read/write properties for an XNET Device I/O Name . Pull down this node to add properties. Right-click to change direction between read and write. Right-click each property name to creat e a constant, control, or indicator. For help on a specific property, open the LabVIEW context help window () and move your cursor over the property name. For more information about LabVIEW property nodes, open the main LabVIEW help (select Property Nodes menu) and look for the topic in Search the LabVIEW Help from the Help the index. Form Factor Data Type Direction Required? Default Read Only No N/A Property Class XNET Device Short Name FormFac Description Returns the XNET board physical form factor. Enumeration Value PXI 0 PCI 1 C Series 2 4-500 NI-XNET Hardware and Software Manual ni.com

566 Chapter 4 NI-XNET API for LabVIE W—XNET Device Property Node Interfaces Direction Data Type Required? Default Read Only No N/A Property Class XNET Device Short Name Intfs Description Returns an array of XNET Interface I/O names a ssociated with this physical hardware device. XNET Interface Details The XNET Interface I/O Name represents a physical communication port on an XNET device. An XNET device may have one or more XNET Interface I/O names, depending on the number of physical connectors the board has. to retrieve You can pass the XNET Interface I/O name to the XNET Interface Property Node hardware information about the interface. This XNET interface is the same I/O name used to create the session. Displayed on the front panel, the XNET Interface I/O name disp lays the interface string name. This string is used for: XNET String to IO Name.vi to retrieve the XNET Interface I/O name. • • Identification in Measurement & Automation Explorer (MAX). 4-501 © National Instruments NI-XNET Hardware and Software Manual

567 Chapter 4 NI-XNET API for LabVIEW—XNET Device Property Node Number of Ports Direction Required? Default Data Type Read Only No N/A Property Class XNET Device Short Name NumPorts Description Returns the number of physical port connectors on the XNET board. Remarks For example, returns 2 for an NI PCI-8517 two-port FlexRay device. Product Name Data Type Direction Required? Default Read Only No N/A Property Class XNET Device Short Name ProductName Description Returns the XNET device product name. Remarks For example, returns NI PCI-8517 (2 ports) for an NI PCI-8517 device. 4-502 NI-XNET Hardware and Software Manual ni.com

568 Chapter 4 NI-XNET API for LabVIE W—XNET Device Property Node Product Number Direction Data Type Required? Default Read Only No N/A Property Class XNET Device Short Name ProductNum Description Returns the numeric portion of the XNET device product name. Remarks For example, returns 8517 for an NI PCI-8517 two-port FlexRay device. Serial Number Data Type Direction Required? Default Read Only No N/A Property Class XNET Device Short Name SerNum Description ciated with the XNET device. Returns the serial number asso Remarks The serial number is written in HEX on a label on the physical XNET board. Convert the return value from this property to HEX to match the label. 4-503 © National Instruments NI-XNET Hardware and Software Manual

569 Chapter 4 NI-XNET API for LabVIEW—XNET Interface Property Node Slot Number Data Type Direction Required? Default N/A Read Only No Property Class XNET Device Short Name SlotNum Description device (module) is located. Physical slot where the slot number within the chassis. For PXI and C Series, this is the XNET Interface Property Node Format Description Property node used to read/write properties for an XNET Interface I/O Name . to change direction between read and write. Pull down this node to add properties. Right-click Right-click each property name to creat e a constant, control, or indicator. For help on a specific property, open the LabVIEW context help window () and move your cursor over the property name. For more information about LabVIEW property nodes, open the main LabVIEW help (select Property Nodes topic in Search the LabVIEW Help from the Help menu) and look for the the index. 4-504 NI-XNET Hardware and Software Manual ni.com

570 Chapter 4 NI-XNET API for LabVIE W—XNET Interface Property Node CAN.Termination Capability Required? Default Data Type Direction Read Only No N/A Property Class XNET Interface Short Name CAN.TermCap Description ace can terminate the CAN bus. ing whether the XNET interf Returns an enumeration indicat Value Enumeration No 0 1 Ye s Remarks Signal reflections on the CAN bus can cause co mmunication failure. To prevent reflections, termination can be present as external re sistance or resistance the XNET board applies internally. This enumeration determines whether the XNET board can add termination to the bus. ver termination, refer to To select the CAN transcei . Interface:CAN:Termination 4-505 © National Instruments NI-XNET Hardware and Software Manual

571 Chapter 4 NI-XNET API for LabVIEW—XNET Interface Property Node CAN.Transceiver Capability Direction Required? Default Data Type Read Only No N/A Property Class XNET Interface Short Name CAN.TcvrCap Description Returns an enumeration indicating the CAN bus physical transceiver support. Value Enumeration High-Speed (HS) 0 1 Low-Speed (LS) XS (HS, LS, SW, or External) 2 Remarks The XS value in the enumeration indicates the board has the physical transceivers for High-Speed (HS), Low-Speed (LS), and Single Wi re (SW), and can connect to an external property. Interface:CAN:Transceiver Type transceiver. This value is switchable through the 4-506 NI-XNET Hardware and Software Manual ni.com

572 Chapter 4 NI-XNET API for LabVIE W—XNET Interface Property Node Device Data Type Direction Required? Default No Read Only N/A Property Class XNET Interface Short Name Device Description , this property returns the XNET device I/O name. From the XNET Interface I/O Name Remarks ysical XNET board that contains the XNET The XNET device I/O name returned is the ph interface. This property determines the physical XNET device through the XNET Device Serial Number property for a given XNET Interface I/O name. Name Data Type Direction Required? Default No N/A Read Only Property Class XNET Interface Short Name Name Description Returns the string name assigned to the XNET Interface I/O name. Remarks This string is used for: , to retrieve the XNET Interface I/O name. XNET String to IO Name.vi • • Identification in MAX. 4-507 © National Instruments NI-XNET Hardware and Software Manual

573 Chapter 4 NI-XNET API for LabVIEW—XNET Interface Property Node Number Direction Required? Default Data Type Read Only No N/A Property Class XNET Interface Short Name Number Description Returns unique number associated with the XNET interface. Remarks The XNET driver assigns each port connector in the system a unique number XNET driver. This number, plus its protocol name, is the XNET Interface I/O Name string name. For example: XNET Interface String Name Number 1 CAN1 3 FlexRay3 4-508 NI-XNET Hardware and Software Manual ni.com

574 Chapter 4 NI-XNET API for LabVIE W—XNET Interface Property Node Port Number Data Type Direction Required? Default N/A Read Only No Property Class XNET Interface Short Name PortNum Description Returns the physical port number printed near the connector on the XNET device. Remarks The port numbers on an XNET board are physi cally identified with numbering. Use this property, along with the XNET Device Serial Number property, to a ssociate an XNET interface with a physical (XNET board and port) combination. . XNET Blink.vi location of an XNET Interface with It is easier to find the physical Note 4-509 © National Instruments NI-XNET Hardware and Software Manual

575 Chapter 4 NI-XNET API for LabVIEW—XNET Interface Property Node Protocol Data Type Direction Required? Default Read Only No N/A Property Class XNET Interface Short Name Protocol Description Returns a protocol supported by the XNET Interface I/O Name as an enumeration. Value Enumeration 0 CAN FlexRay 1 LIN 2 Remarks The protocol enumeration matc e XNET Interface string name. hes the protocol part of th String Name Protocol Enumeration 0 CAN1 1 FlexRay3 4-510 NI-XNET Hardware and Software Manual ni.com

576 Chapter 4 NI-XNET API for La bVIEW—XNET Interface Constant XNET Interface Constant This constant provides the constant form of the XNET Interface I/O name. You drag a constant to the block diagram of your VI, then select an interface. You can change constants XNET e VI. For a complete description, refer to only during configuration, prior to running th Interface I/O Name . XNET Blink.vi Purpose Blinks LEDs for the XNET interface to iden tify its physical port in the system. Format Inputs interface in is the XNET Interface I/O name. modifier controls LED blinking: Disable blinking for identification. This option turns off Disable (0) both LEDs for the port. Enable (1) Enable blinking for identification. Both LEDs of the interface’s physical port turn on and off. The hardware blinks the LEDs automatically until you disable, so there is VI repetitively. no need to call the XNET Blink Both LEDs blink green (not red). The blinking rate is approximately three times per second. error in is the error cluster input (refer to Error Handling ). Outputs interface out is the same as interface in, provided for use with subsequent VIs. is the error cluster output (refer to ). error out Error Handling 4-511 © National Instruments NI-XNET Hardware and Software Manual

577 Chapter 4 NI-XNET API for LabVIEW—XNET Blink.vi Description Each XNET device contains one or two physical po rts. Each port is labeled on the hardware as Port 1 Port 2 . The XNET device also provides two LEDs per port. For a two-port board, or LEDs 1 and 2 are assigned to Port 1, and LE Ds 3 and 4 are assigned to physical Port 2. When your application uses mu ltiple XNET devices, this VI helps to identify each interface to associate its software behavior (LabVIEW c ode) to its hardware connection (port). Prior to running your XNET sessions, you can call this VI to blink the interface LEDs. For example, if you have a system with th ree PCI CAN cards, each with two ports, you can use this VI to blink the LEDs for interface CAN4, to identify it among the six CAN ports. The LEDs of each port support two states: Identification • : Blink LEDs to identify the physical port assigned to the interface. • : LED behavior that XNET sessions control. In Use Identification LED State You can use the XNET Blink VI only in the Identification state. If you call this VI while one or more XNET sessions for the interface are open (created), it returns an error, because the port’s LEDs are in the In Use state. In Use LED State When you create an XNET session for the interface, the LEDs for that ph ysical port transition to the In Use state. If you called the XNET Blink VI previously to enable blinking for identification, that LED behavior no longer applies. The In Use LED state remains until all XNET sessions are cleared. This typically occurs when all LabVIEW VIs are no longer running. The patterns that appear on the LEDs while In Use are documented in the LEDs . NI-XNET Hardware Overview section of Chapter 3, 4-512 NI-XNET Hardware and Software Manual ni.com

578 Chapter 4 NI-XNET API for La bVIEW—XNET System Close.vi XNET System Close.vi Purpose esh XNET hardware information. Closes the XNET system to refr Format Inputs error in is the error cluster input (refer to Error Handling ). Outputs ). Error Handling is the error cluster output (refer to error out Description XNET System Property Node , NI-XNET obtains information When your VI first uses the about all available devices and interfaces in the system. While using property nodes for the devices and interfaces, the hardwa re information maintains consis tency. For example, if you physically add a new device (for example, a plug-in a CompactDAQ chassis), the new device does not appear in the system properties. Use XNET System Close.vi to close the system and associ ated devices and interfaces. The next time your VI uses the XNET System property node, the hardware information is refreshed. to blink a device’s LEDs for identification, If you previously used XNET Blink.vi closes the associated device. disables blinking when it XNET System Close.vi 4-513 © National Instruments NI-XNET Hardware and Software Manual

579 Chapter 4 W—XNET String to IO Name.vi NI-XNET API for LabVIE XNET String to IO Name.vi Purpose to an XNET I/O Name. Converts a LabVIEW string Description This polymorphic VI converts a LabVIEW string to an XNET I/O name. This VI is not required for LabVIEW 2009 or newer. It is provided only for backward compatibility of VIs written in LabVIEW version prior to 2009. Currently supported versions of LabVIEW can now cast LabVIEW strings to XNET I/O names automatically. ni.com 4-514 NI-XNET Hardware and Software Manual

580 Chapter 4 NI-XNET API for LabVIEW—XNET Convert.vi XNET Convert.vi Purpose Converts between NI-XNET signal da ta and frame data or vice versa. Description e conversion direction and type of frame data. The instances of this polymorphic VI specify th There are two categories of XNET Conver t instance VIs: • Frame to Signal : Converts frame data to signal data. A stream of frames is read, and the signal values are filled with the values of the latest respective frames. Frames not matching any signals are ignored. If two or more frames with the same ID are present, the most recent (last) value is returned. • Signal to Frame : Converts signal data to frame data . One frame for each ID involved in the signal list is returned. Data not occupied by the signals from the list is filled with the respective default values. You can use both categories with the same conversion session mode. The XNET Convert instance VIs are: : Reads a set of CAN fr XNET Convert (Frame CAN to Signal).vi • ames and extracts the values from them. most recent signal • XNET Convert (Frame FlexRay to Signal).vi : Reads a set of FlexRay frames and extracts the most recent si gnal values from them. • XNET Convert (Frame LIN to Signal).vi : Reads a set of LIN fr ames and extracts the values from them. most recent signal • XNET Convert (Frame Raw to Signal).vi : Reads a set of raw frames and extracts the most recent signal values from them. : Reads a set of signal values and creates • XNET Convert (Signal to Frame CAN).vi CAN frames with their representation. • XNET Convert (Signal to Frame FlexRay).vi : Reads a set of signal values and creates FlexRay frames with their representation. : Reads a set of signal values and creates LIN XNET Convert (Signal to Frame LIN).vi • frames with their representation. XNET Convert (Signal to Frame Raw).vi • : Reads a set of signal values and creates raw frames with their representation. 4-515 © National Instruments NI-XNET Hardware and Software Manual

581 Chapter 4 NI-XNET API for LabVIEW—XNET Convert.vi XNET Convert (Frame CAN to Signal).vi Purpose Converts between NI-XNET C AN frame data and signals. Format Inputs XNET session in is the session to read. This session is returned from . The session mode must be Conversion. Create Session.vi frame data provides the array of LabVIEW clusters. Each array element corresponds to a frame value to convert. The data you write is converted to si gnal values in the order you provide them. Only the latest signal value is returned. . For an example of how this data applies, refer to Conversion Mode fic to the CAN protocol. For more The elements of each cluster are speci information, refer to Appendix A, Summary of the CAN Standard , or the CAN protocol specification. The cluster elements are: identifier is the CAN frame arbitration identifier. is false, the identifier uses standard format, so 11 bits If extended? of this identifier are valid. If extended? is true, the identifier uses extended format, so 29 bits of this identifier are valid. extended? is a Boolean value that determines whether the identifier uses extended format (t rue) or standard format (false). You must set this element to is not used for conversion. echo? false. 4-516 NI-XNET Hardware and Software Manual ni.com

582 Chapter 4 NI-XNET API for LabVIEW—XNET Convert.vi is the frame type (decimal value in parentheses): type CAN Data (0) : The CAN data frame contains payload data. • used frame type for CAN. This is the most commonly • CAN Remote (1) : CAN remote frame. Your application transmits a CAN remote frame to request data for the identifier corresponding . A remote ECU should respond with a identifier , which you can obtain using CAN data frame for the ngful, as a remote frame XNET Read.vi . This value is not meani does not contain any data to convert. timestamp represents absolute time using the LabVIEW absolute timestamp type. timestamp is not used for conversion. You must set this element to the default value, invalid (0). is the array of data byt es for a CAN data frame. payload d length of the frame value to The array size indicates the payloa transmit. According to the CAN protocol, the payload length range is 0–8. For CAN FD, the range can be 0–8, 12, 16, 20, 24, 32, 48, or 64. For more information, refer to the section for each mode. For a transmitted remote frame (CAN Remote type), the payload length in the frame value specifi es the number of payload bytes requested. Your application provides this payload length by filling payload with the requested number of bytes. This enables your application to specify the fram e payload length, but the actual values in the payload bytes are ignored (not contained in the transmitted frame). is the error cluster input (refer to ). Error Handling error in Outputs session out is the same as session in , provided for use with subsequent VIs. signal data returns a one-dimensional arra y of signal values. Each signal value is scaled, 64-bit floating point. Each array element corresponds to a signal configured for the session. The order of signals in the array correspo nds to the order in the session list. ted value for each signal. If multiple The data returns the most recent conver gnal data from the most recent frame is frames for a signal are input, only si returned. Here, most recent is defined by the order of the frames in the frame data array, not the timestamp. 4-517 © National Instruments NI-XNET Hardware and Software Manual

583 Chapter 4 NI-XNET API for LabVIEW—XNET Convert.vi Default If no frame is input for the corr esponding signals, the XNET Signal Value is returned. For an example of how this data applies, refer to Conversion Mode . error out is the error cluster output (refer to Error Handling ). ni.com 4-518 NI-XNET Hardware and Software Manual

584 Chapter 4 NI-XNET API for LabVIEW—XNET Convert.vi XNET Convert (Frame FlexRay to Signal).vi Purpose Converts between NI-XNET FlexRay frame data and signals. Format Inputs XNET is the session to read. This session is returned from session in Create Session.vi . The session mode must be Conversion. frame data provides the array of LabVIEW clusters. Each array element corresponds to a frame value to convert. The data you write is converted to signal values in the order you provide them. Only the latest signal value is returned. Conversion Mode . For an example of how this data applies, refer to The elements of each cluster are specifi c to the FlexRay protocol. For more information, refer to Appendix B, Summary of the FlexRay Standard , or the FlexRay Protocol Specification . The cluster elements are: within the FlexRay cycle. slot specifies the slot number cycle count specifies the cycle number. The FlexRay cycle count increments from 0 to 63, then rolls over back to 0. startup? is a Boolean value that specifies whether the frame is a startup frame (true) or not (fal se). This field is ignored for conversion. sync? is a Boolean value that specifies whether the frame is a sync field is ignored for conversion. frame (true) or not (false). This 4-519 © National Instruments NI-XNET Hardware and Software Manual

585 Chapter 4 NI-XNET API for LabVIEW—XNET Convert.vi is a Boolean value that specifies the value of the preamble? in the frame header. payload preamble indicator If the frame is in the static segment, preamble? being true indicates the presence of a netw ork management vector at the beginning of the payload. The XNET Cluster FlexRay:Network Management Vector Length property specifies the number of bytes at the beginning. being true If the frame is in the dynamic segment, preamble? indicates the presence of a messag e ID at the beginning of the payload. The message ID is always 2 bytes in length. If preamble? is false, the payload does not contain a network management vector or a message ID. This field is ignored for conversion. chA is a Boolean value that specifies whether to transmit the frame on channel A (true) or not (false). This field is ignored for conversion. is a Boolean value that specifies whether to transmit the chB frame on channel B (true) or not (f alse). This field is ignored for conversion. is not used for conversion. You must set this element to echo? false. type is the frame type. type is not used for transmit, so you must leave this element uninitialized. All frame values are assumed to be the FlexRay Data type. Frames of FlexRay Data type contain payload data. The type is not transmitted based on this type. As FlexRay Null specified in the XNET Frame property, the FlexRay:Timing Type FlexRay null frame is transmitted when a cyclically timed frame does not have new data. timestamp represents absolute time using the LabVIEW absolute timestamp type. timestamp is not used for conversion. You must set this element to the default value, invalid (0). for FlexRay frames of type payload is the array of data bytes . FlexRay Data 4-520 NI-XNET Hardware and Software Manual ni.com

586 Chapter 4 NI-XNET API for LabVIEW—XNET Convert.vi The array size indicates the payloa d length of the frame value to transmit. According to the FlexRay protocol, the length range is 0–254. You can leave all other FlexRay frame cluster elements on, refer to the section for each uninitialized. For more informati mode. error in is the error cluster input (refer to Error Handling ). Outputs , provided for use with subsequent VIs. session out is the same as session in signal data y of signal values. Each signal returns a one-dimensional arra value is scaled, 64-bit floating point. Each array element corresponds to a signal configured for the session. The order of signals in the array correspo nds to the order in the session list. The data returns the most recent conver ted value for each signal. If multiple frames for a signal are input, only si gnal data from the most recent frame is returned. Here, most recent is defined by the order of the frames in the frame data array, not the timestamp. If no frame is input for the corr esponding signals, the XNET Signal Default Value is returned. For an example of how this data applies, refer to Conversion Mode . is the error cluster output (refer to ). error out Error Handling 4-521 © National Instruments NI-XNET Hardware and Software Manual

587 Chapter 4 NI-XNET API for LabVIEW—XNET Convert.vi XNET Convert (Frame LIN to Signal).vi Purpose Converts between NI-XNET LIN frame data and signals. Format Inputs session in is the session to read. This session is returned from XNET Create Session.vi . The session mode must be Conversion. frame data provides the array of LabVIEW clusters. Each array element corresponds to a frame value to convert. The data you write is converted to si gnal values in the order you provide them. Only the latest signal value is returned. Conversion Mode For an example of how this data applies, refer to . The elements of each cluster are speci fic to the LIN protocol. For more information, refer to Appendix C, Summary of the LIN Standard , or the LIN protocol specification. The cluster elements are: is not used for transmit. You must set this element to 0. identifier Each frame is identified based on the list of frames or signals provided for the session. The actual identifier to transmit is taken from the database (frame and sche dule properties). Therefore, this identifier in the frame value is ignored. event slot? is not used for transmit. You must set this element to false. The currently running schedule is used to map the specific frame to a corresponding schedule entry (slot). The schedule entry itself determines whether the slot is unconditional, sporadic, or event triggered. 4-522 NI-XNET Hardware and Software Manual ni.com

588 Chapter 4 NI-XNET API for LabVIEW—XNET Convert.vi is not used for transmit. You must set this element to 0. event ID is not used for conversion. You must set this element to echo? false. type is the frame type (decimal value in parentheses): LIN Data (64) The LIN data frame contains payload data. This is currently the only frame type for LIN. This value is ignored for conversion. represents absolute time using the LabVIEW absolute timestamp timestamp type. timestamp is not used for conversion. You must set this element to the default value, invalid (0). payload is the array of data byt es for a LIN data frame. The array size indicates the payloa d length of the frame value to transmit. According to the LIN protocol, the payload length range is 0–8. For more information, refer to the section for each mode. Error Handling is the error cluster input (refer to error in ). Outputs is the same as session in , provided for use with subsequent VIs. session out signal data returns a one-dimensional arra y of signal values. Each signal value is scaled, 64-bit floating point. Each array element corresponds to a signal configured for the session. The order of signals in the array correspo nds to the order in the session list. The data returns the most recent conver ted value for each signal. If multiple frames for a signal are input, only si gnal data from the most recent frame is returned. Here, most recent is defined by the order of the frames in the frame data array, not the timestamp. If no frame is input for the corr esponding signals, the XNET Signal Default Value is returned. For an example of how this data applies, refer to Conversion Mode . ). Error Handling error out is the error cluster output (refer to 4-523 © National Instruments NI-XNET Hardware and Software Manual

589 Chapter 4 NI-XNET API for LabVIEW—XNET Convert.vi XNET Convert (Frame Raw to Signal).vi Purpose Converts between NI-XNET raw frame data and signals. Format Inputs is the session to read. This session is returned from XNET session in Create Session.vi . The session mode must be Conversion. frame data provides the array of bytes, representing frames to transmit. The raw bytes encode one or more frames using the . Raw Frame Format This frame format is the same for read and write of raw data and also is used for log file examples. For information about which elements of the raw frame are applicable, refer to the XNET Convert.vi instance for the protocol in use ( XNET XNET Convert (Frame FlexRay to , Convert (Frame CAN to Signal).vi Signal).vi , or ). XNET Convert (Frame LIN to Signal).vi Conversion Mode . For an example of how this data applies, refer to is the error cluster input (refer to Error Handling ). error in Outputs session out is the same as session in , provided for use with subsequent VIs. signal data returns a one-dimensional arra y of signal values. Each signal value is scaled, 64-bit floating point. Each array element corresponds to a signal configured for the session. The order of signals in the array correspo nds to the order in the session list. The data returns the most recent conver ted value for each signal. If multiple frames for a signal are input, only si gnal data from the most recent frame is 4-524 NI-XNET Hardware and Software Manual ni.com

590 Chapter 4 NI-XNET API for LabVIEW—XNET Convert.vi returned. Here, most recent is defined by the order of the frames in the frame data array, not the timestamp. Default esponding signals, the XNET Signal If no frame is input for the corr Value is returned. For an example of how this data applies, refer to Conversion Mode . Error Handling error out is the error cluster output (refer to ). 4-525 © National Instruments NI-XNET Hardware and Software Manual

591 Chapter 4 NI-XNET API for LabVIEW—XNET Convert.vi XNET Convert (Signal to Frame CAN).vi Purpose Converts between NI-XNET signals and CAN frame data. Format Inputs session in is the session to read. This session is returned from XNET Create Session.vi . The session mode must be Conversion. signal data returns a one-dimensional arra y of signal values. Each signal value is scaled, 64-bit floating point. Each array element corresponds to a signal configured for the session. The order of signals in the array correspo nds to the order in the session list. The data provides the value for th e next conversion of each signal. For an example of how this data applies, refer to . Conversion Mode is the error cluster input (refer to Error Handling ). error in Outputs session out is the same as session in , provided for use with subsequent VIs. returns the array of LabVIEW clusters. frame data Each array element corresponds to a frame the session converted. The elements of each cluster are speci fic to the CAN protocol. For more , or the information, refer to Appendix A, Summary of the CAN Standard CAN protocol specification. The cluster elements are: identifier is the CAN frame arbitration identifier. is false, the identifier uses standard format, so 11 bits extended? If of this identifier are valid. 4-526 NI-XNET Hardware and Software Manual ni.com

592 Chapter 4 NI-XNET API for LabVIEW—XNET Convert.vi If extended? is true, the identifier uses extended format, so 29 bits of this identifier are valid. extended? is a Boolean value that determines whether the identifier uses extended format (t rue) or standard format (false). is a Boolean value that determines whether the frame was echo? an echo of a successful transmit (true), or received from the network (false). For conversion, it is always set to false. type is the frame type (decimal value in parentheses): payload • CAN Data (0) : The CAN data frame contains data. This is the most commonly used frame type for CAN. : A CAN remote frame. An ECU transmits a • CAN Remote (1) CAN remote frame to request data for the corresponding identifier . Your application can respond by writing a CAN data identifier . This value is not meaningful, as a frame for the remote frame does not contain any data to convert. timestamp represents the absolute time when the XNET interface received the frame (end of frame) , accurate to microseconds. The timestamp returned by the conversion is always invalid (0). payload is the array of data bytes for the CAN data frame. The array size indicates the recei ved frame value payload length. According to the CAN protocol, this payload length range is 0–8. For CAN FD, the range can be 0–8, 12, 16, 20, 24, 32, 48, or 64. of For a received remote frame ( type CAN Remote ), the payload length in the frame value payload bytes specifies the number of requested. This payload length is provided to your application by filling payload with the requested number of bytes. Your application can use the payload array size, but you must ignore the actual values in the payload bytes. is the error cluster output (refer to ). Error Handling error out 4-527 © National Instruments NI-XNET Hardware and Software Manual

593 Chapter 4 NI-XNET API for LabVIEW—XNET Convert.vi XNET Convert (Signal to Frame FlexRay).vi Purpose Converts between NI-XNET signals and FlexRay frame data. Format Inputs session in is the session to read. This session is returned from XNET Create Session.vi . The session mode must be Conversion. signal data returns a one-dimensional arra y of signal values. Each signal value is scaled, 64-bit floating point. Each array element corresponds to a signal configured for the session. The order of signals in the array correspo nds to the order in the session list. The data provides the value for th e next conversion of each signal. For an example of how this data applies, refer to . Conversion Mode error in Error Handling ). is the error cluster input (refer to Outputs session out is the same as session in , provided for use with subsequent VIs. frame data returns the array of LabVIEW clusters. Each array element corresponds to a frame the session converted. c to the FlexRay protocol. For more The elements of each cluster are specifi , or the information, refer to Appendix B, Summary of the FlexRay Standard FlexRay Protocol Specification . The cluster elements are: within the FlexRay cycle. slot specifies the slot number specifies the cycle number. cycle count 4-528 NI-XNET Hardware and Software Manual ni.com

594 Chapter 4 NI-XNET API for LabVIEW—XNET Convert.vi The FlexRay cycle count increments from 0 to 63, then rolls over back to 0. For conversion, this is always set to 0. startup? is a Boolean value that specifies whether the frame is a startup frame (true) or not (false). This field is set to false by conversion. is a Boolean value that specifies whether the frame is a sync sync? frame (true) or not (false). This field is set to false by conversion. preamble? is a Boolean value that specifies the value of the payload preamble indicator in the frame header. If the frame is in the static segment, preamble? being true ork management vector at the indicates the presence of a netw FlexRay:Network beginning of the payload. The XNET Cluster Management Vector Length property specifies the number of bytes at the beginning. being true If the frame is in the dynamic segment, preamble? indicates the presence of a messag e ID at the beginning of the payload. The message ID is always 2 bytes in length. If is false, the payload does not contain a network preamble? management vector or a message ID. This field is set to false by conversion. chA is a Boolean value that specifies whether the frame was received on channel A (true) or not (false). This field is set to false by conversion. chB is a Boolean value that specifies whether the frame was received on channel B (true) or not (f alse). This field is set to false by conversion. is a Boolean value that determines whether the frame was echo? an echo of a successful transmit (true), or received from the network (false). 4-529 © National Instruments NI-XNET Hardware and Software Manual

595 Chapter 4 NI-XNET API for LabVIEW—XNET Convert.vi type is the frame type (decimal value in parentheses): : FlexRay data frame. The frame contains • FlexRay Data (32) payload data. This is the most commonly used frame type for FlexRay. All elements in the frame are applicable. represents the absolute time when the XNET interface timestamp , accurate to microseconds. The received the frame (end of frame) timestamp returned by the conversion is always invalid (0). payload is the array of data bytes for FlexRay frames of type or FlexRay Data FlexRay Null. The array size indicates the receiv ed frame value payload length. According to the FlexRay protocol, this length range is 0–254. ). is the error cluster output (refer to Error Handling error out 4-530 NI-XNET Hardware and Software Manual ni.com

596 Chapter 4 NI-XNET API for LabVIEW—XNET Convert.vi XNET Convert (Signal to Frame LIN).vi Purpose Converts between NI-XNET signals and LIN frame data. Format Inputs is the session to read. This session is returned from XNET session in Create Session.vi . The session mode must be Conversion. signal data returns a one-dimensional arra y of signal values. Each signal value is scaled, 64-bit floating point. Each array element corresponds to a signal configured for the session. The order of signals in the array correspo nds to the order in the session list. e next conversion of each signal. The data provides the value for th . Conversion Mode For an example of how this data applies, refer to error in is the error cluster input (refer to Error Handling ). Outputs session out is the same as session in , provided for use with subsequent VIs. frame data returns the array of LabVIEW clusters. Each array element corresponds to a frame the session converted. The elements of each cluster are spec ific to the LIN protocol. For more Summary of the LIN Standard information, refer to Appendix C, , or the n LIN protocol specificatio . 4-531 © National Instruments NI-XNET Hardware and Software Manual

597 Chapter 4 NI-XNET API for LabVIEW—XNET Convert.vi The cluster elements are: identifier is the identifier received within the frame’s header. The identifier is a number from 0 to 63. If the schedule entry (slot) is unconditional or sporadic, this identifies the payload data (LIN frame). If the schedule entry is event triggered, this identifies the schedule entry itself, and the protected ID contained in the fi rst payload byte identifies the payload. event slot? is not used. This element is false. event ID is not used. This element is 0. is a Boolean value that determines whether the frame was echo? an echo of a successful transmit (true), or received from the network (false). For conversion, it is always set to false. type is the frame type (decimal value in parentheses): • LIN Data (64) : The LIN data frame contains payload data. This is currently the only frame type for LIN. For conversion, this is always set to false. timestamp represents the absolute time when the XNET interface received the frame (end of frame) , accurate to microseconds. The timestamp returned by the conversion is always invalid (0). payload is the array of data byt es for the LIN data frame. The array size indicates the received frame’s payload length. According to the LIN protocol, this payload is 0–8 bytes in length. is the error cluster output (refer to ). Error Handling error out 4-532 NI-XNET Hardware and Software Manual ni.com

598 Chapter 4 NI-XNET API for LabVIEW—XNET Convert.vi XNET Convert (Signal to Frame Raw).vi Purpose Converts between NI-XNET signals and raw frame data. Format Inputs session in XNET is the session to read. This session is returned from Create Session.vi . The session mode must be Conversion. signal data returns a one-dimensional arra y of signal values. Each signal value is scaled, 64-bit floating point. Each array element corresponds to a signal configured for the session. The nds to the order in the session list. order of signals in the array correspo The data provides the value for th e next conversion of each signal. For an example of how this data applies, refer to Conversion Mode . ). Error Handling error in is the error cluster input (refer to Outputs , provided for use with subsequent VIs. session out is the same as session in frame data returns an array of bytes. The raw bytes encode one or more frames using the Raw Frame Format . This frame format is the same for read and write of raw data, and it is also used for log file examples. The data always returns complete frames. 4-533 © National Instruments NI-XNET Hardware and Software Manual

599 Chapter 4 NI-XNET API for LabVIEW—XNET Convert.vi For information about which elements of the raw frame are applicable, refer to the frame read fo r the protocol in use ( XNET Convert (Signal to XNET Convert (Signal to Frame FlexRay).vi , , or Frame CAN).vi XNET Convert (Signal to Frame LIN).vi ). Conversion Mode For an example of how this data applies, refer to . ). is the error cluster output (refer to Error Handling error out 4-534 NI-XNET Hardware and Software Manual ni.com

600 Chapter 4 NI-XNET API for LabVIEW—Controls Palette Controls Palette This palette provides front panel controls for NI-XNET. You drag a control to the front panel of your VI. Typically, you use I/O name controls to select a name during configuration, and the name is ior to running a used at run time. For example, pr XNET Signal I/O Name VI, you can use controls to select signals to re ad. When the user runs the VI, the selected signals are passed to XNET Create Session.vi , followed by calls to XNET Read.vi to read and display data for the selected signals. As an alternative, you also can use I/O name cont rols to select a name at run time. This applies when the VI always is running for the end user, and the VI uses distinct stages for configuration and I/O. Using the pr evious example, the user clicks XNET Signal I/O Name button to Go , the user clicks a iguration stage. Next controls to select signals during the conf proceed to the I/O stage, in which XNET Create Session.vi XNET Read.vi are called. and XNET Session Control This control provides the contro l form of the XNET Session I/O name. You drag a control to of the VI can select a name. For a complete the front panel of your VI, so that the user description, refer to XNET Session I/O Name . Database Controls XNET Database Control This control provides the control form of the XNET Database I/O name. You drag a control to the front panel of your VI, so that the user of the VI can select a name. For a complete description, refer to XNET Database I/O Name . XNET Cluster Control This control provides the control form of the XNET Cluster I/O name. You drag a control to the front panel of your VI, so that the user of the VI can select a name. For a complete description, refer to XNET Cluster I/O Name . XNET ECU Control This control provides the control form of the XNET ECU I/O name. You drag a control to the front panel of your VI, so that the user of the VI can select a name. For a complete description, XNET ECU I/O Name refer to . 4-535 © National Instruments NI-XNET Hardware and Software Manual

601 Chapter 4 NI-XNET API for LabVIEW—System Controls XNET Frame Control This control provides the control form of th e XNET Frame I/O name. You drag a control to the front panel of your VI, so that the user of the VI can select a name. For a complete XNET Frame I/O Name description, refer to . XNET Signal Control This control provides the control form of the XNET Signal I/O name. You drag a control to the front panel of your VI, so that the user of the VI can select a name. For a complete description, refer to XNET Signal I/O Name . XNET LIN Schedule Control the XNET LIN Schedule I/O name. You drag a This control provides the control form of the user of the VI can select a name. For a control to the front panel of your VI, so that complete description, refer to . XNET LIN Schedule I/O Name XNET LIN Schedule Entry Control This control provides the control form of the XNET LIN Schedule Entry I/O name. You drag a control to the front panel of your VI, so that the user of the VI can select a name. For a complete description, refer to XNET LIN Schedule Entry I/O Name . System Controls XNET Interface Control This control provides the cont rol form of the XNET Interface I/O name. You drag a control to the front panel of your VI, so that the user of the VI can select a name. For a complete description, refer to XNET Interface I/O Name . XNET Terminal Control This control provides the control form of th e XNET Terminal I/O name. You drag a control to the front panel of your VI, so that the user of the VI can select a name. For a complete . description, refer to XNET Terminal I/O Name 4-536 NI-XNET Hardware and Software Manual ni.com

602 Chapter 4 LabVIEW—Additional Topics NI-XNET API for Additional Topics This section includes additional CAN, FlexRay, and LIN-related information. Overall Creating a Built Application NI-XNET supports creation of a built application using a LabVIEW project. For a LabVIEW Real-Time (RT) target, the built application typically is used as a startup tion for LabVIEW RT, refer to application. For information about creating a built applica . Using LabVIEW Real-Time For a Windows target (My Computer), th e built application is an executable ( .exe ). You typically distribute the executable to multiple end users, which means you copy to multiple computers (targets). This section describes creating a built ap plication for Windows that uses NI-XNET. , then Create the executable by right-clicking Build Specifications under My Computer select . New»Application (EXE) Sessions If you created NI-XNET sessions under My Computer , the configuration for those sessions is generated to the following text file: nixnetSession.txt This text file is in the same folder as the executable ( .exe ). You must include this text file as part of your distribution. Copy this text file along with the , always to the same folder. .exe If you create sessions at run time using , those sessions are XNET Create Session.vi standalone (no text file required). Databases ), that database is standalone (no If your application uses the in-memory database ( :memory: file or alias required). For more information about the in-memory database, refer to the Create . Database Programming in Memory section of a filepath (not alias), you must ensure that If your application accesses a database file using ery computer. Because LabVIEW uses absolute the file exists at the same filepath on ev 4-537 © National Instruments NI-XNET Hardware and Software Manual

603 Chapter 4 LabVIEW—Additional Topics NI-XNET API for c:\MyDatabases\Database5.dbc filepaths (for example, ), this implies that every computer that runs the executable must use the same file system layout. using an alias, you must add the alias using If your application accesses a database file XNET Database Add Alias.vi . You can use this VI as part of an installation process or call it within the executable itself. Using an alias provides mo re flexibility than a filepath. For example, your application can check for the required file at a likely filepath and add the alias if found, or otherwise pop up a dialog for the end user to browse to the correct filepath (then add an alias). Cyclic and Event Timing For all embedded network protocols (for example, CAN, LIN, and FlexRay), the transmit of a specific frame is classifi ed as one of the following: • Cyclic : The frame transmits at a cyclic (perio dic) rate, regardless of whether the application has updated its payload data. The advantage of cyclic behavior is that the application does not need to worry about when to transmit, yet data changes arrive at other ECUs within a well-defined deadline. • Event : The frame transmits when a specific event occurs. This event often is simply that e. The advantage is other events are possibl the application updated the payload data, but that the frame transmits on the network only as needed. The following sections describe how the cycl ic and event concept apply to each protocol. Within NI-XNET, a Cyclic frame begins transmit as soon as the session starts, regardless of whether you called XNET Write.vi . The call to XNET Write.vi is the event that drives an Event frame transmit. CAN For each frame, the XNET Frame CAN:Timing Type property determines whether the network transfer is cyclic or event: • : This is typical Cyclic frame behavior. Cyclic Data • Event Data : This is typical Event frame behavior. • Cyclic Remote : Because one ECU in the network transmits the CAN remote frame at a cyclic (periodic) rate, the resulting CAN data frame also is cyclic. • Event Remote : One ECU in the network transmits the CAN remote frame based on an esponding CAN data frame. In NI-XNET, event. Another ECU responds with the corr generates the event to transmit the CAN remote frame. XNET Write.vi 4-538 NI-XNET Hardware and Software Manual ni.com

604 Chapter 4 LabVIEW—Additional Topics NI-XNET API for FlexRay For each frame, the XNET Frame property determ ines whether the FlexRay:Timing Type network transfer is cyclic or event: • : No null frame transmits, so this is typical Cyclic frame Cyclic (in static segment) behavior. • Event (in static segment) : The null frame indicates no event. • Cyclic (in dynamic segment) : The frame transmits each FlexRay cycle. This configuration is not common for the dynamic segment, which typically is for Event frames only. • Event (in dynamic segment) : This is typical Event frame behavior. LIN As described in the Using LIN section, the currently running schedule entries determine each LIN frame’s timing. In each sche dule entry, the master transmits a single frame header, and the payload of one (or more) frames can follow. For each schedule entry, the XNET LIN Schedule Entry Type property determines how the Run Mode transmit. The schedule Frames also contributes to the cyclic or event associated behavior. Cyclic: Unconditional type, Continuous run mode : This is typical Cyclic frame • behavior. : Although the frame transmits • Event: Unconditional type, Once run mode unconditionally, the schedule runs once based on an event, so this is Event frame behavior. In NI-XNET, XNET Write (State LIN Schedule Change).vi changes the mode to the run-once schedule. This effectiv ely generates the event to transmit the LIN frame. : In this schedule entry, the master can transmit one of multiple • Event: Sporadic type Event-driven frames. In NI-XNET, writes signal or frame values to XNET Write.vi try itself is Event, this behavior applies generate the event to transmit. Because the en regardless of the schedule’s run mode. : In this schedule entry, multiple slave ECUs can transmit • Event: Event- triggered type t-driven frame. In NI-XNET, in the entry, each using an Even XNET Write.vi writes signal or frame values to generate the event to transmit. Because the entry itself is Event, this behavior applies regardless of the schedule’s run mode. Error Handling within the execution of a node in refers to a problem that occurs error In NI-XNET, the term fault the block diagram (VI or property node). The term refers to a problem that occurs asynchronously to execution of an NI-XNET node. For example, an invalid parameter to 4-539 © National Instruments NI-XNET Hardware and Software Manual

605 Chapter 4 LabVIEW—Additional Topics NI-XNET API for is an error, but a communication problem on the network is a fault. For more XNET Read.vi Fault Handling . information about faults, refer to ss error informati on through each VI. LabVIEW uses error clusters to pa error in and error out clusters in each VI and property node. The NI-XNET uses the elements of these clusters are: status is true if error occurred or fa lse if success or warning occurred. code r or warning. A value of 0 means is a number that identifies the erro success. A negative value means error: The VI did not perform the intended operation. A positive value means warning: The VI performed the intended operation, but something occurred that may require your attention. For a description of the code, right-click the error cluster and select Explain Error or Explain Warning . You also can wire the error cluster to Simple Error Handler.vi to obtain the description at runtime. e error or warning occurred. Identifies the VI where th source For most NI-XNET VIs, if indicates an error, the VI passes the error information to error in error out and does not perform the intended operation. In other words, NI-XNET VIs do not execute under error conditions. The exceptions to this behavior are XNET Clear.vi and XNET Database Close.vi . These VIs always perform the intended operation of closing or otherwise cleaning up, even when error in indicates an error. If error in indicates success or warning, the NI-XNE T VI executes and returns the result of its operation to error out . The cluster is an optional input to a VI, with a default value of no error ( status false error in and code 0). Fault Handling In NI-XNET, the term error refers to a problem that occurs within the execution of a node in the block diagram (VI or property node). The term fault refers to a problem that occurs asynchronously to execution of an NI-XNET node. For example, passing an invalid session to a VI is an error, but a communication problem on the network is a fault. For more information about errors, refer to Error Handling . 4-540 NI-XNET Hardware and Software Manual ni.com

606 Chapter 4 LabVIEW—Additional Topics NI-XNET API for Examples of faults include: • dards each specify mechanisms to detect The CAN, FlexRay, and LIN protocol stan These problems are reflected in the communication problems on the network. communication state and other information. • If you pass invalid data to XNET Write.vi , in some cases the problem cannot be detected until the data is about to be transmitted. Because the transmission occurs after XNET Write.vi returns, this is reported as a fault. NI-XNET reports faults from a special XNET Read.vi instance for the co mmunication state. For CAN, this is XNET Read (State CAN Comm).vi , for FlexRay this is XNET Read (State FlexRay Comm).vi , and for LIN this is XNET Read (State LIN Comm).vi . The information returned from these VIs is not limited to faults. Each VI provides information XNET Read.vi cation on the network. Because about the current state of communi executes quickly, it often is useful within the primary l oop of your application to ascertain the current network state. Each XNET Read.vi returns a cluster with various indicat ors. Most of the indicators provide state information that the protocol specifies, including faults (communication stopped). Faults . fault? specific to NI-XNET are reported in fault? and fault code of status is similar to the of a LabVIEW error cluster. a LabVIEW error cluster, and fault code is similar to the code To detect a fault without stopping the execution of your VIs, you read and interpret the communication state separately from the LabVIEW error cluster flow. For example, you may want to intentionally introduce noise into CAN cables to test how your ECU behaves when gure shows an example block diagram for this the CAN bus off state occurs. The following fi method. Figure 4-15. Restart on CAN Bus Off State 4-541 © National Instruments NI-XNET Hardware and Software Manual

607 Chapter 4 NI-XNET API for LabVIEW—Additional Topics The block diagram detects the CAN bus off st ate, which means that communication stopped due to numerous problems on the bus. When C AN bus off state is detected, the block diagram terface. It then waits for the interface to be increments a count and restarts the NI-XNET in reintegrated with the bus before continuing. This process of reintegrating into a CAN bus after going bus off is known as bus off recovery. Becau se the CAN bus off fault was not propagated as an error, the test continues to execute. To detect a fault and propagate it to an error to break the LabVIEW flow, use a diagram similar to the following example. Propagating CAN Faults to an Error Figure 4-16. The block diagram in the figure above first check s for CAN bus off state, which indicates that communication stopped due to a serious proble m in the CAN protocol state machine (data link layer). Next, the block diagram checks for a fault in the CAN transceiver (physical layer). NI-XNET. If any of these three faults are Finally, the block diagram checks for a fault in detected, it overwrites the previous error in the standard LabVIEW error cluster. If a fault or error occurs, execution of s ubsequent VIs ceases, effectively stopping the LabVIEW application execution. Multiplexed Signals Multiplexed signals do not appear in every instan ce of a frame; they appear only if the frame indicates this. For this reason, a frame can contain a mult iplexer signal and several subframes. The multiplexer signal is at most 16 bits long and contains an unsigned integer number that 4-542 NI-XNET Hardware and Software Manual ni.com

608 Chapter 4 NI-XNET API for LabVIEW—Additional Topics identifies the subframe instance in the inst ance of a frame. The subframes contain the multiplexed signals. This means the frame signal content is not fi xed (static), but can change depending on the multiplexer signal (dynamic) value. atic and a dynamic part. A frame can contain both a st Creating Multiplexed Signals In the API Creating multiplexed signals in the API is a two-step process: 1. Create the multiplexer signal and subframe s as children of the frame object. The subframes are assigned the mode value; that is, the value of the multiplexer signal for which this subframe becomes active. als as children of their respective subframes. This Create the multiplexed sign 2. automatically assigns the signals as dynamic signals to the subframe’s parent frame. In the NI-XNET Database Editor You create multiplexed signals simply by chan ging their Signal Type to Multiplexed and assigning them mode values. The Database Editor handles subframe manipulation completely behind the scenes. Reading Multiplexed Signals rt. Because the You can read multiplexed signals like static signals without an y additional effo frame read also contains the mu ltiplexer signal, the NI-XNET dr iver can decide which signals are present in the frame and return new values for only those signals. Writing Multiplexed Signals Writing multiplexed signals needs additional consideration. As writing signals results in a frame being created and sent over the network, writing multiplexed signals requires the multiplexer signal be part of the writing session. This is needed for the NI-XNET driver to decide which set of dynamic signals a certain frame contains. Only the subframe dynamic signals selected with the multiplexer signal value are written to the frame; the values for the that frame are ignored. other dynamic signals of Support for Multiplexed Signals r CAN only. FlexRay does not support them. Multiplexed signals are currently supported fo 4-543 © National Instruments NI-XNET Hardware and Software Manual

609 Chapter 4 NI-XNET API for LabVIEW—Additional Topics Raw Frame Format file format, This section describes the raw data format for frames. The TDMS XNET Read (Frame Raw).vi , and XNET Write (Frame Raw).vi use this format. monstrate access to log files. The raw frame The raw frame format is for examples that de format is ideal for log files, because you can transfer the data between NI-XNET and the file with very little conversion. Refer to the NI-XNET logfile examples for VIs that convert raw frame data to/from LabVIEW clusters for CAN, FlexRay, or LIN frames. frames encoded in a se quence of bytes. Each The raw frame format consists of one or more frame is encoded as one Base Unit, followed by zero or more Payload Units. Base Unit In the following table, Byte Offset refers to the offset from the frame start. For example, if the second frame is in bytes 24–47, the second frame first frame is in raw data bytes 0–23, and the Identifier starts at byte 32 (24 + Byte Offset 8). 4-544 NI-XNET Hardware and Software Manual ni.com

610 Chapter 4 NI-XNET API for LabVIEW—Additional Topics Table 4-3. Base Unit Elements Element Byte Offset Description Timestamp 64-bit timestamp in 100 ns increments. 0 to 7 The timestamp format is ab solute. The 64-bit element contains the number of 100 ns inte rvals that have elapsed since 12:00 a.m. January 1 1601 Coor dinated Universal Time (UTC). This element contains a 64-bit unsigned integer (U64) in native byte order. For little-endian computing platforms (for example, Windows), Byte Offset 0 is the least significant byte. For big-endian computing platforms (for example, CompactRIO with a PowerPC), Byte Offset 0 is the most significant byte. The LabVIEW absolute timestamp data type is different than this U64 timestamp. NI-XNET includes a pair of VIs to convert between this U64 timestamp format and the LabVIEW timestamp format. Th e NI-XNET VIs handle all time format and byte order aspects. For more information, refer to the NI-XNET examples for logfile access. Identifier The frame identifier. 8 to 11 This element contains a 32-bit unsigned integer (u32) in native byte order. When Type specifies a CAN frame, bit 29 (hex 20000000) indicates the CAN identifier format: set for extended, clear for standard. If bit 29 is clear, the lower 11 bits (0–10) contain the CAN frame identifier. If bit 29 is set, the lower 29 bits (0–28) contain the CAN frame identifier. When Type specifies a FlexRay frame, the lower 16 bits contain the slot number. e, this element contains a When Type specifies a LIN fram number in the range 0–63 (inclusive). This number is the LIN frame’s ID (unprotected). All unused bits are 0. 4-545 © National Instruments NI-XNET Hardware and Software Manual

611 Chapter 4 LabVIEW—Additional Topics NI-XNET API for Base Unit Elements (Continued) Table 4-3. Description Byte Offset Element The frame type. Type 12 This element specifies the fundamental frame type. The Identifier, Flag, and Info elemen t interpretation is different for each type. The upper 4 bits of this elemen t specify the protocol. The valid values in decimal are: 0 CAN 2 FlexRay 4 LIN 14 Special The lower 4 bits of this element contain the specific type. For information about the specific CAN Type values, refer to XNET Read (Frame CAN).vi . For information about the specific FlexRay Type values, refer . to XNET Read (Frame FlexRay).vi For information about the specific LIN Type values, refer to . XNET Read (Frame LIN).vi related to the protocol or bus Special values specify features not traffic. For more information about special frames, refer to Special Frames . ni.com 4-546 NI-XNET Hardware and Software Manual

612 Chapter 4 LabVIEW—Additional Topics NI-XNET API for Base Unit Elements (Continued) Table 4-3. Description Byte Offset Element 13 Eight Boolean flags that Flags qualify the frame type. dependent (supported in CAN, Bit 7 (hex 80) is protocol in FlexRay, and LIN frames). If se t, the frame is echoed (returned from XNET Read.vi after NI-XNET transmitted on the network). If clear, the frame was received from the network (from a remote ECU). For FlexRay frames: • Bit 0 is set if the frame is a Startup frame • Bit 1 is set if the frame is a Sync frame • Bit 2 specifies the frame Preamble bit • Bit 4 specifies if the fr ame transfers on Channel A • Bit 5 specifies if the fr ame transfers on Channel B For LIN frames: ed in an event-triggered entry • Bit 0 is set if the frame occurr (slot). When bit 0 is set, the Info element contains the event-triggered frame ID, and the Identifier element contains the Unconditional ID from the first payload byte. All unused bits are zero. 14 Information that qualifies the frame type. Info This element is not used for CAN. For FlexRay frames, this element provides the frame cycle count (0–63). Flags element is clear, the Info For LIN frames, if bit 0 of the element is unused (0 ). If bit 0 of the Flags element is set Info element contains the (event-triggered entry), the event-triggered frame ID, and th e Identifier element contains the Unconditional ID from the first payload byte. NI-XNET Hardware and Software Manual 4-547 National Instruments ©

613 Chapter 4 LabVIEW—Additional Topics NI-XNET API for Base Unit Elements (Continued) Table 4-3. Description Byte Offset Element The PayloadLength indicates the number of valid data bytes in PayloadLength 15 Payload. For standard CAN and LIN frames, PayloadLength cannot exceed 8. Because this base un it always contains 8 bytes of payload data, the entire frame is contained in the base unit, and no additional payload units exist. For CAN FD frames, PayloadLength can be 0–8, 12, 16, 20, 24, 32, 48, or 64. For FlexRay frames, PayloadLength is 0–254 bytes. If PayloadLength is 0–8, only the base unit exists. If PayloadLength is 9 or greater, one or more payload units follow the base unit. Additional payload units are provided in optimize efficiency for DMA increments of 8 bytes, to transfers. For example, if PayloadLength is 12, bytes 0–7 are in the base unit Payload, bytes 8–11 are in the first byte of the next payload unit, and the last 4 bytes of the next payload unit are ignored. In other words, each raw data fr ame can vary in length. You can bytes) using the following calculate each frame size (in pseudocode: U16 FrameSize // maximum 272 for largest FlexRay frame FrameSize = 24; // 24 byte base unit if (PayloadLength > 8) FrameSize = FrameSize + (U16)(PayloadLength - 1) AND 0xFFF8; The last pseudocode line subt racts 1 and truncates to the nearest multiple of 8 (using bitwise AND). This adds bytes for additional payload units. For example, PayloadLength of 9 through 16 requires one additional payload unit of 8 bytes. The NI-XNET example code helps you handle the encoding details. variable-length frame Payload 16 to 23 This element always uses 8 bytes in the logfile, but PayloadLength determines the number of valid bytes. ni.com 4-548 NI-XNET Hardware and Software Manual

614 Chapter 4 NI-XNET API for LabVIEW—Additional Topics Payload Unit The base unit PayloadLength element determines the number of additional payload units (0–31). Payload Unit Elements Table 4-4. Element Description Byte Offset Payload 0 to 7 This element always uses 8 bytes in the logfile, but PayloadLength determines the number of valid bytes. Special Frames The NI-XNET driver offers a few special fram es not directly used in bus communication. Delay Frame A Delay frame is used during replay. When a fr ame with a Delay frame t ype is in the stream property is set to a replay mode, the Interface:Output Stream Timing output queue while the ds are as follows: The Delay frame fiel hardware delays for the requested time. Element Description 0 (Ignored) Identifier Extended False (Ignored) Echo False (Ignored) Type Delay Timestamp Amount of time to delay. Note that this is not an absolute time and is not related to any other time in the replay frames. A time of 0.25 (that is, LabVIEW absolute time of 6:00:00.250PM 12/31/1903) will delay 250 ms. Payload Length 0 Ignored Payload Log Trigger Frame A Log Trigger frame is a special frame that a Frame Stream Input session can receive. This ected on an external connection (PXI_Trig or frame is generated when a rising edge is det ware to log this frame, you must use FrontPanel trigger). To enable the hard XNET Connect to connect the external connection to the internal LogTrigger terminal. A Log Terminals.vi NI-XNET Hardware and Software Manual 4-549 National Instruments ©

615 Chapter 4 NI-XNET API for LabVIEW—Additional Topics Trigger frame is applicable to CAN, LIN, and FlexRay. The Log Trigger Frame fields are as follows: CAN Frame Description Element identifier 0 False extended? echo? False Log Trigger type Time when the trigger occurred timestamp payload length 0 (may increase in the future) N/A payload LIN Frame Element Description identifier 0 False event slot? 0 event ID echo? False type Log Trigger timestamp Time when the trigger occurred 0 (may increase in the future) payload length N/A payload FlexRay Frame Element Description slot 0 cycle count 0 NI-XNET Hardware and Software Manual 4-550 ni.com

616 Chapter 4 LabVIEW—Additional Topics NI-XNET API for Element Description False startup? False sync? False preamble? False ch A False ch B False echo? Log Trigger Type Timestamp Time when the trigger occurred Payload Length 0 (may increase in the future) N/A Payload Start Trigger Frame A Start Trigger frame is a special frame that a Frame Stream Input session can receive. This for more frame is generated when the interface is started. (Refer to Start Interface Interface:Start log this frame, you must enable the information.) To enable the hardware to property. A Start Trigger frame is applicable to CAN, LIN, Input Stream? Trigger Frames to art Trigger frame are as follows: and FlexRay. The fields of the St CAN Frame Element Description identifier 0 False extended? echo? False type Start Trigger timestamp Time when the interface started payload length 0 (may increase in the future) payload N/A National Instruments NI-XNET Hardware and Software Manual © 4-551

617 Chapter 4 NI-XNET API for LabVIEW—Additional Topics LIN Frame Element Description identifier 0 False event slot? event ID 0 echo? False type Start Trigger timestamp Time when the interface started payload length 0 (may increase in the future) N/A payload FlexRay Frame Description Element slot 0 cycle count 0 startup? False sync? False preamble? False ch A False ch B False echo? False Type Start Trigger Timestamp Time when the interface started Payload Length 0 (may increase in the future) Payload N/A 4-552 NI-XNET Hardware and Software Manual ni.com

618 Chapter 4 NI-XNET API for LabVIEW—Additional Topics Bus Error Frame A Bus Error frame is a special frame that a Frame Stream Input session can receive. This frame is generated when a bus error is detected on the hardware bus. To enable the hardware to log this frame, you must enable the property. es to Input Stream? Interface:Bus Error Fram A Bus Error frame is applicable to CAN and LIN. The fields of the Bus Error frame are as follows: CAN Frame Element Description identifier 0 False extended? echo? False CAN Bus Error type timestamp Time when the bus error was detected 5 (may increase in future) payload length Byte 0: CAN Comm State payload 0 = Error Active 1 = Error Passive 2 = Bus Off Byte 1: TX Error Counter Byte 2: RX Error Counter Byte 3: Detected Bus Error 0 = None (never returned) 1 = Stuff 2 = Form 3 = Ack 4 = Bit 1 5 = Bit 0 6 = CRC Byte 4: Transceiver Error? 0 = no error 1 = error 4-553 © National Instruments NI-XNET Hardware and Software Manual

619 Chapter 4 LabVIEW—Additional Topics NI-XNET API for LIN Frame Description Element identifier 0 False event slot? 0 event ID False echo? LIN Bus Error type timestamp Time when the bus error was detected payload length 5 (May increase in the future) payload Byte 0: LIN Comm State 0 = Idle 1 = Active 2 = Inactive Byte 1: Detected Bus Error 0 = None (never returned) 1 = UnknownId 2 = Form 3 = Framing 4 = Readback 5 = Timeout 6 = CRC Byte 2: Identifier on bus Byte 3: Received byte on bus Byte 4: Expected byte on bus Required Properties base, the object properties may be: When you create a new object in a data • Optional : The property has a default value after creation, and the ap plication does not need to set the property when the default value is desired for the session. Required r creation. An undefined required : The property has no default value afte • property returns an error from XNET Create Session.vi . A required property means you must provide a value for the prop erty after you create the object. 4-554 NI-XNET Hardware and Software Manual ni.com

620 Chapter 4 LabVIEW—Additional Topics NI-XNET API for The following NI-XNET object classes have no required properties: • Session • System • Device Interface • Database • •ECU • LIN Schedule This section lists all required properties. Properties with a protocol prefix (for example, ) in the property name apply only a session that uses the specified protocol. FlexRay: es the following properties: The Cluster object class requir 1 • Baud Rate • FlexRay:Action Point Offset • FlexRay:CAS Rx Low Max • FlexRay:Channels • FlexRay:Cluster Drift Damping • FlexRay:Cold Start Attempts • FlexRay:Cycle • FlexRay:Dynamic Slot Idle Phase • FlexRay:Listen Noise • FlexRay:Macro Per Cycle • FlexRay:Max Without Clock Correction Fatal • FlexRay:Max Without Clock Correction Passive • FlexRay:Minislot Action Point Offset • FlexRay:Minislot • FlexRay:Network Management Vector Length FlexRay:NIT • • FlexRay:Number of Minislots FlexRay:Number of Static Slots • • FlexRay:Offset Correction Start 1 For FlexRay, Baud Rate always is required. For CAN and LI N, when you use a Frame I/O St ream session, you can specify property. For CAN and Interface:Baud Rate Baud Rate using either the XNET Cluster Baud Rate property or XNET Session uster Baud Rate property is required. LIN with other session modes, the XNET Cl 4-555 © National Instruments NI-XNET Hardware and Software Manual

621 Chapter 4 LabVIEW—Additional Topics NI-XNET API for FlexRay:Payload Length Static • • FlexRay:Static Slot FlexRay:Symbol Window • • FlexRay:Sync Node Max • FlexRay:TSS Transmitter • FlexRay:Wakeup Symbol Rx Idle • FlexRay:Wakeup Symbol Rx Low • FlexRay:Wakeup Symbol Rx Window • FlexRay:Wakeup Symbol Tx Idle • FlexRay:Wakeup Symbol Tx Low • LIN:Tick The Frame object class requir es the following properties: FlexRay:Base Cycle • • FlexRay:Channel Assignment • FlexRay:Cycle Repetition • Identifier • Payload Length The Subframe object class requ ires the following property: • Multiplexer Value The Signal object class requires the following properties: Byte Order • • Data Type • Number of Bits • Start Bit The LIN Schedule Entry object class requires the following properties: • Delay • Event Identifier • Frames State Models The following figures show the state model for the NI-XNET session and the associated NI-XNET interface. 4-556 NI-XNET Hardware and Software Manual ni.com

622 Chapter 4 NI-XNET API for LabVIEW—Additional Topics The session controls the transfer of frame values between the interface (network) and the data structures that can be accessed us ing the API. In other words, th e session controls receive or transmit of specific fr ames for the session. The interface controls communicat ion on the physical network cluster. Multiple sessions can share the interface. For example, you can use one session for input on interface CAN1 and a second session for output on interface CAN1. XNET or XNET Read.vi ccur automatically when you call Although most state transitions o , you can perform a more specific transition using XNET Start.vi and XNET Write.vi Stop.vi . If you invoke a transition that has already is not repeated, and occurred, the transition no error is returned. Session State Model . For a description of each transition, For a description of each state, refer to Session States refer to . Session Transitions 4-557 © National Instruments NI-XNET Hardware and Software Manual

623 Chapter 4 NI-XNET API for LabVIEW—Additional Topics Interface Start Session Create Communicating Started Communicating Stopped Clear Stop Session Interface Not Communicating OR Set Session Stop Session Property Session State Model Figure 4-17. Interface State Model For a description of each state, refer to Interface States . For a description of each transition, . Interface Transitions refer to Comm State Start Interface Communicating Started Communicating Stopped Comm State Stop Interface Not communicating OR Set Interface Stop Interface Property Interface State Model Figure 4-18. Session States Stopped The session initially is created in the Stopped stat e. In the Stopped state, the session does not transfer frame values to or from the interface. While the session is Stopped, yo c to this session. You can set u can change properties specifi any property in the Session Property Node excep t those in the Interfa ce category (refer to ). Stopped in Interface States While the session is Started, y jects in the database, such as ou cannot change properties of ob frames or signals. The properties of these objec ts are committed when the session is created. ni.com 4-558 NI-XNET Hardware and Software Manual

624 Chapter 4 LabVIEW—Additional Topics NI-XNET API for Started In the Started state, the session is started, bu t is waiting for the associated interface to be started also. The interface must be communicatin g for the session to exchange data on the network. Started state is transitory in nature. When you call For most applications, the , XNET Read.vi XNET Write.vi , or XNET Start.vi using defaults, the interface is started along with the session. Once the interface is Communicating, the session automatically transitions to Communicating without interaction by your application. If you call XNET Start.vi with the scope of Se ssion Only, the interface is not started. You can use this advanced feature to prepare mul tiple sessions for the interface, then start communication for all sessions to gether by startin g the interface ( XNET Start.vi with scope of Interface Only). Communicating In the Communicating state, the session is communicating on the network with remote ECUs. Frame or signal values are received for an input session. Frame or signal values are transmitted for an output session. Your application accesses these values using XNET or Read.vi . XNET Write.vi Session Transitions Create When the session is created, the database, cluste r, and frame properties are committed to the interface. For this configuration to succeed, the interface must be in the Stopped state. There is one exception: You can create a Frame St ream Input session while the interface is communicating. There are two ways to create a session: • XNET Create Session.vi method : When your application calls XNET Create Session.vi , the session is created. To ensure that all sessions for the interface are created prior to start, you typically wire all calls to XNET Create Session.vi in sequence prior to the first use of XNET Read.vi or XNET Write.vi (for example, prior to the main loop). LabVIEW project method : Although you specify the session properties in the • LabVIEW project user interface, the session is not created at that time. When you run a VI that uses the session with an XNET node (property node or VI), the session is created. In addition, all other sessio ns in the LabVIEW project that use the same interface and cluster (database) are created at that time. This ensures th at all project-based sessions your application uses ar e created before the interface starts (for example, the first call to ). XNET Write.vi or XNET Read.vi 4-559 © National Instruments NI-XNET Hardware and Software Manual

625 Chapter 4 LabVIEW—Additional Topics NI-XNET API for Clear When the session is cleared, it is stopped (no longer communicates), and then all its resources are removed. There are two ways to clear a session: • Application stop method : The typical way to clear a session is to do nothing explicit in application stops execution, your application. When the NI-XNET automatically clears all sessions that application uses. When us ing the LabVIEW development environment, the application stops when the top-level VI goes idle, including when you select the LabVIEW abort button in that VI’s toolbar. When using an application built using a LabVIEW project, the application stops when the executable exits. : This clears the session explicitly. To change the properties of XNET Clear.vi method • XNET Clear.vi to change database objects that a session uses, you may need to call those properties, then recreate the session. Set Session Property c to this session. You can set While the session is Stopped, yo u can change properties specifi except those in the In any property in the XNET Session Property Node terface category (refer to Stopped in Interface States ). state. If there is an Communicating You cannot set properties of a session in the Started or the property help states this. exception for a specific property, Start Session . To read XNET Read.vi For an input session, you can start the session simply by calling received frames, XNET Read.vi performs an automatic Start of scope Normal, which starts the session and interface. For an output session, if you leave the Auto Start? property at its default value of true, you can start the session simply by calling XNET Write.vi . The auto-start feature of XNET which starts the session and interface. Write.vi performs a Start of scope Normal, XNET Write.vi , you can call To start the session prior to calling XNET Read.vi or XNET . The XNET Start.vi default scope is Normal, which starts the session and interface. Start.vi You also can use XNET Start.vi with scope of Session Only (t his Start Session transition) or Start Interface Interface Only (the interface transition). Stop Session You can stop the session by calling XNET Clear.vi or XNET Stop.vi . XNET Stop.vi XNET Start.vi , allowing you to stop the session, interface, or provides the same scope as both (normal scope). 4-560 NI-XNET Hardware and Software Manual ni.com

626 Chapter 4 LabVIEW—Additional Topics NI-XNET API for When the session stops, the underlying queues are not flushed. For example, if an input session receives frames, then you call XNET Stop.vi , you still can call XNET Read.vi to read the frame values from the queues. To flush the queues of a session, call XNET Flush.vi XNET Clear.vi (or ). Interface Communicating This transition occurs when th e session interface enters the Communicating state. Interface Not Communicating This transition occurs when the session interface exits the Communicating state. XNET Clear.vi ssion stops due to The session also exits its Communicating state when the se XNET Stop.vi . or Interface States Stopped ents the communicati on controller of the The interface always exists, because it repres NI-XNET hardware product port. This physical port is wired to a cable that connects to one or more remote ECUs. The NI-XNET interface initially powers on in th e Stopped state. In th e Stopped state, the interface does not communicate on its port. While the interface is Stopped, you can change properties specific to the interface. These properties are contained within the Session Property Node Interface category. When more than one session exists for a given interface, th e Interface category properties provide shared ple, if you set an interface property using access to the interface configuration. For exam one session, then get that same property using a second session, the returned value reflects the change. Properties that you change in the interface are not saved from one execution of your application to another. When the last sessi on for an interface is cleared, the interface properties are restored to defaults. Started In the Started state, the interf ace is started, but it is waiting for the associated communication controller to complete its integration with the network. This state is transitory in nature, in that your application does not control transition out of the Started state. For CAN and LIN, integration with the network occurs in a few bit times, so the Stopped to . For FlexRay, integration with the Communicating transition is ef fectively from 4-561 © National Instruments NI-XNET Hardware and Software Manual

627 Chapter 4 NI-XNET API for LabVIEW—Additional Topics network entails synchronization with global FlexRay time, which can take as long as hundreds of milliseconds. Communicating twork. One or more In the Communicating state, the interface is communicating on the ne to receive and/or tr ansmit frame values. communicating sessions can use the interface The interface remains in the Communicating state as long as communicat ion is feasible. For information about how the interface transitions in and out of this state, refer to Comm State and Comm State Not Communicating . Communicating Interface Transitions Set Interface Property interface-specific properties. These properties While the interface is Stopped, you can change y. When more than one session exists for a are in the Session Property Node Interface categor ties provide shared access to the interface given interface, the Interface category proper e, if you set an interface property using one session, then get that configuration. For exampl same property using a second session, th e returned value reflects the change. e interface while it is in the Started You cannot set properties of th Communicating state. or If there is an exception for a specific prop erty, the property help states this. Start Interface You can request the interface start in two ways: method or Start • XNET Read.vi : The automatic start described for the XNET Write.vi Session h requests the interface and session start. transition uses a scope of Normal, whic • XNET Start.vi method : If you call this VI with scope of Normal or Interface Only, you request the interface start. After you request the interface start, the act ual transition depends on whether you have connected the interface start trigger. Yo u connect the start trigger by calling the XNET Connect T erminals.vi with a destination of Interface Star t Trigger or by writing the XNET inal:Start Trigger Session Interface:Source Term property. The Start Interface transition occurs as foll ows, based on the start trigger connection: • Disconnected (default) : Start Interface occurs as soon as it is requested ( XNET Read.vi , XNET Write.vi , or XNET Start.vi ). • Connected : Start Interface occurs when the c onnected source terminal transitions low-to-high (for exam ple, pulses). Every Start Interface trans ition requires a new so if your application stops the interface (for example, XNET low-to-high transition, 4-562 NI-XNET Hardware and Software Manual ni.com

628 Chapter 4 LabVIEW—Additional Topics NI-XNET API for Stop.vi ), then restarts the interface, the c onnected source terminal must transition low-to-high again. Stop Interface Under normal conditions, the interface is stoppe d when the last session is stopped (or cleared). In other words, the in terface communicates as long as at least one session is in use. If a significant number of errors occur on the network, the communication controller may stop Comm State Not Communicating . the interface on its own. For mo re information, refer to with scope of Interface Only, that immediately XNET Stop.vi If your application calls state. Use this feature with transitions the interface to the Stopped care, because it affects all sessions that use the interface and is not limited to the session passed to XNET Stop.vi . In ly stops communication by all other words, using XNET Stop.vi with a scope of Interface On sessions simultaneously. Comm State Communicating rface is integrated with the network. This transition occurs when the inte rs Error Active or Error Passive state. For For CAN, this occurs when communication ente information about the specific CAN in terface communication XNET Read states, refer to . (State CAN Comm).vi enters one Normal Active or Normal Passive For FlexRay, this occurs when communication the specific FlexRay interface co mmunication states, refer to state. For information about . XNET Read (State FlexRay Comm).vi For LIN, this occurs when communication enters the Active state. The interface remains communicating while in the Active or Inactive state (not affect ed by bus activity). For more information about the specific LIN in XNET Read terface communication states, refer to (State LIN Comm).vi . Comm State Not Communicating This transition occurs when the interface no longer is integrated with the network. For CAN, this occurs when communication enters Bus Off or Idle state. For information about the specific CAN interface comm unication states, refer to XNET Read (State CAN Comm).vi . For FlexRay, this occurs when communication enters the Halt, Config, Default Config, or Ready state. For information about the specifi c FlexRay interface communication states, refer XNET Read (State FlexRay Comm).vi to . 4-563 © National Instruments NI-XNET Hardware and Software Manual

629 Chapter 4 LabVIEW—Additional Topics NI-XNET API for For LIN, this occurs when communication enters the Idle state. For more information about XNET Read (State LIN Comm).vi the specific LIN interface comm unication states, refer to . TDMS This section describes how NI-XNET frame data is stored within National Instruments Technical Data Management Streaming ( .TDMS ) files. The National Instruments TDMS file on NI platforms. The TDMS file format enables format provides efficient and flexible storage storage of a wide variety of measurement types in a single binary file, including CAN, FlexRay, LIN, analog, digital, and so on. This section specifies the method used to store NI-XNET raw frame data within TDMS. Although you also can store NI-XNET signal waveforms within TDMS, raw frame data is the most efficient and complete way to store NI-XNET data. Raw frame data can be easily converted to/from protocol-specific frames or signal waveforms for display and analysis. TDMS is recommended for new applications that access NI-XNET data within files. For examples that demonstr ate use of TDMS with NI-XNET, refer to the NI-XNET Logging and Replay category in the NI Example Finder (for example, Hardware Input and Output : CAN : NI-XNET : Logging and Replay ). a file format called NCL to store raw frame Previous versions of NI-XNET and NI-CAN used data. If you have an existing application that uses NCL, you can continue to use that file format. Examples for NCL continue to be installed with NI-XNET ( examples\nixnet folder in your LabVIE W directory), but they no longer appear in the NI Example Finder. If you need to store multiple sources of data in a single file (for example, multiple CAN interfaces, or CAN with analog input), you s hould consider trans itioning your application from NCL to TDMS. Because bo th file formats use the same raw frame data, the changes required for this transition are relatively small. Within the TDMS file, a sequence of raw frames is stored in a distinct TDMS channel for each NI-XNET interface (for example, CAN port). Fr om the TDMS perspective, the frame data is represents one or more raw frames. an array of U8 values. The U8 array The version of TDMS used with this specification must be 2.0 or higher. Channel Name and Group Name The name of the TDMS channel can use any conventions that you desire, but it should be sufficient to identify the network that is stored. For example, if you log data from two CAN interfaces, you might name the first TDMS channel Powertrain network and the second TDMS channel Body network . If you have an NI-XNET database that contains property often provides a useful distinct clusters fo r each network, the Name (Short) ed directly as the TDMS channel name. description of the network, and can be us 4-564 NI-XNET Hardware and Software Manual ni.com

630 Chapter 4 NI-XNET API for LabVIEW—Additional Topics The name of the TDMS group can use any conventions that you desire. The group name is required for NI-XNET frame data, but if you do not use multiple groups in the TDMS file, you can select a simple group name (for example, My Group ). Channel Data The data you read and write to the TDMS channel must be an array of U8 values. No other TDMS data types are supported. The channel data contains one or more frames encoded using the . The raw Raw Frame Format ation received on the network, along with precise timestamps. frame format encodes all inform The protocols supported include CAN, FlexRay, and LIN. The TDMS Channel Properties specify additional requirements for encoding of the raw frame data. The property NI_network_frame_byte_order is particularly important, as this amp and Identifier elements within each raw specifies the byte order used for the Timest frame. Channel Properties l to distinguish the data from a plain array Special properties are used on each TDMS channe of U8 samples. Properties are also provided to assist in interpreting the data, such as conversion to signals (physical units). frame data use the prefix All properties for NI-XNET NI_network_ . This prefix ensures that your application. Table 4-5 lists the channel the properties do not conflict with names used by properties. 4-565 © National Instruments NI-XNET Hardware and Software Manual

631 Chapter 4 NI-XNET API for LabVIEW—Additional Topics Table 4-5. Channel Properties Description Permissions Name Data Type NI_network_ Specifies the network protocol used for all frames Required protocol in this channel. The property value is an enumeration: 0CAN 1FlexRay 2LIN If this property does not exist, the data shall not be interpreted as raw frames, but as plain U8 samples. NI_network_ Required Specifies the raw frame encoding version. The frame_ encoding of this number is specific to each version protocol listed in . NI_network_protocol For CAN, FlexRay, and LIN, the version encoding is the Upgrade Version in lowest order byte, and Major Version in next order byte. The two upper order bytes are 0. The Major Version indicates a change that breaks compatibility with the previous version. The value for this specification is 2. The Upgrade Version indicates a change that retains compatibility with Upgrade Version 0. The value for this specification is 0. If this property does not exist, the data is not interpreted as raw frames, but as plain U8 samples. 4-566 NI-XNET Hardware and Software Manual ni.com

632 Chapter 4 LabVIEW—Additional Topics NI-XNET API for Channel Properties (Continued) Table 4-5. Name Description Permissions Data Type NI_network_ Required Specifies the byte order for multibyte elements frame_byte_ within each frame’s data. For example, the frame’s order Identifier is a 32-bit value, and Timestamp is a Raw Frame Format 64-bit value. Refer to for details. This property does not specify byte order for TDMS properties or other TDMS channels. This property does not specify byte order for signals within the frame’s Payload (that is, covered by specifications like CANdb, LDF, and FIBEX). The property value is an enumeration: 0 Little-endian (that is, least significant byte in lowest offset, Intel byte order) Big-endian (that is, most significant byte in 1 lowest offset, Motorola byte order) If this property does not exist, the data is not interpreted as raw frames, but as plain U8 samples. NI-XNET Hardware and Software Manual 4-567 National Instruments ©

633 Channel Properties (Continued) Table 4-5. Description Permissions Data Type Name NI_network_ describes the content of Provides information that Optional content the payload of frames on this network. This typically is information to map and scale physical-unit values from each frame’s payload. ng is specific to each The encoding of this stri protocol listed in . NI_network_protocol For CAN, FlexRay, and LIN, the string encoding is: . The specifies an alias to a network database file (content specification). This alias provides a short name, used to refer to a database When you register an file across multiple systems. alias with tools, you typically use the database filename on the local system, without the preceding path or file ex tension. For example, the path c:\MyDatabases\CANdb\ Powertrain.dbc would use an alias of Powertrain . The refers to a specific cluster (network) within the database. A database file can specify multiple networks within a vehicle. This portion of the string is optional (you can use ). If the cluster without “.” or does not exist, it is assumed that only one network is specified within the database. When you use NI-XNET, this string uses the same . The syntax as the XNET Cluster I/O Name registered alias refers to a file on Windows (DBC, LDF, or FIBEX text file), or on LabVIEW Real-Time (compressed binary file). When you use tools that do not explicitly contain NI-XNET (for example, NI DIAdem), support for this property may have limitations. For example, DBC files may be supported, but not LDF or FIBEX.

634 Chapter 4 LabVIEW—Additional Topics NI-XNET API for Channel Properties (Continued) Table 4-5. Name Description Permissions Data Type This property is optional. For applications that read the logfile, if this property does not exist, the effect will depend on the goal: • Display of frame values: no effect—the network content is not needed. • Display of signal values: application opens a dialog to ask the customer to browse to the file. CAN NI-CAN ng interface (API) for National Instruments NI-CAN is the legacy application programmi CAN hardware. Generally speaking, NI-CAN is associated with the legacy CAN hardware, and NI-XNET is associated wi th the new NI-XNET hardware. If you are starting a new application, you typically use NI-XNET (not NI-CAN). Compatibility If you have an existing application that uses NI-CAN, a compatibility library is provided so that you can reuse that code with a new NI- XNET CAN product. Because the features of the compatibility library apply to the NI-CAN API and not NI-XNET, it is described in the NI-CAN Hardware and Software NI-CAN documentation. For more information, refer to the . Manual NI-XNET CAN Products in MAX When the compatibility library is installed, NI-XNET CAN products also are visible in the NI-CAN Devices and Interfaces e the devices for use . Here you can configur branch under with the NI-CAN API. This configuration is independent from the configuration of the same . device for NI-XNET under the root of Devices and Interfaces NI-XNET Hardware and Software Manual 4-569 National Instruments ©

635 Chapter 4 LabVIEW—Additional Topics NI-XNET API for Tr an s i ti o n If you have an existing application that uses NI-CAN and intend to use only new NI-XNET hardware from now on, you may want to transition your code to NI-XNET. NI-XNET unifies many concepts of the earlier NI-CAN API, but the key features are similar. The following table lists NI-CAN terms and analogous NI-XNET terms. 4-570 ni.com NI-XNET Hardware and Software Manual

636 Chapter 4 NI-XNET API for LabVIEW—Additional Topics -XNET Terms NI-CAN and NI Table 4-6. NI-XNET Term NI-CAN Term Comment NI-XNET supports more database file formats than Database CANdb file the NI-CAN Channel API, including the FIBEX format. Frame Message Frame is the industry convention for the bits The term that transfer on the bus. This term is used in standards such as CAN. Signal is the industry convention. This term Signal Channel The term is used in standards such as FIBEX. Session Channel API Task Unlike NI-CAN, NI-XNET supports simultaneous (Signal I/O) use of channel (signal) I/O and frame I/O. Frame API CAN Session (Frame I/O The NI-CAN CAN Object provided both input (read) and output (write) in one object. NI-XNET provides a Single-Point) Object (Queue ection, for better control. Length Zero) different object for each dir If the NI-CAN queue length for a direction is zero, that is analogous to NI-XNET Frame I/O Single-Point. If the NI-CAN queue length for a direction is nonzero, Session (Frame I/O Frame API CAN that is analogous to NI-XNET Frame I/O Queued. Queued) Object (Queue Length Nonzero) The NI-CAN Network Interface Object provided both Session (Frame I/O Frame API Stream) Network Interface input (read) and output (write) in one object. NI-XNET provides a different object for each Object direction, for better control. Interface NI-CAN started interface names at Interface CAN0 , but NI-XNET starts at ). FlexRay1 (or CAN1 CAN Timing Type and Session Mode For each XNET Frame property value, this section describes how the CAN:Timing Type frame behaves for each XNET session mode. An input session receives the CAN data frame from the network, and an output session transmits the CAN data frame. The CAN data fr ame data (payload) is mapped to/from signal values. © NI-XNET Hardware and Software Manual 4-571 National Instruments

637 Chapter 4 LabVIEW—Additional Topics NI-XNET API for ciated CAN data frame from a remote ECU. You use CAN remote frames to request the asso When Timing Type is Cyclic Remote or Event Remote, an input session transmits the CAN remote frame, and an output sessi on receives the CAN remote frame. Cyclic Data The data frame transmits in a cyclic CAN:Transmit (periodic) manner. The XNET Frame Time property defines the time between cycles. Signal Input Single-Point, Signal Input Waveform, Signal Input XY, Frame Input Single-Point, and Frame Input Queued Modes You specify the CAN frame (or its signals) when you create the session. When the CAN data frame is received, a subsequent call to XNET Read.vi returns its data. For information about how the data is represented for each mode, refer to Session Modes . If the CAN remote frame is receive d, it is ignored (with no effect on XNET Read.vi ). Frame Input Stream Mode You specify the CAN cluster when you create the session, but not the specific CAN frame. XNET Read.vi When the CAN data frame is received, a subsequent call to returns its data. for the stream XNET Read.vi If the CAN remote frame is received, a subsequent call to returns it. Signal Output Single-Point, Signal Output Waveform, Signal Output XY, Frame Output Single-Point, and Frame Output Queued Modes You specify the CAN frame (or its signals) when you create the session. When you write data using XNET Write.vi , the CAN data frame is transmitted onto the network. For information . about how the data is represented for each mode, refer to Session Modes When the session and its associated interface ar e started, the first cycle occurs, and the CAN the CAN data frame tran smits once every cycle, data frame transmits. After that first transmit, regardless of whether XNET Write.vi is called. If no new data is available for transmit, the CAN data frame (repeats the payload). next cycle transmits using the previous If you pass the CAN remote frame to XNET Write.vi , it is ignored. Frame Output Stream Mode You specify the CAN cluster when you create the session, but not the specific CAN frame. XNET Write.vi , it is transmitted onto the When you write the CAN data frame using network. 4-572 NI-XNET Hardware and Software Manual ni.com

638 Chapter 4 LabVIEW—Additional Topics NI-XNET API for The stream I/O modes do not use the database-s pecified timing for frames. Therefore, CAN data and CAN remote frames transmit only when you pass them to XNET Write.vi , and do not transmit cyclically afterward. When using a stream output timing of immediate mode, data is transmitted onto the network as soon as possible. Replay Inclusive, data is When using a stream output timin g of either Replay Exclusive or transmitted onto the network based on the timestamps in the frame. Event Data The data frame transmits in an event-driven manner. For output sessions, the event is XNET Write.vi . The XNET Frame CAN:Transmit Time property defines the minimum interval. Signal Input Single-Point, Signal Input Waveform, Signal Input XY, Frame Input Single-Point, and Frame Input Queued Modes . The behavior is the same as Cyclic Data Frame Input Stream Mode The behavior is the same as . Because the stream I/O modes ignore the Cyclic Data u can read either CAN data or CAN remote database-specified timing for all frames, yo frames. Signal Output Single-Point, Signal Output Waveform, Signal Output XY, Frame Output Single-Point, and Frame Output Queued Modes The behavior is the same as Cyclic Data , except that the CAN data frame does not continue has transmitted. Because the to transmit cyclically after the data from XNET Write.vi database-specified timing for the frame is ev XNET ent based, after the CAN data frames for Write.vi have transmitted, the CAN data frame doe s not transmit again until a subsequent call XNET Write.vi . to Frame Output Stream Mode The behavior is the same as Cyclic Data . Because the stream I/O modes ignore the u can write either CAN data or CAN remote database-specified timing for all frames, yo frames. Cyclic Remote The CAN remote frame transmits in a cyclic (p eriodic) manner, followed by the associated CAN data frame as a response. 4-573 © National Instruments NI-XNET Hardware and Software Manual

639 Chapter 4 LabVIEW—Additional Topics NI-XNET API for Signal Input Single-Point, Signal Input Waveform, Signal Input XY, Frame Input Single-Point, and Frame Input Queued Modes You specify the CAN frame (or its signals) when you create the session. When the CAN data frame is received, a subsequent call to XNET Read.vi returns its data. For information about how the data is represented for each mode, refer to Session Modes . When the session and its associated interface ar e started, the first cycle occurs, and the CAN remote frame transmits. This CAN remote fram e requests data from the remote ECU, which (same identifier). After that first transmit, soon responds with the associated CAN data frame ce every cycle. You do not call XNET Write.vi for the the CAN remote frame transmits on session. The CAN remote frame cyclic transmit is inde pendent of the corresponding CAN data frame reception. When NI-XNET transmits a CAN remote frame, it transmit s a CAN remote frame again CAN:Transmit Time later, even if no CAN data frame is received. Frame Input Stream Mode The behavior is the same as Cyclic Data . Because the stream I/O modes ignore the can read either CAN data or CAN remote database-specified timing for all frames, you frames. Signal Output Single-Point, Signal Output Waveform, Signal Output XY, Frame Output Single-Point, and Frame Output Queued Modes You specify the CAN frame (or its signals) when you create the session. When you write data using XNET Write.vi , the CAN data frame is transmitt ed onto the network when the associated CAN remote frame is received (sam e identifier). For info rmation about how the data is represented for each mode, refer to Session Modes . Although the session receives the CA N remote frame, you do not call XNET Read.vi to read that frame. NI-XNET detects the received CAN remote frame, and imme diately transmits the next CAN data frame. Your application uses XNET Write.vi to provide the CAN data frames used for transmit XNET Write.vi , the CAN data frame does not transmit . When you call immediately, but instead waits for the asso ciated CAN remote frame to be received. Frame Output Stream Modes The behavior is the same as Cyclic Data . Because the stream I/O modes ignore the database-specified timing for all frames, you can write either CAN data or CAN remote frames. Event Remote The CAN remote frame transmits in an event-driven manner, followed by the associated CAN XNET Write.vi data frame as a response. For input sessions, the event is . 4-574 NI-XNET Hardware and Software Manual ni.com

640 Chapter 4 LabVIEW—Additional Topics NI-XNET API for Signal Input Single-Point, Signal Input Waveform, Signal Input XY, Frame Input Single-Point, and Frame Input Queued Modes you create the session. When the CAN data You specify the CAN frame (or its signals) when turned from a subsequent call to XNET Read.vi . For frame is received, its data is re represented for each mode, refer to Session Modes . information about how the data is This CAN Timing Type and mode combination is somewhat advanced, in that you must call XNET Read.vi to provide the event XNET Write.vi both . You must call and XNET Write.vi XNET Write.vi , the data is that triggers the CAN remote frame transmit. When you call ignored, and one CAN remote frame transm its as soon as possible. Each call to XNET Write.vi transmits only one CAN remote frame, even if you provide multiple signal or frame values. When the remote ECU receives the CAN remote frame, it responds with a CAN data frame, which is received and read using XNET Read.vi . Frame Input Stream Modes Cyclic Data . Because the stream I/O modes ignore the The behavior is the same as u can read either CAN data or CAN remote database-specified timing for all frames, yo frames. Signal Output Single-Point, Signal Output Waveform, Signal Output XY, Frame Output Single-Point, and Frame Output Queued Modes Cyclic Remote . When you write data using XNET Write.vi , the The behavior is the same as CAN data frame transmits onto the network wh en the associated CAN remote frame is received (same identifier). Unlike Cyclic Data , the remote ECU sends the associated CAN remote frame in an event-dr iven manner, but the behavior is the same regarding XNET Write.vi and the CAN data frame transmit. Frame Output Stream Mode The behavior is the same as Cyclic Data . Because the stream I/O modes ignore the u can write either CAN data or CAN remote database-specified timing for all frames, yo frames. CAN Transceiver State Machine The CAN hardware internally runs a state mach ine for controlling the transceiver state. The transceiver can either be an internal transceiver or an external transceiver. On hardware that ed transceriver by contains software selectable transceivers, you can configure the select setting the Interface:CAN:Transceiver Type property. If you choose an external transceiver, you can configure its behaviors by setting the Interface:CAN:External Transceiver Config property. Both bus conditions as well as the Interface:CAN:Transceiver State property can e different states of ing state machine shows th affect the current transceiver state. The follow the transceiver state machine and ho w the various states transition. 4-575 © National Instruments NI-XNET Hardware and Software Manual

641 Chapter 4 NI-XNET API for LabVIEW—Additional Topics T1 Power-On T2/T3 T13 T10 Normal T5 T6 T14 T7 T4/T9 T11 T12 Single-Wire Single-Wire Sleep T15 Wakeup High Speed T8 T16 Transition Triggered by NI-XNET API Call Transition Triggered by NI-XNET API Call or Bus Conditions T# From To Condition 1 Power-on/close last session Any Power-on 2 Interface is started Power-on Normal 3 Interface:CAN:Transceiver State with value Normal Power-on Normal Normal Interface:CAN:Transceiver State with value Normal Sleep 4 SW Wakeup Normal Interface:CAN:Transceiver State with value Normal 5 6 Interface:CAN:Transceiver State with value Normal SW High Normal Speed Interface:CAN:Transceiver State with value Sleep 7 Normal Sleep 8 Interface:CAN:Transceiver State with value Sleep SW Wakeup Sleep Normal Sleep Wakeup Pattern received on the bus 9 ni.com 4-576 NI-XNET Hardware and Software Manual

642 Chapter 4 LabVIEW—Additional Topics NI-XNET API for From Condition T# To SW Wakeup Power-on Interface:CAN:Transceiver State with value SW 10 Wa ke u p SW Wakeup Normal Interface:CAN:Transceiver State with value SW 11 Wa ke u p SW Wakeup Sleep 12 Interface:CAN:Transceiver State with value SW Wa ke u p Power-on Interface:CAN:Transceiver State with value SW 13 SW HighSpeed High Speed Normal 14 SW Interface:CAN:Transceiver State with value SW High Speed HighSpeed Sleep 15 Interface:CAN:Transceiver State with value SW SW HighSpeed High Speed 16 SW Wakeup SW Interface:CAN:Transceiver State with value SW HighSpeed High Speed FlexRay FlexRay Timing Type and Session Mode FlexRay:Timing Type property value, this section describes how the For each XNET frame frame behaves for each XNET session mode. An input session receives the FlexRay data frame from the network, and an output session transmits the FlexRay data frame. The FlexRay data frame data (paylo ad) is mapped to/from signal values. You use FlexRay null frames in the static segment to indicate that no new payload exists for the frame. In the dynamic segmen t, if no new payload exists for the frame, it simply does not transmit (no frame). For NI-XNET input sessions, the Timing Type does not directly impact the representation of . XNET Read.vi data from For NI-XNET output sessions, the Timing Type determines whether to transmit a data frame when no new payload data is available. NI-XNET Hardware and Software Manual 4-577 National Instruments ©

643 Chapter 4 LabVIEW—Additional Topics NI-XNET API for Cyclic Data The data frame transmits in a cyclic (periodic) manner. If the frame is in the static segment, the rate can be once per cycle ( FlexRay:Cycle 1), once every Repetition cycles ( FlexRay:Cycle Repetition N ), or multiple times per cycle N ( FlexRay:In Cycle Repetitions:Enabled? ). If the frame is in the dynamic se gment, the rate is once per cycle. If no new payload data is available when it is time to transmit, the payload data from the previous transmit is repeated. Signal Input Single-Point, Signal Input Waveform, and Signal Input XY Modes You specify the FlexRay signals when you cr eate the session, and a specific FlexRay data frame contains each signal. When the FlexRay da ta frame is received, a subsequent call to XNET Read.vi returns its data. For information abou t how the data is represented for each mode, refer to Session Modes . XNET Read.vi d, it is ignored (no effect on ). FlexRay null If a FlexRay null frame is receive frames are not used to map signal values. Frame Input Queued and Frame Input Single-Point Modes You specify the FlexRay frame(s) when you create the session. When the FlexRay data frame is received, a subsequent call to XNET Read.vi returns its data. For information about how the data is represented for each mode, refer to Session Modes . If a FlexRay null frame is received, it is ignored (not returned). Frame Input Stream Mode You specify the FlexRay cluster when you creat e the session, but not the specific FlexRay frames. When any FlexRay data frame is received, a subsequent call to XNET Read.vi returns it. Interface:FlexRay:Null Fram es To Input Stream? property is true, and If the XNET Session FlexRay null frames are recei ved, a subsequent call to XNET Read.vi for the stream returns them. If Null Frames To Input Stream? is false (default), FlexRay null frames are ignored (not returned). You can determine whether each fr ame value is data or null by evaluating the type ). element (refer to XNET Read (Frame FlexRay).vi 4-578 NI-XNET Hardware and Software Manual ni.com

644 Chapter 4 LabVIEW—Additional Topics NI-XNET API for Signal Output Single-Point, Signal Output Waveform, Signal Output XY, Frame Output Single-Point, and Frame Output Queued Modes when you create the se ssion. When you write You specify the FlexRay frame (or its signals) XNET Write.vi data using , the FlexRay data frame is transmitted onto the network. For information about how the data is represented for each mode, refer to Session Modes . FlexRay data frame transmits When the session and its associ ated interface are started, the according to its rate. After that first transmit e transmits according to , the FlexRay data fram its rate, regardless of whether XNET Write.vi is called. If no new data is available for transmit, the next cycle transmits using th e previous FlexRay data frame (repeats the payload). If the frame is contained in th e static segment, a FlexRay data frame transmits at all times. The FlexRay null frame is not transmitted. If you pass the FlexRay null frame to XNET , it is ignored. Write.vi e dynamic segment, a FlexRay data If the frame is contained in th frame transmits every cycle. The dynamic frame minislot is always used. Frame Output Stream Mode This session mode is not supported for FlexRay. Event Data The data frame transmits in an ev ent-driven manner. The event is XNET Write.vi . Because FlexRay is a time-driven protocol, the minimum interval between events is specified based on the FlexRay cycle. This minimum interval is configured in the same manner as a Cyclic frame. If the frame is in the static segment, the interval can be once per cycle ( FlexRay:Cycle Repetition 1), once every ), or multiple times per cycle N cycles ( FlexRay:Cycle Repetition N ( FlexRay:In Cycle Repetitions:Enabled? ). If the frame is in the dynamic segm ent, the interval is once per cycle. If no new event (payload data) is available when it is time to transmit, no frame transmits. In the static segment, this lack of ne w data is represented as a null frame. Signal Input Single-Point, Signal Input Waveform, Signal Input XY, Frame Input Single-Point, Frame Input Queued, and Frame Input Stream Modes The behavior is the same as . Cyclic Data 4-579 © National Instruments NI-XNET Hardware and Software Manual

645 Chapter 4 LabVIEW—Additional Topics NI-XNET API for Signal Output Single-Point, Signal Output Waveform, Signal Output XY, Frame Output Single-Point, and Frame Output Queued Modes The behavior is similar to Cyclic Data frame does not continue , except that the FlexRay data to transmit cyclically after the data from XNET Write.vi has transmitted. Because the database-specified timing for the frame is ev ent based, after the FlexRay data frames for XNET Write.vi have transmitted, the FlexRay data frame does not transmit again until a subsequent call to XNET Write.vi . If the frame is contained in the static segment, a FlexRay null frame transmits when no new data is available (no new call to XNET Write.vi ). If you pass the FlexRay null frame to XNET Write.vi , it is ignored. does not transmit when no new the dynamic segment, the frame If the frame is contained in data is available. The dynamic frame minislot is used only when new data is provided to . XNET Write.vi Frame Output Stream Mode This session mode is not supported for FlexRay. Protocol Data Units (PDUs) in NI-XNET Introduction to Protocol Data Units Protocol Data Units (PDUs) are encapsulated network data that are a way to communicate information between independent protocols, su ch as in a CAN-FlexRay gateway. You can in multiple frames. A think of them as containers of signals. The container (PDU) can be single frame can cont ain multiple PDUs. Relationship Between Frames, Signals, and PDUs Frames and PDUs The frame element contains an arbitrary number of nonoverlapping PDUs. A frame can have in different frames. Figure 4-19 shows the multiple PDUs, and the same PDU can exist n number of PDUs in one frame) one-to- n (one PDU in n number of frames) and n -to-one ( relationships. 4-580 NI-XNET Hardware and Software Manual ni.com

646 Chapter 4 LabVIEW—Additional Topics NI-XNET API for PDU Frame 3 Frame 2 Frame 1 (Three) Frames n One PDU in PDU 1 PDU 3 PDU 2 Frame (Three) PDUs in One Frame n Relationships Between PDUs and Frames Figure 4-19. Signals and PDUs A PDU acts like a container for a logical group of signals. Figure 4-20 represents the relationshi p between frames, PDUs, and signals. Signals PDUs Frames Figure 4-20. ames, PDUs, and Signals Relationships Between Fr © National Instruments 4-581 NI-XNET Hardware and Software Manual

647 Chapter 4 NI-XNET API for LabVIEW—Additional Topics Protocol Data Unit Properties Start Bit The start bit of the PDU within the frame indicat es where in the frame the particular PDU data starts. Length The PDU length defines the PDU size in bytes. Update Bit The receiver uses the update bit to determine whether the frame sender has updated data in a particular PDU. Update bits allow for the decoupling of a signal update from a frame occurrence. Update bits is an optional PDU property. PDU Timing and Frame Timing Because the same PDU can exist in multiple Frames, PDUs can have flexible transmission schedules. For example, if PDU A is present in Frame 1 (Timing 1) as well as in Frame 2 (Timing 2), the receiving node receives it as per the different timings of the containing frames. (Refer to Figure 4-21.) PDUs Frames Frame 2, Timing 2 Frame 3, Timing 3 Frame 1, Timing 1 PDU Timing and Frame Timing Figure 4-21. Programming PDUs with NI-XNET You can use PDUs in two ways to create a session for read/write: • ng signals within the PDU. To do this, use the signal name Create a signal I/O session usi as you would with signals contained within a frame. • Create an I/O session to read/write the raw P DU data. To do this, wire the PDU(s) to the XNET Create Session (PDU Input special Create Session mode s for PDU. (Refer to s operate like the equivalent frame for more information.) These mode Queued).vi modes. Important points to consider while programming with PDUs: • PDUs currently are supported only on FlexRay interfaces. ni.com 4-582 NI-XNET Hardware and Software Manual

648 Chapter 4 LabVIEW—Additional Topics NI-XNET API for On the receive side, if the P with it, the NI-XNET driver • DU has an update bit associated sets the update bit when new data is received for the particular PDU from the bus. Otherwise, if no new data is received for this PDU, the PDU is discarded. On the transmit side, the NI-XNET driver sets the update bit when it detects that new data is available for queue or table. The NI-XNET the particular PDU in the PDUs driver clears the bit if no new data is detected in the PDU queue or ta ble. If the frame containing the PDUs has cyclic timing, even if no new data is availabl e for any of the PDUs in the frame, the frame is transmitted across the bus with the updat e bits all cleared. However, if the PDU containing the frame has event timing, it is tr ansmitted across the bus only if at least one PDU that it contains has new data (with update bit set). • PDUs Required? property is useful when programming The read-only XNET Cluster traversal through the database, as it indicates whether to consider PDUs in the traversal. FlexRay Startup/Wakeup Use the FlexRay Startup mechanism to take an idle interface and properly integrate into a FlexRay cluster. If your cluster does not support the wakeup mechan ism, this process is straightforward. After creating your FlexRay session, call XNET Start.vi , which causes the interface to transition from Default Config to Ready , where it attempts to integrate with the FlexRay cluster. If your node is a coldstart node, it initiates integration; otherwise, it attempts to integrate with a has occurred, the inte running FlexRay cluster. Once integration Normal rface transitions to Active unicating with other FlexRay nodes. When , where it typically remains while it is comm you call XNET Stop.vi , the interface transitions back to Default Config (via Halt ) to be ready to start th e process again. If your cluster supports the wakeup mechanism, the process becomes a bit more complex. The route the XNET hardware takes depends on whet her the interface is curre ntly awake or asleep. By default, XNET hardware starts in the awak e state, and the startup process is exactly the same as if your cluster does not support wakeup. However, to use the wakeup mechanism your XNET Start.vi cluster is configured for, before calling , you need to put the interface to sleep. You can do this in one of two ways. First, you can set the Interface:FlexRay:Sleep property Local Sleep . This performs the one-tim e action of putting the interface to sleep. Alternately, to property to true. This puts the you can set the Interface:FlexRay:Auto Asleep When Stopped interface to sleep immediately. It also puts th e interface to sleep automatically every time the interface is stopped, so the startup process is th e same between your first start and subsequent starts. If your interface is asleep when the XNET Start.vi API call is invoked, the interface progresses to nnels to be awake before attempting Ready , where it waits for all connected cha ted channels are awake, the integration process to integrate with the cluster. After all connec occurs exactly like a cluster that does not support wakeup. 4-583 © National Instruments NI-XNET Hardware and Software Manual

649 If you want your interface to wake up a sleepi ng network, you must configure your FlexRay interface to wake up the bus. You can do this in two ways. The first way is to set the Interface:FlexRay:Sleep Remote Wake after you put your FlexRay interface to property to sleep. When you invoke the XNET Start.vi API call, the interface progresses though the state and into the Wakeup state. In Ready , the interface generates the wakeup Wakeup pattern on the FlexRay channel configured by the Interface:FlexRay:Wakeup Channel property and transitions back to Ready . If you have a multichannel bus, a separate node on the bus wakes up the other channel. After all connected channels are awake, the in tegration process occurs exactly like a cluster that does not support wakeup. The second way is to invoke the XNET Start.vi API call to start the interface. The interface progresses to , where it waits for all connected Ready channels to be awake before attempting to integr ate with the cluster. During this time, if you set the Interface:FlexRay:Sleep property to Remote Wake , the interface transitions into Wakeup , where it generates the wakeup pattern on the FlexRay channel configured by the Interface:FlexRay:Wakeup Channel sitions back to Ready . If you have a property and tran multichannel bus, a separate node on the bus wa kes up the other channe l. After all connected channels are awake, the integration process occu rs exactly like a cluster that does not support wakeup.

650 Chapter 4 LabVIEW—Additional Topics NI-XNET API for Power On Reset Default Config T1 T9 Config T2 T3 Ready Halt Wakeup T4 T8 T5 T7 Normal Active Normal Passive T6 Transition Triggered by NI-XNET API Call Transition Triggered by NI-XNET API Call or Internal Conditions Transition Triggered by NI-XNET API Call or Bus Conditions To T# From Condition 2 1 Config Default Config Start trigger received 1 2 Ready Config Startup process initiated Wa keu p Interface:FlexRay:Sleep Remote Wakeup initiated ( 3 Ready property set to Remote Wake ) Ready Wa ke u p Wakeup channel awake 4 National Instruments 4-585 NI-XNET Hardware and Software Manual ©

651 Chapter 4 LabVIEW—Additional Topics NI-XNET API for From Condition T# To Normal Active 5 All connected channels are awake and integration is Ready 3 successful Clock Correction Failed Normal counter reach ed Maximum Normal Active 6 Without Clock Correction Passive Value Passive Normal terms reached the passive Number of valid correction 7 Normal Active to active limit Passive 8 1. Clock Correction Failed counter reached Maximum Without Clock Correction Fatal Value 2. Interface stopped ( XNET Stop.vi ) Interface stopped ( Halt 9 XNET Stop.vi Default Config ) 1 If you are not using synchronization, the XNET Start.vi API call internally generates the Start Trigger. 2 . The Config state is nontransito ry only if the startup procedure In NI-XNET, this is a transitory state under normal situations fails to continue. 3 Any of the following conditions can satis fy all channels awake: the wakeup pattern was transmitted or received on all connected channels, a local wakeup is re quested, or the interface is not asleep. LIN LIN Frame Timing and Session Mode r each XNET session mode. As context for This section describes the LIN behavior fo is section uses the timing concepts described describing LIN frame transfer on the network, th in the LIN section of Cyclic and Event Timing . An input session receives the LIN data frame (payload) from the network, and an output session transmits the LIN data frame. The LIN data frame payload is mapped to/from signal values. timing of each LIN schedule en try does not directly impact For NI-XNET input sessions, the the representation of data from XNET Read.vi . For NI-XNET output sessions, the timing of each LIN schedule entry determines whether to transmit a data frame when no new payload data is available. You can configure the NI-XNET LIN interface to run as the LIN master by requesting a XNET Write (State LIN Schedule Change).vi ). If the NI-XNET LIN interface schedule ( on the network must execute schedules as LIN runs as a LIN slave (default), a remote ECU master for these modes to operate. ni.com 4-586 NI-XNET Hardware and Software Manual

652 Chapter 4 LabVIEW—Additional Topics NI-XNET API for Cyclic The LIN data frame transmits in a cyclic (periodic) manner. This implies that the LIN master is running a continuous schedule, and the LIN data frame is contained within an unconditional schedule entry. If no new payload data is available when it is time to transmit, the payload data from the previous transmit is repeated. Signal Input Single-Point, Signal Input Waveform, and Signal Input XY Modes You specify the signals when you create the sess ion, and a specific LIN data frame contains returns each signal. When the LIN data frame is received, a subsequent call to XNET Read.vi r each mode, refer to data is represented fo its signal data. For information about how the Session Modes . Frame Input Queued and Frame Input Single-Point Modes You specify the LIN frame(s) when you create the session. Wh en the LIN data frame is received, a subsequent call to XNET Read.vi returns its data. For information about how the . data is represented for each mode, refer to Session Modes Frame Input Stream Mode e specific LIN frames. the session, but not th You specify the LIN cluster when you create XNET Read.vi returns it. When any LIN data frame is received, a subsequent call to Signal Output Single-Point, Signal Output XY, Frame Output Single-Point, and Frame Output Queued Modes You specify the LIN frame (or its signals) when you create the session. When you write data using XNET Write.vi , the LIN data frame is transmitted onto the network. For information . about how the data is represented for each mode, refer to Session Modes ciated interface are started, the LIN data frame transmits When the session and its asso Assuming that the LIN frame is contained in only one entry according to its schedule entry. of the continuous schedule, the time between frame transmissions is the same as the time to execute the entire schedule (all entries). After that first transmit, the LIN data frame transmits according to its schedule entr y, regardless of whether XNET Write.vi is called. If no new data evious LIN data frame (repeats is available for transmit, the ne xt cycle transmits using the pr the payload). Signal Output Waveform Mode If the NI-XNET interface runs as a LIN master, NI-XNET executes schedules, and therefore ames. When running as a LIN master, this session mode is controls the timing of LIN fr 4-587 © National Instruments NI-XNET Hardware and Software Manual

653 Chapter 4 LabVIEW—Additional Topics NI-XNET API for supported, and NI-XNET resamples the waveform data such that it transmits at the scheduled frame rates. If the NI-XNET interface runs as a LIN slave (d efault), this session mode is not supported. When running as a LIN slave, NI-XNET does not know which schedule the LIN master is executing. Because the LIN schedule is not kno wn, the frame transfer rates also are not known, which makes it impossible to resample the waveform data. Frame Output Stream Mode rface is master. You specify the LIN cluster This mode is available only when the LIN inte when you create the session, bu t not the specific LIN frame. The stream I/O modes do not use the database-s pecified timing for fra mes. Therefore, LIN data frames transmit only when you pass them to XNET Write.vi and do not transmit cyclically afterward. When using a stream output timing of immediate mode, data is transmitted onto the network as soon as possible. Specifically, if the data ar ray is empty, only the header part of the frame is transmitted (with the expectation that a slave transmits the response). If the data array is not (the full frame) is transmitted. You can use empty, the header + response parts of the frame tion with the scheduler, in which case each frame written to stream this mode in conjunc output is handled as a run-once schedule with lo west priority and having a single one-frame entry. A run-continuous schedule is interrupted to transmit the frame. A run-once schedule is not interrupted, and the frame is transmitte d only when there are no pending run-once schedules with higher-than-lowest priority. When using a stream output timin g of either Replay Exclusive or Replay Inclusive, data is transmitted onto the network based on the timestamps in the frame. Interface:Output Stream Timing Refer to the property for more detail s about using this mode with LIN. Event The LIN data frame transmits in an event-driven manner. The event is XNET Write.vi . If no new event (payload data) is available when it is time to transmit, no frame transmits. This means that the LIN master transm its the frame header, but no payl oad data follows this header. Signal Input Single-Point, Signal Input Waveform, Signal Input XY, Frame Input Single-Point, Frame Input Queued, and Frame Input Stream Modes . The behavior is the same as Cyclic 4-588 NI-XNET Hardware and Software Manual ni.com

654 Chapter 4 LabVIEW—Additional Topics NI-XNET API for Signal Output Single-Point, Signal Output XY, Frame Output Single-Point, and Frame Output Queued Modes The behavior is similar to Cyclic , except that the LIN data frame does not continue to transmit after the data from XNET Write.vi has transmitted. are values for multiple frames If the frame is contained in a s poradic schedule entry, and there pending for that entry, NI-XNET selects a singl e frame to transmit in each entry. NI-XNET selects the frame using the order in the XNET LIN Schedule Entry Frames property. For example, if the Frames property contains three frames, and you write data for the first and third, NI-XNET transmits the first frame (index 0) in the next occurrence of the sporadic entry, and then transmits the third frame (index 2) when that sporadic entry executes again. If the frame is contained in an event-triggered schedule entry, a collision may occur if another If the NI-XNET LIN interface runs as a LIN ECU transmits in the same schedule entry. Collision Resolving Schedule master, it automatically uses the XNET LIN Schedule Entry property to resolve this collision. Signal Output Waveform Mode The behavior is the same as Cyclic . If the NI-XNET interface runs as a LIN master, NI-XNET executes schedules, and therefore controls the timing of LIN fram es. An event-driven LIN frame can transmit at most once per execution of its schedule entry. If the NI-XNET interface runs as a LIN slave (d efault), this session mode is not supported. Frame Output Stream Mode When using a stream output timing of immediate mode, if the frame for transmit is defined as transmit, the interface a collision occurs during an event-triggered frame in the database, and automatically executes the collision resolving schedule defined for the frame, exactly as if the frame were transmitted in a sc heduled event-triggered slot. or Replay Inclusive, if the When using a stream output timin g of either Replay Exclusive frame for transmit is determined to be defined as an event-triggered frame in the database, the frame is transmitted with a head er ID equal to the unconditional frame ID contained in data byte 0. The data is transmitted without modification. In other words, the frame is transmitted as an unconditional frame associated with the event-triggered frame. property for more detail Interface:Output Stream Timing s about using this mode Refer to the with LIN. 4-589 © National Instruments NI-XNET Hardware and Software Manual

655 Chapter 4 LabVIEW—Additional Topics NI-XNET API for XNET I/O Names LabVIEW I/O names (also known as refnum tags ) are provided for various object classes within NI-XNET. I/O names provide user interface features for easy configuration. You can use an I/O name as a: Control (or indicator) • ect a specific instance on the front : Use an I/O name control to sel panel. NI-XNET I/O name controls are in the front panel Modern»I/O»XNET controls palette. Typically, you use I/O name controls to select an instance during configuration, and the instance is used at run time. For exampl e, prior to running a VI, you can use XNET Signal I/O Name en the user runs the VI, the selected controls to select signals to read. Wh signals are passed to XNET Create Session.vi , followed by calls to XNET Read.vi to read and display data fo r the selected signals. As an alternative, you also can use I/O name controls to select an instance at run time. This applies when the VI always is running for the end user, and the VI uses distinct stages for configuration an d I/O. Using the previous example, the user clicks XNET e configuration stage. Next, the user controls to select signals during th Signal I/O Name XNET Create Session.vi and to the I/O stage, in which clicks a Go button to proceed XNET Read.vi are called. ecutable) that contains NI-XNET I/O name You can build a standalone application (ex controls on its front panel. While running in an executable, the I/O name drop-down menu is supported, but the right-click menu is not operational. • Constant : Use an I/O name constant to select a specific instance on the block diagram. NI-XNET I/O name constants are in the block diagram Measurement I/O»XNET tants only during config uration, prior to functions palette. You can access I/O name cons running the VI. If you are using LabVIEW Real-Time (RT), y ou can right-click the RT target within a LabVIEW Project and select the Connect menu item. This connects to the RT target over TCP/IP, which in turn enables the user interface of NI-XNET I/O names to operate remotely. target and menu items to manage database You can select names from the databases on the RT deployments. At run time, the VIs use I/O names to access feat ures for the selected instance. The I/O name has two simultaneous LabVIEW types: • String : When you wire the I/O name to a La bVIEW string, the string contains the ore the I/O name is a portable form, such as selected instance name. Use this string to st a text file. You can wire a LabVIEW string directly to an I/O name. 4-590 NI-XNET Hardware and Software Manual ni.com

656 Chapter 4 LabVIEW—Additional Topics NI-XNET API for Refnum numeric reference to the instance for use • : At run time, the I/O name contains a with NI-XNET property nodes and VIs. The property node for the I/O name provides thods for the instance, access to its configuration. The VIs provide me such as to change state (start/stop), or access data (read/write). I/O Name Classes NI-XNET includes the follo wing I/O name classes: Session Each session represents a connection between your National Instruments hardware and hardware products on the external network. Your application uses XNET sessions to read and write I/O data. The session I/O name is primarily for sessions created during configuration using a LabVIEW project. When you create a session at run time with XNET Create Session.vi , the I/O name serves only as a refnum (its string is irrelevant). Database Classes To communicate with hardware products on the external network, NI-XNET applications must understand how that hardware communicat es in the actual embedded system, such as the vehicle. This embedded communication is de scribed within a standa rdized file, such as CANdb ( ) for FlexRay, or LDF ( .xml ) for LIN. Within .ldf .dbc ) for CAN, FIBEX ( NI-XNET, this file is referred to as a databa se. The database contains many object classes, each of which describes a distinct entity in the embedded system: • Database : Each database is represented as a di stinct instance in NI-XNET. Although the I/O name string can be the complete file path, it typically uses a shortened alias. • Cluster : Each database contains one or more clusters, where the cluster represents a collection of hardware products all connect ed over a shared cabling harness. In other k. For example, the database may describe words, each cluster represents a single networ hicle contains one Body CAN cluster, another Powertrain a single vehicle, where the ve CAN cluster, and one Chassis FlexRay cluster. • ECU : Each Electronic Control Un it (ECU) represents a single hardware product in the more ECUs, all conn embedded system. The cluster contains one or ected over a network cable. Multiple clusters can co ntain a single ECU, in which case it behaves as a gateway between the clusters. • Frame : Each frame represents a unique unit of da ta transfer over the cluster cable. The r that specifies the da frame bits contain payload data and an identifie ta (signal) content. Only one ECU in the cluster transmits each frame, and one or more ECUs receive each frame. 4-591 © National Instruments NI-XNET Hardware and Software Manual

657 Chapter 4 LabVIEW—Additional Topics NI-XNET API for Signal es, each of which is called a signal. For • : Each frame contains zero or more valu example, the first two bytes of a frame payloa d may represent a temperature, and the third payload byte may represent a pressure. Within the database, each signal specifies its the frame, and a scal name, position, and length of the raw bits in ing formula to convert raw bits to/from a physical unit. The physical unit uses a LabVIEW double-precision floating-point numeric type. The signal is the highest level of abstraction for embedded networks. When you use an XNET Session to r ead/write signal values as physical units, your application does not need to be concer ned with protocol (CAN/FlexRay/LIN) and frame encoding details. • : The LIN protocol is different than CAN or FlexRay, in that it supports LIN Schedule multiple schedules that determ ine when frames transmit. You can change the current schedule at runtime. • LIN Schedule Entry : Each LIN Schedule contains one or more entries, or slots. Each entry in turn contains one or more frames th at can transmit during the entry’s time slot. A single frame can be located in multiple LIN schedules and within multiple LIN schedule entries. Additional database classes include PDU and Subframe. System Classes These classes describe hardware in your Nati , such as PXI or a onal Instruments system desktop PC containing PCI cards. Device : This represents the National Instrume nts device for CAN/FlexRay/LIN, such as • a PXI or PCI card. Each NI-XNET devi ce contains one or more interfaces. • Interface : This represents a single CAN, FlexRay, or LIN connector (por t) on the device. Within NI-XNET, the interface is the object us ed to communicate with external hardware described in the database. When you create an NI-XNET session, you specify a physical rface and a cluster. Because the cluster and logical connection between the NI inte represents a single physical cable harness, it does not make sense to connect the NI interface to multiple clusters simultaneously. Terminal : Each interface contains various term inals. The terminals are for NI-XNET • synchronization features , to connect triggers and timebas es (clocks) to/from the interface hardware. The terminal I/O name is for selecting a string input to the XNET Connect Terminals.vi or XNET Disconnect Terminals.vi , both of which operate on the session. Unlike the other I/O name classes, the termin al does not provide refnum features such as property nodes. XNET Cluster I/O Name , where the cluster represents a collection of Each database contains one or more clusters hardware products all connected over a shared cabling harness. In other words, each cluster represents a single CAN network or FlexRay network. For example, the database may 4-592 NI-XNET Hardware and Software Manual ni.com

658 Chapter 4 LabVIEW—Additional Topics NI-XNET API for e the vehicle contains a Body describe a single vehicle, wher CAN cluster, a Powertrain CAN cluster, and a Chassis FlexRay cluster. Use the XNET Cluster I/O name to select a cl uster, access properties, and invoke methods. such as when to use them, refer to For general information about I/O names, XNET I/O Names . User Interface When you select the drop-down arrow on the right side of the I/O name, you see a list of all clusters known to NI-XNET, followed by a separator (line), then a list of menu items. Each cluster in the drop-down lis . The list of clusters String Use t uses the syntax specified in spans all database aliases known to NI-XNET. If you have not added an alias, the list of clusters is empty. You can select a cluster from the drop-down list or by typing the name. As you type a name, LabVIEW selects the closest match from the list. Right-clicking the I/O name displays a menu of LabVIEW items and items specific to NI-XNET. The XNET Cluster I/O name includes the following menu items (in right-click or drop-down menus): • Browse For Database File : If you have an existing CANdb ( .dbc ), FIBEX ( .xml ), LDF ( .ncd ) database file, select this item to add an alias to ), or NI-CAN ( .ldf NI-XNET. Use the file dialog to browse to the database file on your system. When you , NI-XNET adds an alias to the file. The alias uses the filename, such as OK select MyDatabase for a file path of C:\Embedded\Vehicle5\MyDatabase.dbc . If the alias is not unique, NI-XNET appends a number per LabVIEW conventions (for example, MyDatabase 2 ). After adding the alias, you can select the objects in that database from any NI-XNET I/O name. : If you do not have an existing database file, select this item to • New XNET Database . You can use the NI-XNET to Database Editor launch the NI-XNET Database Editor to a file. When you save the file, the create objects for the database and then save NI-XNET Database Editor also adds an alias. Therefore, after you save from the editor, the clusters in the database become available in the XNET Cluster I/O name drop-down list. • Edit XNET Database : If you selected a cluster using th e I/O name, select this item to launch the NI-XNET Database Editor with that cluster’s database file. You can use the editor to make changes to the da tabase file, including the cluster. : Select this menu item to open a dialog for managing aliases. Manage Database Aliases • You can review your list of aliases and asso ciated file paths, remove an alias (without deleting the file), and add new aliases. 4-593 © National Instruments NI-XNET Hardware and Software Manual

659 Chapter 4 LabVIEW—Additional Topics NI-XNET API for ou can right-click the RT target within If you are using LabVIEW Real-Time (RT), y and select the Connect menu item. This connects to the RT target over LabVIEW Project the user interface of NI-XNET I/O names to operate remotely. TCP/IP, which in turn enables If you open the dialog while connected to an RT ta rget, the dialog provides features Manage for reviewing the list of databases on the RT target, deploying a new database from Windows to the RT target, and undeploying a database (removing an alias and file from RT target). String Use Use one of two syntax conventions for the string in the XNET Cluster I/O name: • . The first syntax convention is the most complete, in that it contains the name of a database alias, followed by a dot separator, followed by the name of the cluster within that database. Use this syntax with FIBEX files, which contain multiple named clusters. The second syntax convention uses the database alias only. This is supported for CANdb ( .dbc ), LDF ( .ldf ), and NI-CAN ( .ncd ) files, which always contain a single unnamed cluster. Lowercase letters, uppercase letters, numbers, underscore (_), and space ( ) are valid acters are not sup . Period (.) and other special char ported within the characters for is used as the filename portion of an internal filepath name. Because the (that is, absolute path and file extension removed), it must use the minimum file conventions for all operating systems. The al ias name is not case sensitive. Lowercase letters, uppercase letters, numbers, a nd the underscore (_) are valid characters for . The space ( ), period (.), and other speci al characters are not supported within the cluster name. The cluster name must begin w ith a letter (uppercase or lowercase) or underscore, and not a number. The cluster name is limited to 128 characters. The cluster name is case sensitive. For FIBEX ( name is stored in the database file. For CANdb .xml ) files, the ( ), LDF ( .ldf ), or NI-CAN ( .ncd ) files, no name is stored in the file, so .dbc Cluster NI-XNET uses the name when a name is required. You can use the XNET Cluster I/O name string as follows: • XNET Create Session (Frame In Strea m, Frame Out Stream, Generic).vi : The stream I/O sessions transfer an arbitrary sequence of frames on the cluster, so only the XNET Cluster is required for configuration (n ot specific frames). The Generic instance provides advanced features to pass in data base object names as strings, including the cluster. Within Create Session, NI-XNET opens the database file, reads information for the cluster, and then closes the database. 4-594 NI-XNET Hardware and Software Manual ni.com

660 Chapter 4 LabVIEW—Additional Topics NI-XNET API for • Open Refnum : LabVIEW can open the XNET Cluster I/O name automatically. Wire the I/O name to a property node or VI, and the refnum is opened prior to the first use. Refnum Use You can use the XNET Cluster I/O name refnum as follows: • XNET Cluster Property Node : The cluster property node provides information about its contents, such as the list of all XNET Fr ames. This property nod e is the most common es needed to query use case for the XNET Cluster I/O name, because it provides the featur and/or edit the cluster contents in the database file. Create (ECU, Frame) : If you are creating a new database, call this VI to create a new • XNET ECU or Frame within the cluster. XNET Database I/O Name To communicate with hardware products on the external CAN/FlexRay/LIN network, NI-XNET applications must understand how that hardware communicates in the actual embedded system, such as the vehicle. This em bedded communication is described within a standardized file, such as CANdb ( ) for .dbc ) or NI-CAN ( .ncd ) for CAN, or FIBEX ( .xml FlexRay. Within NI-XNET, this file is referred to as a database. The database contains many e embedded system. stinct entity in th object classes, each of which describes a di database, access properties, and invoke methods Use the XNET Database I/O name to select a (for example, save). For general information abou t I/O names, such as when to use them, refer to XNET I/O Names . When using a database file with NI-XNET, you can specify the file path or specify an alias to the file. The alias provides a shorter, easier-to-r ead name for use within your application. For example, for the file path C:\Documents and Settings\All Users\Documents\ Vehicle5\MyDatabase.dbc . In addition to , you can add an alias named MyDatabase improving readability, the alias concept isolat cation from the specific es your LabVIEW appli application uses the alias MyDatabase , and you change its file filepath. For example, if your path to , your LabVIEW application C:\Embedded\Vehicle5\MyDatabase.dbc continues to run without change. The alias co st NI-XNET features, ncept is used in mo including deployment of database files to LabVIEW Real-Time targets. For more information about aliases, refer to What Is an Alias? . User Interface side of the I/O name, you see a list of all When you select the drop-down arrow on the right database aliases known to NI-XNET, followed by a separator (line), then a list of menu items. If you have not added an alias, the first list is empty. You can select an alias from the drop-down list or by typing the name. As you type a name, LabVIEW selects the closest match from the list. 4-595 © National Instruments NI-XNET Hardware and Software Manual

661 Chapter 4 LabVIEW—Additional Topics NI-XNET API for Right-clicking the I/O name displays a menu of LabVIEW items and items specific to NI-XNET. The XNET Database I/O name provides the following menu items in right-click and drop-down menus: • Browse For Database File : If you have an existing CANdb ( .dbc ), FIBEX ( .xml ), LDF ( .ldf ), or NI-CAN ( .ncd ) database file, select this item to add an alias to NI-XNET. Use the file dialog to browse to the database file on your system. When you select OK, NI-XNET adds an alias to the file. The alias uses the filename, such as for a file path of MyDatabase C:\Embedded\Vehicle5\MyDatabase.dbc . If the alias is not unique, NI-XNET appends a number per LabVIEW conventions (for example, MyDatabase 2 ). After adding the alias, you can select the objects in that database from any NI-XNET I/O name. • New XNET Database : If you do not have an existing database file, select this item to to launch the NI-XNET Database Editor . You can use the NI-XNET Database Editor create objects for the database and then save to a file. When you save the file, the NI-XNET also adds an alias. Therefore, after you save from the editor, Database Editor the database becomes available in the XNET Database I/O name drop-down list. • Edit XNET Database : If you have selected a database using the I/O name, select this item to launch the NI-XNET Database Editor with that database file. You can use the editor to make changes to the database file. • Manage Database Aliases : Select this menu item to open a dialog to manage aliases. You can review your list of aliases and asso ciated file paths, remove an alias (without deleting the file), and add new aliases. If you are using LabVIEW Real-Time (RT), y ou can right-click the RT target within a Connect menu item. This connects to the RT target over LabVIEW Project and select the TCP/IP, which in turn enables the user interface of NI-XNET I/O names to operate remotely. If you open the Manage dialog while connected to an RT target, the dialog provides features to review the list of databases on the RT target, deploy a new database from Windows to the RT target, and undeploy a database (remove the alias and file from the RT target). String Use Use one of two syntax conventions for the XNET Database I/O name string: • is the database file short name, used as an alias to the complete filepath. This The syntax is the only option available when you se lect a database from the drop-down list or use the menu items. 4-596 NI-XNET Hardware and Software Manual ni.com

662 Chapter 4 LabVIEW—Additional Topics NI-XNET API for Lowercase letters, uppercase letters, numbers, underscore (_), and space ( ) are valid characters for . Period (.) and other special char acters are not sup ported within the name. Because the is used as the filename portion of an internal filepath (that is, absolute path and file extension removed), it must use the minimum file conventions ems. The alias name is not case sensitive. for all operating syst The is the absolute path to the text database file, using the operating system file conventions (such as C:\Embedded\Vehicle5\MyDatabase.dbc ). You can use the syntax to open the database directly , without adding an alias to NI-XNET. Valid characters for include any characters your op erating system supports for an absolute file path. Relative file paths are no t supported. Because speci al characters typically as \ or : ), NI-XNET uses these characters to are required in an absolute filepath (such distinguish the alias syntax from syntax. You can use the XNET Database I/O name string as follows: • XNET Create Session (Generic).vi : The commonly used XNET Create Session.vi nd not the database directly. The Generic instances use signal or frame I/O names a instance provides advanced features to pa ss in database object names as strings, including the database itself. Within Create Session, NI-XNET opens the database file, reads information, and closes the database. • Open Refnum : LabVIEW can open the XNET Database I/O name automatically. Wire the I/O name to a property node or VI, and the refnum is opened prior to the first use. Remove Alias, Deploy, Undeploy : These VIs enable you to manage an existing alias at • run time, much like the Manage Database Aliases dialog. The XNET Database is passed um. These VIs require the alias syntax for the in as a string, and is not opened as a refn XNET Database (not filepath). Refnum Use You can use the XNET Database I/O name refnum as follows: : The database property node provides information on • XNET Database Property Node its contents, such as the list of all XNET Clusters. This property node is the most common use case for the XNET Database I/O name, b ecause it provides the features needed to query and/or edit all database contents from the top-level down to all other objects. • XNET Database Create (Cluster).vi : If you are creating a new database, call this VI to create a new XNET Cluster within the database. • : After you set properties for the database or XNET Database Delete (LIN Schedule).vi any of its objects, call this VI to save those changes to the file. The file is saved in the FIBEX format. 4-597 © National Instruments NI-XNET Hardware and Software Manual

663 Chapter 4 LabVIEW—Additional Topics NI-XNET API for XNET Device I/O Name Within NI-XNET, the term refers to your National Instruments CAN/FlexRay/LIN device hardware product, such as a PXI or PCI card. Each device contains one or more interf aces to communicate on a CAN/FlexRay/LIN network. User Interface The XNET Device I/O name is not intended for use on VI front panels or as a diagram constant. This I/O name class is returned as the value of the following properties: Devices • XNET System • Device XNET Interface The value these properties return is used as a refnum only. String Use string syntax internally. This syntax may NI-XNET determines the XNET Device I/O name change in future versions, so string display or formation is not recommended. Refnum Use XNET Device You can use the XNET Device I/O name refnum as a device node. The Property Node provides information such as the serial number and list of interfaces contained within the device. LabVIEW closes the XNET device automatically. This occurs when the last top-level VI using the device goes idle (aborted or stops executing). XNET ECU I/O Name ts a single hardware product in the embedded Each Electronic Control Unit (ECU) represen system. The cluster contains one or more ECUs , all connected by a CAN, FlexRay, or LIN cable. Use the XNET ECU I/O name to select an EC U, access properties, and invoke methods. For ch as when to use them, refer to general information about I/O names, su XNET I/O Names . User Interface Select Database to select a cluster within a Before using the ECU I/O name, you must use known database. Because the NI-XNET hardware interface physically connects to a single cluster in your embedded system, it makes sense to limit the list to ECUs contained in a single cluster. 4-598 NI-XNET Hardware and Software Manual ni.com

664 Chapter 4 LabVIEW—Additional Topics NI-XNET API for side of the I/O name, you see a list of all When you select the drop-down arrow on the right ECUs within the selected cluster, followed by a separator (line), then a list of menu items. Each ECU in the drop-down list uses the syntax specified in String Use . You can select an ECU from the drop-down list or by typing the name. As you type a name, LabVIEW selects the closest match from the list. Right-clicking the I/O name displays a menu of LabVIEW items and items specific to NI-XNET. The XNET ECU I/O name provides the following menu items in right-click and drop-down menus: • Select Database : In the drop-down list, this menu item opens a dialog to select a cluster. In the right-click menu, this item provides a pull-right menu to select the cluster. You must select a cluster to specify the fram e selection scope. The list of clusters uses the same list as the . Each cluster name typically is just the XNET Cluster I/O Name only, but when a FIBEX file is used, each . name is database listed. • Browse For Database File : If you have an existing CANdb ( .dbc ), FIBEX ( .xml ), LDF ( ) database file, select this item to add an alias to .ldf ), or NI-CAN ( .ncd NI-XNET. Use the file dialog to browse to the database file on your system. When you OK select , NI-XNET adds an alias to the file. The alias uses the filename, such as for a file path of MyDatabase C:\Embedded\Vehicle5\MyDatabase.dbc . If the alias is not unique, NI-XNET appends a number per LabVIEW conventions (for ). After adding the alias, you MyDatabase 2 can select the objects in that example, database from any NI-XNET I/O name. After adding the alias, it appears in the Select Database list, and the first cluster in the database is selected automatically. : If you do not have an existing database file, select this item to • New XNET Database Database Editor . You can use the NI-XNET to launch the NI-XNET Database Editor to a file. When you save the file, the create objects for the database and then save NI-XNET Database Editor also adds an alias. Therefore, after you save from the editor, the clusters in the database become available in the Select Database list. You must select the desired cluster when you finish using the NI-XNET Database Editor . • Edit XNET Database : If you have selected a cluster using Select Database , select this item to launch the NI-XNET Database Editor with that cluster’s database file. You can use the editor to make changes to the database file, including the ECUs. : Select this menu item to open a dialog to manage aliases. • Manage Database Aliases ciated file paths, remove an alias (without You can review your list of aliases and asso deleting the file), and add new aliases. 4-599 © National Instruments NI-XNET Hardware and Software Manual

665 Chapter 4 LabVIEW—Additional Topics NI-XNET API for ou can right-click the RT target within a If you are using LabVIEW Real-Time (RT), y Connect menu item. This connects to the RT target over LabVIEW Project and select the TCP/IP, which in turn enables the user interface of NI-XNET I/O names to operate ile connected to an RT target, the dialog remotely. If you open the Manage dialog wh view the list of databases on the RT target, deploy a new database provides features to re from Windows to the RT target, and undeploy a database (remove the alias and file from an RT target). String Use Use the following syntax convention for the XNET ECU I/O name string: \n The string contains the ECU na \n ) as a separator, followed by the me, followed by a new line ( selected cluster name. When you drop the I/O name onto your front panel, the control displays only one line by default. This enables the VI e nd user to focus on selecting the , rather than the more complex syntax that includes . Lowercase letters, uppercase letters, numbers, a nd the underscore (_) are valid characters for . The space ( ), period (.), and other speci al characters are not supported within the ercase or lowercase) or underscore, name must begin with a letter (upp ECU name. The name is limited to 128 char acters. The ECU name is case and not a number. The sensitive. For FIBEX ( ) and CANdb ( .dbc .xml ) files, the database file stores the name. ECU specifications are not provided within NI-CAN ( .ncd ) files. is appended to the ECU name to ensure that the XNET ECU I/O name is The unique. LabVIEW requires each me, because each instance is I/O name to use a unique na located using its name. By appending the cluster name, NI-XNET ensures that the entire name is unique in large applications that use multiple NI-XNET interfaces (multiple clusters). The Select Database characters for are the same as the name you selected using , which uses the same syntax convention as the XNET Cluster I/O Name . To view the when the I/O name is displayed, resize its constant/control to show multiple lines. You can use the XNET ECU I/O name string as follows: : LabVIEW can open the XNET ECU I/O name automatically. Wire the Open Refnum • I/O name to a property node or VI, and the refnum is opened prior to the first use. 4-600 NI-XNET Hardware and Software Manual ni.com

666 Chapter 4 LabVIEW—Additional Topics NI-XNET API for Refnum Use You can use the XNET ECU I/O name refnum as follows: • XNET ECU Property Node : The ECU property node provides the list of all frames the ECU transmits and receives. When you are cr eating an application to test a single ECU product, these frame lists help you create sessions for input/output of all frames (or signals) to fully test the ECU behavior. XNET Frame I/O Name Each frame represents a unique unit of data tr ansfer over the cluster cable. The frame bits contain payload data and an iden (signal) content. Only one ECU tifier that specifies the data in the cluster transmits e ach frame, and one or more ECUs receive each frame. For CAN, each frame is identified by its arbitration ID. The XNET Frame Identifier and CAN:Extended Identifier? properties specify this arbitration ID. For FlexRay, each frame is identified by its location within the FlexRay cycle and channels. , FlexRay:Base Cycle , FlexRay:Cycle Repetition The XNET Frame Identifier , FlexRay:Channel Assignment FlexRay:In Cycle Repetitions:Enabled? properties , and specify this location. Use the XNET Frame I/O name to select a fram e, access properties, and invoke methods. For general information about I/O names, su ch as when to use them, refer to XNET I/O Names . User Interface Before using the frame I/O name, you must use to select a cluster within a Select Database known database. Because the NI-XNET hardware interface physically connects to a single cluster in your embedded system, it makes sense to limit the list to frames contained in a single cluster. When you select the drop-down arrow on the right side of the I/O name, you see a list of all frames within the selected clus ter, followed by a separator (line), then a list of menu items. . Each frame in the drop-down list uses the syntax specified in String Use You can select a frame from the drop-down list or by typing the name. As you type a name, LabVIEW selects the closest match from the list. Right-clicking the I/O name displays a menu of LabVIEW items and items specific to NI-XNET. The XNET Frame I/O name includes the following menu items in right-click and drop-down menus: 4-601 © National Instruments NI-XNET Hardware and Software Manual

667 Chapter 4 LabVIEW—Additional Topics NI-XNET API for Select Database • : In the drop-down list, this menu item opens a dialog to select a cluster. In the right-click menu, this item includes a pull-right menu to select the cluster. You must select a cluster to specify the fram e selection scope. The list of clusters uses the same list as the XNET Cluster I/O Name . Each cluster name typically is just the database . name is only, but when a FIBEX file is used, each listed. • Browse For Database File : If you have an existing CANdb ( .dbc ), .xml ), FIBEX ( LDF ( .ldf ), or NI-CAN ( .ncd ) database file, select this item to add an alias to NI-XNET. Use the file dialog to browse to the database file on your system. When you select OK , NI-XNET adds an alias to the file. The alias uses the filename, such as for a file path of MyDatabase C:\Embedded\Vehicle5\MyDatabase.dbc . If the alias is not unique, NI-XNET appends a number per LabVIEW conventions (for example, MyDatabase 2 ). After adding the alias, you can select the objects in that database from any NI-XNET I/O name. Select Database list, and the first cluster in the After adding the alias, it appears in the database is selected automatically. • : If you do not have an existing database file, select this item to New XNET Database Database Editor . You can use the NI-XNET Database Editor to launch the NI-XNET to a file. When you save the file, the create objects for the database and then save NI-XNET Database Editor also adds an alias. Therefore, after you save from the editor, the clusters in the database become available in the Select Database list. You must select the desired cluster when you finish using the NI-XNET Database Editor . , select this • Edit XNET Database : If you have selected a cluster using Select Database item to launch the NI-XNET with that cluster’s database file. You can Database Editor e database file, including the frames. use the editor to make changes to th • Manage Database Aliases : Select this menu item to open a dialog to manage aliases. You can review your list of aliases and asso ciated file paths, remove an alias (without deleting the file), and add new aliases. ou can right-click the RT target within a If you are using LabVIEW Real-Time (RT), y LabVIEW Project and select the menu item. This connects to the RT target over Connect TCP/IP, which in turn enables the user interface of NI-XNET I/O names to operate remotely. If you open the Manage dialog wh ile connected to an RT target, the dialog provides features to re view the list of databases on the RT target, deploy a new database from Windows to the RT target, and undeploy a database (remove the alias and file from the RT target). String Use for the XNET Frame I/O name string: Use the following syntax convention \n 4-602 NI-XNET Hardware and Software Manual ni.com

668 Chapter 4 NI-XNET API for LabVIEW—Additional Topics \n ) as a separator, followed by The string contains the frame name, followed by a new line ( the selected cluster name. When you drop the I/O name onto your front panel, the control displays only one line by default. This enables the VI end , rather than the more user to focus on selecting the . complex syntax that includes nd the underscore (_) are valid characters for Lowercase letters, uppercase letters, numbers, a . The space ( ), period (.), and other special characters are not supported within the name. The name must begin with a letter (uppercase or lowercase) or underscore, and not a number. The name is limited to 1 28 characters. The frame name is case sensitive. For all supported database formats, the database file stores the name. is appended to the frame name to ensure that the XNET Frame I/O name The use a unique name, because each instance is is unique. LabVIEW requires each I/O name to located using its name. By appending the cluster name, NI-XNET ensures that the entire name is unique in large applications that use multiple NI-XNET inte rfaces (multiple clusters). The characters for , Select Database are the same as the name you selected using . To view the XNET Cluster I/O Name which uses the same syntax convention as the when the I/O name is displayed, resize its constant/control to show multiple lines. You can use the XNET Frame I/O name string as follows: • XNET Create Session (Frame In Queued , Frame In Single-Point, Frame Out Queued, Frame Out Sing le-Point, Generic).vi : The queued I/O sessions transfer a sequence of values for a single frame in the cl uster. The single-point I/O sessions transfer vanced features to the recent value for a list of frames. The Gene ric instance provides ad pass in database object names as strings, including one or more frames. For all of these instances, the XNET Frame I/O name is passed in as input, but is used as a string. Within Create Session, NI-XNET opens the database f ile, reads information for the frames, and closes the database. • Open Refnum : LabVIEW can open the XNET Frame I/O name automatically. Wire the I/O name to a property node or VI, and the refnum is opened prior to the first use. Refnum Use You can use the XNET Frame I/O name refnum as follows: • XNET Frame Property Node : The frame property node provides the information such as the network identification, number of payl oad bytes, and the list of signals within the frame. : If you are creating a new database, call XNET Database Create (Signal, Subframe).vi • this VI to create a new XNET Signal or Subframe within the frame. 4-603 © National Instruments NI-XNET Hardware and Software Manual

669 Chapter 4 LabVIEW—Additional Topics NI-XNET API for XNET Interface I/O Name The XNET interface represents a single CAN, Flex Ray, or LIN connector (port) on the device. Within NI-XNET, the interface is the object us ed to communicate with external hardware described in the database. When you create an NI-XNET session, you specify a physical and interface and a cluster. Because the cluster represents a logical connection between the NI single physical cable harness, it does not make sense to have the NI interface connected to multiple clusters simultaneously. The XNET interface I/O name is used to select an interface to pass to XNET Create Session.vi , and to read hardware information properties. For general information about I/O names, such as when you can use them, refer to XNET I/O Names . User Interface When you select the drop-down arrow on the right side of the I/O name, you see a list of all interfaces available in your system. You can select an interface from the drop-down list or by typing the name. As you type a name, LabVIEW selects the closest match from the list. You can type the name of an interface that doe stem. For example, you s not exist in your sy can type CAN4 even if only CAN1 and CAN2 exist in your system. The check for an actual at runtime (for exampl e, within a session). CAN4 interface does not occur until it is used ou can right-click the RT target within If you are using LabVIEW Real-Time (RT), y LabVIEW project and select Connect . This connects to the RT target over TCP/IP, which in turn enables the user interface of NI-XN ET I/O names to operate remotely. The XNET until you connect the RT target. When interface drop-down list shows (target disconnected) the RT target is connected, th aces on that RT target (for e drop-down list shows all interf example, a PXI chassis). When you right-click the I/O name, the menu contains LabVIEW items including I/O Name . Use this menu item to filter the interface names shown in the I/O name. You can Filtering show all interfaces, CAN only, FlexRay only, or LIN only. The selected filtering is saved along with the VI that uses the I/O name. is available at edit-time only, before you run your VI. This is done under I/O Name Filtering the assumption that if you filter for a specific protocol, the code in the VI block diagram works with that protocol only. Therefore, you do not want to allow the VI end users to select a different protocol at runtime. 4-604 NI-XNET Hardware and Software Manual ni.com

670 Chapter 4 LabVIEW—Additional Topics NI-XNET API for String Use Use one of two syntax conventions for th e string in the XNET Interface I/O name: rface or FlexRay for a FlexRay interface. The The protocol is either CAN for a CAN inte protocol name is not case sensitive. The number identifies the specific interface with in the scope of the protocol. The numbering starts at 1. For example, if you have a two-port CAN device and a two-port FlexRay1 , the interface names will be FlexRay device in your system , and CAN1 , CAN2 , . FlexRay2 Although you can change the interface number within MAX, the typical practice is to allow NI-XNET to select the number automa tically. NI-XNET always starts at 1 and increments for each new interface found. If you do not change the numb er in MAX, and your system always uses a single two-port CAN devi ce, you can write all of your applications to AN card exists in your system, NI-XNET uses assume CAN1 and CAN2. For as long as that C ce, even if new CAN cards are added. the same interface numbers for that devi You can use the XNET Interface I/O name string as follows: XNET Create Session.vi : All XNET Create Session.vi instances use the interface I/O • name to specify the interface for the session’s I/O. Within XNET Create Session.vi , NI-XNET opens the interface and configures the hardware for the session’s I/O communication. Refnum Use The XNET interface refnum always is opened a nd closed automatically. When you wire the I/O name to one of the following nodes, LabVIEW opens a refnum for the interface. The lly when it is no longer used . The XNET interface refnum refnum is closed automatica ation and identification, prior to using the interface within a features are for hardware inform session. You can use the XNET Frame I/O Name refnum as follows: : The interface property node • XNET Interface Property Node provides information for the hardware, such as the port number next to the connector. • Blink : If no session is in use for the interface, you can use this VI to identify a specific interface within a large system (for exampl e, chassis with multiple CAN devices). XNET Session I/O Name The XNET Session represents a connect ion between your National Instruments CAN/FlexRay/LIN hardware and hardware products on the external CAN/FlexRay/LIN ssions to read and write I/O data. network. Your application uses se 4-605 © National Instruments NI-XNET Hardware and Software Manual

671 Chapter 4 LabVIEW—Additional Topics NI-XNET API for Use the session class I/O name primarily for se ssions created at edit time using a LabVIEW project. When you create a session at run time with XNET Create Session.vi , the I/O name serves only as a refnum (its string is irrelevant). Use the XNET Session I/O name to select a session defined in a LabVIEW project, for use XNET Write.vi . For general information about I/O with methods such as XNET Read.vi or XNET I/O Names names, such as when to use them, refer to User Interface When you select the drop-down arrow on the right side of the I/O name, you see a list of all available sessions. If you are using a VI within a LabVIEW project , the available sessions are listed under the VI target ( RT or My Computer ). If you are using a VI within a built application ( .exe ), the available sessions are in the NI-XNET configuration file ( ) the nixnetSession.txt LabVIEW build generates. You can select a session from the drop-down list or by typing the name. As you type a name, LabVIEW selects the closest match from the list. If you are using LabVIEW Real-Time (RT), y ou can right-click the RT target within a LabVIEW project and select the Connect menu item. This connects to the RT target over TCP/IP, which in turn enables the user interface of NI-XNET I/O names to operate remotely. The XNET session drop-down list shows (target disconnected) until you connect the RT target. When the RT target is connected, the drop-down list shows all sessions on that RT target (for example, PXI chassis). When you right-click the I/O name, the menu contains LabVIEW items and the following items: Edit XNET Session : This item opens the Properties di • alog for the selected session. You properties and select OK to save those changes in the project. This can change the session menu item is available at edit time only, before you run your VI. New XNET Session • : This launches the wizard to create a new XNET Session. The new session is created under the same target as th e current VI. This menu item is available at edit time only, before you run your VI. String Use Use a session name from the drop-down list. , including special LabVIEW conventions for names in a project allow any character characters such as space ( ) and slash (/). The session name is case sensitive. 4-606 NI-XNET Hardware and Software Manual ni.com

672 Chapter 4 NI-XNET API for LabVIEW—Additional Topics The XNET Session I/O name string is not used directly, in that it always is opened automatically for use as a refnum. Refnum Use The XNET Session refnum always is opened an d closed automatically. When you wire the I/O name to a node, LabVIEW opens a refnum for the session. The refnum is closed automatically when your top-level VIs are no longer executing (idle). You also can close the . refnum by calling XNET Clear.vi core NI-XNET functionality, in that you use The XNET Session refnum features represent the the session to read and write data on the embedded network using the following property node and VIs: XNET Session Property Node : Use the session property node to change the session • configuration. • : Read data for an input session and read state information for the session XNET Read.vi interface. • : Write data for an output session. XNET Write.vi XNET Start.vi , • , and XNET Flush.vi : Control the session and buffer XNET Stop.vi states. • : Handle notification of events that XNET Create Timing Source.vi and XNET Wait.vi occur in the session. XNET Connect Terminals.vi and XNET Disconnect Terminals.vi : • Connect/disconnect sync hronization terminals. • XNET Clear.vi : Close the session refnum, including stopping all I/O. If this VI is not called, LabVIEW closes the refnum automatical ly when your top-level VIs are no longer executing (idle). XNET Signal I/O Name Each frame contains zero or more values, each of which is called a signal. For example, the first two bytes of a frame payload may repres the third payload byte ent a temperature, and may represent a pressure. Within the database, each signal specifies its name, position, and length of the raw bits in the frame, and a scalin g formula to convert raw bits to/from a physical unit. The physical unit uses a LabVIEW double-precision floating-point numeric type. The signal is the highest level of abstraction for embedded networks. When you use an XNET Session to read/write signal values as physical units, your application does not need to be concerned with protocol (CAN/FlexR ay/LIN) details and frame encoding. Use the XNET Signal I/O name to select a sign al, access properties, and invoke methods. For XNET I/O Names ch as when to use them, refer to . general information about I/O names, su 4-607 © National Instruments NI-XNET Hardware and Software Manual

673 Chapter 4 NI-XNET API for LabVIEW—Additional Topics User Interface Before using the signal I/O name, you must use Select Database to select a cluster within a known database. Because the NI-XNET hardware interface physically connects to a single cluster in your embedded system, it makes sense to limit the list to signals contained in a single cluster. side of the I/O name, you see a list of all When you select the drop-down arrow on the right signals within the selected cluster, followed by a separator (line), then a list of menu items. String Use Each signal in the drop-down list uses the syntax specified in . You can select a signal from the drop-down list or by typing the name. As you type a name, LabVIEW selects the closest match from the list. Right-clicking the I/O name displays a menu of LabVIEW items and items specific to NI-XNET. The XNET Signal I/O name provides the following menu items in right-click and drop-down menus: Select Database • : In the drop-down list, this menu item opens a dialog to select a cluster. In the right-click menu, this item provides a pull-right menu to select the cluster. You must select a cluster to specify the signal selection scope. The list of clusters uses the same list as the XNET Cluster I/O Name . Each cluster name typically is just the only, but when a FIBEX file is used, each database . name is listed. • Browse For Database File : If you have an existing CANdb ( .xml ), FIBEX ( .dbc ), LDF ( ), or NI-CAN ( .ncd ) database file, select this item to add an alias to .ldf NI-XNET. Use the file dialog to browse to the database file on your system. When you select OK , NI-XNET adds an alias to the file. The alias uses the filename, such as MyDatabase for a file path of C:\Embedded\Vehicle5\MyDatabase.dbc . If the alias is not unique, NI-XNET appends a number per LabVIEW conventions (for example, MyDatabase 2 ). After adding the alias, you can select the objects in that database from any NI-XNET I/O name. After adding the alias, it appears in the Select Database list, and the first cluster in the database is selected automatically. New XNET Database : If you do not have an existing database file, select this item to • launch the NI-XNET Database Editor . You can use the NI-XNET Database Editor to create objects for the database and then save to a file. When you save the file, the NI-XNET Database Editor also adds an alias. Therefore, after you save from the editor, the clusters in the database become available in the Select Database list. You must select the desired cluster when you finish using the NI-XNET . Database Editor 4-608 NI-XNET Hardware and Software Manual ni.com

674 Chapter 4 LabVIEW—Additional Topics NI-XNET API for • Edit XNET Database : If you have selected a cluster using Select Database , select this item to launch the NI-XNET Database Editor with that cluster’s database file. You can use the editor to make changes to the database file, including the signals. • Manage Database Aliases : Select this menu item to open a dialog to manage aliases. You can review your list of aliases and asso ciated file paths, remove an alias (without deleting the file), and add new aliases. If you are using LabVIEW Real-Time (RT), y ou can right-click the RT target within a Connect menu item. This connects to the RT target over LabVIEW Project and select the TCP/IP, which in turn enables the user interface of NI-XNET I/O names to operate remotely. If you open the Manage dialog wh ile connected to an RT target, the dialog provides features to re view the list of databases on the RT target, deploy a new database from Windows to the RT target, and undeploy a database (remove the alias and file from the RT target). String Use Use one of two syntax conventions for the XNET Signal I/O name string: • \n \n • . Use the first syntax convention when the signal name is unique within the cluster (not used in gn for signal names, because it provides a multiple frames). This is the recommended desi e signal, followed by a new line The string contains the name of th clear and simple syntax. ( \n ) as a separator, followed by the selected cluster name. Use the second syntax convention when the signal name is used in multiple frames. The string contains the name of frame, fo llowed by a dot separator, foll owed by the text of the first syntax convention (signal name and selected cluster). When you drop the I/O name onto your front panel, the control displays only one line by , rather than the more default. This enables the VI end user to focus on selecting the complex syntax that includes . nd the underscore (_) are valid characters for Lowercase letters, uppercase letters, numbers, a . The space ( ), period (.), and other speci al characters are not supported within the name must begin with a letter signal name. The (uppercase or lowercase) or underscore, and not a number. The name is limited to 128 characters. The signal name is case sensitive. For all supported database formats, the name is stored in the database file. sure that the XNET Signal I/O name is appended to the signal name to en The use a unique name, because each instance is is unique. LabVIEW requires each I/O name to located using its name. By appending the cluster name, NI-XNET ensures that the entire name 4-609 © National Instruments NI-XNET Hardware and Software Manual

675 Chapter 4 LabVIEW—Additional Topics NI-XNET API for is unique in large applications that use multiple NI-XNET interfaces (multiple clusters). The , characters for are the same as the name you selected using Select Database which uses the same syntax convention as the XNET Cluster I/O Name . To view the when the I/O name is displayed, resize its constant/control to show multiple lines. You can use the XNET Signal I/O name string as follows: XNET Create Session (Signal In Single-Poi nt, Signal In Waveform, Signal In XY, • Signal Out Single-Point, Signal Out Waveform, Signal Out XY, Generic).vi : The signals. The waveform I/O single-point I/O sessions transf er the recent value for a list of sessions transfer signal data as LabVIEW waveforms. The XY I/O sessions transfer a sequence of values for each signal in a lis t. The Generic instance provides advanced features to pass in database object names as strings, including one or more signals. For all these instances, the XNET Signal I/O name is passed in as an input, but is used as a XNET Create Session.vi , NI-XNET opens the database file, reads string. Within information for the signals, and closes the database. • : LabVIEW can open the XN ET Signal I/O name automatically. Wire the Open Refnum I/O name to a property node or VI, and the refnum is opened prior to the first use. Refnum Use You can use the XNET Signal I/O name refnum as follows: • XNET Signal Property Node : The signal property node pr ovides information such as the signal position and size in the payload, scaling formula to physical units, and so on. XNET Subframe I/O Name Within your embedded network, some frames ma y use a feature called data multiplexing (also known as mode-dependent messages). The fram e specifies a single signal called the data multiplexer. A specific range of bits within th e multiplexed frame is designated to contain subframes. Each subframe contains a distinct set of signals, referred to as dynamic signals. When a frame is transmitted on the network, the data multip lexer signal value selects the subframe. For example, if the data multiplexer is 0, a subframe with dynamic signals A and B may exist in the last bytes; if the data multiplexer is 1, a subframe with dynamic signals C and D may exist in the same last bytes. Use the XNET Subframe I/O name to access properties for a specific subframe. User Interface The XNET Subframe I/O name is not intended fo r use on VI front panels or as a diagram constant. This I/O name class is returned as the value of the following properties: • XNET Frame Mux:Subframes • Mux:Subframe XNET Signal 4-610 NI-XNET Hardware and Software Manual ni.com

676 Chapter 4 LabVIEW—Additional Topics NI-XNET API for String Use NI-XNET determines the XNET Subframe I/O name string syntax internally. This syntax may change in future versions, so string display or formation is not recommended. You can use the XNET Frame I/O name string as follows: : LabVIEW can open the XNET Subframe I/O name automatically. Wire • Open Refnum the I/O name to a property node or VI, and the refnum is opened prior to the first use. Refnum Use You can use the XNET Frame I/O name refnum as follows: • XNET Subframe Property Node : The XNET Subframe property node provides the information such as the data multiplexer value for the subframe and the list of dynamic signals within the subframe. • XNET Database Create (Dynamic Signal).vi : If you are creating a new database, call this VI to create a new XNET Signal within the frame. This instance creates a dynamic signal contained within the su bframe. To create a static sign al that exists in all frame XNET Database Create (Signal).vi using the parent XNET Frame (not the values, call subframe). XNET Terminal I/O Name Each interface contains vari are for NI-XNET synchronization ous terminals. The terminals s (clocks) to/from the interface hardware. features, to connect triggers and timebase Use the XNET Terminal I/O name to select a string input to the XNET Connect Terminals.vi or XNET Disconnect Terminals.vi , both of which operate on the session. For general information about I/O names, su ch as when to use them, refer to XNET I/O Names . User Interface side of the I/O name, you see a list of all When you select the drop-down arrow on the right terminals any NI-X NET interface uses. You can select a terminal from the drop-down list or by typing the name. As you type a name, LabVIEW selects the closest match from the list. The list of terminals is not specific to a partic ular interface. For example, if you have only a CAN device in your system, the dr op-down list still contains te rminals for FlexRay interfaces. String Use Use a terminal name from the drop-down list. For a description of each name, refer to . XNET Connect Terminals.vi 4-611 © National Instruments NI-XNET Hardware and Software Manual

677 Chapter 4 LabVIEW—Additional Topics NI-XNET API for Lowercase letters, uppercase letters, numbers, a nd the underscore (_) are valid characters for the name. The space ( ), period (.), and other sp ecial characters are not supported within the name. The terminal name is not case sensitive. The terminal name scope always is local to th e XNET interface used within the session that . One of the terminals (source or destination) is on you pass to XNET Connect Terminals.vi cable), and the othe r is within the XNET the trigger bus (PXI backplane or PCI RTSI interface. You can use the XNET Interface I/O name term as follows: XNET Connect Terminals.vi • : Connect a source terminal to a destination terminal on the interface. rminals on the interface. • XNET Disconnect Terminals.vi : Disconnect a pair of te Refnum Use um features such as property nodes. The XNET Terminal does not provide refn XNET LIN Schedule I/O Name y, in that it supports multiple schedules that The LIN protocol is different than CAN or FlexRa determine when frames transmit. You can change the current schedule at runtime. Within a database file, a cluster for LIN contains one or more LIN schedules. Each LIN schedule contains one or more LIN schedule entries. Use the XNET LIN Schedule I/O name to sel ect a schedule, access pr operties, and invoke methods. For general information about I/O names, such as when to use them, refer to XNET . I/O Names User Interface Select Database to select a cluster Before using the LIN Schedule I/O name, you must use within a known database. Because the NI-XNET hardware interface physically connects to a single cluster in your embedded system, it makes sense to limit the list to schedules contained in a single cluster. When you select the drop-down arrow on the right side of the I/O name, you see a list of all LIN schedules within the selected cluster, foll owed by a separator (line), then a list of menu items. String Use . Each schedule in the drop-down lis t uses the syntax specified in You can select a schedule from the drop-down list or by typing the name. As you type a name, LabVIEW selects the closest match from the list. 4-612 NI-XNET Hardware and Software Manual ni.com

678 Chapter 4 LabVIEW—Additional Topics NI-XNET API for Right-clicking the I/O name displays a menu of LabVIEW items and items specific to NI-XNET. The XNET LIN Schedule I/O name provides the following menu items in right-click and drop-down menus: Select Database : In the drop-down list, this menu item opens a dialog to select a cluster. • In the right-click menu, this item provides a pull-right menu to select the cluster. You must select a cluster to specify the LIN schedule selection scope. The list of clusters uses the same list as the XNET Cluster I/O Na me. Each cluster name typically is just the name is . database only, but when a FIBEX file is used, each listed. • Browse For Database File : If you have an existing CANdb ( ), .dbc ), FIBEX ( .xml LDF ( .ldf ), or NI-CAN ( .ncd ) database file, select this item to add an alias to NI-XNET. Use the file dialog to browse to the database file on your system. When you , NI-XNET adds an alias to the file. The alias uses the filename, such as OK select for a file path of MyDatabase If the C:\Embedded\Vehicle5\MyDatabase.dbc. alias is not unique, NI-XNET appends a number per LabVIEW conventions (for ). After adding the alias, you example, MyDatabase 2 can select the objects in that database from any NI-XNET I/O name. After adding the alias, it appears in the Select Database list, and the first cluster in the database is selected automatically. Manage Database Aliases : Select this menu item to open a dialog to manage aliases. • You can review your list of aliases and asso ciated file paths, remove an alias (without deleting the file), and add new aliases. If you are using LabVIEW Real-Time (RT), y ou can right-click the RT target within a LabVIEW Project and select the Connect menu item. This connects to the RT target over TCP/IP, which in turn enables the user interface of NI-XNET I/O names to operate remotely. If you open the Manage dialog wh ile connected to an RT target, the dialog provides features to re view the list of databases on the RT target, deploy a new database from Windows to the RT target, and undeploy a database (remove the alias and file from the RT target). String Use the XNET LIN Schedule I/O name string: Use the following syntax convention for \n ) as a separator, The string contains the LIN schedule name, followed by a new line ( \n followed by the selected cluster name. 4-613 © National Instruments NI-XNET Hardware and Software Manual

679 Chapter 4 LabVIEW—Additional Topics NI-XNET API for When you drop the I/O name onto your front panel, the control displays only one line by default. This enables the VI e nd user to focus on selecting the , rather than the more complex syntax that includes . Lowercase letters, uppercase letters, numbers, a nd the underscore (_) are valid characters for . The space ( ), period (.), and other sp ecial characters are no t supported within name must begin with a letter (uppercase or lowercase) the schedule name. The name is limited to 128 characters. The or underscore, and not a number. The schedule name is case sensitive. For LDF ( name. The NI-CAN ( ), the database file stores the .ncd .ldf ) and CANdb ( .dbc ) file formats do not support LIN. The current version of NI-XNET does not support LIN with FIBEX ( .xml ). is appended to the schedule name to ensure that the XNET LIN Schedule The I/O name is unique. LabVIEW requires each I/ O name to use a unique name, because each instance is located using its name. By appending the cluster name, NI-XNET ensures that the rge applications that use multi ple NI-XNET interfaces (multiple entire name is unique in la clusters). The characters for are the same as the name you selected using Select Database , which uses the same syntax convention as the XNET Cluster I/O Name. To view the when the I/O name is displayed, resize its constant/control to show multiple lines. You can use the XNET LIN Schedule I/O name string as follows: Schedule I/O name automatically. • Open Refnum : LabVIEW can open the XNET LIN Wire the I/O name to a property node or VI, and the refnum is opened prior to the first use. • Write (LIN Schedule Change) : While running your session, you can change the currently running LIN schedule. You wire the XNET LIN Schedule I/O name to XNET as a string to specify the schedule to execute. Write (State LIN Schedule Change).vi Refnum Use You can use the XNET LIN Schedule I/O name refnum as follows: • XNET LIN Schedule Property Node : The LIN schedule property node provides the list of all schedule entries, plus other aspects of the schedule such as run mode. XNET LIN Schedule Entry I/O Name Each LIN Schedule contains one or more entries, or slots. Each entry in turn contains one or A single frame can be located in transmit during the entry’s time slot. more frames that can multiple LIN schedules and within multiple LIN schedule entries. 4-614 NI-XNET Hardware and Software Manual ni.com

680 Chapter 4 LabVIEW—Additional Topics NI-XNET API for Use the XNET LIN Schedule Entry I/O name to access properties for a specific schedule entry. User Interface The XNET LIN Schedule Entry I/O name is not intended for use on VI front panels or as a diagram constant. This I/O name class is retu rned as the value of the XNET LIN Schedule Entries property. String Use NI-XNET determines the XNET LIN Schedule Entry I/O name string syntax internally. This ring display or formation is not recommended. syntax may change in future versions, so st You can use the XNET LIN Schedule Entry I/O name string as follows: : LabVIEW can open the XNET LIN Schedule Entry I/O name • Open Refnum automatically. Wire the I/O name to a property node or VI, and the refnum is opened prior to the first use. Refnum Use You can use the XNET LIN Schedule Entry I/O name refnum as follows: : The XNET LIN Schedule Entry property • XNET LIN Schedule Entry Property Node ation such as the entry type, list node provides the inform of frames transmitted, and so on. • XNET Database Create (LIN Schedule Entry).vi : If you are creating a new database, call this VI to create a new XNET LIN Schedule Entry within the LIN schedule. XNET PDU I/O Name Many FlexRay networks use the concept of a Protocol Data Unit (PDU) to implement ntainer of signals. You can use a single PDU configurations similar to CAN. The PDU is a co ster timing. A single frame can contain multiple PDUs, each within multiple frames for fa updated independently. For more information, refer to Protocol Data Units (PDUs) in NI-XNET . Use the XNET PDU I/O name to select a PDU, access properties, and invoke methods. For general information about I/O names, su ch as when to use them, refer to XNET I/O Names . User Interface Before using the PDU I/O name, you must use Select Database to select a cluster within a known database. Because the NI-XNET hardware interface physically connects to a single cluster in your embedded system, it makes sense to limit the list to PDUs contained in a single cluster. 4-615 © National Instruments NI-XNET Hardware and Software Manual

681 Chapter 4 LabVIEW—Additional Topics NI-XNET API for side of the I/O name, you see a list of all When you select the drop-down arrow on the right PDUs within the selected cluster, followed by a separator (line), then a list of menu items. Each PDU in the drop-down list uses the syntax specified in String Use . You can select a PDU from the drop-down list or by typing the name. As you type a name, LabVIEW selects the closest match from the list. Right-clicking the I/O name displays a menu of LabVIEW items and items specific to NI-XNET. The XNET PDU I/O name includes the following menu items in right-click and drop-down menus: • Select Database : In the drop-down list, this menu item opens a dialog to select a cluster. In the right-click menu, this item provides a pull-right menu to select the cluster. You must select a cluster to specify the PDU se lection scope. The list of clusters uses the same list as the . Each cluster name typically is just the database XNET Cluster I/O Name . name is listed. only, but when a FIBEX file is used, each • Browse For Database File : If you have an existing CANdb ( .dbc ), FIBEX ( .xml ), LDF ( .ldf ), or NI-CAN ( .ncd ) database file, select this item to add an alias to NI-XNET. Use the file dialog to browse to the database file on your system. When you select OK , NI-XNET adds an alias to the file. The alias uses the filename, such as for a file path of MyDatabase . If the C:\Embedded\Vehicle5\MyDatabase.dbc alias is not unique, NI-XNET appends a number per LabVIEW conventions (for MyDatabase 2 ). After adding the alias, you can select the objects in that example, database from any NI-XNET I/O name. After adding the alias, it appears in the Select Database list, and the first cluster in the database is selected automatically. • New XNET Database : If you do not have an existing database file, select this item to launch the NI-XNET Database Editor . You can use the NI-XNET Database Editor to create objects for the database and then save to a file. When you save the file, the also adds an alias. Therefore, NI-XNET Database Editor after you save from the editor, the clusters in the database become available in the Select Database list. You must select Database Editor . the desired cluster when you finish using the NI-XNET Edit XNET Database : If you have selected a cluster using Select Database , select this • item to launch the NI-XNET Database Editor with that cluster's database file. You can use the editor to make changes to the database file, including the signals. • Manage Database Aliases : Select this menu item to open a dialog to manage aliases. You can review your list of aliases and asso ciated file paths, remove an alias (without deleting the file), and add new aliases. If you are using LabVIEW Real-Time (RT), y ou can right-click the RT target within a LabVIEW Project and select the menu item. This connects to the RT target over Connect 4-616 NI-XNET Hardware and Software Manual ni.com

682 Chapter 4 LabVIEW—Additional Topics NI-XNET API for TCP/IP, which in turn enables the user interface of NI-XNET I/O names to operate remotely. If you open the Manage dialog while connected to an RT target, the dialog provides features to re view the list of databases on the RT target, deploy a new database from Windows to the RT target, and undeploy a database (remove the alias and file from the RT target). String Use Use the following syntax convention for the XNET PDU I/O name string: \n The string contains the PDU na me, followed by a new line ( \n ) as a separator, followed by the selected cluster name. When you drop the I/O name onto your front panel, the control displays only one line by nd user to focus on selecting the , rather than the more default. This enables the VI e complex syntax that includes . nd the underscore (_) are valid characters for Lowercase letters, uppercase letters, numbers, a . The space ( ), period (.), and other speci al characters are not supported within the name. The name must begin with a lette r (uppercase or lowercase) or name is limited to 128 characters. The PDU name underscore, and not a number. The is case sensitive. For all supported database formats, the database file stores the name. is appended to the PDU name to ensure that the XNET PDU I/O name is The unique. LabVIEW requires each I/O name to use a unique na me, because each instance is located using its name. By appending the cluster name, NI-XNET ensures that the entire name that use multiple NI-XNET inte is unique in large applications rfaces (multiple clusters). The characters for are the same as the name you selected using Select Database , . To view the XNET Cluster I/O Name which uses the same syntax convention as the when the I/O name is displayed, resize its constant/control to show multiple lines. You can use the XNET PDU I/O name string as follows: • XNET Create Session (Frame In PDU Queu ed, Frame In PDU Single-Point, Frame Out PDU Queued, Frame Out PD U Single-Point, Generic).vi : These modes operate on PDUs in a manner equivalent to frames. The queued I/O session s transfer a sequence of values for a single PDU in the cluster. Th e single-point I/O sessi ons transfer the recent value for a list of PDUs. The Generic instan ce provides advanced features to pass in database object names as strings, including one or more PDUs. For all instances, the XNET PDU I/O name is passed in as input, but Within Create Session, is used as a string. DUs, and closes the NI-XNET opens the database file, reads in formation for the P database. 4-617 © National Instruments NI-XNET Hardware and Software Manual

683 Chapter 4 LabVIEW—Additional Topics NI-XNET API for : LabVIEW can open the XNET PDU I/O name automatically. Wire the Open Refnum • I/O name to a property node or VI, and the refnum is opened prior to the first use. Refnum Use You can use the XNET PDU I/O name refnum as follows: • XNET PDU Property Node : The PDU property node provides information such as the PDU position and size in the frame, contained signals, and so on. ni.com 4-618 NI-XNET Hardware and Software Manual

684 5 NI-XNET API for C XNET API for C and describes the NI-XNET C This chapter explains how to use the NI- functions and properties. Getting Started This section helps you get started using NI-XNET for C. It includes information about using NI-XNET within LabWindows/CVI and Microsoft Visual C, and C examples. LabWindows/CVI . This opens a dialog To view the NI-XNET function panels, select Library»NI-XNET use the Library Tree to access all the function containing the NI-XNET classes. You also can panels quickly. To use the NI-XNET Library Tree, go to View and make sure that Library is selected. In the Library Tree, expand Libraries and scroll down to NI-XNET . Tree n panel by right-clicki ng the function panel You can access the help for each class or functio Class Help... or Function Help... . and selecting Examples NI-XNET includes LabWindows/CVI examples th at demonstrate a wide variety of use cases. The examples build on the basic concepts to demonstrate more in-depth use cases. To view the NI-XNET examples, select Find Examples... Help from the LabWindows/CVI task, NI-XNET examples are under menu. When you browse examples by Hardware Input . The examples are grouped by protocol in CAN and Output FlexRay , and LIN folders. , Although you can write NI-XNET appli cations for either protocol , and each folder contains shared examples, this organization helps you find examples for your specific hardware product. A few examples are suggested to get started with NI-XNET. For CAN (at Hardware Input and Output»CAN»NI-XNET»Basic ): • CAN Signal Input Single Point with CAN Signal Output Single Point . CAN Signal Output Waveform • CAN Signal Input Waveform with . CAN Frame Input Stream • with any output example. National Instruments NI-XNET Hardware and Software Manual 5-1 ©

685 Chapter 5 NI-XNET API for C Hardware Input and Output»FlexRay»Basic For FlexRay (at ): FlexRay Signal Input Single Point with FlexRay Signal Output Single Point • . • FlexRay Signal Input Waveform with FlexRay Signal Output Waveform . • FlexRay Frame Input Stream with any output example. For LIN (at ut»LIN»NI-XNET»Basic ): Hardware Input and Outp • LIN Signal Input Single Point with LIN Signal Output Single Point . • LIN Signal Input Waveform with LIN Signal Output Waveform . with any output example. LIN Frame Input Stream • Open an example project by double-clicking its name. To run the example, select values using the front panel controls, then read the instructions on the front panel to run the examples. Visual C++ 6 The NI-XNET software supports Microsoft Visual C/C++ version 6. The NIEXTCCOMPILERSUPP environment variable is provided as an alias to the C language header file and library location. You can use this variable when compiling and linking an application. For compiling applications that use th e NI-XNET API, you must include the nixnet.h header file in the code. For C applications (files with a .c extension), include the header file by adding a #include to the beginning of the code, such as: #include "nixnet.h" In your project options for compiling, you must include this statement to add a search directory to find the header file: /I "$(NIEXTCCOMPILERSUPP)include" For linking applications, you must add the nixnet.lib file and the following statement to your linker project options to search for the library: /libpath:"$(NIEXTCCOMPILERSUPP)\lib32\msvc" . The reference for each NI-XNET API function is in NI-XNET API for C Reference 5-2 NI-XNET Hardware and Software Manual ni.com

686 Chapter 5 NI-XNET API for C Examples NI-XNET includes C examples that demo nstrate a wide variety of use cases. You can find examples for the C language in the MS Visual C subfolder of the \Users\ Public\Public Documents\National Instruments\NI-XNET\Examples directory on Windows 7 or Windows Vista and the \Documents and Settings\All Users\Shared Documents\National Instruments\NI-XNET\Examples directory on Windows XP. Each example is in a separate folder. A description of each example is in comments at the top of the .c file. Interfaces What Is an Interface? The interface represents a single CAN, FlexRay, or LIN connector on an NI hardware device. Within NI-XNET, the interface is the object us ed to communicate with external hardware described in the database. Each interface name uses the following syntax: The is either CAN for a CAN interface, FlexRay for a FlexRay interface, or LIN for a LIN interface. scope. The identifies the specific interface within the The number numbering starts at 1. For example, if you have a two-port CAN device, a two-port FlexRay device, and a two-port LIN device in CAN1 , CAN2 , interface names are your system, the , FlexRay2 , LIN1 , and LIN2 , respectively. FlexRay1 change the interface number within Measurement & Automation Although you can allow NI-XNET to select the number Explorer (MAX), the typical practice is to automatically. NI-XNET always starts at 1 an d increments for each new interface found. If you do not change the number in MAX, and your system always uses a single two-port CAN device, you can write all your applications to assume CAN1 and CAN2. For as long as that CAN card exists in your system, NI-XNET uses the same interface numbers for that device, even if you add new CAN cards. NI-XNET also uses the term port to refer to the connector on an NI hardware device. The difference between the terms is that port refers to the hardware object (physical), and interface refers to the software object (logical). The benefit of this separation is that you can use the interface name as an alias to any port, so that your application do es not need to change r example, if you have when your hardware configuration changes. Fo a PXI chassis with a CAN1 single CAN PXI device in slot 3, the CAN port labeled Port 1 is assigned as interface . 5-3 © National Instruments NI-XNET Hardware and Software Manual

687 Chapter 5 NI-XNET API for C Later on, if you remove the CAN PXI card and connect a USB device for CAN, the CAN port on the USB device is assigned as interface CAN1 . Although the physical port is in a different place, programs written to use CAN1 work with either hardware configuration without change. How Do I View Available Interfaces? Measurement and Automation Explorer (MAX) Use MAX to view your available NI-XNET ha rdware, including all devices and interfaces. Devices and Interfaces under To view hardware in your local Windows system, select . Each NI-XNET device is listed with the hardware product name, such as My System NI PCI-8517 “FlexRay1, FlexRay2” . sted with the current Select each NI-XNET device to view its physical ports. Each port is li interface name assignment, such as rt, the right window FlexRay1 . When you select a po shows a picture of the device with the port circled and the port LED blinking. The blinking LED assists in identifying a specific port when your system contains multiple instances of the same hardware product (for example, a chassis with five CAN devices). on the right, you can change one property: the interface name. In the selected port’s window fferent interface name than the default. For example, you can Therefore, you can assign a di change the interface for physical port 2 of a PCI-8517 to FlexRay1 instead of FlexRay2. To view hardware in a remote LabVIEW Real-Time system, find the desired system under Remote Systems and select under that system . The features of Devices and Interfaces NI-XNET devices and interfaces are the same as the local system. Databases What Is a Database? For the NI-XNET interface to communicate with hardware products on the external network, NI-XNET must understand the communication in the actual embedded system, such as the vehicle. This embedded communication is desc ribed within a standardized file, such as CANdb ( .dbc ) for CAN, FIBEX ( .xml ) for FlexRay, or LIN Description File ( .ldf ) for LIN. Within NI-XNET, this file is referred to as a . The database contains many database object classes, each of which describes a di stinct entity in th e embedded system. • Database : Each database is represented as a di stinct instance in NI-XNET. Although the database typically is a file, you also can create the database at run time (in memory). • Cluster : Each database contains one or more clusters, where the cluster represents a collection of hardware products connected over a shared cabling harness. In other words, each cluster represents a single CAN, Flex Ray, or LIN network. For example, the 5-4 NI-XNET Hardware and Software Manual ni.com

688 Chapter 5 NI-XNET API for C where the vehicle contains one CAN cluster database may describe a single vehicle, Body , another CAN cluster Powertrain Chassis , and a LIN cluster , one FlexRay cluster PowerSeat . • ECU : Each Electronic Control Un it (ECU) represents a single hardware product in the embedded system. The cluster contains one or more ECUs connected over a CAN, FlexRay, or LIN cable. It is possible for a single ECU to be contained in multiple clusters, in which case it behaves as a gateway between the clusters. • Frame : Each frame represents a unique unit of da ta transfer over the cluster cable. The frame bits contain payload data and an identifie r that specifies the da ta (signal) content. Only one ECU in the cluster transmits (sends ) each frame, and one or more ECUs receive each frame. , each of which is called a signal. Within : Each frame contains zero or more values Signal • the database, each signal specifies its name, posi tion, length of the raw bits in the frame, e physical unit uses and a scaling formula to convert raw bits to/ from a physical unit. Th a double-precision floating-point numeric type. Other object classes include the Subframe , LIN Schedule, and LIN Schedule Entry. What Is an Alias? When using a database file with NI-XNET, you can specify the file path or an alias to the file. ead name for use within your application. The alias provides a shorter, easier-to-r For example, for the file path C:\Documents and Settings\All Users\Documents\Vehicle5\ MyDatabase.dbc you can add an alias named MyDatabase . In addition to improving readability, the alias c file path. For example, if your application concept isolates your application from the specifi uses the alias MyDatabase and you change its file path to C:\Embedded\Vehicle5\MyDatabase.dbc your application continues to run without change. After you create an alias, it exists until you explicitly delete it. If you uninstall NI-XNET, the all (upgrade) NI-XNET, the aliases from the aliases are deleted; however, if you reinst does not delete the database file itself, but previous installation remain. Deleting an alias merely the association within NI-XNET. 5-5 © National Instruments NI-XNET Hardware and Software Manual

689 Chapter 5 NI-XNET API for C Database Programming The NI-XNET software provides various methods for creating your application database configuration. Figure 5-1 shows a process for d eciding the database source. A description of each step in the process follows the flowchart. N o Ye s Already Have File? No Yes No Yes Want to Can I use Use a File? file as is? Create New Edit and Select From Create in File Using Select File Memory Editor Figure 5-1. Decision Process for Choosing Database Source Already Have File? e, the vehicle maker (or the maker’s supplier) If you are testing an ECU used within a vehicl already may have provided a database file. This file likely would be in CANdb, FIBEX, or LDF format. When you have this file, using NI-XNET is relatively straightforward. Can I Use File as Is? Is the file up to date with respect to your ECU(s)? the best choice is to assume Yes and begin If you do not know the answer to this question, using NI-XNET with the file. If you encounter problems, you can use the techniques discussed in Edit and Select to update your application without significant redesign. 5-6 NI-XNET Hardware and Software Manual ni.com

690 Chapter 5 NI-XNET API for C Select From File parameter You can simply pass the names of objects from the database to the List and the database name (alias or filepath) itself to the DatabaseName parameter of nxCreateSession . This uses the selected objects from the database in the session created. Edit and Select There are two options for editing the databa se objects for the NI-XNET session: edit in memory and edit the file. Edit in Memory and nxdbSetProperty Use nxdbFindObject to change properties of selected objects. This changes the representation in memory, but does not save the change to the file. When you pass the object into , the changes in memory (not the original file) nxCreateSession are used. Edit the File Database Editor is a tool for editing database files for use with NI-XNET. The NI-XNET Using this tool, you open an existing file, edit the objects, and save those changes. You can save the changes to the existing file or a new file. e changes you need, you select objects in your application as When you have a file with th described in Select From File . Want to Use a File? If you do not have a usable database file, you can choose to create a file or avoid files altogether for a self-contained application. Create New File Usin g the Database Editor You can use the NI-XNET Database Editor to create a new database file. Once you have a file, Select From File you select objects in your application as described in . As a general rule, for FlexRay applications, using a FIBEX file is recommended. FlexRay mber of complex properties, and storage in communication configuration requires a large nu a file makes this easier to manage. The NI-XNET Database Editor has features that facilitate this configuration. Create in Memory You can use nxdbCreateObject to create new database objects in memory. Using this technique, you can avoid fi les entirely and make your application self contained. You configure each object you cr eate using the property node. E ach class of database object contains required properties Required Properties that you must set (refer to ). 5-7 © National Instruments NI-XNET Hardware and Software Manual

691 Chapter 5 NI-XNET API for C :memory: fies a database that does not The database name is . This special database name speci originate from a file. After you create and configure obj ects in memory, you can use nxdbSaveDatabase to save the objects to a file. This enables you to implement a database editor within your application. Sessions What Is a Session? The NI-XNET session represents a connection between your National Instruments CAN/FlexRay/LIN hardware and hardware products on the external network. Each session config uration includes: • : This specifies the Nati onal Instruments hardware to use. (Refer to What Is an Interface Interface? ) • Database objects : These describe how external ha rdware communicates. (Refer to What Is a Database? ) presentation of I/O data. (Refer to : This specifies the direction and re Session • Mode Modes .) The links above link to detailed information about configuration. The Session Modes section has additional links to sections that explain how to read or wr ite I/O data for each mode. The I/O data consists of values for frames or signals. In addition to read/write of I/O data, you can use the session to interact with the network in other ways. For example, nxReadState includes selections to read the state of communication, such as whether communication has stopped due to error detection defined by the protocol standard. You can use sessions for multiple hardware interfaces. For each interface, you can use multiple input sessions and multiple output sessions simultaneously. The sessions can use different modes. For example, you can use a Signal Input Single-Point session at the same time you use a Frame Input Stream session. The limitations on sessions relate primarily to a specific frame or its signals. For example, if you create a Frame Out put Queued session for frameA , then create a Signal Output ), NI-XNET returns an error. This frameA Single-Point session for frameA.signalB (a signal in combination of sessions is not allowed, because writing data for the same frame with two sessions would result in inconsistent sequences of data on the network. 5-8 NI-XNET Hardware and Software Manual ni.com

692 Chapter 5 NI-XNET API for C Session Modes The session mode specifies the data type (signa ls or frames), direction (input or output), and how data is transferred between your application and the network. The mode is an enumeration of the following: • Signal Input Single-Point Mode : Reads the most recent value received for each signal. This mode typically is used for control or simulation applications, such as Hardware In the Loop (HIL). signal frame is received, • Signal Input Waveform Mode : Using the time when the resamples the signal data to a waveform with a fixed sample rate. This mode typically is used for synchronizing XNET data with DAQmx analog/digital input channels. • Signal Input XY Mode : For each frame received, provides its signals as a value/timestamp pair. This is the recommende d mode for reading a sequence of all signal values. • Signal Output Single-Point Mode : Writes signal values for th e next frame transmit. This mode typically is used for control or simulation applications, such as Hardware In the Loop (HIL). : Using the time when the signal frame is transmitted • Signal Output Waveform Mode according to the database, resamp veform with a fixed sample les the signal data from a wa rate. This mode typically is used for synchronizing XNET data with DAQmx analog/digital output channels. • Signal Output XY Mode : Provides a sequence of signal values for transmit using each frame’s timing as the database specifies. Th is is the recommended mode for writing a sequence of all signal values. • Frame Input Stream Mode : Reads all frames received from the network using a single stream. This mode typically is used for analyzing and/or lo gging all frame traffic in the network. • : Reads data from a dedicated queue per frame. This mode Frame Input Queued Mode enables your application to read a sequence of data specific to a frame (for example, CAN identifier). • Frame Input Single-Point Mode : Reads the most recent value received for each frame. This mode typically is used for control or si mulation applications that require lower level access to frames (not signals). • Frame Output Stream Mode : Transmits an arbitrary seque nce of frame values using a e in the database, but can e not limited to a single fram single stream. The values ar transmit any frame. Frame Output Queued Mode • : Provides a sequence of values for a single frame, for transmit using that frame’s timing as the database specifies. 5-9 © National Instruments NI-XNET Hardware and Software Manual

693 Chapter 5 NI-XNET API for C Frame Output Single-Point Mode • : Writes frame values for the next transmit. This mode typically is used for control or simulation applicat ions that require lower level access to frames (not signals). Conversion Mode : This mode does not use any hardware. It is used to convert data • between the signal representatio n and frame representation. Frame Input Queued Mode This mode reads data from a dedicated queue pe r frame. It enables your application to read a sequence of data specific to a fram e (for example, a CAN identifier). You specify only one frame for the session, and nxReadFrame returns values for that frame only. If you need sequential data for multiple frames, create multiple sessions, one per frame. The input data is returned as an array of frame values. Thes e values represent all values received for the frame sin ce the previous call to nxReadFrame . Example frame that transmits on In this example network, frame C is a cyclic the network once every 2 ms. Frame E is an event-driven frame. Fo r information about cyclic and event-driven frames, refer to Cyclic and Event Timing . Each frame contains two signals, one in th e first byte and another in the second byte. This example uses CAN. The fo llowing figure shows a timeline of a frame transfer on the CAN network, followed by two calls to nxReadFrame (one for C and one for E). Read Read C E C1,2 C3,4 C5,6 C3,4 E5,6 E1,2 E7,8 Time 0 ms 6 ms 7 ms 8 ms 3 ms 2 ms 1 ms 4 ms 5 ms 5-10 NI-XNET Hardware and Software Manual ni.com

694 Chapter 5 NI-XNET API for C The following figure shows the data returned from the two calls to nxReadFrame (two different sessions). The first call to r frame C, and the second call to nxReadFrame returned an array of values fo nxReadFrame frame is displayed with CAN-specific returns an array for frame E. Each elements. For information about the data re turned from the read function, refer to Raw Frame . The example uses hexadecimal C and E as the identifier of each frame. The first Format two payload bytes contain the signal data. The timestamp represents the absolute time when the XNET interface received the frame (end of frame), accurate to microseconds. , this mode effectively sorts Frame Input Stream Mode Compared to the example for the ss them on an individual basis. received frames so you can proce 5-11 © National Instruments NI-XNET Hardware and Software Manual

695 Chapter 5 NI-XNET API for C Frame Input Single-Point Mode This mode reads the most recent value received fo r each frame. It typically is used for control or simulation applications that require lo wer level access to frames (not signals). This mode does not use queues to store each received frame. If the interface receives two frames prior to calling ls for the second frame. nxReadFrame , that read returns signa ames, one for each frame specified for the session. The input data is returned as an array of fr Example frame that transmits on In this example network, frame C is a cyclic the network once every 2 ms. Frame E is an event-driven frame. Fo r information about cyclic and event-driven . frames, refer to Cyclic and Event Timing Each frame contains two signals, one in th e first byte and another in the second byte. The example uses CAN. The foll owing figure shows a timeline of a frame transfer on the CAN network, followed by a single call to nxReadFrame . Each frame contains its name (C or E), followed by the value of its two signals. 1s t 3rd 2nd Read Read Read C3,4 C5,6 C1,2 E5,6 E1,2 E7,8 Time 0 ms 7 ms 8 ms 3 ms 2 ms 1 ms 4 ms 5 ms 6 ms 5-12 NI-XNET Hardware and Software Manual ni.com

696 Chapter 5 NI-XNET API for C The following figure shows the data retu rned from each of the three calls to nxReadFrame . Each frame is displayed with CAN-specific elem ents. For information about the data returned from the read function, refer to Raw Frame Format . The session contains frame data for two frames: C and E. In the data returned from the first call to , frame C contains values 3 and 4 in nxReadFrame its payload. The first reception of frame C values (1 and 2) were lost, because this mode returns the most recent values. In the frame timeline, Time of 0 ms indicates the time at which the session started to receive frames. For frame E, no frame is received prior to the first call to , so the nxReadFrame timestamp is invalid, and the payload is the . For this example we assume that Default Payload the Default Payload is all 0. In the data returned from the second call to nxReadFrame , payload values 3 and 4 are ame has been received since the previous call returned again for frame C, because no new fr to . nxReadFrame . The timestamp for frame C is the same as the first call to nxReadFrame In the data returned from the third call to , both frame C and frame E are nxReadFrame received, so both elements return new values. Frame Input Stream Mode eceived from the network using a This mode reads all frames r single stream. It typically is used for analyzing and/or logging all frame traffic in the network. frames. Because all frames are returned, your The input data is returned as an array of application must evaluate iden tification in each frame (such as a CAN identifier or FlexRay slot/cycle/channel) to interpret the frame payload data. Previously, you could use only one Frame Input Stream session for a given interface. Now, multiple Frame Input Stream sessions can be open at the same time. 5-13 © National Instruments NI-XNET Hardware and Software Manual

697 Chapter 5 NI-XNET API for C While using one or more Frame Input Stream sessions, you can use other sessions with different input modes. Received put Stream sessi ons in addition frames are copied to Frame In to any other applicable input session. For ex ample, if you create a Frame Input Single-Point session for FrameA, then create a Frame Input Stream session, when FrameA is received, its data is returned from the call to nxReadFrame of both sessions. This duplication of incoming frames enables you to analyze ov er level application that uses erall traffic while running a high specific frame or signal data. When used with a FlexRay interface, frames fr om both channels are returned. For example, if a frame is received in a static slot on both ch annel A and channel B, two frames are returned from nxReadFrame . Example In this example network, frame C is a cyclic the network once every frame that transmits on r information about cyclic and event-driven 2 ms. Frame E is an event-driven frame. Fo frames, refer to Cyclic and Event Timing . e first byte and another in the second byte. Each frame contains two signals, one in th The example uses CAN. The foll owing figure shows a timeline of a frame transfer on the CAN network, followed by a single call to nxReadFrame . Each frame contains its name (C or E), followed by the value of its two signals. Read C1,2 C3,4 C3,4 C5,6 E7,8 E1,2 E5,6 Time 0 ms 1 ms 4 ms 5 ms 6 ms 7 ms 8 ms 3 ms 2 ms 5-14 NI-XNET Hardware and Software Manual ni.com

698 Chapter 5 NI-XNET API for C The following figure shows the data returned from nxReadFrame . ray of frames. Each frame is displayed with Frame C and frame E are returned in a single ar CAN-specific elements. For information about the data returned from the read function, refer and E as the identifier of each to Raw Frame Format . This example uses hexadecimal C frame. The signal data is cont ained in the first two payload bytes. The timestamp represents e (end of frame), accurate to XNET interface received the fram the absolute time when the microseconds. 5-15 © National Instruments NI-XNET Hardware and Software Manual

699 Chapter 5 NI-XNET API for C Frame Output Queued Mode This mode provides a sequence of values for a single frame, for tran smit using that frame’s timing as specified in the database. The output data is provided as an array of frame values, to be transmitted sequentially for the frame specified in the session. This mode allows you to specify only one fram e for the session. To transmit sequential values ion for each frame or use the for multiple frames, use a differ ent Frame Output Queued sess . Frame Output Stream Mode The frame values for this mode are stored in a queue, such that every value provided is transmitted. For this mode, NI-XNET transmits each frame a ccording to its properti es in the database. Therefore, when you call nxWriteFrame , the number of payload bytes in each frame value property. The other frame value elements are must match that frame’s Payload Length For CAN interfaces, if the number of payload ignored, so you can leave them uninitialized. th configured in the database, the requested bytes you write is smaller than the Payload Leng number of bytes transmits. If the number of pa yload bytes is larger than the Payload Length d and no frames transmit. For other interfaces, configured in the database, the queue is flushe transmitting a number of payload bytes different than the frame’s payload may cause unexpected results on the bus. Examples the network once every In this example network, frame C is a cyclic frame that transmits on en frame that uses a transmit time (minimum interval) of 2.0 ms. Frame E is an event-driv and event-driven frames, refer to Cyclic and Event 2.5 ms. For information about cyclic Timing . Each frame contains two signals, one in th e first byte and another in the second byte. The example uses CAN. The foll owing figure shows a timeline of a frame transfer on the CAN network. Each frame contains its name (C or E), followed by the value of its two signals. The timeline begins with two calls to nxWriteFrame , one for frame C, followed immediately by another call for frame E. 5-16 NI-XNET Hardware and Software Manual ni.com

700 Chapter 5 NI-XNET API for C Write C5,6 C5,6 C3,4 C1,2 E7,8 E5,8 Time 0 ms 6 ms 5 ms 1 ms 2 ms 4 ms 3 ms 8 ms 7 ms . Each frame is nxWriteFrame The following figure shows the data provided to each call to displayed with CAN-specific elements. For information about the data returned from the write function, refer to . The first array shows data for the session with Raw Frame Format ta for the session with frame E. frame C. The second array shows da 5-17 © NI-XNET Hardware and Software Manual National Instruments

701 Chapter 5 NI-XNET API for C Auto Start? , each session starts within the call Assuming the property uses the default of true to . Frame C transmits followed by frame nxWriteFrame E, both using the frame values from the first element (index 0 of each array). According to the database, frame C transmits on ce every 2.0 ms, and frame E is limited to an event-driven transmit once every 2.5 ms. At 2.0 ms in the timeline, the frame value with bytes 3, 4 is taken from index 1 of the frame C array and used for tr ansmit of frame C. When 2.5 ms have elapsed after acknowledgment of the previous transmit of frame E, the frame value with bytes 5, 8, 0, 0 is taken from index 1 of frame E array and used for transmit of frame E. At 4.0 ms in the timeline, the frame value with bytes 5, 6 is taken from index 2 of the frame C array and used for tr ansmit of frame C. Because there are no more frame values for fram e E, this frame no long er transmits. Frame E is event-driven, so new frame valu es are required for each transmit. Because frame C is a cyclic frame, it transmits repeatedly. Although th ere are no more frame the timeline, and every used again at 6.0 ms in values for frame C, the previous frame value is 2.0 ms thereafter. If is called again, the new frame value is used. nxWriteFrame Frame Output Single-Point Mode This mode writes frame values for the next tr ansmit. It typically is used for control or simulation applications th at require lower level access to frames (not signals). This mode does not use queues to store frame values. If nxWriteFrame is called twice before the next transmit, the transmitted frame uses the value from the second call to . nxWriteFrame The output data is provided as an array of frames, one for each frame specified for the session. ccording to its properti es in the database. For this mode, NI-XNET transmits each frame a Therefore, when you call nxWriteFrame , the number of payload bytes in each frame value must match that frame’s