[TRNSYS-users] error with dll found but is not loading the type on Virtual Machine Win10
Jeff Thornton
thornton at tess-inc.com
Tue Jan 26 20:23:00 PST 2021
Please send the list file for the project that fails as well as the list file for the project with Type533 that fails. The list file provides more information than the log file.
Jeff
Sent from my iPhone
> On Jan 26, 2021, at 9:06 PM, David BRADLEY via TRNSYS-users <trnsys-users at lists.onebuilding.org> wrote:
>
>
> I am afraid that I don't have any other suggestions.
>
> kind regards,
>
> David
>
>
>
> On 01/26/2021 02:52, Jobard Xavier wrote:
>> Dear David, Dear Werner,
>> Thank you very much for the support !
>> First to answer Werner :
>> architecture : are all machines 32 or 64 bit ?
>> both are 64 bit machines
>> dependencies : do the types use any third-party DLLs (e.g. C runtime, .Net framework, ...) that you have on your laptop but not on the production machine ?
>> I don’t think so, however I am not the developer of the types so I cannot be certain. Type 6139 is written in C++ and have include statements in the source code with relative path to header files (#include "export/include/FMIComponentBackEnd.h"). But I believe, there are only use for the compilation of the code.
>> debug vs. release : are you using a recompiled version in debug mode on your laptop, while the other machine uses a 'normal' (release' TRNSYS ?
>> I tried with the TRNDLL that I have on my laptop (it is a recompiled version in release mode) and the result is the same error
>> do the types make assumptions about the environment (e.g. existing directories, files or environment variables) which make them return something different than one when they do not find them ?
>> see answer #2
>> I believe these also answers the David’s questions
>>
>> As for testing other External libs. Here is what I get with TESS example for type 533 and 534. As well type 533 is not loaded and I get the following error (see screen shot). However, I tried type600 example and it runs…
>>
>> Again many thanks and I hope we can solve this issue,
>>
>> Xavier
>>
>> <image002.png>
>> De : David BRADLEY <d.bradley at tess-inc.com>
>> Envoyé : lundi, 25 janvier 2021 16:50
>> À : Jobard Xavier <xavier.jobard at heig-vd.ch>; TRNSYS users mailing list at OneBuilding.org <trnsys-users at lists.onebuilding.org>
>> Objet : Re: [TRNSYS-users] error with dll found but is not loading the type on Virtual Machine Win10
>>
>> Xavier,
>>
>> It is possible that if you are using the debug form of the TRNDll and external dlls that the computer needs to have a microsoft run-time library installed.
>>
>> Werner's question about other dependencies is a good one; are the Types simple self contained things or do they perhaps in turn call on libraries that may not be available?
>>
>> Another interesting thing to try would beto try and run some TESS Libraries examples (if you have access to them) on this machine. Since the TESS Libraries are set up to load from external dlls, it would test whether the problem is fundamentally external dlls or whether it is your specific dlls.
>>
>> kind regards,
>>
>> David
>>
>>
>>
>> On 01/25/2021 02:06, Jobard Xavier wrote:
>> Dear David,
>> Many thanks for the answer.
>> I realize that my question was not specified correctly.
>> To answer your questions:
>> 1. The dlls are correctly located
>> 2. I am running Trnsys 17, so I should not have any compatibility problem between 32-bit and 64-bit dlls.
>> Can you help me further ?
>> Regards,
>> Xavier
>>
>> De : David BRADLEY <d.bradley at tess-inc.com>
>> Envoyé : vendredi, 22 janvier 2021 17:12
>> À : TRNSYS users mailing list at OneBuilding.org <trnsys-users at lists.onebuilding.org>
>> Cc : Jobard Xavier <xavier.jobard at heig-vd.ch>
>> Objet : Re: [TRNSYS-users] error with dll found but is not loading the type on Virtual Machine Win10
>>
>> Xavier,
>>
>> I think the first thing to check is to make sure that the dlls containing Types832 and 6139 are in the appropriate subdirectory of .\TrnsysXX\UserLib. The other thing that occurs to me is that there may be a mismatch between 64- and 32- bit versions. If those Types are compiled as 32-bit dlls they will not be found by the 64-bit Trnsys18 even if the files are in the correct location.
>>
>> I apologize if these suggestions are very basic!
>>
>> kind regards,
>>
>> David
>>
>>
>>
>> On 01/21/2021 10:13, Jobard Xavier via TRNSYS-users wrote:
>> Dear TRNSYS user,
>>
>> I am trying to run a Trnsys deck with non-standard types (Type 832 and Type 6139) on a virtual machine (win10).
>>
>> A simple example (SDHW.dck) works fine. However my deck with type832 and type6139 which works fine on my laptop throws the errors but are actually listed as found further up the log file :
>> *** Fatal Error at time : 0.000000
>> Generated by Unit : Not applicable or not available
>> Generated by Type : 832
>> TRNSYS Message 105 : A TYPE was called in the TRNSYS input file but was either not linked into trndll.dll or was not found in an external dll. A dummy subroutine was called in its place. Please link the TYPE or remove it from the input file
>> Reported information : Type832 could not be located in either the trndll.dll or in an external dll. Please relink theTRNDll.dll including this Type or make sure that an external DLL in the \UserLib\DebugDLLs and \UserLib\ReleaseDLLs folders contain the Type.
>> *** Fatal Error at time : 0.000000
>> Generated by Unit : Not applicable or not available
>> Generated by Type : 6139
>> TRNSYS Message 105 : A TYPE was called in the TRNSYS input file but was either not linked into trndll.dll or was not found in an external dll. A dummy subroutine was called in its place. Please link the TYPE or remove it from the input file
>> Reported information : Type6139 could not be located in either the trndll.dll or in an external dll. Please relink theTRNDll.dll including this Type or make sure that an external DLL in the \UserLib\DebugDLLs and \UserLib\ReleaseDLLs folders contain the Type.
>>
>> These 2 types are distributed by research institutes and were not recompiled in any way. Type 832 was used on several machines without problem before.
>>
>> Can somebody help ?
>>
>>
>> XAVIER JOBARD
>> Ing. INSA Strasbourg
>>
>> Collaborateur Ra&D
>>
>> Institut de Génie Thermique (IGT)
>> Laboratoire d’énergétique solaire et de physique du bâtiment (LESBAT)
>>
>>
>> Prof. :
>> +41 24 557 28 17
>> Site web :
>> http://www.lesbat.ch
>>
>>
>> xavier.jobard at heig-vd.ch
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> TRNSYS-users mailing list
>> TRNSYS-users at lists.onebuilding.org
>> http://lists.onebuilding.org/listinfo.cgi/trnsys-users-onebuilding.org
>> --
>> ***************************
>> David BRADLEY
>> Principal
>> Thermal Energy Systems Specialists, LLC
>> 3 North Pinckney Street - suite 202
>> Madison, WI 53703 USA
>>
>> P:+1.608.274.2577
>> d.bradley at tess-inc.com
>>
>> http://www.tess-inc.com
>> http://www.trnsys.com
>> --
>> ***************************
>> David BRADLEY
>> Principal
>> Thermal Energy Systems Specialists, LLC
>> 3 North Pinckney Street - suite 202
>> Madison, WI 53703 USA
>>
>> P:+1.608.274.2577
>> d.bradley at tess-inc.com
>>
>> http://www.tess-inc.com
>> http://www.trnsys.com
> --
> ***************************
> David BRADLEY
> Principal
> Thermal Energy Systems Specialists, LLC
> 3 North Pinckney Street - suite 202
> Madison, WI 53703 USA
>
> P:+1.608.274.2577
> d.bradley at tess-inc.com
>
> http://www.tess-inc.com
> http://www.trnsys.com
> _______________________________________________
> TRNSYS-users mailing list
> TRNSYS-users at lists.onebuilding.org
> http://lists.onebuilding.org/listinfo.cgi/trnsys-users-onebuilding.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.onebuilding.org/pipermail/trnsys-users-onebuilding.org/attachments/20210126/35776bc9/attachment-0001.html>
More information about the TRNSYS-users
mailing list