Jump to content

eberaud

Members
  • Posts

    289
  • Joined

  • Last visited

  • Days Won

    10

eberaud last won the day on January 25 2022

eberaud had the most liked content!

Profile Information

  • Gender
    Male
  • Location
    Riorges, France
  • Interests
    Rock climbing

LabVIEW Information

  • Version
    LabVIEW 2023
  • Since
    2006

Contact Methods

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

eberaud's Achievements

  1. Only 17 years later 😅 ... Has the situation changed? Or is it still impossible to change the grid size programatically? Thanks!
  2. Thank you Darren, I upgraded to 2023 Q3 and it did fix the issue. I had managed to strip down my code to the point where all I had was one empty class with just a .NET refnum in its private data (System.Windows.Forms.NotyIcon), and only a "DAQmx Start Task.vi" in the startup VI. Same thing was happening if instead of the daqmx VI, my startup VI contained a "XNET Create Session.vi". Any chance you could explain what the issue was? If I removed the .NET refnum or the DAQmx (or XNET) subvi, then it would compile fine. I am attaching a zip file with the files I mentioned and the .lvproj itself (in LV2023Q1) in case somebody want to test it on their own PC (you would need to install DAQmx and/or XNET drivers of course). Anyway, now that this is fixed, I resumed building my whole project and I'm now running into an error 2 "memory is full" 🤯. Cheers, error 13 investigation.zip
  3. it would help a lot if you could post a snapshot of your code
  4. Hexadecimal is just a display representation. At the end of the day, the data in the background is an integer value. So you don't really need to worry about "staying in hex". If you use a combo box, which is purely text, then yes you'll need to choose hex when you convert your numeric values to strings. When the user picks a value you will need to convert back to an integer by telling LabVIEW to interpret the string as hex. What you want to achieve sounds totally doable (and easy).
  5. Hi everyone, I recently installed LabVIEW 2023Q1 and am trying to compile (create an executable of) my company's application, that we can successfully compile with LabVIEW 2019. Unfortunately, at the end of the compilation I get an "error 13" message, just like in this link: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000g34oSAA&l=en-CA However, I don't think it applies to me, since this was supposed to be only in LabVIEW 2017, and that my "Use fast file format" is already disabled anyway. When trying to remove/add back part of my source code, I notice I tend to have problems when I include code that have dependencies inside the new LVAddons folder (C:\Program Files\NI\LVAddons) that NI came up with in LabVIEW 2022Q3 (specifically, xnet and daqmx). Googling specifically for building errors with LVAddons, I came across this issue reported by JKI: https://github.com/vipm-io/vipm-desktop-issues/issues/17 Since it's related to building a package and not an executable, I'm not sure it's relevant for my situation. What makes it hard to troubleshoot is that everything looks happy in the lvproj. All dependencies are found in LVAddons instead of C:\Program Files (x86)\National Instruments\LabVIEW 2023\vi.lib, which seems to match NI's intentions. And the error only occurs at the very end of the compilation. Has anyone encountered this problem while building with either LV2022Q3 or LV2023Q1? I have installed the latest versions of NI-XNET and NI-DAQx drivers (2023Q2). The whole error message is as follows: Error 13 occurred at Invoke Node in AB_Engine_Write_Linker_Wrapper.vi->AB_Build.lvclass:Copy_Files_Core_Old.vi->AB_Build.lvclass:Copy_Files.vi->AB_Application.lvclass:Copy_Files.vi->AB_EXE.lvclass:Copy_Files.vi->AB_Build.lvclass:Build.vi->AB_Application.lvclass:Build.vi->AB_EXE.lvclass:Build.vi->AB_Engine_Build.vi->AB_Build_Invoke.vi->AB_Build_Invoke.vi.ProxyCaller Possible reason(s): LabVIEW: (Hex 0xD) Failed to load dynamic library because of missing external symbols or dependencies, or because of an invalid file format. ========================= LabVIEW: (Hex 0xD) Failed to load dynamic library because of missing external symbols or dependencies, or because of an invalid file format. ========================= Shareable board exclusively owned. Method Name: Linker:Write Info To File
  6. We have a position opened for a LabVIEW developer in the Vancouver area, British Columbia, Canada. Please find out more here: https://greenlightinnovation.betterteam.com/labview-software-developer-2
  7. I haven't. Thanks for the posting it, will definitely check it out!
  8. Thanks ensegre and Mads. I think the CAR related to what you two talked about is CAR 202900. Unfortunately I don't think this applies to my problem.
  9. Thanks Bob and Bryan, I'll try to dig into this.
  10. I've been asked to escalate the issue related to CAR 185890 where text that should normally be interpreted as ASCII suddenly starts being interpreted as Unicode, which means the text is replaced by random Chinese characters. It seems like this CAR has been opened for 10 years now. I found some NI forums related to this, but nothing on LAVA. So I'd love to know if you also still experience this really pervert bug. It's hard to reproduce, it usually occurs after weeks of running our application (executable). Note that in my case, I do have some text (mostly control captions) that is Unicode on purpose so we can localize it, and this works fine. But the rest (table and listbox content in particular) is always displayed as ASCII and works fine most of the time, expect when LabVIEW decides to suddenly interpret EVERYTHING on the front panel as Unicode. Most of what I could find about this is from 2010-2013, so it would be nice to see what people experience about this in 2021
  11. Hi everyone, my apologies if there is already a topic about this, I couldn't find one. My company is looking into acquiring an automation testing tool to troubleshoot and validate our LabVIEW-built application (and maybe one day perform some CI but we're not there yet). I did some research and found a lot (Ranorex, TestArchitect, TestComplete, TestProject, Katalon, Telerik...) but as I read, I think none of them will work with LabVIEW. I need the tool to be able to click buttons in our application, fill text fields, and analyze what it sees on our application windows. Do you know if any of those tools would be able to do that? The only one that seems to be based on picture recogniction is Sikuli, apparently now renamed Sikulix. Could anyone confirm? And is there any way other than picture recognition to interface that 3rd party tool with our Labview application? (I guess we could add a bunch of LabVIEW code to have some TCP/IP communication, but the goal is not to have to modify our application...) Thanks a lot for any advice!
  12. My advice is to completely rewrite this VI with a proper state machine. I'd recommend the JKI state machine. Have a single while loop containing a case structure, where each case of the structure is a state. You should at least have an Init state, an Idle state, and an Exit state. In the Idle state you want to have your event structure so you can detect that the Pause or Stop buttons were pressed. If no button were pressed then the Timeout event will occur, and this is where you want to handle your pump and do your math... Good luck
×
×
  • Create New...

Important Information

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