Sent SequenceContext to a dll with InvokeNode

[Risotto]

Hi,

I want to pass the SequenceContext of a Teststand sequence from LabVIEW to a dll.

But when I connect my SequenceContext control to the parameter of the InvokeNode, I get the error "Broken Wire". Please see attached picture.

Any idea?

Regards,

Risotto

[RayFarmer]

Hi,

From the JPG, you are trying to connect to different types, one of Automation Reference and the other a.NET reference.

You will need to make them the same type.

Regards

Ray Farmer

[Risotto]

Hi,

Yes you are right.

But how can I pass an automation object with the InvokeNode. The possible type seems to be int, double, string, array of standard types, but not more.

Regards,

Risotto

[RayFarmer]

Hi,

You could try casting it to the .Net refnum

Regards

Ray Farmer

[Lycangeek]

I'm afraid it isn't quite that easy, and it depends on what you plan to do with the Sequence item when you're done. If you just want to hold it and pass it back to LV some other time, then you can type cast it to an int32 and type cast it back to the right automation type later.

However, if you want to access it in .NET, you can't. The problems are

1. The refnum is not a pointer, but a reference to an internal tracking database inside LV. So the int32 value that you get in the refnum wire is a magic value understood by LV only.
2. If the API for your class took a COM interface, we would convert the refnum value back into the COM interface pointer, but you can't do that with .NET. The .NET type system does not support unmanaged COM interfaces. You can call COM from .NET, but only through their interop object structure.

So I'm afraid both .NET and LV are conspiring against you on this.

Could you post what it is you're trying to do? I might be able to suggest alternate approaches.

[Risotto]

Hi Brian,

I will try to explain you what I am trying to do.

I write an application which purpose is to test a software in an embedded electronic in a car. I control supply voltage, signal generator with Teststand and let run in parallel a time-loop which do some measurement with a PCI-6014 each 50ms, so that I separate the control part from the measurement part - the time-loop runs  independently on what happens with Teststand.

The time loop save on a separate task - in C# - the data in a buffer and then in on the disk. Now, I need sometime to transfer some data from LV to TS. I already wrote VIs to do this, but the problem is that LV is not "completly" multitasking - we have a single processor computer and we run on Windows2000. During the data transfer, my time loop as not enough time to do the measurement each 50ms. I already tried to rise the priority of the measurement task and lower the priority of the transfer VI, but I doesn't change anything. I can reduce this problem if I transfer more often the data (less data to transfer means littler transfer time), but I am not comfortable with it. And in some test, I need to do measurement during 60s and then to transfer the data.

So I realize that I need to put the transfer functionality outside of Labview: either Teststand or C#. On other side, I can't base my data acquisition whithout  rewrite almost all my VIs. This means, I have to put somehow the data in a kind of buffer in a C#-variable and then access directly from Teststand to this variable to get the data: so the transfer would run outside LV and I hope I will not get the jitter on my time-loop.

I work at the moment on a possible use of .NET Remoting to resolve my problem - actually Brian, you give me the idea. I am not completly through with it, but I have done some progress and I think I could find a solution whith it. But which kind of results, I don't know actually. This is why I am looking for alternativ solution.

So I hope I could explain what I am trying to do.

Regards,

Risotto

[Lycangeek]

I'm afraid I don't understand what you are saying with regards to LV not being multi-tasking, but that you hope to achieve by doing the transfer outside of LV. If your computer has a single CPU, you'll be taking cycles away from your measurement loop no matter what language or application you use. You can set the transfer VI and the measurement VIs to always be on different threads by setting the VI Execution properties, but again you'll only have the single CPU. But if you do set the thread and the priority, you might get it to work.

Some other thoughts I have...

1. Upgrade the computer/memory?

2. Use Datasockets?

3. Go with a cRIO system to run the measurement loop? That is the best way to ensure you get a regular cycle on your measurement. Using LV 8, you could then use the shared variable engine to export the data w/o affecting the measurement timing.