[TRNSYS-users] C++ API not working

Mon Apr 17 12:54:48 PDT 2017

Yuichi - 

The immediate problem I see in this coding is if there is a space in the
deckfile name then the trim function will cut off the name at the first
space. I have found it to be more robust to pass the length of the
string and then trim to that exact length. 

Regards, 

Tim 

---
Timothy P. McDowell
Executive Vice President
Thermal Energy System Specialists, LLC
22 N Carroll St, Suite 370
Madison, WI 53703
office: 608-274-2577
cell: 608-225-5250

On 2017-04-15 02:00, Yuichi Yasuda via TRNSYS-users wrote: 

> FYI
> 
> Finally I found a way to call the getDeckFileName() function from C/C++ directly.
> See example below.
> 
> TRNSYS.h
> extern "C" __declspec(dllimport) int _cdecl TRNSYSFUNCTIONS_mp_GETMAXPATHLENGTH(void);
> extern "C" __declspec(dllimport) char* _cdecl TRNSYSFUNCTIONS_mp_GETDECKFILENAME(char* dck, size_t len);
> #define getMaxPathLength TRNSYSFUNCTIONS_mp_GETMAXPATHLENGTH 
> #define getDeckFileName TRNSYSFUNCTIONS_mp_GETDECKFILENAME
> 
> Example
> std::string trim(const std::string& str)
> {
> size_t first = str.find_first_not_of(' ');
> if (std::string::npos == first)
> {
> return str;
> }
> size_t last = str.find_last_not_of(' ');
> return str.substr(first, (last - first + 1));
> }
> 
> size_t maxlen = getMaxPathLength();
> char *fname= new char[maxlen]; 
> getDeckFileName(fname, maxlen);
> std::string deckFileName = trim(std::string(fname,0,maxlen)); // trimming the string, just in case
> delete[] fname; 
> 
> cheers,
> 
> Yuichi 
> 
> On 2016/05/26 14:17, Yuichi Yasuda via TRNSYS-users wrote: 
> Michael,
> 
> I assume you are using TRNSYS16 coding style in your component. I'm not sure that the getMaxLabelLength() function works with the coding style.However, the function works fine in my TRNSYS'17' coding style component.
> 
> The getDeckFileName() seems to me that the function does not care about C/C++ strings. I have got exactly same error.
> Unless, you modified the function to cope with C/C++ style, I think that you can not avoid the access violation error.
> For example, I have added the following new function in the TrnsysFunction.f90 to avoid the error.
> 
> -TrnsysFunction.f90
> 
> Function getDeckFileNameEx() bind(c,name="getDeckFileNameEx")
> !dec$ attributes dllexport :: getDeckFileNameEx
> Use TrnsysData
> Use, intrinsic :: iso_c_binding
> type(C_ptr) :: getDeckFileNameEx
> Character(len=maxPathLength) ret 
> ret = trim(deckn1)//CHAR(0)
> getDeckFileNameEx = C_LOC(ret)
> End Function getDeckFileNameEx
> 
> - C/C++ Component sourcecode
> extern "C" __declspec(dllimport) char* _cdecl getDeckFileNameEx(void);
> 
> char *dckfilename;
> dckfilename = getDeckFileNameEx(); 
> 
> I do not like this idea because an expensive Fortran compiler is needed to build.
> Does anyone know that how to call FORTRAN function returns characters?
> 
> Best regards,
> 
> Yuichi Yasuda
> quattro corporate design co.,ltd
> T2000 Bld. 4F, 1-11-29 Mita, Meguro-ku, Tokyo, 153-0062, Japan
> Tel:+81 [2] (0)3 5768 6744 Fax:+81 (0)3 5768 6745
> Email: yasuda at qcd.co.jp
> http://www.qcd.co.jp/ [3]
> 
> On 2016/05/21 0:22, Michael Holzhauser via TRNSYS-users wrote: Hello all, 
> 
> I managed to build a customized TRNSYS Type in C++ by extending the Type202 example that is delivered with TRNSYS 17. I can access the input values and return the corresponding output values without any problems. However, the communication with the TRNSYS Core functions somehow don't work. Whenever I invoke some function that returns an integer value (like getMaxLabelLength()), the result is NaN. Whenever I try to invoke some function that returns characters (like getDeckFileName()), TRNSYS crashes with something like „Access violation at address XXXXX in module ‚TRNDLL.DLL'. Write of address XXXXX." or with „forttrl: severe (408): fort: (18): Dummy character variable ‚GETLABEL at 0' has length 300 which is greater than actual variable length 1" (in case of getLabel). 
> 
> As I read in other topics like this one, there seemed to be several issues in the TRNSYS.h header file and the library files long ago: 
> https://www.mail-archive.com/trnsys-users@engr.wisc.edu/msg00005.html [4] 
> 
> However, 11 years later, is there a workaround for this problem? 
> 
> Thanks in advance. 
> 
> -- 
> 
> M.Sc. Michael Holzhauser
> AG Optimization
> University of Kaiserslautern 
> 
> Paul-Ehrlich-Str. 14 - 451
> 67663 Kaiserslautern, Germany
> 
> Phone: +49 (631) 205-2511
> E-mail: holzhauser at mathematik.uni-kl.de
> 
> www.mathematik.uni-kl.de/~holzhauser [5] 
> 
> _______________________________________________
> TRNSYS-users mailing list
> TRNSYS-users at lists.onebuilding.org
> http://lists.onebuilding.org/listinfo.cgi/trnsys-users-onebuilding.org [1]
> 
> _______________________________________________
> TRNSYS-users mailing list
> TRNSYS-users at lists.onebuilding.org
> http://lists.onebuilding.org/listinfo.cgi/trnsys-users-onebuilding.org [1]

-- 

株式会社クアトロ
http://qcd.co.jp/ [6]
 安田　雄市
 TEL 03-5768-6744
 FAX 03-5768-6745
 e-mail: yasuda at qcd.co.jp 

_______________________________________________
TRNSYS-users mailing list
TRNSYS-users at lists.onebuilding.org
http://lists.onebuilding.org/listinfo.cgi/trnsys-users-onebuilding.org
[1]

Links:
------
[1]
http://lists.onebuilding.org/listinfo.cgi/trnsys-users-onebuilding.org
[2] Tel:+81
[3] http://www.qcd.co.jp/
[4]
https://www.mail-archive.com/trnsys-users@engr.wisc.edu/msg00005.html
[5] http://www.mathematik.uni-kl.de/%7Eholzhauser
[6] http://qcd.co.jp/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.onebuilding.org/pipermail/trnsys-users-onebuilding.org/attachments/20170417/f7205675/attachment-0003.htm>