Leaderboard

We'll grow into it eventually 😋

LV 2019 augments the right-click menus for class wires/terminals to provide a method list you can drop, which should alleviate this issue. I found a way to make the right-click menu plug-in able to add the graphical palette menus and then built a right-click plug-in that builds the method palette on the fly if the class doesn't already have its own default palette.

My first ever meme prompted from this post

PS: Did I mention that the design of these things was arcane and bad? Yes? Ok. 'Cause it's true. I have a long list of lessons I hope NXG learns.

XControls work just fine... if you dance with them the way they were intended. *head bang* If you don't want data to be saved, one way is to not put it in the State data. If you only need the data in the facade, add a shift register. But if you need it lots of places, put a global unique ID (GUID) in the XControl's state data, something that never changes after creation, and create an LV-2 style global with a lookup table from the unique ID to the data. You can create GUIDs on any LV OS using: LabVIEW 2017\resource\Framework\Providers\API\mxLvGenerateGuid.vi Changing the state shouldn't cause the VI to need to be saved unless it needs to be saved. So, yes, sure, in the IDE in a directly called VI, yes, changing state dirties the VI. But obviously that doesn't happen in a built app. AND, importantly, it doesn't happen in the IDE for any dynamically loaded VI (unless you are adding the 0x1 flag to track changes, in which case you get what you requested). If you're loading the hosted VI into a subpanel, that means you're working with it by VI Reference. So load it using Open VI Reference (without the flag) and the problem of being prompted to save should go away.

am I doing this right?

Not quite a meme, but my attempt at an NI style April Fools product announcement (a fake fake product announcement?). See links at the bottom of post for a history of NI's real April 1st jokes. A history of NI's April Fools' courtesy of the Wayback Machine: "National Instruments Announces PC-Based Solution for Matrimonially Inept" (1998) "Spousal Acquisition Toolkit Version 2.0 -- Now Featuring Undo!" (1999) "New MXI Interface Kit for Palm Pilot IIIc" (2000) "President Bush Nominates Jeff Kodosky to Cabinet Post" (2001) "New eIeI/O Software Suite Introduces eFarming" (2002) "New PXI Module Transfers Engineering Knowledge into Marketing Brains" (2003) "National Instruments Releases LabVIEW 7 Espresso" (2004) "Use LabVIEW Graphical Programming to Complete Your Tax Return" (2005) "National Instruments Announces Plans for 'Engineer Barbie'" (2006) "National Instruments Re-Releases LabVIEW 2.0" (2007) "Elementary Students Use NI LabVIEW to Model Impact of Simultaneous Trigger of Rapid Flow Events" (2008) "NI LabVIEW R&D Team Responds to Rumors About Performance-Enhancing Substances" (2009) "National Instruments Develops Cybernetic Leadership Team" (2010) "Time Capsule Captures NI Founders' Technology and Cultural Predictions" (2011) "National Instruments Releases King-Sized Products to Address Big Data Challenges" (2013) "NI Announces New Certification Level: Certified LabVIEW Gladiator" (2014) (Wayback Machine didn't have this one archived. NI pulled it pretty quickly supposedly because people seemed to be taking it seriously) "NI drives time travel with stylish new cRIO module" (2017)

Greetings Friends of LAVA, colleagues, cohorts, and Wireworkers Extraordinaire -- it's LAVA BBQ time! Date: Tuesday, May 21, 2019 Time: 7:30-10:00 pm Location: Uncle Billy's Brewery and Smokehouse, 1530 Barton Springs Rd, Austin, TX 78704 (1.5 miles from Convention Center) Cost: $25 Early Bird (through April 30th) $30 Regular Admission (through May 20th) $35 Door Price (May 21st) Meal Options: Expect to enjoy your choice of meats (brisket, turkey, ribs) with sides like street corn, cole slaw, and bbq beans. A vegetarian option is available when purchasing tickets. Cash beer bar. Who: Everyone is welcome, including spouses traveling with you. Even if it's your first time, expect to recognize many faces/names from the forums and NI R&D. What to wear: It's a covered, outdoor venue in Austin during Spring, so dress for the weather and comfort. Door Prizes: We will have a drawing to give away prizes. All attendees are eligible and will receive a door prize ticket upon entry. See below about sponsoring a door prize yourself to share the love. Hope to see you there! Chime in once you buy tickets to let everyone know you're coming. ------------>>------------>> Get LAVA BBQ 2019 Tickets Here <<------------<<------------ The venue is a 30 minute walk from the convention center, or a $6 Uber. Get together and carpool, people are typically gathering at Challenge the Champions in the Expo Hall, which is great fun. There is a free parking garage behind the building. We'd love for you to sponsor a door prize - Continue Reading: If you or your company want to sponsor a LAVA BBQ door prize, please post a reply below. You can also include a small blurb about your company and a link to your website in the post below. By donating a prize you and your company will receive a small announcement of your choosing, during the event. We will ask you to write the announcement on a post-it note and will attach it to the prize to be read before awarding it. We love the door prizes, but we love time for socializing too. Here are some guidelines to keep our event balanced and streamlined. Single item donations work best. If donating more than one item, then multiple identical items is strongly preferred. If donating non-tangible items or something that is not physically with you, then please bring a card with your contact info and instructions on how to collect the prize. This will be given to the winner. Donations are typically $25-$200 in value. Not recommended: Apparel (hats, t-shirts, underwear, etc.) - never the right size Software licenses (Toolkits, add-ons, LabVIEW) Branded trade show booth type giveaways (mouse pads, pens, keychains, etc.) Jokes or something meant as a gag and not a real prize

That may be a while - but the package file itself in the top of the thread.... Edit: Thinking about, because I'm dependent on the ZMQ bindings which are not available on the NI Tools network, I'm not sure I can put this package (and the SHA-256) library on the NI Tools network either - so it will always need to be installed from manually downloaded vipm files.

Ok, bit of Easter holiday coding today. Version 1.1.0 should allow connections to remote and already running kernels (well it does for me), and will only issue kernel shutdown messages if it started the kernel itself. To connect to a remote kernel, you can either manually fill in a cluster of port numbers etc, or simply paste the json from the connection file or (if you have an existing front end to the kernel) do: from ipykernel.connect import get_connection_info print(get_connection_info()) If starting kernels on another machine, remember to tell them to bind to an IP address that isn't localhost e.g. ipython kernel --ip=u.x.y.z and make sure the firewall will let the ports through.

Hmm, there was a problem I had there but I thought the version I packaged had fixed it. My current development version should find that path - but it depends quite a lot if you have multiple Pythons installed on your machine. BAsically there doesn't seem to be a bullet proof way of getting the correct path in Windows.... That's a sensible idea - it's going into the development code. That's largely a result of the test client being mainly aimed at debugging the protocol and for testing message handling rather before moving on to code to more tightly integrate LabVIEW programs with the remote kernel. That said, I'm in the process of adapting the client to allow different methods of locating and connection to the kernel and that will include suppressing the kernel shutdown message on exit. I'm also (very slowly) working on an implentation of a LabVIEW universal-binary-json serialiser/deserialiser with a view to creating some custom ipython messages for transferring binary data efficiently between LabVIEW and Python. The idea is that the LabVIEW client would create message handlers at the Python end that would allow LabVIEW data to be pushed directly into the Python namespace or to request python data to be sent back to LabVIEW. Don't hold your breath though, the day job comes first...

There are multiple ways actually. Here are a few that come to mind: Let it run faster by adjusting the code inside the loop accordingly Split it into multiple loops to utilize more cores of your CPU Buy a faster computer Note that there is a limit to how many concurrent threads LV supports: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000PARmSAO&l=en-US The maximum speed of a while loop is only limited by the speed of your CPU at 100% load (and of course the way your operating system shares the CPU between processes and threads). That is assuming your loop does nothing, which makes it pretty useless. Of course, if your computer has multiple cores, you can run multiple loops in parallel to make use of them. This is contradictory to your first statement. I suppose you mean to increase the loop speed, right? If your code is simple, it should be easy to optimize for speed or to run multiple instances concurrently if applicable.

In the compiler doc here (https://www.ni.com/tutorial/11472/en/) theres mention of a yieldIfNeeded block which is inserted into loops which allows for coordination with the rest of the runtime. If you just have the one while loop, you are still having to check against the runtime engine if you should keep running or if you need to pause and let other code run. Its not just a simple jump. tl;dr I dont think there is any way to do this with a regular loop. A timed loop may work. The overhead should be minimal compared to any actual code you wish to run in the loop, and if that isn't true labview is probably not the tool for the job.

The being simple doesn't mean it's going to execute fast, I think there is more to optimise in the code inside the loop than anything else. That said, one thing that might help (again depending on what's in the loop) is to change the while loop for a timed loop to which you can give the highest priority. Also if you have some NI Hardware available you could use the clock as the reference for the loop, but that would probably improve jitter more than raw speed.

See the posts starting here. You have to use opkg to install sqlite on a Linux RT system.

The best thing about a UDP joke is I don't care if you don't get it.