Jump to content

Jordan Kuehn

Members
  • Posts

    690
  • Joined

  • Last visited

  • Days Won

    21

Posts posted by Jordan Kuehn

  1. Doubtful. The variables in question are to give users direct control over digital output lines. Since the UI code is broken due to the error, the UI can't run and the values aren't updated.

    The cRIO code should still be executing, and you can manipulate shared variables with the DSM. It can be a pretty handy tool when working with cRIOs. Won't get you inside the FPGA, but it can give you a peek inside the RT side and the CPU.

  2. For GOD sake, this is my VI, please help me, i know TCP is better, but i just wanna see it working with UDP, so what shall i change to not see this error message anymore :(

    You'll find that getting angry at people trying to help you here won't get you far, especially if it is a homework assignment and the goal is for you to figure it out on your own. I agree with Phillip, the information here + some Googling will get you where you need to go.

  3. I will say convert codes in each sequence to a vi and use Error cluster to enforce sequence if it is only 3 sequence.For more than 3 sequence use State Machine.

    I agree with the first part, but I do not necessarily agree on arbitrarily converting a series of subvi's into a state machine if there is never any need to programatically change the order of execution. In fact, for a series of subvi's that are always called in sequence (very likely in this case, since I doubt the frames have been coded with any idea of replication elsewhere) I'd find that keeping them laid out in a row would be more readable, especially with some informative icons.

  4. The advantage to using a more comprehensive service rather than just a folder on a server somewhere is mostly web access and viewing. You can even begin to integrate things like bug tracking into it. Bitbucket is nice and free and is probably the best option if you are using Mercurial. If you'd like to set something up for yourself on your own server, RhodeCode is a very nice and free package that will let you do that.

  5. If you are finding some of the built in signal processing tools lacking, I might suggest looking into MathScript (aka Matlab) nodes. Despite the work of NI, there is still a world of matlab signal processing code that is quite useful at times and this is a way to bring it into labview. (apologies if you were aware of this already)

  6. I've read through the manuals for the advanced courses (took the training for the lower ones) and they had some very useful information, but from what I've seen in the CLA exam it may not directly corrolate. The ones I've read are likely from 2009 though. My best guess is you'd learn a lot, but still have work to do to prepare for the CLA. (note I'm only CLD right now. I'll probably take the CLA when it's time for recert)

  7. I have never seen (or thought of doing) this before reading it here.

    Do any other developers do this?

    I do not. However, I like this idea quite a lot and may start including it. There are times when I switch to a new approach and leave the old one while I test the new implementation, but I'll usually delete the structure when I'm done.

  8. There are alternative drivers for Kinect - OpenKinect. DLLs, are pure C style, so easy accessible from LabVIEW. There is also some work done on LV wrappers for OenKinect.

    Vugie, thanks for pointing those drivers out as well. I had looked into them some prior to the release of the SDK and felt they had promise, but I feel that it is better to build an approach around the official supported SDK now that it's available. Of course, the attractiveness of homebrew drivers is inversely proportional to the level of success I have with the official ones :cool:

  9. NI has released an API for using the Microsoft Kinect SDK and I've been tasked with a research project involving this device. See the links below:

    http://zone.ni.com/d...a/epd/p/id/6504

    http://www.xbox.com/en-US/kinect

    http://kinectforwindows.org/

    I've followed the instructions on the SDK website, installed the drivers and Visual Studio Express, and everything works fine in the MS demos.

    The labview config file to allow it to use .NET 4.0 is in place and it sees the .dll included in the API as well as the one installed by the SDK. I've tried mapping the constructor to both.

    When trying to run the demo I encounter the error screen below in LV2011 x86, LV2011 x64, and LV2010 x86. LV subsequently crashes on all versions, but that's nothing new ;)

    USegi.png

    Thoughts?

    I've posted to the API page and will post to the dark side if needed. .NET isn't really my cup of tea...

    //Edit. Google searches have suggested that people who encounter this when doing *shiver* text based programming have corrected the issue by modifying a parameter of their build environment from 'Any CPU' to only x86 CPU. I'm not sure how this would correlate with LabVIEW though.

  10. IMHO, websockets will make all of them obsolete. Firefox 7 is available on android and Ipad/Iphone comes shipped with websocket enabled Safari (iOS 4.2). There has already been a proof of concept implementation on this thread.

    Really? I've read the thread, but wasn't aware that the iOS safari supported it. I may take a serious look at it now then! There are a few of our projects where an iPad interface would make a customer ecstatic.

  11. Wait, wait, wait.. I thought the dialog was a simple while loop with two buttons; where'd this event structure come from? If you have an event structure in a dialog you have to be careful to clear any leftover events, otherwise those extra key presses or clicks will be queued up and ready to go the next time the dialog runs. I think the only way to go is to dynamically register for any events you want, and unregister as you exit the dialog. Re-registering on the next call to the dialog will ensure there are no leftover events from last time. Never use statically-registered events in a dialog, as they can't be cleared.

    To clarify, that was a quick fix (well not really), and is no longer in the dialog. Yes, prior to this it was stopped by two boolean controls OR'd into the stop condition. Sorry for the confusion.

  12. Well, the second dialog (a while loop with simply two boolean controls to stop it) was definitely blown through with no input from the user. I was able to compare time stamps from the end of the action and the confirmation of that dialog, which were nearly identical. Verified that key focus is on neither of the buttons, nor are they bound to any keys. Then moved to an alternate approach that involved using F-keys to trigger an event structure (key up) in the dialog rather than the controls. We were able to queue up multiple events with this approach which led to the screen being dismissed on subsequent sequences. In a last minute solution, I ditched the event structure in the dialog and simply opened a reference to the keyboard and used the keys from that. No time to test much beyond basic functionality. This is all very strange.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.