Some parameters to a dynamic sequence call don't get passed. Why?

[Heartbeat]

Example: Main.seq:

Step 1: Create a .net object, store reference in FileGlobals.MyRef

Step 2: Sequence call to external file. "#NoValidation, "C:\\"+Locals.UUT.PartName+".seq",

I load the sequence prototype manually and pass FileGlobals.MyRef as a parameter. It is passed by reference. The types are also correct.

Inside the subsequence the received parameter is set to Nothing. Why? How may I achieve this?

If I use propogate to subsequence and if MyRef is a local variable it works correctly.

[YusufD_UK]

Hi,

Thanks for your post.

I have a few questions:

1. Are you using absolute paths to call the external file?

2. Have you seen this article?

Passing Data to a Subsequence with Parameters in TestStand - National Instruments

3. Please also see this forum.

Solved: Re: Pass a Sequence Reference from calling Sequence to called Sequence - Discussion Forums -...

Many thanks,

YD

[Heartbeat]

1. Yes,
2. Yes
3. Yes

I still have problems passing a .net object reference to a some dynamically called sequences. For some sequences it works well. But not for others.

[Alex_Kr]

This might be a shot in a dark, and not applicable to others, but this is what happened with my case:

Had this same problem with TestStand reporting missing dlls, and what was frustrating about it that it was intermittent, and seemed to relate to switching between TestStand 2016.1 and 2017. After we moved to production where we ran on custom operator interface instead of TestStand editor the error changed to unable to locate function(s) in .Net assembly even though the functions where present.

After trying all sorts of solutions and talking to NI engineers here is the theory. We used same .Net dlls in the operator interface as we used in the sequence, but older version. Some .Net assemblies had dependencies on other assemblies, and that caused TestStand to get confused. TestStand used Search Directories to locate the main assembly that you had referenced in the sequence, but after that it did not care to look for dependencies in the same folder, it would reuse the same dlls that were loaded previously. So the solution was to have single set of dlls in one location and the problem went away.

BTW it was helpful to run Task Manager from SysInternals, because it would show you exactly which assemblies and from what locations were loaded by SeqEdit.exe.