Inconsistent Output Length Using Call Library Function Node

[pelkeyj]

The issue I'm having is that the number of samples (channels) is not consistent with how I am setting the sample time and number of samples in LabView. When I run my code twice under the same settings, the number of samples output varies randomly. I'm not sure if it is an issue with my LabView code or the library I'm using made by ET enterprises (which is specific to the hardware I'm using, a PMT), or the interface between the two. 

I have attached an image showing my LabView code. Also, I've attached an image of the output of my LabView code after runtime, showing that the number of samples of output is inconsistent with my input. Further, I've attached the output from a different program using the same library, which outputs the correct number of samples (channels). I would greatly appreciate any help debugging my code. 

[PsyenceFact]

It's a bit difficult to offer much insight without the actual LabVIEW code so it's probably worth posting that as well.  I appreciated that it won't run without the ET DLL but it will be easier to diagnose code issues.

A couple of things that occur to me:

1) Your LabVIEW code has Outputs 1 & 2 both set to "High" whereas the other software has Output 1 set to "Low".

2) Is there a risk of a race condition between the calls to GetReadings and ReadingNumber?  At the moment you have nothing to control the order of execution which may account for getting different values on repeat runs.

Andy

[pelkeyj]

Thank you so much for your help! After speaking to a engineer from the company that designed the hardware we are interfacing to, it seems that the problem was that our LabView code, for whatever reason, is not fast enough to accept the input from their software, but they do output it elsewhere on our computers so that we have a work around. Thanks again.

[PsyenceFact]

Glad to have helped!

[wiebe@CARYA]

---

@pelkeyj wrote:

it seems that the problem was that our LabView code, for whatever reason, is not fast enough to accept the input from their software, but they do output it elsewhere on our computers so that we have a work around. Thanks again.

---

You might have more luck if you configure the Call Library Function Nodes to run in any thread.

By configuring Run In UI Thread, it will synchronize with the UI thread, and that will limit the execution speed. Of course the dll needs to be thread safe, but if it's not, you can make sure it's called only sequentially yourself.

The Wait Until Next Multiple rarely has the intended effect. If execution (of the previous iteration!) took longer then 10 ms, do you really want it to wait another 10 ms? I'd stick to Wait (ms).