CAN Class Integration with LabVIEW/TestStand—Wrap in DQMH?

[python007]

Hi everyone,

I’m developing a LabVIEW class for CAN communication with methods like Create Instance, Get Info, Get NMT, Get Node State, Read/Write SDO (single and batch), Set NMT, and more. My goal is to use all these methods from both LabVIEW applications and TestStand sequences, in a way that’s robust and reusable across multiple projects.

I frequently need to read SDOs—for example, every CAN device has a UID at a specific Index, Subindex and Datatype. I want to make these common operations as simple as possible for both LabVIEW and TestStand users.

My main questions:

1. Is it recommended to wrap my CAN communication class in a DQMH module for better integration and reuse in both LabVIEW and TestStand, or should I call the class methods directly?
2. For frequent operations like reading the UID, is it better to add dedicated DQMH request events (e.g., “Read UID”) or just provide helper VIs that call the generic SDO read method with fixed parameters?
3. What are best practices for exposing all class methods to both LabVIEW and TestStand, especially for asynchronous or batch operations?

Any advice, examples, or experiences with DQMH, class design, and integration with both LabVIEW and TestStand would be greatly appreciated!

Thanks in advance!

---

[karen763purvis]

Hello!

Wrapping your CAN class in a DQMH module is recommended for better integration with both LabVIEW and TestStand, especially for asynchronous and reusable operations. For frequent tasks like reading a UID, use dedicated request events to simplify usage. Maintain a clean API layer and use helper VIs for preset parameters and validation to keep the design modular and scalable. 

[Olivier-JOURDAN]

Yes, wrapping a class in a DQMH module is generally an excellent idea.

Regarding the use of the class in both LabVIEW and TestStand, I'd encourage you to explore the TestStandifier tool. This is a free tool made to simplify the use of the DQMH module in TestStand.