Help with DLL and using clusters as handle (VERY HARD)

[wiebe@CARYA]

---

@Jdetlefs wrote:

Thanks for the replies. I'm still a bit lost in all this to be honest. Ask for a better API? I don't even know what an API is. 

---

So this would mean asking the supplier for help.

Question 1) I can't get this to work in LabVIEW. Do you have LabVIEW examples?

They probably ask what LabVIEW is. Ask if they have examples for anything else then C(++).

Getting the hardware to work from Python would give mostly the same problems. Making a better API for languages like LabVIEW and\or Python could be beneficial. They or one of their customers might have done this in the past.

Question 2) Can you make something that allows me to use this in LabVIEW?

The reason that "no" is the probable answer is that a) you can't reach the right person, b) they don't care (enough) and c) they don't know LabVIEW or how to program in LabVIEW.

Talking to them might just give you some solution. In my experience, chances are 1/20.

But email is cheap.

[Jdetlefs]

Hey All,

Thanks for all your advice. This was pretty much what my hunch was and that it is way out of scope for my current abilities. 

I will inquire to RTD Embedded Technologies about better APIs or examples for LabVIEW or other programming environments. 

Our hard deadline is in April. Finding someone who knows C, FPGA, and LabVIEW and able to commit to making a DLL before then is

an unlikely scenario. We have been looking at other hardware entirely to see if we can replace the RTD all together. Red Pitayas have been

the most likely replacements which have tons of examples and a LabVIEW driver I have already got working. 

The RTD board does have way more capabilities and just way more impressive tech than red pitayas and NI boards.  The NI Boards were used in our gen. 1 models and those simply do not have the capabilities we needed anymore. So we were really trying to get the RTD to work with LabVIEW. It's unfortunate that the dll is so poorly done. 

Thanks for the advice and options. 

Best wishes,

James

[wiebe@CARYA]

---

@Jdetlefs wrote:

Our hard deadline is in April. Finding someone who knows C, FPGA, and LabVIEW and able to commit to making a DLL before then is an unlikely scenario. We have been looking at other hardware entirely to see if we can replace the RTD all together. Red Pitayas have been the most likely replacements which have tons of examples and a LabVIEW driver I have already got working. 

---

I'm not sure how you got from a wrapper to the RTD to knowing  C, FPGA and LabVIEW.

I'm sure there's a solution to get this working, but it would be a matter of finding the right person.

Note that you don't have to make a wrapper for the entire RTD API. You can modify an RTD example to do exactly what you want, and make inputs and outputs available to LabVIEW. This could easily be <5% of the effort to make a full wrapper.

[Jdetlefs]

Yeah, I don't know if modifying one example to do what I need is going to suffice. We need all 16 ADC channels to be read simultaneously and in sync from an external clock and triggered externally.  On top of that, provide a generic wave function from the DAC as necessary. The RTD can do this, but even the examples fall short of showing how. I need to write a wrapper in C for it to make it LabVIEW friendly? That is a lot to learn and not a lot of time to learn it. Every day I spend on a solution that isn't likely to work shortens the window on the solution that will. 

I'm much better at LabVIEW which is why I was hoping to make it work by interfacing with the dll which apparently is difficult and the provided dll only makes it worse. So far contacting RTD for labview examples or python examples, or just replacing it with Red Pitayas is our most likely solution. 

I also don't know what I don't know, so maybe it's way easier than I am thinking but It hasn't been made clear on how easy wrappers are to make to interface this with LabVIEW. Rolf seems pretty forward about the unlikelihood of getting this to work without a proper API/DLL. What am I failing to understand? 

Thanks for your replies.

James

[wiebe@CARYA]

---

@Jdetlefs wrote:

Yeah, I don't know if modifying one example to do what I need is going to suffice. We need all 16 ADC channels to be read simultaneously and in sync from an external clock and triggered externally.  On top of that, provide a generic wave function from the DAC as necessary. The RTD can do this, but even the examples fall short of showing how. I need to write a wrapper in C for it to make it LabVIEW friendly? That is a lot to learn and not a lot of time to learn it. Every day I spend on a solution that isn't likely to work shortens the window on the solution that will. 

---

Still, an API to do that could be made by a C\C++ programmer. It shouldn't take that long, weeks, not months would be reasonable. If (s)he set's it up properly, you'd be able to make changes (love it when customers say that about LabVIEW). Note that C++ can make an API that works for LabVIEW.

The problem is finding someone suitable that has time to do this, and to make sure you get something that does work.

---

@Jdetlefs wrote:

I'm much better at LabVIEW which is why I was hoping to make it work by interfacing with the dll which apparently is difficult and the provided dll only makes it worse. So far contacting RTD for labview examples or python examples, or just replacing it with Red Pitayas is our most likely solution. 

---

I'd hope for the best, plan for the worst. That seems to be what you're doing.

---

@Jdetlefs wrote:

I also don't know what I don't know, so maybe it's way easier than I am thinking but It hasn't been made clear on how easy wrappers are to make to interface this with LabVIEW.

---

It's not that hard. If you're completely new to C\C++\API then I guess a few months are reasonable. However, there's a good change that you'd be producing crap, no offense. This isn't a beginners project, you'd have to get very lucky to do it good enough the first time.

---

@Jdetlefs wrote:

Rolf seems pretty forward about the unlikelihood of getting this to work without a proper API/DLL. 

---

Even if it is possible, it would not be the easy way out.

---

@Jdetlefs wrote:

What am I failing to understand? 

---

Not a lot, I'd say.

[rolfk]

---

@Jdetlefs wrote:

Rolf seems pretty forward about the unlikelihood of getting this to work without a proper API/DLL. What am I failing to understand? 

---

It's not that it is impossible to do but there are a lot of ifs that all will cost a lot of effort each or make it completely impossible:

- If the hardware can indeed do it, if not that would be the KO

- AND if the DLL API provides enough functionality to do it, could be a KO criteria

- AND you don't need to program also FPGA to do it, not a KO criteria but a lot of extra work to do

- AND then program a lot of low level stuff around the rather complicated API to interface to the new FPGA functionality

If it is only about accessing the API from LabVIEW and be done with it, there is certainly a path but it absolutely will involve writing a C wrapper DLL that does all the low level nitty gritty structures and callback handling and then provides a more LabVIEW friendly interface. That does require quite good C programming knowledge, and also a good understanding of the hardware in question, and how it relates to the different API elements.

Not impossible but even for a really good C programmer with LabVIEW knowledge more than just one or two weeks of programming and then there needs to be also significant testing. Without that C knowledge, even if you are a LabVIEW crack, it is almost impossible, and you don't learn that level of C programming in just a week or even a month. It takes quite a bit of learning time and a few less demanding projects of this type to get up to snuff with this.

If there is also work involved to actually program the FPGA then your timeframe is simply unachievable. There are VERY few people in the whole world who do have AND the FPGA programming knowledge AND the C programming knowledge AND the LabVIEW programming knowledge to solve this problem. And they are VERY unlikely to be available on short notice for such a project. I for one haven't done any real VHDL programming for instance, only integrated a few partly self written simple VHDL blocks into LabVIEW FPGA. And this RTD device can't be programmed with LabVIEW FPGA. Even if it could, it would take a lot of time, FPGA programming is even more time consuming and involved than C programming, even if you use LabVIEW FPGA. VHDL programming is an entirely different ballpark of its own.

There are VHDL pros out there, but I would almost bet that they will look at you in deep pain, if you tell them you are trying to use this hardware in LabVIEW, that is if they even know what LabVIEW is. Someone who thinks and breaths VHDL is very unlikely to even understand that you can indeed make programs in LabVIEW.

[Jdetlefs]

Hey All,

Thanks for the replies. I am very new to C so writing wrappers etc isn't really a feasible solution. Our best bet is that RTD Inc. provides

labVIEW functions, a better API/other language examples, or just outright replace it with Red Pitaya which seems to be the way we are going. 

We already use 5 RP, so adding more isn't that big a deal. We just have to be sure it's hardware can replace the requirements provided by the RTD.  It's unfortunate the RTD is so difficult to program because it is a really capable device. Least I know this is a dead end, which helps a lot. 

Thanks!

James