ned

QUOTE (jlokanis @ Apr 17 2009, 06:59 PM) You should be able to wire the string "localhost" or the IP address 127.0.0.1 to get a connection to the local machine, rather than going through String to IP and back.

QUOTE (torekp @ Apr 17 2009, 11:37 AM) This sounds like an ideal use of UDP in place of TCP, since you don't need determinism or guaranteed transmission. It's simpler to set up a UDP listener because there's no connection - kind of like sending a fax instead of calling someone on the telephone. Your DAQ computer sends a UDP packet whenever it wants to display an update; your user computer listens for UDP packets and displays them upon reception.

QUOTE (Val Brown @ Apr 16 2009, 04:38 PM) Yup, that's exactly what his problem is. If you check off the "Send me email confirmation of this activation" box when you install/activate your NI software, you'll get an email back with a bunch of long, unique codes, one for each product you've activated. So he's not getting different treatment than the rest of us with an SSP, he's just unfortunate to be working on a machine that's not on the internet. EDIT: oops, somehow that comment was the last one on the page and I missed that the comments had spilled onto the next page where everyone else had commented on the same thing before I replied.

QUOTE (Mark Yedinak @ Apr 8 2009, 06:33 PM) Something to consider: variant attributes are also variants. So, you could get rid of the cluster, and assign each data element a "type" attribute instead which would contain your enumeration value.

I think you've already gotten your wish - have you looked at Quick Drop, added in LabVIEW 8.6?

Are you stopping the VI on both computers, or just computer 1? When you open the connection on computer 1 (the non-listening end), are you specifying the local port, or allowing the operating system to choose? You should be allowing the operating system to choose, because the operating system will hold a specific IP/port combination for an amount of time after closing the connection (this is part of the TCP specification) which could cause the error you're seeing.

QUOTE (Waterppk @ Mar 25 2009, 02:44 PM) You shouldn't have problems running VIs simultaneously on your RT system and your PC. Do you have all your VIs set up properly as separate targets in your project? All the VIs that run on your PC should be under "My Computer". What happens when you run the RT VIs, then start the PC VIs? If it attemps to download and deploy to the RT system, you're running your PC VIs on the wrong target. You might also try starting the RT VIs, then right-click on the RT target in the project explorer and choose "Disconnect." Your VIs will continue running on the RT system but LabVIEW will disconnect from it.

QUOTE (Jeffrey Habets @ Mar 21 2009, 06:28 AM) For whatever it's worth, NI provided a framework that uses the Abort approach for the FIRST Robotics projects. The "autonomous mode" VI (the part that runs the robot without any user interaction) is run by reference and aborted when the autonomous period of the competition (usually the first 15 seconds) ends. All references are opened in the main VI and stored in global variables; it looks a little weird to me as a LabVIEW programmer but allows the students to get their code working without getting into queues or notifiers and makes it easy to stop the autonomous mode when necessary.

The FPGA module offers two types of FIFOs - FPGA FIFOs (both "target-scoped" and "VI-scoped"), and DMA FIFOs. The former are for transferring data between loops on the FPGA, the latter are for transferring data between the FPGA and the host system. The FPGA FIFOs are an efficient way to transfer data between loops, as is FPGA memory in a single-reader single-writer situation. Expect a learning curve and plan to rewrite your initial attempt a few times - the FPGA module looks like LabVIEW but requires you to think about how your code is executing at a lower level to take full advantage of it.

Do you dislike shift registers? Instead of writing the start time to a local variable in your initialization case, instead write it to a shift register. Then every execution of the while loop (outside your case structure), subtract the shift register value from the current time and display that on your screen - voila, the elapsed time. Is that what you want? Maybe I misunderstood. You will need to do something with that elapsed time in your final case - maybe write it to total time indicator - because the elapsed time indicator will continue to increase after the sequence completes.

QUOTE (Cat @ Mar 19 2009, 08:27 AM) Actually, it sounds like your coworker gave you a pretty good simplified explanation. I might be the wrong person to answer this - I haven't yet had a need for LVOOP in my projects - but I've been following all the discussions about LVOOP, and I've taken several classes in Java and used a bit of C++, and the implementation of objects in LabVIEW appears to be different enough (by-value versus by reference) that you'll probably be less confused if you jump right into OOP in LabVIEW rather than trying to learn it in C++ first.

QUOTE (rom76 @ Mar 18 2009, 10:40 AM) Could you make an effort to write it yourself, then post that? You haven't even made an attempt yet to read data out of your table. You'll probably want to create a cluster containing at least Name, Start Time, and Message Period, so that you can convert the latter two items to numbers. It may also need some sort of flag to indicate when the last message of that type was sent. Put that cluster in an array, one element per message type. Then you'll need to track the time since your code started, as you're already doing, and loop through the array to see if it's time to send a new message.

Would anyone else like to share their experience at a FRC Regional competition? I just attended the Boston Regional with the team I've been mentoring (from my former high school) and had a great time; it helped that my team did well despite their rookie status. It was very well organized with minimal technical troubles. I might be at the Hartford Regional at the end of March and would like to meet other LAVAers, especially those who mentored teams - will you be there? Below are my LabVIEW-specific observations; if you mentored a team or attended an event, please share your comments! I was surprised that I didn't see anyone from National Instruments at the event. One of the FIRST volunteers, who I'd met at the local kick-off event that he organized, directed me towards several teams looking for last-minute LabVIEW assistance, and I'm sure there were more teams who would have liked help if it had been available earlier. The most common problems I encountered were a lack of subVIs, code that attempted to re-open references (to motors, etc) inside autonomous mode after opening them in the Robot Main, and a lot of confusion over terminology (for example, global variables vs subVIs) that made it hard to communicate problems and solutions effectively. While I think NI did a good job with the overall structure - I found it easy to follow when I dug into it - I wish they hadn't set up the framework to encourage the use of global variables, and executing "Autonomous Independent" by reference is puzzling to new users. There did not seem to be many LabVIEW experts (among both mentors and students), although perhaps I didn't meet them because the teams that had them didn't need help. I didn't hear anyone who was wildly enthusiastic about LabVIEW (in the sense of "this is the best thing ever!") - for many teams it was yet another language to learn after several years of FRC apparently switching languages with each new control system. I don't have a sense of how many teams used LabVIEW versus C++ nor whether language choice contributed to a team's success.

You're close, but a LabVIEW array inside a cluster isn't quite like a C array inside a struct. To get a fixed-size array you need to use a cluster, not an array. Try using bundle instead of build array to build up the data component, or insert array to cluster with a fixed size of 8 cluster elements.

QUOTE (BrokenArrow @ Feb 26 2009, 11:24 AM) I wonder if this is related to this thread about memory allocation and constant values. LabVIEW includes constant values in its compiled code. If you then modify the constant at run-time (attempt to reuse its buffer), LabVIEW makes a new copy since it's effectively no longer constant. With a local variable, there's no value pre-compiled into the code so need to make a copy at run-time.

Aahh, the frustration. I never knew that Register for Events accepts a cluster of user event references (and I haven't seen it documented anywhere). Do I take advantage of this trick to clean up my code, or stay away from it to avoid this bug?

QUOTE (Thang Nguyen @ Feb 10 2009, 03:34 PM) One option that may help is to check off "Set to focus on toggle" in the Key Navigation properties for whichever button is bound to Enter. If you are using an event structure, read the numeric values in the event case for the OK button. Or, create a timeout case with the timeout wired to a shift register. Start with that shift register set to -1. In the event case for the OK button, set the timeout shift register to 0. All pending events will execute (for example, value change events on your numeric controls), then the timeout will occur. Put your code from the OK button event into that timeout case.

QUOTE (vultac @ Jan 28 2009, 05:26 PM) Have you looked at For and While loops?

QUOTE (sachsm @ Jan 21 2009, 10:00 AM) I'm going to guess that it came from the Datalogging and Supervisory Control (DSC) toolkit, which includes front panel controls for process objects (pipes, pumps, etc).

A couple of really quick comments, although this probably deserves a more detailed reply: - Spell LabVIEW with VIEW in capitals (that's the official name) - You don't need to list your major when you've already given it with your degree (ie, no need to put both "Master of Science - Bioengineering" and "Major in Bioengineering") - Remove "Programming" following names of computer languages in both your courses and skills sections. Similarly remove "Drawing" after CAD. - Remove the skills section entirely, or at least make it much shorter. There's a lot of overlap with both your technical courses and your past experience. Use the experience section to highlight actual use of your skills. The two skills you list as "Expert" are not improving your resume. Do you really want to tell people that your strongest skills are "M.S. product" (did you mean Microsoft Office?) and browsing the web and downloading files ("HTTP,FTP")? - Spell technique properly (it's not technic)

QUOTE (Marcus Törndahl @ Jan 15 2009, 05:09 AM) You need to make it a strict type definition.

QUOTE (Marcus Törndahl @ Jan 15 2009, 05:09 AM) You need to make it a strict type definition.

QUOTE (blitzkrieg @ Dec 14 2008, 01:49 PM) This isn't directly related, but is anyone else seeing a bug with this VI? I opened it in 8.6, did "Remove Sequence," and all the wires to tunnels in the sequence turned invisible. LabVIEW thinks they're still there, the run arrow isn't broken and if I put the cursor over where a wire should be the cursor changes and the right-click menu pops up appropriately, but there's no visible wire.

QUOTE (Marcus Törndahl @ Jan 12 2009, 04:34 AM) If you change the numeric representation of the ring within the type definition, say from I32 to U32, it will force all instances of that type definition to update.

QUOTE (Aaron L @ Jan 8 2009, 10:52 PM) EDIT to remove incorrect information. Those boards have a counter input but do not provide pulse generation. What you want is something like the PCI-6601, which provides digital IO and counter/timer channels with pulse generation outputs. A quick search on NI.com suggests that the least expensive USB device capable of pulse generation is the http://sine.ni.com/nips/cds/view/p/lang/en/nid/203189' target="_blank">USB-6221.