hardware initialization

[Manfred Schininger]

I've written a hardware.dll that encapsulates all necessary hardware drivers
(GPIB+DAQ) for our test machine and supports functions like power(ON/OFF) or
vakuum(ON/OFF) and so on. I'd like to load and initialize this .dll only one
time when starting TestStand. Where's the best place to do this ? I've tried
to put the initialization function into the SequenceFileLoad of the
ProcessModel but when a user logs out, the model-module and the hardware.dll
gets unloaded, and when another user logs in the initialization is done
again.

Thanks

[KittF]

Manfred,

There are different places you could do this, however, I think that how you do it is just as important as where. Let me explain.

Lets say you do the loading first thing and never again. A problem will occur if the user manually selects File>>Unload All Modules. Your DLLs will be unloaded and will never be reloaded until your sequence editor/opertor interface is reloaded.

The solution to this is to use Windows SDK functions, LoadLibrary and FreeLibrary from Kernel32.dll library. See

http://msdn.microsoft.com/library/psdk/winbase/dll_1o8p.htm

As quoted from Microsoft:
"Each process maintains a reference count for each loaded library module. This reference count is incremented each time LoadLibrary is called and is decremented each time FreeLibrary is called. A DLL module loaded at process initialization due to load-time dynamic linking has a reference count of one."

You can call these functions using an Action step with the DLL Flexible Prototype Adapter. If you load a DLL in this manner then a user selecting File>>Unload All Modules will not unload your DLL. You can either explicitly unload it using FreeLibrary or it will unload when you shut down your process (i.e. sequence editor or operator interface). I would probably let the DLL unload with shutdown. If you do want to call FreeLibrary you need not store that LoadLibrary returns. You can simply call GetModuleHandle to obtain a reference to the loaded DLL.

You can also use GetModuleHandle to see if the DLL is currently loaded.

Now the only question is where should load your DLL. You could return to using the SequenceFileLoad of the ProcessModel but only call LoadLibrary if GetModuleHandle returns 0. You could also put this in your FrontEndCallbacks.seq in the LoginLogout sequence. I would still only call LoadLibrary if GetModuleHandle returns 0. This latter method does ties your loading to logging in rather to a specific process model. It really depends on the scope you desire for the dll. Does it need to be loaded for every product you are ever going to test?

You could also create a new sequence in the FrontEndCallbacks.seq called LoadDLL. Your operator interface could call this in the same manner that it calls the LogginLogout sequence. This way you can add whatever steps you want to sequence and have it execute only when you want. While you can make this simple change to your operator interface, you cannot make it to the sequence editor since you do not have its code.

Hope this isn't too much information.

[Manfred Schininger]

Thanks Nemo, this was exactly what I needed!

PS: Information can never be too much 😉 !


Nemo schrieb in im Newsbeitrag:
5065000000050000003D2C0000-991568043000@quiq.com...
> Manfred,
>
> There are different places you could do this, however, I think that
> how you do it is just as important as where. Let me explain.
>
> Lets say you do the loading first thing and never again. A problem
> will occur if the user manually selects File>>Unload All Modules.
> Your DLLs will be unloaded and will never be reloaded until your
> sequence editor/opertor interface is reloaded.
>
> The solution to this is to use Windows SDK functions, LoadLibrary and
> FreeLibrary from Kernel32.dll library. See
>
> http://msdn.microsoft.com/library/psdk/winbase/dll_1o8p.htm
>
> As quoted from Microsoft:
> "Each process maintains a reference count for each loaded library
> module. This reference count is incremented each time LoadLibrary is
> called and is decremented each time FreeLibrary is called. A DLL
> module loaded at process initialization due to load-time dynamic
> linking has a reference count of one."
>
> You can call these functions using an Action step with the DLL
> Flexible Prototype Adapter. If you load a DLL in this manner then a
> user selecting File>>Unload All Modules will not unload your DLL. You
> can either explicitly unload it using FreeLibrary or it will unload
> when you shut down your process (i.e. sequence editor or operator
> interface). I would probably let the DLL unload with shutdown. If
> you do want to call FreeLibrary you need not store that LoadLibrary
> returns. You can simply call GetModuleHandle to obtain a reference to
> the loaded DLL.
>
> You can also use GetModuleHandle to see if the DLL is currently
> loaded.
>
> Now the only question is where should load your DLL. You could return
> to using the SequenceFileLoad of the ProcessModel but only call
> LoadLibrary if GetModuleHandle returns 0. You could also put this in
> your FrontEndCallbacks.seq in the LoginLogout sequence. I would still
> only call LoadLibrary if GetModuleHandle returns 0. This latter
> method does ties your loading to logging in rather to a specific
> process model. It really depends on the scope you desire for the dll.
> Does it need to be loaded for every product you are ever going to
> test?
>
> You could also create a new sequence in the FrontEndCallbacks.seq
> called LoadDLL. Your operator interface could call this in the same
> manner that it calls the LogginLogout sequence. This way you can add
> whatever steps you want to sequence and have it execute only when you
> want. While you can make this simple change to your operator
> interface, you cannot make it to the sequence editor since you do not
> have its code.
>
> Hope this isn't too much information.