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.