Trouble Getting Started

[oitinc]

‎04-11-2018 11:49 PM

I'm running into problems setting up what I would think should be a pretty straightforward configuration: running in Windows session 0 and automatically getting data at a specified interval from three channels on our Fluke 2625A. (Everything's easy when you know how.)

How far have I gotten? I'm barely out of the gate yet, if even that.

I've installed VS2013 into a VM so I can get all of what the MS2015 package has to offer. (I know we're supposed to be able to run different versions side-by-side, but I just don't trust it—especially not with a five-year-old IDE.) Once I get the driver wrapper code generated I'll copy that to my 2017 instance on my workstation and build out my Windows service from there. This is my current plan, anyway—I'm open to suggestions for improvement on this.

So I installed MS and NI-VISA, in that order, but I'm not sure what to do next. I'm not finding any code samples specific to my scenario. It seems I can do everything but what I want to do.

The driver for our device is here:

http://sine.ni.com/apps/utf8/niid_web_display.download_page?p_id_guid=E2E2A3038D074997E04400144FB7D2...

...but it's in source code form only. I'm highly proficient in VB.NET, but I'm absolutely lost when it comes to C/C++. Do I have to build this thing from source? I sure hope not. I wouldn't trust myself for a thousand dollars on that one.

How do all these pieces fit together? What advice would someone have for a stone-cold beginner?

Thanks,
Jeff Bowman
Fairbanks, Alaska

[MrJacket]

Hey Jeff,

Can you clarify on how you are using windows session 0 with your Fluke 2625A?  Also, what specific language do you plan on using in Visual Studio?

-Brian

[oitinc]

Hi Brian, thanks for stopping in.

'Session 0' is another way of saying 'Windows service.' Services run in Session 0. In other words, I'm fully automating the data collection—user intervention is neither required nor allowed. There will be no logonUI.

This is in VB.NET, but I'm mildly familiar with C#—at least on a read-only basis. Target: VS2017, Framework 4.7.1.

All of this I have no problem with. I've done it dozens of times over the years. Where I'm lost is in establishing communications with our device. The Fluke 2625A instrument driver comes in source code only form, but the generated .NET wrapper code has a .DLL dependency.

As I mentioned, I'm like a fish out of water when it comes to the notion of building a .DLL from C source. But is that what I'm going to have to do?

Thanks,
Jeff Bowman
Fairbanks, Alaska

[MrJacket]

Hey Jeff,

I checked out the driver on my end and had a follow up question. 

Do you have access to LabWindows/CVI? The driver does have source code in C and if you have access to it, it can make the compilation process a little easier. We do have some documentation if you do not have access to it. 

But upon adding your own application needs to the source/header file, you can then use that in your .NET application as a DLL. 

Thanks,

-Brian

[oitinc]

Do you have access to LabWindows/CVI?

---

I do, an evaluation edition, but I've since discovered that I can command the instrument using raw serial communications in .NET. I've located the API documentation and I'm making good progress.

Over the weekend I was in fact able to build a .DLL from source using LabWindows/CVI. (We're just about on the same page, aren't we?) I must say, it was a lot easier than I was anticipating. In the end, however, I had stability troubles. Function calls would fail consistently, but in a random order: first a configuration call, then a data read call. This would go on until a reboot, after which I could get one successful run only. After that one, subsequent runs would fail until the next reboot.

Anyway...  the take away from all of this is that it looks like I'm going to stick with raw serial ports. This doesn't bode well for NI, I know, but at least I'm fighting a known entity as I work out the proper command sequence.

I really appreciate your time and your advice.

Thanks,
Jeff Bowman
Fairbanks, Alaska