XCP (protocol) XCP is a successor to CAN Calibration Protocol ( CCP) that was developed back in the mid-1990s. At that time, CAN was the dominant networking system in the automobile industry. Over time, other bus systems such as LIN, MOST and FlexRay emerged and made it necessary to extend the protocol to other transport media.
Danlaw MxVDev integrates with LabVIEW utilizing the MxNet networking infrastructure, which consists of a high-speed data streaming and queuing mechanism. A set of custom LabVIEW with an API implements the MxNet protocol over /IP and provides I/O device and channel enumeration and data transition scheduling for LabVIEW. A complementary signal transform (inserted into the MxTransIt transform graph) enumerates and provides access to the LabVIEW I/O from MxVDev. Data transitions are then received by, queued, and executed on the LabVIEW system via the MxNet dispatcher (protocol machine).MxNet employs a reliable positive-acknowledgment UDP-based protocol designed for use on a high-bandwidth LAN.
For production use, it is recommended that a dedicated and isolated physical network connection be used to connect the system running MxVDev with the system running the LabVIEW VIs, because it is ideal to promoting real-time behavior and avoiding performance degradation from a corporate network.The MxNet protocol works by time-shifting the time-stamps of data transitions into the future so that they are queued up for execution by the LabVIEW environment relative to the LabVIEW clock. This transformation of time provides a real-time buffer between the PC clock and the LabVIEW system clock, and enacts “glitchless” execution of the test-case waveforms, thus overcoming the inherit lack of real-time capabilities of Windows.The VIs are organized into two sets:. A set of low-level API calls that can be used to integrate with a highly customized LabVIEW testing solution. A set of high-level, turn-key, example VIs that create a functional hardware-in-the-loop tester with minimal configuration and modifications.
For example, if CAN hardware is present, the CAN configuration must be updated.These sets of VIs implement back end HIL tester functionality that MxTransIt connector transforms for LabVIEW communicate with (via the MxNet protocol). They expose the available hardware device and I/O channels to MxVDev. LabVIEW on WindowsTo achieve real-time performance, LabVIEW Real-Time is required, but LabVIEW on Windows is also supported.
You can run both MxVDev and LabVIEW simultaneously on one computer, or share the load with MxVDev on one computer, and LabVIEW on another. You can use the same VIs as for the Real-Time system. When you connect to them, instead of a remote IP address, use the IP address of your local machine or 'localhost'.
Some things could be removed, for example you might not need Tasks that Send or Receive CAN messages. Troubleshooting LabVIEWIf you get this error: 'Time structures aren’t allowed in time critical VIs' for a VI, go to ‘VI properties’ and change ‘Execution Properties’ priority to ‘normal priority’. See Example.vi for a top-level of an MxNet on LabVIEW. Enumeration“Enumeration” is the process of identifying available hardware I/O and associating cards and ports of each type with unique identifiers.
This occurs when the VI initializes before any other action is taken. The process of enumeration is:.
MxNet is initialized. A set of VIs determines the available devices and channels and feeds this information to the MxNet data stores. The “active channels” are selected from the list of total available I/O. The active channels and corresponding hardware are opened and passed forward into the main loop. Main-BodyThe main-body consists of four threads:. The UDP traffic thread.
The CAN traffic thread. An I/O thread. A utility thread to handle the Stop buttonUDP ThreadThe UDP packet sending and receiving mechanism is divided into separate I/O threads to prevent being “stuck” if the VIs are pending an operation. This ensures that performance is maintained for the main VI and that any hiccups that occur during IP packet processing do not affect the real-time analog and digital I/O.CAN ThreadSimilar to UDP packet processing threads, the CAN message transmission and reception is divided into separate LabVIEW tasks for performance reasons.
Some of the CAN VIs are blocking calls that have been known to degrade performance of the overall system when they are inline with the I/O logic. This setup will cause a few millisecond delay in CAN messages transmission and processing of incoming messages, but experiments show that this provides the highest quality of service that the existing NI-CAN sub-system is capable of providing.I/O ThreadThe I/O thread is the most time-critical part of the system. This thread processes the MxNet packets to queue CAN messages, queue UDP packets, and process the MxNet transition queue to change the state of the digital and analog I/O pins.Stop ButtonThe stop button has its own thread solely for 'plumbing' reasons so that it is responsive while the other threads are executing. LabVIEW ConnectorThe LabVIEW connector transform provides the bridge between the MxVDev Transform infrastructure and the LabVIEW or LabVIEW RT MxNet HIL system. The LabVIEW connector transform is a web that houses additional LabVIEW transforms to communicate with specific I/O sub-systems. The supported sub-systems at this time are MIO, CAN, CAN Transport, and CCP.In MxTransIt, select the NI LabVIEW/LabVIEW-RT Transform from the Toolbox.The LabVIEW connector connects to either a Windows-based LabVIEW system or a Pharlap-based LabVIEW Real-time system.Debug Logging - Normally this property should set to None unless a requested by a developer. The MxNet VIs are designed and tested to execute on the LabVIEW Real-Time platform.
For supported versions, see.A nominal cycle time of 1ms is achievable with a 2GHz dual-core system. Data Transfer Rate Performance100 transitions per millisecond (50 Stimulus and 50 response transitions) are reliably transmitted between the PC running MxSuite and a PXI chassis running the LabVIEW Real-Time OS. In testing, we observed:. PC: Win7, Intel Xeon CPU W3530 (4 cores) @ 2.80 GHz, 6 GB RAM. CPU utilization averaged at about 25%. LabVIEW Real-Time: LV2011RT, PXI-8108 CORE 2 DUO 2.53 GHz, 2 GB RAM, both cores were 20% busy on average.
Data transmission was via UDP over Ethernet operating at one Gigabit transmission rate. The physical connection was a dedicated Ethernet cable between the two computers. When installing a new version of the MxSuite, the matching DLL must be used with LabVIEW Real-Time. The installation wizard copies the DLL into the MxSuite install directory, for example:C:Program Files (x86)MicroMaxMxSuite 3.36.4.25414HarnessMxNetLabViewRTMxNetLabviewRT.dllCopy this DLL into the directory with your LabVIEW VIs to be deployed on the Real-Time system.To prevent LabVIEW from reusing an old DLL, use this procedure when deploying a LabVIEW project as a start-up application:1.
Browse to /ni-rt/startup/data/ on the LabVIEW RT system.2. Delete /ni-rt/startup/data/MxNetLabviewRT.dll.You can do this using FTP or LabVIEW Real-Time browser utilities.