Michael Aivaliotis

13 hours ago, bbean said:

I need to image a few cRIOs in the near future.

Creating a crio image is a little different than changing the entire OS stack from Windows to Linux.
You can image a crio using the Replication and Deployment utility. I use this all the time.

Quote

 I would like to convert the cDAQ 9133 with WES7 to LinuxRT. 

I think you would need to get the installation image NI uses to setup that specific Linux cRIO and some instructions. NI has the image and they can choose to give it to you or not. If they can't provide it due to warranty or licensing issues. Then they should offer a service where you send it in so they can do it for free or even a fee. It's not unreasonable to ask for a service fee since this is not a common request. However, considering the astronomical cost of the hardware, they should do this without question. In the past, when I've requested things from support that are out of the ordinary, they tend to shrug it off. However, once I get a sales rep involved and explain the customer need and criticality of the situation, then they have the power to get support to do anything. NI should be doing this, not you.

Not sure what's going on but their download speed is a snails pace across the board.

I mentioned that I would make an announcement when new account creation will be available. Well, today's the day! I added a google captcha system on the Wiki so it will prevent bot registrations. I think this is working. I haven't seen any spammers for a couple days that it's been running. So if you have the urge to contribute or use the Wiki for your LabVIEW related content, then go right ahead.

There's no restriction at the moment to what content is allowed. As long as it relates to LabVIEW in some way and adds some useful information. There will be ongoing editing of course as content comes in.

Hey LAVA worshipers! Just wanted to update y'all on recent changes to the site. LAVA and the WIKI are now running on a dedicated server. You will notice that the site runs faster because of this. Also because of the transfer, we got more disk space which will help if we want to host a repo in the future. Anyway, just wanted to keep you in the loop so  you know that there's work happening behind the scenes to keep the LAVA site running smoothly and with the latest features. Some of the funds for this comes from the site ads and some comes from the yearly LAVA BBQ. So thank you all for your contributions and support.

7 hours ago, MikaelH said:

I hope it will be easier in NXG.

😀

Check out the awesome home page updates that @The Q has made. Huge improvement. I love it!

https://labviewwiki.org

Just ditch 8.5 man.

*sigh*

Seems like a LabVIEW bug.

@Antoine Chalons doesn't have to write the session reference back to the class. But he also can still keep the class object out.

Have you investigated a source distribution? It should pull in the DLL since they are referenced by the VIs.

3 hours ago, Phillip Brooks said:

EasyXML Toolkit

Ya, but at least I can checkout the EasyXML repo locally and even fork it, which I have.

50 minutes ago, TomOrr0W said:

LabVIEW 2015 SP1 is also supported on WIndows 10

Yes, I ran into this issue as well. I couldn't upgrade a customer PC to Windows 10 because I was using LV2014. So then I decided to upgrade to LV2018, but the customer had 1 PC running WindowsXP. yes. XP. So that aborted the whole upgrade, just for 1 PC. So the highest I could go was LV2015.

On 9/28/2018 at 12:01 AM, ThomasGutzler said:

Interesting choice on ignoring the incoming error when you get the attributes

Yes, but ignoring the IPE error out on read as well? I would think that you would want to know if the IPE structure fails completely. This would be a sign of a bad DVR ref.

10 hours ago, Rolf Kalbermatter said:

But I'm not familiar with the exact release procedure

That's great @Rolf Kalbermatter . If we can figure out this last piece, then it would go a long way to allowing improvements to the library. I think it would also be useful to document this procedure somewhere, perhaps in the Wiki. However, I think the answer might be: email JKI to get it released.

See this post. This thread is now closed.

8 hours ago, TomOrr0W said:

Has JKI ever mentioned why they chose to have this restriction?

Isn't it obvious? Charging for desirable features is one way of creating revenue. Deciding where to draw the line between free and paid features is always a challenge.

2 hours ago, Jim Kring said:

LAVA posts aren't the best way to get in touch

The OpenG forums here on LAVA have been considered as official channels for some time, unless that's changed. But thanks for finding this. I think moving to GitHub is a great idea and would allow better collaboration. Bug reports and feature requests can be managed on GitHub more efficiently probably than on LAVA. However, freeform discussion forums are also very usefull. What can we do to accelerate the Github migration?

45 minutes ago, smithd said:

Also, a good landing page for NIPM is: https://forums.ni.com/t5/NI-Package-Management/NI-Package-Management-Portal-READ-THIS-FIRST/ta-p/3805952

Ya, I saw that and am planning to read through that to be better knowledgeable on what I'm complaining about. But for starters, there are 3 questions on that doc and nobody from NI has responded. Stuff like that irritates me.

There's no NIPM forum though. None that I could find anyway.

Assuming all you claim is true as of this writing. Then yes, I can see several things that are limitations. Let me look at each one:

1. Palette editing. You can edit palettes in LabVIEW and grab the menu file. I know, it would suck, but not a deal-breaker.
2. Package release for every LabVIEW version. Wow, this seems like NI took the one built-in feature of LabVIEW (automatic up-conversion) and threw it out the window. Way to go NI?
3. Pre-Post build actions. I would have to look into this further. I thought NIPM had a command-line interface (or at least this is what I was told). You could build a wrapper around that and create a VIPM-like experience, could you not? Then include your pre-bost build steps? Perhaps include palette editing (see item 1).
4. Only Post-Install and Pre-Uninstall actions are allowed. - Ya, more flexibility is needed. Not a show-stopper though.
5. Package dependencies seem to only be checked between the current feed. - That could either be a fundamental flaw, or a benefit. Not sure. However, it would be nice to have the choice. In VIPM there is no line drawn on this, and it's sometimes useful to limit yourself to a certain repo. Seems Ni took the safe approach.
6. No dependency scanning. - This is a useful feature, but I'm not sure in what context you are referring. Do you mean, during package building, to make sure the dependancies are declared? Manually declaring dependencies might be ok for now.
7. No package of packages.- Meh. Nice to have but there are other possible solutions to the same problem.
8. No offline single file with everything included - VIPM doesn't have this, unless you are referring to VIPC files.
9. Packages can't be loose VIs, they must be in something like an EXE, or source distribution first. - Well, VIPM creates a source distribution behind the scenes when it builds a package. But I get your point. NIPM could hide this complexity. - Not a showstopper though.

I think it's a combination of all of these issues that make NIPM a bad choice right now for packaging VIs.

However, If I imagined a world where VIPM did not exist and all I had was the current version of NIPM. And I was 15 years younger... I would probably figure out how to create a VIPM-like interface to the NIPM core. Fixing all the inadequacies. Not saying it's possible, but I would be working on that right now. Because it would be a fun thing to do. After all, it's how VIPM was built in the first place.

The core of it though is that NI is betting on this horse and is putting resources into it. I suggest we guide it in the right direction and make sure it's a winner and does what we want it to do. If not, then we should figure out a way to work with it, augment it and fix it. The more we do that, the more NI will make it better and modify it to remove limitations. - sigh, at least I hope.

Check out the NIPM API

6 hours ago, LogMAN said:

I agree. It just needs to be more visible to users (i.e. by putting "Downloads" in the main navigation bar next to "Leaderbord")

Done!

I've only just seen this thread.

So the mechanism for creating a repo is simple and the current LAVA server can do this no problem. The issue is file size which would would eat up disk space and is what costs money. However, there are ways around this. For example, as @rolfk pointed out, the OpenG packages are served up from sourceforge but distributed from the JKI repo. So workarounds are possible. I don't want to get into that right now as this is not the main issue.

There are 2 main VIPM Pro bottlenecks that have to be addressed for a LAVA repo to become a reality. First is the Repo management. This needs a Pro license. However, since this function only needs to be done be a handful of people and infrequently, it could be acceptable if LAVA purchases a license and assigns some administrators for this. Second bottleneck, and the biggest hurdle, is that in order to subscribe to a repo you need a Pro license. This is the main thing preventing widespread adoption of the VIPM repo model. If JKI removed this barrier, then it would make sense to not only have a LAVA repo, but a number of repos. That would mean that anyone with a free license of VIPM could connect to any repo and get the tools they need from within VIPM, from the repo they care about. Companies could create internal repos and use that to distribute code to their developers. Or special repos for their customers. ?The possibilities are endless ?.

Ok, back down to reality.

Maybe we can use NIPM? I was browsing this content and it seems NIPM allows public feeds:

https://forums.ni.com/t5/NI-Package-Management/Introduction-to-NIPM-Feeds/ta-p/3808155

What's the issue with NIPM exactly?