Jump to content

Eric Griwicki

Members
  • Posts

    3
  • Joined

  • Last visited

    Never

Everything posted by Eric Griwicki

  1. Hello All, I found this quote on the Ardence website concerning calling DLLs: http://www.ardence.com/uploadedFiles/Embed...cts/ETS_FAQ.pdf Q. Are all WIN32 API Function calls supported in ETS? A. ETS supports a large subset of the WIN32 API, however function calls that fall into following categories are typically not supported by ETS: - OLE/ActiveX/COM/COM+/DCOM Functions - MFC or ATL related calls - GDI APIs - .NET framework, managed C++ - Common Language Runtime (CLR) It looks like they are calling the subset of the Win32 API by a different name, which is RtWinAPI (try googling it). There are some white papers that provide a little more details on what is and isn't supported. Thanks for all the help Eric
  2. Has anyone had any luck calling external code (DLL) in LabVIEW RT? I have an application that requires the use of an external library written in C++ which makes use of the STL and some Win32 API calls (wsock32.dll). I am exploring the idea of creating a C wrapper DLL for the library which would enable it to be called by LabVIEW, but I'm not sure that the DLL would run under LabVIEW RT. I know NI has a DLL checker on their website that verifies the DLL as capable of running in LabVIEW RT but they still don't guarantee that it will work. I haven't built a DLL that wraps the code yet to test it out. (still not sure if I want to go this route) Does anyone have a list of the supported or unsupported libraries in the Ardence Phar Lap ETS (RTOS)? And has anyone been able to call a DLL from LabVIEW RT that makes a call to the WIN32 API? It may also be possible to strip out the Win32 stuff. Has anyone had any experience just calling pure code in a DLL from LabVIEW RT? Thanks in advance for your help. Eric
  3. Hello Everyone, This is my first post, but this topic applies directly to the project that I am developing and I would like a second opinion on the method that I came up with. I had a very similar problem where I wanted to communicate between parallel running VI's and transfer data between them in a queue but more event driven. The solution I came up with used the event structure and user events that sort of act like queues. I know events are queued up and with a user event you can send data to another loop without polling. The only drawback is that you can't have priority queues because you can't insert an event at the beginning of the queue. To illustrate what I'm talking about I reworked the "queue_comm.vi" that Michael Aivaliotis posted (I hope that is OK). It works the same but if you turn execution highlighting on you'll see that the loops really are dormant until you generate an event with one of the buttons. Eric Download File:post-1576-1114810073.vi
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.