peteski

Hmmm, kind of like AI, except in this case the "I" doesn't necessarily stand for "Intelligence"... perhaps another "I" word? -Pete Liiva

Ah, an active Q-switch. I was just curious if it were some form of modulation we don't tend to use in the labs I work in here. Thanks for answering my query! :thumbup: If you get stuck with the counter/timer programming, feel free to post what you have in the forum here, and we'll see if we can help out. Good Luck! -Pete Liiva

Xander, Although this is not something I've played with, this link sends you to this forum's LabView FAQ that talks about using the parallel port. While you are there, there are plenty of other wonderful topics of LabView wisdom that I highly recomend you browse through. In general, pure software driven pulses tend to have much larger jitter and lower frequencies that hardware solutions, and if you need a software configurable high (up to 20MHz or so) low jitter TTL/CMOS style output, I would highly reccomend getting a some NI hardware with some counter/timers on it. They are very versitile and once configured they can operate independant of the computer's CPU. Counter/Timer's jitter specifications are (or at least close to) those of the oscillator driving them. Hope this helps, -Pete Liiva

Ahhh, so there must be a "n" drink minimum in the LAVA Lounge! Where n is a non-zero integer... Legacy of FORTRAN!?!? (I'm oddly compelled to offer that non sequitur...) -Pete Liiva

A pathway to fully implementing this and a very versitile option to try before going for Labview Real Time is to use the Counter/Timers on your PCI-6033E card. Once configured by the software, they operate autonomously and don't need to "lean" on the software during their operation. At that point, your jitter specifications fall to the clock used to run the counter/timer and become completely independant of the software. You can also trigger your AI sampling off of the counter/timer as well. In fact, if you need some form of delay between trigger and acquisition, you could have the laser trigger off of the rising edge and the AI sample trigger off the falling edge, and vary your pusle width to change the time alignment. Your limitation is that the maximum clock rate for the counter timer is 20 MHz. I will admit that programming the counter timers takes a little getting used to, but the following pictures show examples provided by NI that should get you started. Using DAQmx (more recomended) Using Traditional DAQ (less recommended) Just to give you fair warning, some of the more advanced counter/timer tricks will require the use of both counter/timers on the card. BTW, what kind of shutter are you using to modulate at 1 kHz, if you don't mind me asking? -Pete Liiva

Well, that's somewhat better, at least engineering wise. At least you are putting that available torque to SOME use, unlike the "barbie" application. Don't know if I would consider it an "elegant" design, though... But then again if those "blokes" using it are the designers, I would want to be caught using the word "elegant" in their presence! -Pete Liiva

Good God!! That thing just BOTHERS me on sooo many levels!!! Most of them engineering, and a few of them enviromental. I wonder if they have a catalytic converter in there - somehow I doubt it as it could take a while for a catalytic converter to get up to temperature if no significant load is applied to the engine. -Pete Liiva

Oh yeah, Baby! My first programming experience was on something that was very much like one of these (if not exactly this) in some form of Basic. Used to have some of those puched tape roles for programs. Later, cassette tapes were so much more convenient, and a 30 to 60 minute tape could hold LOTS of programs. I don't really miss them, though... -Pete Liiva

And do you know what port number it is listening to? That is as important in establishing a connection as knowing the IP address. -Pete Liiva

Seeing that China and India are in the "dot" column, I would suggest that "dot" is more popular. For what its worth. -Pete Liiva

Knex, I'm not sure how to interpret your results exactly. You seem to be using the "," to indicate the decimal place, and if so you seem to have readings which appear to be in the range of a few hundeths of a hertz. That is clearly not correct. If your "," is not the decimal palce and you outputs are really 158 Hz and 426 Hz, I would say that is almost believable, but seems to indicate that the two E strings are horribly out of tune. Those two E strings should be two octives apart which means that the "high" E should be 4 times the frequency of the "low" E, but if and only if they are well tuned. It is possible that the way you have provided the data to the tone analysis vi doesn't properly inform the vi as to what sample rate you are using. If so, it will not be able to give you accurate results. Could you post your code? -Pete Liiva

My wife and I are hooked on this too, and my wife is NOT a Sci-Fi nut (though I can reach that plateau from time to time ) It's a remarkable show that simply blows away the old Battlestar Galactica series. I remember watching the old series as a young teen, and loving every minute of it the old series, but a decade or so later I happened to see re-runs while on a business trip, and just... couldn't... stop... *cringing*... for days! I think I liked it when I was going through that phase of male adolecence that was rather well represented by Bevis and Butthead! -Pete Liiva

Folks, I just wanted to make a note that the specific PCI card linked to in the above quote does NOT work for Labview Real Time ETS v7.1. I can't speak to whether or not it does in Labview RT v8. The chipset used in the above card is the Intel 82541PI. A very similar card based on the Intel 82540EM DOES work with Labview RT ETS v7.1, and it can be purchased here. Even though they are cheap, the NICs usable for Labview RT ETS v7.1 are so specific, its rather crtitical to make sure the correct one gets selected. It is, of course, possible to get NI's combo GPIB and Gbit ethernet card, but that will cost you more. -Pete Liiva

Karlos, There is a saying about teaching someone to fish as oposed to just giving them the fish, so I'll suggest that you try the following: 1) With your web browser, go to www.ni.com. 2) Notice the search box in the upper right corner. 3) Put your error code in (DON"T leave the - sign in there!! The search engine will interpret that the wrong way! The "10243" is unique enough as it is.) 4) Press Go. I came up with 3 items when I just did that, but I don't know your hardware, application, or what you are trying to do beyond trying to configure a DIO port so I don't know which may pertain to you. After you check that, if that doesn't help, perhaps you want to post to this forum your program that is having trouble, and mention what hardware you are trying to address with the program. Good Luck! -Pete Liiva

Fred, It couldn't be the array size, 7200 items is not at all big! I've filled arrays to the point that I ran into RAM limitations, so lets say 300MB of free space, 8 bytes per array element, comes to about 37,000,000 array elements. Sure, the computer gets a bit testy in these cases, refuses to respond, etc, etc..., but never at a mere 7200! As Mike and Crelf said, post what you have and someone here ought to see the problem. -Pete Liiva

You know, in this case, I really think its the fact that the code is password protected that makes this so precious... -Pete Liiva

Crelf, Yeah, if a 1553 implementation had to share space with the CVS control on an FPGA, it could be rather painful. Doing 1553 like this would probably be a huge time sink, which is probably part of the reason the available vendor solutions tend to be so expensive. What little I know about 1553 tells me enough that I would not want to have to build something to do it from scratch! -Pete Liiva

Crelf, If you have the option, RS422 would be MUCH cheaper and easier. 1553 has a whole host of considerations, and as others have said here, the hardware is expensive. Now, that being said, it is a very robust interface designed to work no matter what. If you are designing for a system that must deal with a lot of RF interference and/or a rough and tumble environment, 1553 was designed with all of that in mind. For what its worth, I worked on a test setup for ground testing of an instrument that is presently in low earth orbit. The actual instrument itself used 1553 for its housekeeping data and RS422 for its science data. Over the last 3+ years in orbit, I don't think we have seen any significant problems with either interface as far as data integrity. If you are required to use 1553, I don't see why you couldn't take the data gathered by the 1553 card (do you know whether your role would be as Bus Controller, Remote Terminal, or Bus Monitor?) and

pesce, Looking at your diagram and reading your problem, I'm just about willing to bet that your "FBC" indicator is not really connected to the "fbc" output of the formula node, but is really just connected to your "x2" input of the formula node. If this is the case, it is obscured by the path of the wire being "underneath" the formula node. Try double clicking on the wire leading to your "FBC" indicator and the outline of where the wire "really" leads to should become apparent. Just a guess, -Pete Liiva

I concur with Aitor having to do with the "Matlab script node" and needing Matlab installed on the machine. I had done this once myself to do a 3-d parabolic curve fitting to acquired data, which was easily done with the combination. I just had to feed my array data into the script node, paste the Matlab code into the script node, and the output gave me exactly what I needed! If what you want is something that auto-magically convert a Matlab script into a Labview Diagram, I have certainly never heard of such a beast, though maybe through Labview scripting something like this is possible. On the other hand, if you have a Matlab script, AND you have Labview installed on your computer, BUT you don't have the Matlab APPLICATION installed on your computer, you could always manually program Labview to perform the same operations as the Matlab script. Just about anything you need to do in MatLab you should be able to do in Labview, sometimes with more effort and sometimes with less. Just my :2cents: -Pete Liiva

Phillip, I have to say that if I were going through a slow spell at work, I'd probably check out the NI hosted forum, but I'm a bit overwhelmed between Work and Home To Do lists. I find that there is a very high quality of information from very high caliber personnel in the LAVA forum which is largely unencumbered by any corporate affiliation. I would say that its going to be hard to beat that. Seems to me that we recently had an April fools joke that scared the *&%$ out of some of us along these lines. Now, if I could only get around to donating to LAVA... (procrastinate... procrastinate... pro.. -Pete Liiva

hlseck, If I understand you correctly, as you state things I don't think any "sampling theory" would be violated. I *think* you are talking about sampling a single channel at a rate of 1000 Hz, and that channel happens to have a 100 Hz signal on it. If you have a loop reading one sample at a time, as long as the card is reading and buffering the acquistion AND the loop on average can read a single sample within a millisecond or less, then everything should work fine. If on the other hand, you have set the DAQ card to trigger on on the 100 Hz signal and you only grab one sample after each trigger, regardless of the 1000 samples per second, you would have "slaved" your acquistion to the 100 Hz characteristic of the channel. This would be a thing to avoid unless you have a good reason to do this (and there can be VERY good reasons to do things like this!) More appropriately, in a well buffered system, you would be better off downloading several points at a time so that the overhead of buffer manipulation and loop control doesn't get the better of your processors resources. Unless you have a system that needs to react within 1 ms to a particular value, you may want to download, say, 1000 points at once as a waveform, which could be done by the loop once per second. If you are using NI hardware with NI-DAQ drivers, much of the common buffering is already programmed into the device drivers. -Pete Liiva

[humor] Michael, So, the "Set Pen State.vi" shows as number one no matter what... Could it be the vi might have been written by a Penn State alumni?!? :laugh: So, somehow I just don't see a problem with that... [/humor] -Pete Liiva

Fred, Are you sure you are adressing the port correctly? Also, are you sure that there is no other software that is blocking NI from accessing the port? I might suggest this as a sanity check. Without having Labview open, try communicating with your RS232 connected device with Hyperterminal. If you can't get that to work, then Labview would probably never be able to see anything at the port either. After writing the above, I checked the NI website and found the following statement about the demo: Maybe this is your problem? -Pete Liiva

But why stop at the third dimension?!? The fourth dimension could really allow for some very cool tricks. :thumbup: If done right, you might never have to rush for a deadline again. I'd hate to see what would happen if done wrong, though... Wait a second! Wasn't there another thread that perhaps eluding to this?!? -Pete Liiva p.s. Do we have any string theorists in the forum? If so, this could get real... complex...