Jump to content
News about the LabVIEW Wiki! Read more... ×


  • Content Count

  • Joined

  • Last visited

  • Days Won


ShaunR last won the day on January 7

ShaunR had the most liked content!

Community Reputation


About ShaunR

  • Rank
    LabVIEW Archetype

Profile Information

  • Gender

LabVIEW Information

  • Version
    LabVIEW 2009
  • Since

Recent Profile Visitors

14,567 profile views
  1. True. I'm just spit-balling. You may also get version control out of it.
  2. Well. You could also generate a menu so it appears in the palette.
  3. Getting back to this again. What should we do with plain zip files? What I'm thinking of are the zip packages which are basically "install to a place of your choice-have fun" type packages. Many of these are given away as "driver" packages for interfacing to hardware. OGPM, VIPM and NIPM all have meta data of how and where to install but a simple zip file has no meta data. How would we handle this? Should we handle this?
  4. I use TSVN and it didn't crash on my machine.
  5. That's your problem then. You've whipped the carpet out from under LabVIEW. Namepace the VIs in the sequencer.
  6. ShaunR

    Wiki News!

    Maybe you are not creating articles but general admin akin to what you are doing is the corner stone of a great Wiki and usually goes unrecognised and un-loved. Keep up the good work.
  7. I was unable to get a crash. I gave up when it indicated about 5000 deletions. Did I need to do more? LabVIEW 2017 both 32 & 64 bit on Windows 10. (Note: not SP1)
  8. ShaunR

    LabView Memory Full Error

  9. Yes. It is in the build process, not at install-by then it's too late (at install) and the recompile passes but the VIs are broken. By the way. this happens also with the TPLAT so it isn't a particular VIPM problem. The work around is to delete the DLLs just before building (so that VIPM or TPLAT fail to find the files during the build) and press "ignore" when it searches. Luckily, that doesn't fail the build but I can see that at some point they might "fix" it so the build fails.
  10. ShaunR

    LabVIEW snippet PNGs are being sanitized

    I was going to be flippant and say "The NI forum has loads" but they don't work either.
  11. Don't you use a modified OpenGPackage Manager for zlib rather than VIPM? I'm not sure if it is the same issue but when VIPM compiles the *.* it "fixes" the file path to whatever bitness you compiled it in if it successfully finds the library. That means if you created the package with 64 bit LabVIEW and the file name is "something_*.*", then the path gets "fixed" to "something_64.dll". The result is that something_32.dll isn't searched for when installed and recompiled on a 32 bit platform and the Vis are broken.
  12. Code Library Function Node. The prototype you have put on the diagram. It is the "Return Value", the first and fixed item in the parameter list. Set that to Numeric and then choose Signed 32 bit Integer. You can't with that function. It requires a lot of setup allocations before you can call it. You need to start with the initialisation and de-initialisation functions then build it up from there. I would suggest using the DLL import wizard as a first pass (in the LV menu under Import>Shared Library(dll) ). It will create the VIs with the nodes (where it can) and then you need to figure out what it got wrong and what order to call them in. I would guess nxDrvInit and nxDrvExit are the first calls you should be looking to try.
  13. Your basic goal is to get the function prototype (shown at the bottom of the CLFN dialogue) the same as that in the documentation. You have void xChannelIORead(uint32_t ulAreaNumber, uint32_t ulOffset, uint32_t ulDataLen, InstanceDataPtr *pvData, uint32_t ulTimeout); The return value is int32_t not void. You are missing the Handle parameter (CIFXHANDLE) and pvData is a pointer to something (probably an array) - not an InstanceDataPtr (which is a special LabVIEW parameter). Even if you fix that. You are still not finished. You will need to call other functions to get CIFXHANDLE through some sort of initialisation procedure and then deinitialise once finished. You will probably also have to call the enumerate functions to get the boards and their channel numbers so you can populate those parameters. If they have provided C/C++ examples then that will tell you what functions you have to call and in what order. Any mistakes will usually result in a LabVIEW crash. For the calling convention, you will have to look at the header files.
  14. You mean it's "dark"? 😋 You can already do similar stuff like that with LabVIEW (although it could be a lot easier). What you can't really do is skinning.
  15. Hmm. I'm not sure what your expecting me to say here. For debugging I want to see the results (on the FP) whilst I go probing the diagram (or even sub diagrams) especially for intermittent bugs. Quite often I throw indicators up instead of using the probe window, which I've always detested as it gets in the way of everything and you can't resize controls. So the FP becomes my probe window (usually after I found the place with the probe window). I tend to make changes to the diagram then hit CTRL+R in a kind of micro test when I'm just tidying up so I make sure I get the same result on the FP after rewiring - I don't want to keep moving windows around between editing and viewing the result. So I have all FPs are on the left screen and all diagrams are on the right screen.

Important Information

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