Custom IVI step types

[cstryker]

So, I have a several RFSigGen devices, all with IVI-C drivers, and need to do use with them in TestStand 2017. I have it working with DLL calls, but I found this post from waaayyyy back and for the sake of my own education, I kind of want to go down the rabbit hole and explore making custom IVI step types (knowing full well that I'll probably chicken out before I make useful progress). It references the source for the IVI step types being in the following directory: \Components\NI\StepTypes\IVISteps

The closest I can find is  \TestStand 2017\Components\StepTypes\IVISteps which doesn't contain any source. I'm guessing I'm either a) looking in the wrong place, b) missed an option when installing, or c) the code no longer ships. Any chance someone could point me in the right direction?

[RoxtheFox]

Hey Chris,

Those step types are now obsoleted as of 2019. The source for that is written VB6 and we stopped shipping the source at some point in 2012 or 2013. I suggest taking a look at Best Practices for Custom Steps Types.

However, if you are just starting out with these drivers, developing code modules might be a better starting point than jumping straight into customer step types.

Thanks,

Roxy

[ChrisStrykesAgain]

Roxy, thanks for the response; that's good to know. That said, it leads to further questions (please pardon my TestStand ignorance here):

By "developing code modules," I assume you mean creating CVI/LabVIEW/C code that will combine a few different IVI calls in to a single, coherent operation. Is that correct? Or did you mean just write direct 'wrappers' for each of the IVI-C driver functions directly?

If the former, requirements state that I should expose all functionality directly, so while I assume it's a 'best practice' (and completely agree that would make sense), it's not the goal here.

If the latter, it's unclear to me what would be gained from wrapping the raw IVI functions. I used visatype.h to find the definitions for all the vi* datatypes, and am passing them directly as arguments to the IVI-C dlls. Is that a bad idea?

[RoxtheFox]

Hey Chris,

Yes, the first suggestion is recommended.

What is the functionality required to expose? Does the consumer of this code really need all of the inputs, or are some fixed and so on? What does the test developer need?  That could determine the amount of functionality to expose.

If the goal is to expose the functionality, then why even wrap them in LabVIEW? Seems that would limit the scope more than expand it.

Thanks,

Roxy 

[ChrisStrykesAgain]

---

@RoxtheFox wrote:

Hey Chris,

Yes, the first suggestion is recommended.

What is the functionality required to expose? Does the consumer of this code really need all of the inputs, or are some fixed and so on? What does the test developer need?  That could determine the amount of functionality to expose.

If the goal is to expose the functionality, then why even wrap them in LabVIEW? Seems that would limit the scope more than expand it.

Thanks,

Roxy 

---

Roxy,

I'm not wrapping in LabVIEW - it would be a CVI wrapper if anything. I guess my concern was that I don't see a point in writing code modules in this case, given the functionality I need would basically just be a direct wrapper for the IVI-C driver. The only point I see in wrapping would be that using native C datatypes would allow the function signatures to auto-populate (which isn't a requirement). Is that a correct assessment?

Thanks!

Edit - For clarity, these aren't actually designed to test a DUT, they are designed to expose functionality to allow a user to access the hardware directly for diagnostic purposes. There will be some self-test sequences, which I agree, should be written as code modules.