Because I used the same SCPI commands as in my earlier Linux/SCPI project on a Raspberry Pi:  SCPI on a Linux Board - Part 5a: LabVIEW Driver for LAB Switch: Open, Close and Switch functions ,
that project's LabVIEW Virtual Instrument blocks worked straight away with the Pico project. I only had to select a different VISA resource string.

Because the Pico firmware registers as an USBTMC device, it automatically popped up in the Visa resource selection box.

Quite an advance project with Rapberry Pi Pico, I must say. 

I've been playing  a bit with TinyUSB to make an USBTMC device, and I was wondering if you have tried to make a composite device that uses USBTMC and CDC. Since CDC uses IAD, I needed to define class/sub-class/protocol to 0xEF, 0x02, 0x01. But when I tried it, NI-max did not detect the USBTMC device. Then I set the class/subclass/protocol to 0x00, 0x00, 0x00, and everything worked just fine. But as this appears to be non-standard, I'm not sure if it would work well on machines that are not Windows 10. 

I have never tried to make composite tinyUSB firmware. 

The commercial devices I have at home with composite, are usually debuggers. I have USBTMC scopes, psu and dmm.  But they don't enumerate with additional (CDC or other) interfaces. I don't know if TMC and CDC can live together on the same USB...

Thanks Jan.  This is a nice economical method for creating Labview controlled switches.  I remember back in the day we would buy I/O cards directly from National Instruments.  Your method is definitely easier on the wallet.

I don't know if this is useful for your application or not, and maybe you've already considered it; it might be simpler to be able to select one of the modes on power-up, since it may be unlikely that the user wants both methods of communication. It could be selectable by holding down a button, but another option that I've used a few times for similarish-scenarios (not USBTMC related) is for the microcontroller on power-up to wait a few seconds for a connection using one protocol. If it doesn't see that, then it switches to the other protocol. 

I suppose in the worse case, if its not supported, one could expose them as connected to a virtual hub. I haven't tried that yet though, not sure how much work that may require. In the meantime I'll just use the 0x00, 0x00, 0x00 class/subclass/protocol, as its working well to make a composite device with 3 different interfaces (USBTMC, CDC, MSC)

Actually my plan was to use CDC for configuration CLI, USBTMC for control, and a MSC to host a redirecting html file. Another alternative to keep things simple would be to expose the CLI to a USB-USART bridge, and use just 2 ports, 1 for USBTMC and another for CDC CLI (and not use MSC at all). Another alternative would be to use a hub IC and connect everything to one single output, but this could eventually also be achieved through software. A similart alternative to your proposition could also be implemented I suppose, the systems starts as CLI, and if no access to the CDC is detected within a few seconds, then the USB restarts as USBTMC.

Many alternatives that I'll have to evaluate, as of now, my (eventually non-compliant) USBTMC-CDC-MSC composite device seems to be working. So unless it fails on Linux or Windows 11, I'll probably keep it like that.

Great project, Jan. I built one with a 16 relay board. It's super convenient that the TMC device can be referred from pyvisa by name regardless what USB port it's plugged in. In contrast with ASRL devices, where names will change with the USB location. I built two other SCPI devicest, a DAC and a function generator, I'm considering to port their firmware to TMC for this reason.