Jump to content

Jordan Kuehn

Members
  • Posts

    621
  • Joined

  • Last visited

  • Days Won

    16

Everything posted by Jordan Kuehn

  1. Oh that’s perfect. Just like OP on that post it’s the reboot time that’s the issue for me. This line is what I was missing: /etc/init.d/nilvrt stop && /etc/init.d/nilvrt start I’ll give this a try. Thank you.
  2. Rolf, I've been looking for this information myself. Not quite in this use case as requested, but simply to restart the application. Do you have any reference for simply restarting the runtime engine and relaunching the configured rtexe? SystemLink is capable of doing this, but I haven't managed to figure out how yet.
  3. Awesome, I will give it a try. The cluster writing would be great as well!
  4. So, I think you have pulled it apart fairly well in your summary. I believe the issue with the regular Write function is that it can fragment the data and builds the index on the file to take care of this. That combined with flushing, segmenting file writes, and defragmenting after completion will address it for many use cases. The waveform issue is that first the advanced write won’t take the data type due to the properties next to it, and that’s all it is like you said, and array of doubles, some standard components (t0, dt), and possibly some variants. Then second even if you were to write an array of doubles using the standard write vi it is not as performant. When using the advanced VI you specify the block sizes and it streams that to disk exactly as written. (I’m sure there’s a little more complexity at the c level here.) So you must write the same size every time, but it is quite fast and does not leak memory. So, I see a space here where in general advanced tdms functions could be chosen given the condition that subsequent writes follow the same size as the first write (allowing to read that and perform the configure), and then to further that, could automatically unbundle a waveform type to package the properties up and write the array. It’s a thought, and something I’ve encountered a few handfuls of times over the years and it’s a pain every time.
  5. Hooovah, I appreciate this toolkit and the work you've done to make it. I have a common problem that I run into and eventually just have to bit the bullet and roll my own solution. When streaming large datasets to disk I have to use the TDMS Advanced vis to get it to avoid a memory leak. It is even worse with waveforms, though I would like to be able to write those directly you can't with the Advanced vis. So I wind up stripping the t0 and dt off and saving as waveform components, flushing the file to apply them, configuring block sizes, etc. Could this library be adapted to use the more performant vis, with some preconditions, say that all subsequent writes must be identical in size/composition, so that I can stream waveforms to disk? I attempted to use your size based file writer and ran into the same memory leaks I encountered when using the regular tdms files, described here.
  6. Anyone have any news if NI will be bringing this conference back? I see the Austin Convention center has a listing for May 24-26, 2022.
  7. I was unaware of this bug until today, but I figured it might be appreciated as a heads up in this sub-forum. There is an issue with LINX (or whatever it is now) and LV2021. The link below has detailed instructions for configuring a fresh pi as well as updating one that is already set up for 2020. https://forums.ni.com/t5/Hobbyist-Toolkit/Labview-CE-2020-connects-to-raspberry-but-CE-2021-does-not/td-p/4198964
  8. What if you created an open source tool kit via CE and then someone else profited utilizing it? Arguably the best use case for CE to built out the community code could get legally murky? I am not a lawyer, just an engineer.
  9. I agree with you here. Community edition of LV is one step forward, while SaaS is a few steps back in terms of pursuing market adoption. Python is ubiquitous because it is free and people can copy/paste code bits they find on sourceforge together to get something to work while playing around with a Pi at home/university. Then they find those skills actually have value in the market.
  10. At risk of derailing this topic I've seen you make many arguments as such, but they rely on the assumption that the user is utilizing an HTML "View" and can plug and play LV or Python or whatever behind it. In your workflow I 100% believe that is the case. However, I do not think that is common. Certainly I will admit my knowledge of python driven UIs is lacking. However, flawed and outdated as LV UIs are, they are still an advantage from my perspective. I have dabbled with your approach and do see the positives there, but it's not dissimilar to having to program a host application for an RT target and adding an additional layer to every application.
  11. Gotcha. That's with the pricing structure as it stands today right? Theoretically they could meet in the middle or change things in other ways as that lock-in rate starts expiring for *lots* of users all at once.
  12. I think we said the same thing here, albeit mine was far less comprehensive. Are there other caveats other than the switch getting flipped off on the software when you stop paying? I'm not diminishing that one, but in terms of practical impact if you currently maintain an SSP there is no real change.
  13. It seems to me that if you already maintain SSP it's not a big change aside from the point above should you choose to stop and no longer have access to LV.
  14. You may have better luck on ni's forums. Especially if your IT needs an answer from NI staff.
  15. No. But you could host a web app and then view it from within the pi in a browser. Here is an example application you may be able to use for inspiration. Credit Sam Sharp I think. https://www.mediamongrels.com/democracybot-rpi-linx-websockets-nxg-webvis/
  16. I think if you can reach an NTP server you’ll be ok if sub-second accuracy is tolerable. If so, see my comment on this KB article. The whole thing is worth going through and there are a few different ways to go about it. I think mine combines them all including disabling NI-Sync. Note that this is only available on version 20.1 or higher. This has bit me since I have many systems with 20.0. https://forums.ni.com/t5/Example-Code/Installing-and-Configuring-NTP-on-NI-Linux-Real-Time-Devices/tac-p/4165930/highlight/true#M14787
  17. If they do not do this they need to beef up their offerings. Right now the 9047 is the most powerful cRIO platform (-40C) and we are reaching limitations with it, but the only more powerful platform is a PXI controller. Lettings us put Linux RT on hardware we source would also help with the current lead times that are stretching out past 6 months for some of this hardware.
  18. How is your disk usage? I've had systems lock up when filling the drive.
  19. Could you expand on this? Are you seeing poor service regarding support requests? Or something else?
  20. This website is old, but has some information. https://www.labviewmakerhub.com/doku.php?id=libraries:linx:start You might also find some useful things here: https://forums.ni.com/t5/Hobbyist-Toolkit/bd-p/linx-toolkit?profile.language=en
  21. When using GigE make sure your network adapter supports jumbo frames. Or at least be aware that this is necessary at times. https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019Lj9SAE&l=en-US
  22. This may be of some help: https://zone.ni.com/reference/en-XX/help/370281AG-01/nivisionlvbasics/acquire_or_read_an_image/
  23. What chip is it? There are several libraries out there for some common hardware. This link may be helpful. https://www.vipm.io/package/mediamongrels_lib_linx_raspberry_pi_addons/
  24. We have had some similar issues. In general we could get in touch within a few days of pestering, but occasionally we escalated to the (3rd Party) sales rep as well. Support has certainly taken a noticeable hit in the last couple years.
×
×
  • Create New...

Important Information

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