Jump to content

dadreamer

Members
  • Posts

    107
  • Joined

  • Last visited

  • Days Won

    10

dadreamer last won the day on August 27 2021

dadreamer had the most liked content!

5 Followers

Profile Information

  • Gender
    Male
  • Location
    RF

LabVIEW Information

  • Version
    LabVIEW 2020
  • Since
    2010

Recent Profile Visitors

1,272 profile views

dadreamer's Achievements

Rookie

Rookie (2/14)

  • Reacting Well Rare
  • First Post Rare
  • Collaborator Rare
  • Dedicated Rare
  • Week One Done Rare

Recent Badges

38

Reputation

  1. Back to experiments with Basic Object Flags? I think, you forgot to cast a spell on that string constant. 😀
  2. funkyErrClustWire works even in LabVIEW 6.0 (6i). https://labviewwiki.org/wiki/LabVIEW_configuration_file/Block_Diagram Doesn't work in LV 5.0. But! This token is still being read in modern LV versions. For example, this is from LV 2020. So, if you don't like that brown(ish), you can switch to pink classic.
  3. Well, if you implement everything in LabVIEW, you could create such a global with DSNewPtr, which would give you a pointer, that you could easily pass to UA_Server_run. Then when the server is running, you may stop it by writing a zero to that pointer using MoveBlock. In such a way you won't need an additional wrapper DLL. Of course, your global should be one before you call UA_Server_run. Also don't forget to dispose that pointer when finished with it.
  4. If you export running global variable from your DLL, then you could get its memory address with GetProcAddress and pass it to your UA_Server_run function as the second argument. That should work, if I got your tactic right.
  5. 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.
  6. 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?..
  7. Maybe it's time to try WaveIO library written by Christian Zeitnitz then?
  8. 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.
  9. 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.
  10. 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.
  11. 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).
  12. 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).
  13. 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.
  14. 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.
  15. 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).
×
×
  • Create New...

Important Information

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