Leaderboard

Ok. first off. Windows is not a real time OS so it isn't deterministic. I know that, you know that but your project manager probably doesn't so that was for him. Second. I bet you are so close, that if we can just optimise what we already have a little better, we will be home and dry. Sure. Then in 6 months the spec changes to every 7 ms and the project manager says "you did it before, now do it again - it's only 1ms". So. What is the problem? Ahh. Just poking over the 8 ms in places. Lets see if its what all the girls say that size does matter and bigger is better. Ah yes. No problem with under 8ms. The girls are half wrong and half right. Size does matter but smaller is better. (In fact it is linear. 400,000 will yeild about 3 ms, 200,000 about 1.5 ms etc). Easy answer 1. Reduce the data size in the global. But why so slow? Is it the array disassembling? Is it the reading from the global? Does it need more coffee? Oooh. Microseconds. My spidy sense tells me its the global. Easy answer 2: Don't use a global for big arrays if you're time constrained. That about wraps it up for reading. In the next issue we will cover: Oh my god. It all falls to crap when I write data.

Name: Traffic Jam Game Submitter: hooovahh Submitted: 04 Feb 2015 Category: *Uncertified* LabVIEW Version: 2011License Type: BSD (Most common) Has your stressful day at work got you down? Want to take a load off and relax with a game? Why not a LabVIEW game? Here is a game I made a while ago and forgot about. It is called Traffic Jam similar to this, or this one called Rush Hour. The basic goal of the game is to get the red car out of the parking lot, by moving the other cars. Cars can only move in one direction and can't turn. My coding style has improved over the years, but I'm not yet ashamed of the work I did on it. It was fun working with the picture control and generating the UI based on the level files. This game comes with 122 levels. Why 122? Because I forgot to put in the last 18. Feel free to add them yourself by editing the Set text files. This game also keeps track of your high score, so you can try to go back and do it in less moves. Click here to download this file

This is very tricky, and I definitely don't totally understand it. Also, despite the NI under my name I am not remotely part of R&D and so may just be making this stuff up. But it seems to be mostly accurate in my experience. LabVIEW is going to use a set of buffers to store your array. You can see these buffers with the "show buffer allocations" tool, but the tool doesnt show the full story. In the specific image in Shaun's post, there should be no difference between a tunnel and shift register, because everything in the loop is *completely* read-only, meaning that LabVIEW can reference just one buffer (one copy of the array) from multiple locations. If you modify the array (for example, your in-place element structure), it means there has to be one copy of the array which retains the original values and another copy which stores the new values. Thats defined by dataflow semantics. However, labview can perform different optimizations if you use them differently. I've attached a picture. The circled dots are what the buffer allocations tool shows you and the rectangles are my guess of the lifetime of each copy of the array: There are three versions. In version 1 the array is modified inside the loop, so labview cannot optimize. It must take the original array buffer (blue), make a copy of it in its original form into a second buffer (red) and then change elements of the red buffer so that the access downstream can access the updated (red) data. Version 2 shows the read-only case. Only one buffer is required. Version 3 shows where a shift register can aid in optimization. As in version one we are changing the buffer with replace array subset, but because the shift register basically tells labview "these two buffers are actually the same", it doesn't need to copy the data on every iteration. This changes with one simple modification: However you'll note that in order to force a new data copy (note the dot), I had to use a sequence structure to tell labview "these two versions must be available in memory simultaneously". If you remove the sequence structure, LabVIEW just changes the flow of execution to remove the copy (by performing index before replace): For fun, I've also put a global version together. You'll note that the copy is also made on every iteration here (as labview has to leave the buffer in the global location and must also make sure the local buffer, on the wire, is up to date). Sorry for the tl;dr, but hopefully this makes some sense. If not, please correct me

I'm pretty sure this was reported on the NI forums and the easy fix was the LabVIEW band-aid the always copy. I tried in 2014 and it also is broken.