Jump to content

dadreamer

Members
  • Posts

    103
  • Joined

  • Last visited

  • Days Won

    10

dadreamer last won the day on August 27

dadreamer had the most liked content!

4 Followers

Profile Information

  • Gender
    Male
  • Location
    RF

LabVIEW Information

  • Version
    LabVIEW 2020
  • Since
    2010

Recent Profile Visitors

1,001 profile views

dadreamer's Achievements

Newbie

Newbie (1/14)

  • First Post Rare
  • Collaborator Rare
  • Dedicated Rare
  • Week One Done Rare
  • One Month Later Rare

Recent Badges

37

Reputation

  1. Regarding your second issue - on which LabVIEW did you see that it doesn't require a case to handle the Timeout event if the timeout input is wired? I have checked on various LabVIEWs for Windows and even in LV 7.1 it breaks the VI and wants me to provide a Timeout case.
  2. Your issue with Event Structure names reminds me this thread - LabVIEW Event names are completely off. Even though that was experienced on Windows and the OP solved the issue by removing LabVIEW and cleaning up the system with msiBlast. Might it be that something didn't get installed properly in your case?..
  3. Maybe it's time to try WaveIO library written by Christian Zeitnitz then?
  4. It's just that NI designed those JPEGToLVImageDataPreflight and JPEGToLVImageData functions to run in UI thread. I don't know whether it's safe to set the CLFNs to "Run in any thread" and use it, because we don't have the sources. You could test it on your own and see. But it's known that most of WinAPI functions are reentrant, thus you may freely use WIC or GDI+ from multiple threads simultaneously. So, to re-invent JPEG reading VI with WIC this thread could be a starting point (along with Decode Image Stream VI diagram as an example). For GDI+ this thread becomes useful, but this way requires writing a small DLL to use GDI classes. I don't recommend using .NET nodes in LabVIEW here, as the execution speed is that important for you.
  5. You could probably take a look at this: https://forums.ni.com/t5/Machine-Vision/Convert-JPEG-image-in-memory-to-Imaq-Image/m-p/3786705#M51129 For PNGs there are already native PNG Data to LV Image VI and LV Image to PNG Data VI.
  6. Another option would be to get NI's hands on IntervalZero RTX64 product, which is able to turn any Windows-driven computer into a real-time target. That would definitely require writing kernel drivers for NI hardware and some utilities/wrappers for LabVIEW to interact with the drivers through user-space libraries. Of course, the latter is possible now with CLFN's but it's not that user-friendly, because focuses mainly on C/C++ programing. Not to mention, that a limited subset of hardware is supported.
  7. Also take into account the bitness of your ActiveX libraries, that you're going to use. If you want to use 32-bit libraries, then you invoke "%systemroot%\SysWoW64\regsvr32.exe" in your command shell. For 64-bit libraries you invoke "%systemroot%\System32\regsvr32.exe" to register. That is true on 64-bit Windows. Better do this manually and, of course, with administrator privileges (otherwise it may not register or may report "fake" success).
  8. You also can create the buttons in run-time with the means of .NET - the basic example is here (of course, you need to attach the event callback (handler) to your button(s) to be able to catch the button events).
  9. If you meant me, then no, I even didn't use your conversations with Jim Kring on OpenG subject. Seriously, what's the joy of just rewriting the prototypes?.. I have studied those on my own, even though I have LV 2.5 distro for a while and do know, that some Occurrence functions are exposed there (in MANAGER.H, to be more precise). Moreover, those headers don't contain the entire interface. This is all, that is presented: /* Occurrence routines */ typedef Private *OccurHdlr; #define kNonOccurrence 0L #define kMaxInterval 0x7FFFFFFFL extern uInt32 gNextTimedOccurInterval; typedef void (*OHdlrProcPtr)(int32); Occurrence AllocOccur(void); int32 DeallocOccur(Occurrence o); OccurHdlr AllocOccurHdlr(Occurrence o, OHdlrProcPtr p, int32 param); int32 DeallocOccurHdlr(OccurHdlr oh); int32 Occur(Occurrence o); void OccurAtTime(Occurrence o, uInt32 t); int32 OnOccurrence(OccurHdlr oh, boolean noPrevious); int32 CancelOnOccur(OccurHdlr oh); boolean ChkOccurrences(void); boolean ChkTimerOccurrences(void); The headers lack OnOccurrenceWithTimeout and FireOccurHdlr and some others (likely, they seem to be non-existent in those early versions). Having said that, I admit that Occurrence API is not that complicated and is easily reversible for more or less experienced LV and asm programmers.
  10. Queues, Notifiers, DVRs and similar stuff, even when seems to be exposed from labview.exe in some form, is totally undocumented. Of course, you could try to RE those functions and if you're lucky enough, you could use few, maybe. But it will take a significant effort of you and won't become worth it at all. To synchronize your library with LabVIEW, you'd better try OS-native API (like Events, Mutexes, Semaphores or WaitableTimers on Windows) or some documented things like PostLVUserEvent or Occur of Occurrence API. To be honest, there are more Occurrence functions revealed, but they're undocumented as well, so use them at your own risk. What about CINs, I do recall that former Queues/Notifiers implementations were made on CINs entirely. I never had a chance to study their code, and not that I really wanted to. I suppose, they're not functional in modern LV versions anymore as they got replaced with better internal analogues.
  11. There's also LV Process pipes implementation (part of GOLPI project), which seems to work in 64-bit LabVIEW and is more or less updated. Honestly I've never given it a serious try and I recall some limitations of it comparing to the Rolf's library (e.g., the lack of stderr support AFAICR).
  12. I think, you need to organize some kind of Inter-Process Communication (IPC) between the two. As long as both apps are made in LabVIEW, you have a wide variety of ways for them to communicate: TCP/IP, UDP, Network Streams, SV, Pipes, Shared Memory etc. I don't recommend the files-based IPC because it has some negative caveats like these. There's also an article on the other side: Inter-Application Communication (rather dated though).
  13. You should use Use Default if Unwired property. I couldn't come quickly with a good example, you may take a look at this post for the start.
  14. Maybe then you'd have more luck trying in PowerShell (if available). Also try without preceding .\ symbols. As I have Python paths written into the PATH environment variable, I don't even need to launch Python's own shell, I just execute that command in common Windows shell and it works.
  15. Take a look at https://github.com/mefistotelis/pylabview You will need 3rd Python and Pillow package: After that you proceed as follows: Unpack the .exe into a separate directory (7-Zip unarchiver works fine for me). Take \.rsrc\RCDATA\2 file and put it near readRSRC.py. Run .\readRSRC.py -x -i ./2 in the command shell. Unpack 2_LVzp.bin to get your VIs. You may also find this thread interesting to read: EXE back to buildable project
×
×
  • Create New...

Important Information

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