Jump to content

Thoric

Members
  • Content Count

    150
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by Thoric

  1. I should add that this is in LabVIEW Real-Time 2017 SP1. When launched from the IDE it works fine, but when compiled and deployed as an RTEXE that's when I see this issue.
  2. I'm returning to some Messenger work after a short break, which might explain why I can't see what's wrong with my Messenger Actor based project. Right now I have a Main actor which is responsible for launching a number of sub-actors. One of these is the FPGA actor. Directly after the launcher I register for all notifications. Within FPGA actor, the "Self: Initialize" message runs a number of states, the final one being to publish a notification event. This is to be received by the Main actor to known when it has initialised. Unfortunately this event is not received by the Main
  3. For your front panel to resize to fit a changing front panel control, you will need to programmatically adjust it. There is no way to do this automatically. Smarlow has shown a great example above of how to do this.
  4. Just be careful with kerning. A "w" character followed by a "a", for example, might be narrower than the sum of the "w" and the "a" separately. I'm not sure how advanced the text printing functions are in LabVIEW, but true-type fonts are often kerned.
  5. Can you set the FP to not show when called, then programmatically show the front panel within code. This ensures the FP will not display until it's actually running. Just a thought.
  6. James, I believe the risk is only with variants and there's actually been no change to their flattened syntax since LV8.2 A 2017 flattened string refused to be interpreted by older LV code is purely a precautionary act. However annoying it is one can understand perhaps the design intent. So unless there are improvements in the NI pipeline for flattening variants then I don't believe there are any risks with forcing the version to the same as the Messenger toolkit source version (2011).
  7. I have a separate issue. When I load my project which uses Messenger toolkit, LabVIEW warns that the "Library information could not be updated". This pops up three times consecutively, yet once cleared everything seems to work OK. I've seen this before, when I used Messenger library about two years ago on another project LabVIEW used to complain with the exact same notification (today that project loads without the warning). I've only see this warning when I open a project using Messenger toolkit, so I think it's fairly safe to assume it's related? I was wondering if anyone else
  8. My experience having used this technique in my own application (not Messenger Framework related, but nonetheless the same issue) is that it works without loss. This flatten function honours any attributes within the variant. It does not, however, include a bitness setting, so you cannot set the bitness to your own choice. However, this shouldn't be an issue when passing data between Messenger actors. There are, as far as I understand, no changes to the variant flattening syntax since LabVIEW 8.2, so unless something changes in the future there would be no loss of info using this.
  9. My issue is not with Messenger, but with my own variant handling code between differing versions of LabVIEW. The LabVIEW version data requires 8 bits, not just the top 5 bits. For example, LabVIEW 2012 is represented by x12008004. But if the Messenger library (built in LabVIEW 2013?) were to enfornce the same LabVIEW version format for all flattened data then they ought to be compatible across all instances. I'm still battling to get this to work in my own code - I'm encountering problems associated with nested variants (A variant as part a few items in a cluster array, which is pass
  10. Unbelievably, I'm encountering this exact same complication today. As far as I can tell, the reason is that variants are flattened to strings differently in every version of LabVIEW. Althoug the schema is the same, the actual version of LabVIEW is prepended in the flattened string. Thus, when a 2016 flattened string is passed to LabVIEW 2014 it does not assume to know the schema and throws error 122. NI's white paper on using "Variant Flatten Exp", which allows you to set the flattening format structure, is their recommended approach. Thus you can set your 2016 code to create 2014-st
  11. Hi Rolf, Thanks, that sounds very interesting. I wonder if there's documentation (MSDN?) that covers these requirements. I'm looking forward to hearing back from you on the availability of your toolkit.
  12. I'm attempting this today. I have a LabVIEW 2014 executable to be launched as a service on Windows Server 2012 R2. I followed Microsoft's instructions to run "instsrv.exe <service_name> srvany.exe" (exes are from the resouce toolkit), and then configured srvany to launch my LabVIEW exe as a service. I can see it listed in the Windows Services manager. Success. However, this appears to be a dirty way to convert any application into a service. What it really does is turn "srvany.exe" into a service, and then you configure srvany to launch your application. This means there's no r
  13. A quick VI that creates sparse representations of digital data, and plots them. The plot supports multiple waveforms and includes a horizontal scrollbar to scroll through the time axis. It needs axes plotting adding, and support for zoom (just need to capture a user event, such as mouse scroll, to change x axis range and replot). This any use? Sparse_Digital_Plot_Multiple_Example.vi
  14. That's a very interesting need. If you represent your data sparsely, such that you store transitions and timestamps only, then you're unlikely to find a plotting tool that handles this data format. It might worth looking for a .NET control that exists already for this and interfacing with that. But I would prefer a pure LabVIEW solution if possible. My immediate thought is that you're going to need to create your own graphing tools. If you want to look at the entire signal then you'll need to reinterpret the sparse data in order to use it on a traditional LabVIEW graph, but then you have
  15. Neil - Random thought. If you build your LabVIEW numeric keypad into a DLL and call it with the CLFN, maybe then it will exist in Windows separate from the LabVIEW windows and can be self-manipulated to be NonActive? Wouldn't take long to trial, possibly worth a shot.
  16. According to this it's not possible due to the complex manner in which LabVIEW owns and manages it's own FP windows
  17. It didn't work! Here is the ini file, alongside the exe: [DWJar] server.app.propertiesEnabled=True server.ole.enabled=True server.tcp.paranoid=True server.tcp.serviceName="My Computer/VI Server" server.vi.callsEnabled=True server.vi.propertiesEnabled=True WebServer.TcpAccess="c+*" WebServer.ViAccess="+*" DebugServerEnabled=False DebugServerWaitOnLaunch=False HideRootWindow=True Any clues as to why my front panel still showed? It wasn't hidden or minimised, it was fully visible and on screen. I've also set "Allow User to Minimise Window" to disabled in the VI Properties, as indicate
  18. Thanks everyone. I'll use this approach. I am indeed using the Averna notification icon toolkit, which is why I wanted no task bar item to show for the application. So does anyone have an explanation as to why the VI behaves differently in the dev env compared to when built? I hate it when things change just because you build your code into an exe. Some things, like paths, are understandable, but visual behaviour changes are unacceptable to me.
  19. This quick test VI, when run in the dev env, immediately hides its front panel and the taskbar item for it disappears too, then two seconds later it sounds the PC beep, then closes itself an additional second later. The beep is purely there so that I know the VI is still running and not quit out. This hidden front panel is the behaviour I want for my VI. But when I build an executable from it and run it, the item in the Windows Task Bar remains. It's there for the duration (three seconds), then vanishes when the VI closes. So, why does the built executable cause a visible taskbar ite
×
×
  • Create New...

Important Information

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