Neil Pate

It begins... ignore the messy code in the background, just proof of concept stuff.

Million-to-one chances...crop up nine times out of ten(especially on a Friday)

You are right, but this is probably less true on FPGA. As there is no data-flow dependency on this I would be very surprised if it did not reliably get cleared at the start of each iteration of the acquisition loop. Defensive programming techniques are my preference so I would probably introduce some fake data-flow dependency to clear it at the start of each iteration.

The rules of data-flow are still valid, the value of the Triggered indicator is taken from the tunnel going into your for loop, so will have the same value for every iteration of the loop as it is really only "sampled" once on the very first iteration of the loop. One thing to add, perhaps put in a control in the path of the Timed Out? feedback node to allow you to reset the timed-out latch, this can be useful during development.

Well, as acceleration is just the second derivative of position surely you just double integrate the acceleration. (I jest...) I think it will be very difficult to infer any kind of accurate absolute position and velocity in 3D space with the measurements you have available, especially on a rocket! As some of the other links show, a Kalman filter type approach may be a good starting point, but I still think this is a very tricky proposition given the speeds your rocket is likely to be travelling at. Can you not add a simple GPS device to your rocket?

Do zombies even live for 11 years?

I think the standard recommendation of not doing too much processing in the event structure applies if you are also using it to handle GUI events. Are you doing this in your code?

I am a member of the IEEE, and have been since I was a student (so about 18 years in total). But honestly I do not really get much from it, other than a magazine each month which occasionally have some interesting articles.

I think it can be done, but rather than doing a Reg Event, just replace the actual cluster element. Note: this is quite old code I wrote some time ago when I was just learning about User Events (LV 8.5), I am not sure I would do things like this now if I had to!

Definitely do not break the VI would be my vote.

Tom, I have seen lots of instability in the past when doing parallel VISA reads. Admittedly these were using USB<-->232 converters and I always laid the blame on flaky USB converters.

Pah that's nothing..., my Oculus Rift dev kit should be arriving soon so I will soon be able to code in one more dimension than you (I wish...)

I install everything on my SSD (240 GB). Especially LabVIEW; I switch between quite a few different projects in many different versions of LV, so I really like it to load nice and snappily. I would definitely prefer to offload the NIFPGA directory somewhere else though, as the SSD is not helping at all for that stuff.

The strange thing about the mklink document is that it mentions Vista, and 8, but not 7 which clearly sits in between the two. Surely just a documentation error I think?

Great idea, I will give it a try. I think this also supports Win 7 even though it is not mentioned.

I think the MDF directory is used when you build an installer which needs additional components. LabVIEW first looks in the MDF directory to see if a copy of the other component installer is there.

So the ProgramData\National Instruments directory is getting very big on my disk, approaching 80 GB with the Update Service and installers (MDF). This along with with 40 GB in the NIFPGA directory is getting a bit silly. My primary disk is a nice fast SSD, but it is not huge. As such I want to move as much of this stuff off the c:\ as possible. I have moved the Update Service stuff onto bigger (mechanical) HDD, this is possible by changing the preferences of the NI Update Service. I don't yet know if this has actually worked, as I manually moved all the files after changing the preferences. Does anybody know if it is possible to move the NIFPGA and ProgramData\National Instruments\MDF somewhere else?

Yes, that's what I normally do (keeping track of whether we have wrapped around or not etc). I have never done any benchmarks, always just done it that way. Quite often my circular buffers have a method to read n samples rather than the whole buffer, so I find I need to keep track of a separate read pointer.

Nice work. This is such a good use of XNodes adapting to type behaviour. Couple of questions though... In the Read, there is a Rotate 1 D array, is this not quite an expensive operation? Could that could be removed if a Read Pointer was introduced?

Not to the best of my knowledge on the "older" cRIOs. The brand-spanking new ones do actually use Linux (the old ones use VxWorks or Pharlap for their RTOS) so perhaps that does have a shell you can ssh into or something. Hoping to try this out soon

The LabVIEW beta normally rolls out around about January or February.

We do what we must because we can.

I have seen things like this where "stale" classes were inside Diagram Disable Structures, everything generally ran fine until one day the build just broke for no apparent reason. May be totally unrelated to your problem though...

You have a Starcraft II avatar, already that gets you points in my book :-) I have actually approached the problem slightly different, as I did not like the Strategy object needing to do the VISA read, and due due to the asynchronous nature my device sends data (all on its own it periodically sends data). I have implemented the Received data (and the parsing thereof) as a type of Strategy pattern, but the actual reading of the characters on the serial port is done somewhere else.

As someone wiser (and more sarcastic) than myself has already pointed out... Some people, when confronted with a problem, think “I know, I'll use regular expressions.†Now they have two problems.