Jordan Kuehn

6 hours ago, Mads said:

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

 

 

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. 

21 hours ago, Rolf Kalbermatter said:

No! An rtexe is not a real executable. It is more like a ZIP archive that can not be started in itself but that needs to be started by invoking the runtime engine and passing it the rtexe as parameter. And the exact mechanism is fairly obscure and not well researched and totally not documented. Unless you are a Linux kernel hacker who knows how to investigate the run level initialization and how the LabVIEW rtexe mechanisme is added in there.

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.

Awesome, I will give it a try. The cluster writing would be great as well!

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.  

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.

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.

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

37 minutes ago, Rolf Kalbermatter said:

But the overall idea of the Community Edition license is: If you or someone you know makes money from your use of the Community Edition, you are in violation of the license!

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. 

55 minutes ago, ShaunR said:

However, the point I'm obviously failing to make is that Python has already conquered one niche space that used to be a strong selling point for LabVIEW and making it  Software-as-a-service will make it even more unpalatable going forward. Don't get hung-up on Python though. Javascript is a contender also. However Python is more ubiquitous in T&M at present.

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.

4 hours ago, ShaunR said:

The market has spoken. While you may be correct from a technical point of view, Python is now dominant in T&M and for everything else, there is Matlab. That leaves FPGA and Hardware still in NI's wheelhouse with regards to LabVIEW.

UI isn't a strength in LabVIEW and I take your point about Python with regards to WISIWIG component forms but when you do everything with an HTML interface-it's just a back-end choice with Python being a lot easier to interface to. The question to ask is...if I wanted to create an application that produced a walled garden like NI are now doing (a service in the cloud); how easy would it be with LabVIEW? I can guarantee that a lot of the services they are now promoting have very little LabVIEW programming in them and this is where many industries, including NI now, have already moved to.

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 minutes ago, Rolf Kalbermatter said:

Well, it depends a little on the duration of use. With the perpetual model you paid a hefty initial price and then a yearly SSP for as long as you wanted to be able to use newer LabVIEW versions, have access to technical support (which for a few years has been next to useless but it seems it has improved considerably in the last year). With the subscription model you pay a lower initial price but a higher early subscription price than what the SSP used to be. If you have a current SSP you can initially transition to a subscription license for the cost of your current SSP (and lock that in for to up to three years) but after that is over, you pay significantly more per year than what you did with the SSP.

 

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.

51 minutes ago, Rolf Kalbermatter said:

Actually it is! If you stop paying your SSP fees you can still continue to use the LabVIEW version that was current when you stopped paying. With the subscription model if you stop paying, any software version will stop working at the end of your subscription term. No loading up an old program to fix this little bug that would anyhow be to much of a hassle to port to the greatest and latest LabVIEW version. Any LabVIEW version you have installed simply stops working.

You could of course install LabVIEW with the Community Edition license then, but that violates the license agreement you entered when signing up for the Community Edition if your program is used in any professional capacity. And the Community Edition does not include things like RT, FPGA, and just about every other thing with a paid license including the Application Builder.

And if NI decides to shutdown their license server altogether, or for certain older versions of LabVIEW you are equally hampered. It's unlikely that they will let you activate LabVIEW 2009 indefinitely under a subscription model. I'm not even sure if you can activate older versions if you sign up for a subscription model now.

Yes it is how every software provider is heading nowadays. Greater revenues and user lockin are tempting. Once they got a user, be it Office 365, Altium and now LabVIEW the user has only the choice to keep paying or stop using the software platform altogether with all the hassles of trying to port existing solutions to a different platform which simply does the same anyhow. So the challenge is to get people to sign up and start using it, after that it is a safe business that is not so easily going away unless you totally start to f*ck them. Rising prices? If you do it in regular small steps, except for new users, you are not likely to lose many users! Nobody wants to end up with Office documents that he can't open anymore!

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.

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. 

You may have better luck on ni's forums. Especially if your IT needs an answer from NI staff.

4 minutes ago, Oprea said:

Can LabVIEW (via LINX) put data on the virtual front panel of a Raspberry Pi so that an app such as VNC Viewer can see it remotely using any laptop?

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/

5 hours ago, Heiso said:

As an update, 3 days in after disabling the Set Time vi and re-enabling the Linux OS time synchronization and it's going strong.  It looks promising, and if it makes it a week I'll let my guard down a little.

Assuming this fixes it, if I can't use the Set Time.vi to set the system clock, how can I synchronize multiple systems that are geographically isolated and have no common network timing source (e.g., NTP, PTP, etc.)? GPS is something that's readily available so I'd like to use that, but not if it's going to cause lockups days after I call the function a single time... Again, this is all predicated on disabling GPS fixing the issue.

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

10 minutes ago, Antoine Chalons said:

Indeed the IC line of product was supposed to stand between the cRIO and PXI in term of perf - without offering the modularity that cRIO and PXI offer of course, but for Vision application it was ok with usb3 and GigE.

But even then, the perf was disappointing for heavy vision application. I use to use Advantech IPC range, updated every 6 month with new CPUs etc.

 

Supporting 3rd party hardware with NI Linux RT would probably require a huge effort for NI, not sure they're ready for that.

And where NI is disappointing me a bit more is by not telling us what their plan is for Hardware between cRIO and PXI, at least if they were to say they are only going to maintain cRIO and PXI in the future at least we'd stop hopping a find a different solution.

I agree with all of this.

8 hours ago, Antoine Chalons said:

At some point NI was considering allowing to install NI Linux RT on non NI hardware, but I seriously doubt they'll ever to that, it would be in huge contradiction with their business model.

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.

How is your disk usage? I've had systems lock up when filling the drive.

2 hours ago, F-souza said:

However, here in Brazil, NI is now providing a poor service the cost is escalating very quickly. 

Could you expand on this? Are you seeing poor service regarding support requests? Or something else?

15 hours ago, Oprea said:

Hi, Jordan.  Do you (or anyone else) know of any additional LabVIEW LINX libraries for Raspberry Pi?  I'm looking for as many different hardware drivers that I can find.

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

13 minutes ago, Neil Pate said:

After getting burned by the system with the USB cameras I switched over to GigE and never looked back. Multiple USB cameras running at full frame-rate is a recipe for disaster!

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

This may be of some help:

https://zone.ni.com/reference/en-XX/help/370281AG-01/nivisionlvbasics/acquire_or_read_an_image/

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/

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.