Jump to content

Jordan Kuehn

Members
  • Posts

    688
  • Joined

  • Last visited

  • Days Won

    21

Jordan Kuehn last won the day on June 26 2023

Jordan Kuehn had the most liked content!

Profile Information

  • Gender
    Male
  • Location
    Chicago

LabVIEW Information

  • Version
    LabVIEW 2023
  • Since
    2009

Recent Profile Visitors

7,378 profile views

Jordan Kuehn's Achievements

  1. I've found the newest files edited in this directory provide some insight when you have crashes or issues with your app starting. It's not always intuitive as to what all is there, but I have been able to identify problem components from the legible portions. /var/local/natinst/log I don't share the same experience as Mads regarding reduced reliability or increased bugs, save for the compilation issue I commented on in another thread which was actually a software bug I introduced and discovered via that log directory. We utilize hundreds of cRIOs across the country running for weeks or months at a time in mission critical applications. In fact the reliability of Linux RT is a pretty big factor in keeping with the platform instead of utilizing expansion chassis and a central computer approach. Obviously built-in FPGA is another huge asset when needed.
  2. I have many systems that utilize NSVs with programmatic access. They are reliable and work well in these applications. That said, we've transitioned away in newer applications and utilize MQTT for communication. There are several flavors of tcp communication wrappers/messaging libraries around as well.
  3. Are you able to see the shared variables listed under the target using the Distributed System Manager? Depending on the type you may or may not be able to see the current value, but its presence alone will help tell you if it was properly deployed or not. Further, are you capturing errors when writing or reading from them? While the error codes aren't always super helpful they can lend some insight. Lastly, are you dropping the variables on the BD from the project to r/w or are you programmatically addressing them and utilizing the shared variable vis to communicate with them? The latter option, while not as convenient, seems to be more robust, scalable, and gives you the most insight into the activity or errors there.
  4. Well this is timely. We upgraded to 2023 Q3 64-bit a couple months back. No major issues at the time, even transitioning to 64-bit and programming RT. However for the last several days I have RT builds that proceed successfully but simply will not execute on the target. These were already built and deployed after the transition just fine, but now after minor changes it refuses to build something that will run. It's certainly possible I have a problem in the code or whatnot, but your post popped up on day 3 of me fighting this so I figured I'd chime in.
  5. Google can be easier at times. If you include site:lavag.org at the end it will filter it. That said, I could not find that thread with Google either. Even searching the title itself. So, my suggestion isn't super helpful in this case, but I use that google feature often with LAVA or NI.
  6. Implementing the State Pattern in Actor Framework.pdf This PDF is in the project template. I'm literally in the middle of a new State Pattern implementation and am using this template for the first time myself. If anything it could use a refresh with the new launch nested actor vis, but aside from that the information is available in this example project.
  7. Excellent points. All of them. I have echoed your frustrations with the ability to put Linux RT on arbitrary hardware, with lack of low/middle cost I/O boards, lack of low cost FPGA, etc.
  8. Included in the project is documentation that directly addresses your question about overriding the Substitute Actor.vi including some caveats and considerations to make while doing it. The project itself is a simple functional example as well, as originally requested.
  9. Stagg54's suggestion was a good one. Take a look at the State Pattern Actor example project that heavily utilizes this override. https://www.vipm.io/package/ni_lib_state_pattern_actor/
  10. Thank you for sharing! I would have never seen it since I'm rarely on those forums. The link is broken, but here is the darkside link: https://forums.ni.com/t5/LabVIEW/Darren-s-Occasional-Nugget-08-07-2023/td-p/4321488
  11. If you have a current service agreement I would suggest taking this to NI directly if you haven't yet. https://sine.ni.com/srm/app/myServiceRequests
  12. SystemLink is an (expensive) solution to this as well. Though it doesn't give you project or shell access. Another, cheaper, alternative is to utilize a modem/router based VPN so that you can see the devices. Cradlepoint and Peplink are two that we have used.
  13. Here's one for you. The AXS Port is a modbus device that monitors power inverters. It would be great to feed Nigel the attached document and have it generate drivers/API for communication with the device. https://www.outbackpower.com/products/system-management/axs-port Another one for you, in a similar vein, but a little less straightforward. This is a Banner IO-Link Master that can communicate via ethernet/IP or modbus. An ethernet/IP driver would be great that could configure the device as well as the IFM DTI434 IO-Link RFID read head also linked below with attached documents. https://www.bannerengineering.com/us/en/products/industrial-networking---smart-i-o/io-link-masters/dxmr90-ethernet-io-link-master.html?sort=4#all https://www.ifm.com/us/en/product/DTI434 ifm-DTI410-20190125-IODD11-en (2).pdf dxmr904k.pdf axs_app_note.pdf 229732.pdf
  14. The demo made me wonder if it could theoretically create drivers from spec sheets automatically. It seems like it would be a well bounded problem, create labview wrappers for the commands listed in the manual.
  15. Is anyone headed to Austin for NI Connect in a couple weeks? Since I haven't seen any LAVA BBQ news I assume that's not happening, but perhaps we have some fellow LAVA-ers(?) interested in gathering somewhere?
×
×
  • Create New...

Important Information

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