Phillip Brooks Posted April 30, 2012 Report Share Posted April 30, 2012 http://en.wikipedia....elated_software The Ch interpreter is a C/C++ Interpreter that can be embedded into LabVIEW for Scripting.[8] Quote Link to comment
JamesMc86 Posted May 2, 2012 Report Share Posted May 2, 2012 Hmm that wikipedia page seems like it needs looking over! I have never heard to it referred as Ch but the only thing I am aware of that it could be is the C interface node but DLLs or other compiled alternatives appear to be encouraged instead now. (null) Quote Link to comment
Rolf Kalbermatter Posted May 3, 2012 Report Share Posted May 3, 2012 http://en.wikipedia....elated_software The Ch interpreter is a C/C++ Interpreter that can be embedded into LabVIEW for Scripting.[8] I guess it could be integrated in LabVIEW in a similar way than Lua through LuaVIEW. But as current maintainer of LuaVIEW I don't see much merit in getting my time fragmented even more with yet another scripting interface for LabVIEW. The wiki page certainly looks problematic and the license doesn't make it the first choice for a scripting interface either. Quote Link to comment
Saverio Posted May 3, 2012 Report Share Posted May 3, 2012 I remember seeing this a few years back. There wasn't much more provided beyond a post in the NI Community, which included a paper on the whole thing. I don't think it ever went beyond that. Quote Link to comment
Rolf Kalbermatter Posted May 4, 2012 Report Share Posted May 4, 2012 I remember seeing this a few years back. There wasn't much more provided beyond a post in the NI Community, which included a paper on the whole thing. I don't think it ever went beyond that. Well the approach chosen in that paper is rather cumbersome. It means you have to create a CIN or DLL for every operation you want to perform, with an external filename whose name is compiled into this external code. Yes it gives the flexibility to change the actual Ch code by changing the external file contents, but it is highly coupled in a logical way and highly decoupled in a process way, in fact the total opposite you would want with a scripting solution. Using an interpreted C environment in a way that requires to write a VI that interfaces to compiled C code for every individual problem is quite an involved way. That may work if you have a specific problem to solve, whose algorithme needs fine tuning in the field, but it doesn't feel like a general purpose approach to integrating scripting into LabVIEW, or any programming environment actually. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.