The growth of embedded software in modern automobiles and airplanes presents significant challenges for manufacturers trying to eliminate software bugs and make products as safe as possible.
Developing and testing embedded software with an emphasis on quality can strain the balance of business needs such as short time to market, low test cost, and the ability to meet the technical requirements driven by customer demand for new features and product differentiation.
All embedded system manufacturers face similar demands, but they cannot sacrifice quality when it comes to safety-critical applications. Organizations that can evolve their development strategies to incorporate advanced hardware-in-the-loop (HIL) testing can reduce spending on software quality maintenance, improve their market perception, and, most importantly, ensure customer safety.
Learn more about how hardware-in-the-loop solutions drive down test costs on page 12 of the Automated Test Outlook.
Fueled by advancements in mobility and the Internet of Things, bandwidth consumption and network capacity are increasing exponentially.
Research on fifth-generation (5G) technology aims to provide transmission speeds that exceed 10 Gb/s, which is around 1,000 times faster than LTE speeds. NTT DOCOMO, the leading mobile phone operator in Japan, selected NI technology for its 5G mobile communications demonstration experiments, which aim to rapidly drive innovation and support real-world experiments.
DOCOMO will use NI technology to conduct demonstrations that compare 5G with a range of mobile communications technologies. Featuring LabVIEW system design software and software defined radio hardware, the NI platform saves time from theory to results.
“By adopting NI’s cutting-edge 5G wireless rapid prototyping test system, we expect to see results on performance and capabilities faster,” said Takehiro Nakamura, vice president and managing director of the 5G Laboratory at NTT DoCoMo.
In response to DOCOMO’s adoption of NI technology, NI Japan managing director Ryota Ikeda said, "It is a genuine pleasure to be able to support the activities of DOCOMO, an important global vendor involved in resolving the exponential increase in network capacity as well as a leading player in 5G mobile communications research and experimentation.” He added that with 2020 as DOCOMO’s target, NI will continue to provide productive and revolutionary tools that will support the formation of more advanced technology.
I wanted to let everyone know about some great work done by one of our interns from the University of Manchester working at National Instruments in the UK. myBall & Beam is based on the classic ball balancing systems control using myRIO as the controller, Multisim for schematic design and Ultiboard for PCB layout.
myBall & Beam uses an IR sensor to continuously detect the ball's current position and a servo to control the tilt of the beam. This information is analyzed on the myRIO's embedded processor to provide feedback to the system. To check out the full project with schematics, PCB layout and code visit this location.
We're excited to announce the date of our next Sheffield meet up! We'll be hosting another afternoon session from 2-5pm on the Thursday afternoon to talk all things labVIEW!
We also have speaking at the event, our first guest speaker in the shape of Sam Sharp. Sam will be presenting the following;
Title: WebSockets - Bringing LabVIEW to the Web
LabVIEW is a very powerful tool for interfacing with hardware, but it can sometimes be lacking in its interfacing with users. The Web, on the other hand, has a vast array of tools and resources for creating great responsive user interfaces. Wouldn't it be great if we could combine the two?
I would like to show you my WebSockets library (published on the NI community) that allows you to transfer data between a LabVIEW application and a browser to multiple clients with low latency and present a couple of examples of how I have been able to leverage this technology to bring LabVIEW to the web.
You can register an early interest for this event by clicking on the event brite link below and reserving your place!
Did you know that there are a bunch of built-in FRC examples right in LabVIEW? There are!
Just click on the Help drop-down menu and choose Find Examples. Shablam!LabVIEW Example Finder! You'll see an FRC Robotics folder and a roboRIO folder inside it. There, you'll find examples for everything from CAN and Pneumatics to Joystick, Sensors, and Vision.
These examples are ready to run! You can also customize them, change them, and use them however you want. You can combine them, copy/paste parts of them into other VIs or into your robot project, or just run them independently. The world is your VI!
Az Együtt a Jövő Mérnökeiért Szövetség (EJMSZ) többrészes ismeretterjesztő sorozatában 2 fiatal riporter feltárja, hogy mennyire színes és sokoldalú a mérnök szakma. Az FLL Közép-európai elődöntőn, az Ericssonnál és a Continentálnál is forgattak.
EJMSZ - Keressük a jövő mérnökeit - FIRST LEGO League
We hope are able to join us for the next South West LabVIEW User Group which will take place on Wednesday 11th March you'll have the chance to meet other LabVIEW users and learn, collaborate and network with some new faces - we hope you can also join us for a drink after the event!
Introduction - 10 mins - DB
LabVIEW 2014 SP1 - Group discussion - 10 mins
Why not try 2014 SP1 before you arrive to get the most benefit
Recertification - Group discussion - 10 mins
Atlassian Suite and websockets library - 20 mins - Martin McD
LabVIEW in Linux and Gizmo board for £100 - 20 mins - Kevin R
Ask other engineers (Open forum for Q/A) - 20 mins
Code challenge + prize - 30 mins
If possible bring a laptop with LabVIEW installed if you want to participate (there will be a few available but we cannot guarantee numbers
Social drinks afterwards for anyone who is interested
Tea / coffee will be available during the event as well as some light snacks.
We are excited to be holding this quarters event at the Bath Royal Literary and Scientific Institution, the address of which is:
16-18 Queen Square,
If you are interested in attending please sign up via Eventbrite.
By road: BRLSI is on the A4 as it goes through the centre of Bath. We are five minutes from the Charlotte Street long-stay car park (10 mins if you park at the far end!) - drive past BRLSI, turn left at the top of the square, then first right (it's the empty space below 'Royal Ave' on the map, right). There is also limited on-street parking in Queen Square.
By rail/bus: Bath Spa railway station is 10-15 minutes walk away (south-east of BRLSI - drag the map, right, to see it), and Bath's new bus station is next door to it. Taxis are available from the railway station at most times.
Last episode we talked about the differences between these 2 functions. This time, we’ll run some timing VIs that show exactly how they differ. This and the last episode are direct excerpts from our Lucid LabVIEW Fundamentals Course.
To get a better feel of how this works, let’s take a look at this VI, Wait until next millisecond Multiple. I shortened it. And this VI, which is called, creatively enough, Wait. The only difference between these two VIs is the function we’re curious about. The Wait function, in the Wait VI, and the Wait until next Millisecond Multiple function in the Wait until Next VI. So here’s what’s going to happen. In both cases, we’re executing a For Loop 20 times, and telling it to wait first 100 milliseconds per iteration. Inside this loop, we’re calling the tick count. The tick count returns exactly what this returns out the other side, the millisecond timer value, which we already looked at. You can see some previous values of that, that I ran earlier, when you weren’t looking. This is in a sequence frame so that this runs first. And we get the millisecond timer and then we run your code.
Let’s take a look at your code. It’s pretty simple. We’re just performing a divide function 500,000 times. We timed how long that takes by calling tick count first, performing the operation, calling tick count again, and seeing how long the process took. And then we output that from the VI. So from here, we’ll get an array of 20 values of how long the process took. And so what we also want to do is take a look at how long each loop iteration took. Is it exactly equal to the process time or is it more? To get that, we take this millisecond timer value. We get the size of the array, subtract one from it, bring the whole array in and we’re going to just take the difference between each value. Indexing out the zeroth iteration, the zeroth value and also the first value, the next iteration will be one and two. And so we’re getting the difference between each of these values.
Let’s move this over a bit so we can see where the differences are. If we flip over into the Wait function, we’ll see it behaves exactly the same way. Except…that’ s better. Now first with the wait function, I’m going to put a wait time of 100. And I’ll run it. It will run for a few seconds here as we can see. The process time which is the time it takes to divide a number by itself half a million times looks to be somewhere between 30 and 60 milliseconds each iteration. Now looking at our millisecond timer value, we can see that they’re pretty much off by 100. And in fact that’s what the differences tell us. Very rarely we will get a one in there. Let’s run it again. This is just based on the inconsistencies of a non-deterministic or non-real time system. LabVIEW is getting these resources like access to the CPU from Windows and Windows is scheduling a bunch of other tasks as well. So sometimes the availability of resources from Windows varies and so our process times vary.
Now let’s flip over to the Wait until next Millisecond Multiple and see how that works. I’ll run it. And notice, that after a couple iterations we get to around 100 milliseconds per iteration, which is what we want. Our process time is always much lower than that, from 30 to 60 like we saw before, closer to 30 in general. But the Wait until next Millisecond Multiple is different from the Wait function in the first iteration. Like we saw in our Context Help, it told us: “however, it is possible that the first loop period might be short”. Indeed it is. In this case, it’s even shorter than the process time which is why it affects the next loop iteration too.
Here’s a good example. The millisecond timer value initially was 625. So the Wait until next Millisecond Multiple function wants to go again at 700. So it waits 75 milliseconds in order to get on that 700 the next time. And from then on, it tries to maintain this 100 millisecond difference per iterations. Again, as long as the time the code takes is less than the time we wait, we’re going to see these relatively consistent loop times. Now, let’s change our wait time to less than the process time. The process time as we see, hovering in between 30 and 60 milliseconds. Let’s take our wait time down to ten. Run it. And now we see the differences between iterations is equal to the process times. Since the time the code takes is longer than what we’ve specified, the code itself is what’s timing the loop. Not this. This is the same for the Wait until next Millisecond Multiple and the Wait function. Here’s the wait. Run it. Same thing.
So, what’s the benefit of using one over another? Again, our Context Help is very valuable because it tells us: “use this function”, the Wait until next Millisecond Multiple, “to synchronize activities”. So, if we have multiple loops running and we want them all to sync up and start together, this is the one we want. If I have multiple loops and I just use the Wait function, it’s possible that they could get off on different times. It may happen on the first iteration or on subsequent iterations. The choice of which to use is up to you, depending on your application.