Leaderboard

Hi LAVA friends, We are pleased to announce that the Delacor Queued Message Handler (DQMH) is now available via the LabVIEW Tools Network: http://sine.ni.com/nips/cds/view/p/lang/en/nid/213286 You can read about the thought process behind DQMH at our blog post: Ours is not better than yours (or YAF=Yet Another Framework) at WalkingTheWires.com The DQMH is based on the NI QMH Project Template. The DQMH expands on the NI QMH by providing safe, event-based message handling and scripting tools to encourage same style between different developers in the same project and improve efficiency. The DQMH is ideal for applications where multiple modules must run in parallel, possibly at different rates, while communicating with each other. The DQMH can also be used for applications that have a single module, where the developer would benefit from having a Tester with the capability of eavesdropping on the different DQMH events and messages. The DQMH integrates with TestStand since all development and troubleshooting can take place under LabVIEW, while calling the public API VIs as individual steps in the TestStand sequence. The tester can eavesdrop during the execution of the TestStand sequence. This is specially useful when the LabVIEW code is written during the research and development or prototyping phase, because the same code can be called by TestStand in production or manufacturing sequences without any changes. The DQMH uses LVOOP for some internal functions, but developers need not be familiar with LVOOP to use or understand this architecture. Try it out and let's us know what you think. Fab and the Delacor team.

Hi Guys; Now that the Arduino Compatible Compiler for LabVIEW has been launched for a few months, it is time to tackle the next challenge; having LabVIEW code deployed to my favorite dessert: Raspberry Pi. http://www.tsxperts.com/labviewforraspberrypi/ My personal favorite thing to do lately has been to watch LabVIEW GUIs running on a Raspberry Pi connected to a small monitor. We got a cool demo of a Vibration Monitoring and Alarm system using an Arduino and a Raspberry Pi; both programmed in LabVIEW. If you are making to NIWeek this year, make sure to stop by our booth to check it out. Once the NIWeek madness is out of the way I will post a video of it. Cheers Filipe

Let's get a list of who's presenting what at NIWeek so that we don't have to rifle through the agenda to figure out whats actually worth going to!!! I've got 2 on alliance day (Monday) He Chose.....Wisely; Picking the right RF Software for your next RF Opportunity (2:30PM room 15) You can pick your customers, You can pick your SpecAn, but you can't pick your customers SpecAn (3:30 room 15) [specAn is a spectrum analyzer fwiw] For those of you a bit leery of an RF-centric presentation, consider that I usually hear this at least once after presenting; "that was very entertaining...I'm not sure if I understood it all...but it was entertaining" Looking forward to entertaining you all ~,~ The Captain Was Here....and will be there too. aka Norm Kirchner

Just use the invoke node on the Sequence reference, and use the Convert to Flat Sequence. The two objects don't belong to the same direct parent class so methods on one don't always translate to the other. In 2014 the Stacked Sequence structure was removed from the palette, it is still supported just maybe close to being deprecated.

TLDR: Delacor has some cool stuff, and I had some cool stuff. Wow very cool Fab. I'm starting to wonder if everyone has developed something like this in secret and just not published it. I didn't really get around to getting permission to post my version publicly, but I talked about it and even named it Glued. Lots of Glued's functionality is mirrored in your QMH but here's a few of the differences I see so far. DQMH and Glued both had scripting for adding new modules, and messages. Glued didn't have one for removing messages so good on you. Glued also had the ability to create global messages, which is a message all modules listen and react to. This makes messaging 1:1, and 1:N, I never came up with a good N:1 scheme but then again I didn't really need it. When doing a Do Something Wait for Reply, you use a user event to send the message and a notifier to wait on the reply. I found this to be a bit problematic when doing a shutdown. If I have a sequencer running that is requesting analog data and waiting on the reply, but at some point the user closes the software. That close is going to be a global event telling the whole application to shutdown. If my analog actor loop shuts down, but my sequencer doesn't get the request to shutdown, before requesting a read, then all actors will shutdown except the sequence, which will be waiting for the reply from the analog. In Glued a user event sends the request, and a user event is used for sending the reply. The reason for this is because when waiting for the reply we also register for the quit event. This way if the quit event is fired while waiting for a reply, we will also stop waiting for the reply and shutdown. DQMH has a timeout where Glued by default had a -1 timeout and with this change I didn't see any kind of issue. For the messaging there are essentially three functions you need to have. Sending the request, convert the request variant to the request type def, and send the reply. There were also two type defs, one for the request data one for the reply. In Glued this was all contained in one polymorphic VI. The purpose of this was to quickly find where in the code a request was being sent, or a reply was being sent by right clicking on the polymorphic instance and selecting Find All Instances. Then I could find all places I was requesting data, where I was acting on that, and where I was sending that data back. The Request, or the Request and wait functions were in the same VI, and there was a boolean input for Wait For Reply. In Glued modules has the ability to send a message to itself using the same polymorphic request VI mentioned before. There existed a manual screen module. This module was a place for all other modules that had manual panels to be seen. It basically was a listbox of modules, and a subpanel to insert into it. This is where sending messages to itself would come in handy because the buttons on the FP of the module invoked the same code as that message would coming from any other module. In this manual screen actors could be undocked, which would just make floating windows of each. If a module performed a request and waited on the reply, the reply would contain the data and the error from the request. So say you send a request to read an analog and wait on the reply. The DAQmx calls perform the operation and the error out is sent back with the reply data. So from the caller it has a single VI with a request in, reply out, and error out. This helped make the caller handle errors when it could instead of the module. As mentioned before the state machine was an array of strings so having this information would help track down the case where the error happened. The request and reply data used a variant, but used variant attributed combined with the Variant Repository so data like who sent the request, where it was going, the payload, and the error could be also sent if desired. I prefer state machines that have the ability to have multiple cases queued up. Either a multi-line string like JKI, or an array of string, or even an array of enums if you want. I'm sure you are familiar with the pros and cons. Glued used an array of string, but I've been using a modified JKI lately and think I prefer that. There existed an error control module. All modules that gets an error in continuous operation would just send that error to the error actor which would log it, prompt, and try to act. In practice this wasn't very helpful because it was an asynchronous process, but it was nice to have a single log for errors. Another benefit of this is it would keep track of what module the error originated from, and the state machine states that lead up to the error. Because the state machine used an array of string it logged this information too. There existed a config module. This module was a central place for setting all application settings and would publish data the config data as a second level variant repository, and would send out a global event when settings were updated. This would cause all modules to go and read the new data and perform any operation it needed to with this new data. Like if a new COM port was selected, we might want to close the current port and re-open a new one. Changing settings while running a test were limited to prevent issues with this. For debug I had an actor probe which registers for all events, request, reply, and global events, and has a central place to see all the events, and their data in the order they are generated. Here is a post talking a bit about it and showing it. And lastly Glued had no cloning of actors. In my design I haven't really had a need for it. So if I needed a CAN actor for doing CAN communication, I would make that actor and call it in parallel with all the other actors. They all started at the same time, and all stopped at the same time. No actor ever shutdown, without sending a message to shutdown he other actors. This again might be because I focused on request reply more and sending a request to an actor that doesn't exist, had issues. Actors not being clones makes debug a lot easier. At any point in the software I could go to the main VI, hold CTRL and double click the actor, which would open the BD of the actor VI that was running, and start probing wires. If I had N CAN cards it would be handled by having one CAN actor with with an array of hardware references to work with. Oh and I noticed this is for 2014 and newer only Glued was 2011 and newer, but I think that held it back a bit because of some of the improvements in 2012, and 2013. Wow wall of text so sorry, can't wait to meet up with you next week and we can talk more if you are interested. Thanks again.

You can't be entirely serious. Maybe you haven't used these new features but they are awesome and going back you realize what you are missing. But seriously since the event structure? That was LabVIEW 6.x right? (maybe 7.0?). Project explorer. What about classes, and libraries in general? VI Server has had major upgrades since then. VI Scripting that is a ginormous feature. XNodes (unofficial but still major new feature). Static VI references, along with the other asyncronous tools (run dynamically). Application builder API. Icon editor API. System Configuration API. Was there even dynamic user events in 2009? I know they didn't have priorities. Event Inspection Window, Bookmark manager. Events being lossy. Conditional/concatenating tunnels. QuickDrop and other QD related features. Do they have make type def from a block diagram constant? Native JSON and XML. DVRs (couldn't remember the version they came). Native FTP, HTTP, SMTP Email, WebDAV, Bluetooth. Not sure when Network Streams, and network shared variables, and Web Services came about. Libraries with licensing restrictions. The list literally goes on and on. I might not use all those features daily, but there have been major improvements over the years. And 2015 has some really compelling features for me personally. But this is true, that no one at NI is saying errors will be improved in the near future.

This year, STUDIO BODs joins the LAVA BBQ again. The door prize we offer this year is Time, but we all know time is money! We will give 1000 LabVIEW custom Boolean controls (6-states) created with pictures and colors schemes of your choice. Let’s say it takes 2 minutes to create a LV custom Boolean control, and you have an intern doing them (25$/h), this door prize will save you more than 800$! You will have 18 months to generate your 1000 buttons with LV Button, by STUDIO BODs http://labview-button.com See ya all at NI Week!

Hello Hooovahh; You hit a nerve on the event structure. We are currently looking at the best way to implement it and are not sure yet if it will make it to the first release. That one is the challenge for the front panel stuff. Just like the Arduino Compatible Compiler for LabVIEW, we are interested in getting something in the hands of the community as soon as possible and let the feedback guide the short term feature set. However, since the Pi is MUCH more powerful than Arduinos, there will be less limitations than on the compiler for Arduinos. Just to cite a few, we will have parallel threading right off the bat, so a typical producer consumer is fair game, with queues and multiple loops in parallel. That is how the Vib Monitoring demo I mentioned was implemented and is working. We probably won't have property/invoke nodes, and the synchronization primitives (notifier, rendevous, etc); and as far as data types, I don't think we will have waveform. But will have clusters/typedefs. Won't support LVOOP. These limitations are for the first release and it is not to say they won't make it later. Other than that, I don't see other big limitations for the first launch. Don't take this as set in stone yet as we are about 4 months away from release, so the final feature set will become clear a little later. In the last couple of weeks, it has been all about NIWeek week prep, but we will hit it hard again once that is past us. As far as pricing, we haven't decided yet, but don't think it will deviate much from what we did for the Arduino one. Still TBD at this time though.

I'm in I will be sure to record it for those that can't make it this year.