TDMS Scaling information returns error 1003 in VeriStand custom device

[Mathieu_R.]

Hello,

I'm working on a custom device that uses raw DAQ acquisition data and logs it to a TDMS file. I need a continuous acquisition, but I don't need to save the entire acquisition (so the DAQmx/TDMS functionnality does not apply). I try to use TDMS scaling information in order to get a 'readable' file. And there, VeriStand returns the error 1003 (RT target screen). Obviously, some dependencies are missing.

The VI Hierachy shows that the TDMS Scaling Information VI calls Windows registery key VIs (??). I know that there is often structure to select code according to the execution target, but as long as TDMS VIs are password locked, I cannot investigate further. I tried to modify the build specification to include dependencies, to move code and build specifications for a RT target (create a new target in the custom device projet). Same result.

I found a workarround by using a 'template' TDMS file, including a pre-define hierarchy (group and channel) and scaling information. Then, you can write raw data, scales apply as expected. But as long as the llb includine custom device engine do not include TDMS file, I have to manually copy the template to the target.

- Is there a way to get a kind of 'debug mode' for Custom Devices, running with VeriStand?
- How to get this TDMS Scaling Information VI work with VeriStand?

Thanks,

[YongqingYe]

The only reason why TDMS Scaling Information needs to use code of reading Registry is that we want to know where tdms.dll locate. 

[Mathieu_R.]

Thanks YonggingYe,

I don't think there is a registery base under PharLap ETS. I found this tdms.dll on the target I use (PXIe-8108) in ni-rt/system directory (every NI component are expected to be there, isn't it?).

Is the TDMS Scaling Information VI designed to have differenciated behavior from Windows to PharLap (perhaps do I miss something in my tests), i.e. not use registery VIs when under non-Windows OS?

Best regards,

[YongqingYe]

Hi Mathieu R.

You are right. TDMS supports Windows, PharLap and VxWorks now. It reads Registry just on Windows, doesn't read any Registry on PharLap or VxWorks.

[Jarrod_S.]

It appears the code that accesses the registry is under a Conditional Compile statement with TARGET_TYPE==Windows set. If you build your Custom Device source distribution under My Computer, then this is the code that will be active. And, of course, this code is not executable on PharLap.

So to use the Scaling function, you will need to create a PXI target in your Custom Device source project and recreate the Driver VI source distribution build specification under that target. Building it from there will disable this code and allow the Scaling VI to run on PharLap as expected.

[Mathieu_R.]

Damn, shame on me.

I've tried something like this before posting here, but I probably missed something. I'm going to persevere according to your advice.

Note that the Custom Device Template Tool generates a lvlib on My Computer; the build specification include the whole lvlib in source files, to be placed in the Engine llb.

In a project, is this correct to have a lvlib on both targets, Windows (My Computer) and PharLap (RT PXI)? Or do I have to 'split' my llb into two distinct lvlib?

Best regards,

[Jarrod_S.]

It is absolutely appropriate to have your lvlib under two or more targets. LabVIEW is designed to handle this.

[Mathieu_R.]

Great!

(that's right, everything is possible with LabVIEW ^^)

In the original template build specification, under Source Files, the lvlib is marked as Always Include. If I want to build my configuration source distribution, and that I use some specific RT VI (RT Debug string for instance), this VI is missing (okay, this sould not be a problem, as long as the VI containing the RT specific code is not launched by VeriStand on Windows - but this is not rigorous)

I removed the lvlib from 'Always Include' section, the build is okay, I have no more missing VIs, and no error in VeriStand... I don't like remove paramters without understanding what is going to change, by removing what I am about to remove.

If the lvlib is appears in the Always Include section, in the template project, there is probably a good reason. I know that dynamically called subVIs could be problematic if not explicitly included for instance.But the template does not have such mecanisms. On the other hand, the VeriStand API relies on strictly typed dynamic calls, but the API lvlib does not appear in 'Always Include' section.

Why is the MyCustomDevice.lvlib always includes?

Best regards