Back in the stone age (i.e. NI-CAN 1.2), us LabVIEW 6 programmers had to write our own parsing routines for dynamically-specified data inside a CAN frame. At the driver layer, we were locked-in to only one layer of arbitration. An oft-overlooked but extremely powerful feature in contemporary versions of the NI-CAN drivers handle this automatically.
Example: a BMS (battery managment system) for a hybrid automotive battery broadcasts status information. Status information will always be available on the same Arbitration ID, but– this is the important part– the interpretation of those bytes can vary, depending on other information in the frame. If you have to read Byte 1 to tell you what Bytes 2-8 actually mean, this is the tool you need. Here, Byte 1 is defined as a Mode, and the remaining bytes are decoded according to a lookup definition that is set in MAX. These definitions are portable– they can be created, distributed, and deployed on Windows-based or Real-Time targets.
CAN channel multiplexing drastically simplifies the previously-programmatic solution of sorting out data that can be broadcasted within the same Arbitration ID. Alas, that extra degree of freedom is here.
More information on NI-CAN and multiplexing can be found here at the National Instruments website.