Jump to content

Mads

Members
  • Posts

    374
  • Joined

  • Last visited

  • Days Won

    23

Mads last won the day on January 10

Mads had the most liked content!

About Mads

  • Birthday 12/01/1975

Profile Information

  • Gender
    Male
  • Location
    Bergen, Norway
  • Interests
    Trail running, skiing, fly fishing, science fiction, food and travel.

LabVIEW Information

  • Version
    LabVIEW 2020
  • Since
    1997

Contact Methods

Recent Profile Visitors

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

Mads's Achievements

Apprentice

Apprentice (3/14)

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

Recent Badges

76

Reputation

  1. The path to the rtexe launched by the RTE is not fixed...so perhaps you could just change the given path before killing the current application? I have not tried, but if it works it would allow you to keep multiple rtexe files instead of overwriting them: On LinuxRT the path is in: etc/natinst/share/lvrt.conf which is an ini-file formatted file it looks like with the key: RTTarget.ApplicationPath=/home/lvuser/natinst/bin/startup.rtexe
  2. We normally just make the executable reboot the cRIO/sbRIO it runs on instead, through the system configuration function nisyscfg.lvlib:Restart.vi, but here are two discussions on killing and restarting just the rtexe on LinuxRT: https://forums.ni.com/t5/NI-Linux-Real-Time-Discussions/Launching-startup-rtxe-from-terminal-or-linux-window-manager/td-p/3457415 https://forums.ni.com/t5/NI-Linux-Real-Time-Discussions/Is-it-possible-to-close-and-re-open-RTEXE-through-Embedded-UI/td-p/3707540
  3. LabVIEW, as the Xerox GUI, needs a Steve Jobs... I was an Apple fan back in the 20 MB HDD days. It was only natural to fall in love with LabVIEW as well.🤩
  4. I do not like to judge anyone by their official background but if we are talking about it his background prior to that seems to be mainly in hardware and testing. He has a lot of chiefs, vice presidents and fellows under him though...(Too many, with too much overlap is my initial reaction). I do not fully grasp how the top management ended up with those particular titles, but based on their titles I assume the two most responsible below him in the hierarchy for taking care of LabVIEW are the newly hired CTO, Thomas Benjamin (with SaaS background) and Scott Rust, as the Executive Vice President, Platform & Products, or? Where in the organization does Omid Sojoodi , the Senior Vice President of R&D, Software sit? This is the best organizational map I found. It has one role specifically for software strategy, but that's a software *sales* strategy role it seems?
  5. What I do not understand about the decision to change it into a subscription model is the timing (and pricing). With the (predicted) failure of NXG, NI should lay low and try to save as many customers as possible from running off scared. Looking at the numbers and seeing how much money they threw at NXG it seems as if they think; well we need to cover that cost... What they should do is conclude that they need to seriously change (revert?) how they run their business (especially the LabVIEW development projects). The true cost of NXG will continue to rise by causing damage to their brand; unless they *simplify* ownership, *lower* the price, increase the work to recruit new (starting with students) and keep customers -AND invest the required amounts into developing a proper "NXG" (it is the foundation for the ecosystem that makes NI great, the cost of it has to be divided on the whole system, not just the SW itself). When that work is well on its way, and only then, they can think about subscriptions (the SSP solution is much more customer friendly though) and increased prices.
  6. Is this an announcement you know will be made later today, or has it already been issued? In the latter case - do you have a link to it? I could not find anything... Or better yet - elaborate, if you can 😉
  7. How realistic is the test setup that fails to reproduce the issue? Does it have the same potentially slow/unstable links/external devices, does it run the exact same operations etc? Perhaps a DNS server that disappears from the network now and then e.g, or other connected equipment that fails / you can cause errors in to expose potential issues? Is the test unit set up based on an image of the troublesome unit? More difficult obviously but can you alternatively downscale software/ turn off some of the tasks / remove parts of the code on the field unit to see if that removes the issue? When the cRIO fails to respond is it really dead locally as well, or is it running/responding locally? We have had units unreachable through existing network links due to DNS and other issues where we had to modify the code (remove any DNS lookups e.g.) to get it to respond properly... Have you tried enabling and reading the debug output from the device? We had some sbRIOs crash without much explanations due to a sudden spike in the memory usage (inferred, not fully observed) caused by a calculation that was triggered. There was no obvious reason; the debug logs and memory monitoring could not really explain why - we just had to push down the memory footprint until it started working... Have you tried formatting the cRIO in the field and setting it up again? Would it be possible to replace the cRIO in the field with another one - then bring the field unit back and use that to try to recreate the issue? If it stops in the field with the new cRIO it is most likely linked to the cRIO hardware...or a system corruption on it. If it shows up witht he new cRIO and not in the test setup the test setup is obviously not realistic enough...
  8. For logging of some of our more erratic parameters we are looking at using this algorithm. It is called "Largest-Triangle-Three-Buckets" and is quite simple to implement. For more gradually changing values (tempeatures or pressures e.g.) I found a nice compression algorithm many years ago that was patent-protected by GE at the time. The patent is expired now though, so it should be usable. I have attached a demo of that one here (run CACF_Demo and generate a fluctuating value with the slider to see how it compresses the data), it is called the Critical Aperture Convergence Filter. Critical Aperture Convergence Filter.zip
  9. In the example I posted earlier there is a tab at the bottom which (seemingly) scales nicely. It is a trick though...I described it a long time ago here. Maybe someday we get this implemented.... Or better yet, anchoring.
  10. Awesome as in unusual but cool / exploring new concepts in user interface design (often irritating the user in the long run though...) - or as in user friendly and nice (non-LabVIEW-typical?) looking? I too would love to see examples of what others have made. I can share some of the designs I have made myself or have influenced, that I think at least fit the user friendly but not typically LabVIEW-looking bill: We make monitoring systems and use LabVIEW to develop everything that runs on PCs and PACs. I have always put a lot of effort into making the user interfaces as nice, intuitive and recognizable as regular Windows applications (helps with the intuitiveness) as possible in G...The system typically consists of a headless service/embedded server (sbRIO inside a subsea device e.g.) gathering, analyzing and logging data from sensors, and exposing it to control systems or data historians through Modbus, OPC or CANOpen. Users can connect remotely to configure the server and view and analyze the results using application specific clients (through TCP, serial or CANOpen (Cia309.3 transparent links)). Here is a screenshot of the main window of one of the clients (this one is used for corrosion-erosion monitoring): We also make many of the tools we need to do tests and troubleshooting on these sensors and systems, and some of them we have chosen to release as shareware (CAN Monitor on the NI Tools Network e.g.). Here is an example of the Modbus Test Master: We do not earn much from the shareware, but since we want these tools ourselves anyway, and need to maintain them, having them out there at least do not cost us much. It also puts a bit of extra pressure on us to make even (some of) the internal tools look and work well.
  11. I agree with you, and would normally stick to just a File\Exit menu option and window close. As long as extra ways of closing the application do not harm (read: confuse) more than they help I would not argue too much against them though. It depends mostly on the type of application. Different people prefer different solutions (the true lesson in the 80/20 rule). A File>Exit (Ctrl+Q) menu option and the window close covers the standard methods, so they should always be there, but if the application might end up running on a computer with a touch screen, and access to an exit is desirable, having a button would be nice too - and not weird. (Assuming it is made distinct from other buttons that just stop sub-processes (as ShaunR mentioned earlier)). I am lucky to normally have the final say in such matters myself😃. PS. We used to have a financial system that did not offer any save options. Instead you were always required to select print, and then Print to file (💩!). I would love to meet and have a chat with the people who designed and approved that solution😉. (This was even before printing to pdf e.g. became a concept, which at least makes it partially recognizable as an *optional* route today).
  12. I have to agree with the requirement (although having an OK and a Cancel would suffice unless you also want to apply prior to closing the window). Stick to the norms established by the OS, familiarity is key. If I regret entering the dialog and/changing something having OK/Cancel there will allow me to recognise what to do in a fraction of a second. If this particular designer though it obvious that closing the window would revert...eh, I mean save the...hmmm. Do I need to change back the changes I did, or is it enough to close the window, I wonder....🤔
  13. Hi, My guess is that you have set the Get Image method to use 16 bit colors. Use 24 bit and it will show up correct (I recreated and solved the issue just now by generating a front panel image of a screenshot of your original colors).
  14. What is the cost you are worried about? Is it speed, memory, or both? If it is speed - is the example representative? In that case I would calculate the window function within the inner loop and just output the result, not generate an array of all the subwindows and *then* apply the actual window calculation. The loop(s) can also be configured for parallelism to speed things up significantly (assuming you have more than one core at least)... More speed, less memory. If none of that reduces the cost enough you will probably have to do the processing in external (non-G) code.
  15. If only NI could implement my second most popular idea on the idea exchange 😉 (please vote!). (Hopefully they can squeeze it in while working on my most popular idea/rant which partially covers this one anyway).
×
×
  • Create New...

Important Information

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