JohnRH

QUOTE (MikaelH @ Jan 22 2009, 11:49 PM) NI has "LabVIEW 64bit Pioneer" available under their beta test program. (go to "www.ni.com/beta") If beta software is an option, then you may find this helpful.

OK, I'll try to write this without sounding too desperate. If any of you are interested in working in Charlottesville as a hardware test engineer, please contact me. The most important requirement is that you are either a US Citizen, or have your "Green Card" (we are a defense contractor). Some familiarity with electronic circuits is also necessary. (basic circuit analysis stuff) Obviously, you should also know LabVIEW. You can reach me by email at jhoward at niitek dot com.

QUOTE (crelf @ Sep 11 2008, 03:47 PM) Unfortunately it has to be optical. The UUT has fiberoptic transceivers which are controlled by an FPGA, which impliments a completely custom Manchester encoded data signal. If necessary, I'll design a small fiber-optic interface card which I can control with a DIO card. But I would rather not re-invent something that might already exist.

When adding/subtracting values of 0.1 or 0.01 using doubles, you will often have VERY small rounding errors. At a minimum you'll probably have to decide on a value that you will consider close enough to zero.

I think this is a long shot ... Does anyone know if someone makes an optical digital IO card? By this I mean something with the same function as a regular digital IO card, but with optical transceivers rather than regular digital IO lines. Thanks!

QUOTE (Michael_Aivaliotis @ Sep 3 2008, 02:49 PM) Or else "Punch buggy! No punch back!". There must be many variations on the theme.

I wonder if NI will eventually extend their Graphical System Design concept from just embedded systems to more complete systems - along the lines of this discussion. I think they already own Micro-Sim. It seems like a fairly logical extension.

For those of you that do electrical system design. What are the "best" tools for doing top level block diagrams? Currently I use VISO, but it seems like there has got to be something better! My systems usually consist of several 'components' (circuit boards and/or COTS components), contained inside a box, with lots of cable, connectors, and terminal blocks. What would be really cool is something in which I could activly link the blocks to the lower level design detail. (circuit diagrams, interface specs, LabVIEW FPGA code, LabVIEW software, etc.)

QUOTE(tcplomp @ Apr 30 2007, 03:33 PM) Looks like I'm going to have to familiarize myself with OpenG builder! (I've often wondered what advanatages it had over the regular NI App builder.) In the mean time, it suddenly dawned on me that there is no reason I can't build the dynamic VI into it's own executable and launch it from the main app as a system command. (the vi is just a stand alone UDP server) At least for now this gets things working. Thanks! John

Hi, After beginning to wonder if there is some kind of evil LabVIEW gnome trying to mess with my head, I found this thread and think the light might be starting to turn on - or at least flicker. (for some reason I am having a really hard time getting my head around this problem) I'm in a situation where I am dynamically calling a rather complex vi, which has several layers of sub-vi's. If I am understanding the posts to this thread correctly, I am going to need to either make the dynamically called vi flat (no sub-vi's), or else build some kind of source distribution. (am I missing something, or shouldn't this be considered a bug?) With much difficulty, I guess I could 'flatten' the vi, but the amount of work to do so makes me very interested in the second option - building something. Finally to the questions. Do I build a source distribution which contains only the dynamically called vi? To do this, do I need to create a new project which only contains the dynamic vi? (am I even headed in the right direction?) Sorry for the ignorant questions. Any guidance is GREATLY appreaciated here! Thanks! John

I'd have to rate this as probably the most pain free upgrade I've ever done. (I've done them all from version 4.something on)

I noticed that the LV Runtime engine that is included with NI-VISA 4.1, claims to be version 8.2.1. (NI-VISA 4.1 is available for download) Could this be correct?

QUOTE(gmart @ Mar 16 2007, 02:00 PM) This is it! If I select the icon file then click OK rather than double clicking the icon file, it works without locking. Thanks! John

This just happened to me as well. Never had this problem until I changed the .ico file in my project. Now every time I try to change from the default icon, the project explorer locks completely, and I have to end task to restart. From what I inderstand, LabVIEW didn't lockup like this for the rest of you? Am I the first to have it completely lock up like this? Is this new bug behaviour that I should bring to NI's attention? Thanks! John

QUOTE(John Rouse @ Mar 15 2007, 01:11 PM) I also believe that simply learning to relax while you work (both physically and mentally) makes a HUGE difference. (It may actually take practice to learn to do this.) Also - pay attention to minor physical discomforts. Some people ignore them because they are minor, but over time these minor discomforts can turn into serious and perphaps permanent injuries. Then of course, as already mentioned - exercise! It doesn't have to be strenuous or lengthly to make a huge difference. As for hardware, I have yet to find a mouse that is really ergonomic. (I find trackballs too difficult to program with)

QUOTE(REM1 @ Mar 14 2007, 02:15 PM) I am pleased to see at least one example of practical common sense being more important than a quarterly deadline. (one of the pet peaves I no longer have to deal with, now that I am an independent contractor)

QUOTE(Rick @ Mar 14 2007, 11:54 AM) I was wondering about that as well. (I guess 'quarterly' doesn't necessarily mean every 3 months!)

QUOTE(Jim Kring @ Mar 13 2007, 04:29 PM) I feel better already.

QUOTE(Tomi Maila @ Mar 13 2007, 03:38 PM) I am possibly (hopefully!) making an incorrect assumption. I inferred this from a recent post by an NI member regarding one of the recent bugs discussed in the LV8.2 bug forum. They mention that the specific bug mentioned will be fixed in the next major LabVIEW release. (I think it was the TDMS file reference bug) I really hope that I am wrong, and that there will be an interm bug fix release.

Hello all! I've been absent from the LV scene for over a year now, and just got back into it with some contracting work. For this contract I am required to use the latest version of LabVIEW (currently 8.2). Based on my passed experience with LabVIEW, I've been very surprised - in some cases shocked - by all the bugs that are biting me on this project. What surprises me even more is that it seems that NI is not planning to fix these bugs until the next major release of LV! (which of course will probably not be a free upgrade) Am I alone in thinking that LV 8.2 is a little more 'buggy' than most? Perhaps it is simply that my project is more complicated than the others that I've worked on (thus a higher probablilty of encountering bugs). On the other hand, maybe other developers are getting as frusterated as myself with this version of LabVIEW? Does anyone with more experience than myself on larger projects have an opinion on this? I guess I am feeling a little burned, but wondering if I am really justified in feeling this way. Thanks for the feedback! John

That's the version I was referring to as well.

Are you checking this bug list against the newest version of LabVIEW very extensivly? Would it be worth coordinating effort to get them all checked out? (I could help, but no sense duplicating effort)

I heard there are performance problems when accessing many (hundreds) of tags. Bryan's worst case is something like 250 tags on a single server computer. With 63 server computers and one or two client computers. Having to put the DSC engine on all 63 computers is what we are trying to avoid. (I only know this because Bryan and I are working on the same project) I wonder if we could use datasocket on each of the server computers, to make the data available to the client computers in a different form (plain UDP or something)? This would also allow us to put some intelligence into the server computers, which could minimize the traffic over the network to the client computer. Hmmm...

About the only thing I can think of is to replace your text wth graphics. Not that bad for simple stuff, but a pain in the but for anything containing a lot of controls and indicators.

I had a similar problem back when I was working with LabVIEW 5.0. I believe the problem went away when upgrading to LabVIEW 5.1? (it was a long time ago, so hard to remember accurate details) Thanks to a corporate email server upgrade, I no longer have the email I exchanged with NI back then. John