Jeff Plotzke

QUOTE(vee_yar @ Mar 14 2007, 10:06 AM) Here's a few suggestions from playing around with your VI: -You may want to use the 'Sound Output Wait' VI after your Output Write VI to hold your loop until the sound has completed playing. After your Sound Output Wait, you can use a Wait (ms) VI to wait a given amount of time after your sound is output. This will help keep the duration between pulses equal. -Generate the amount of the sine wave you want in your Simulate Signal -- For example, right now you have it set for a simulated 10kHz acquisition and generating 5k points. Therefore, you'll get 0.5 seconds of a sine wave. Make sure that you generate as long as a sample as you need. -In the Output Configure VI, set the 'number of samples per channel' input to the number of points you're generating with the 'Simulate Signal' VI. If you leave this at 10000 and you give the sound output 5000 points, the sound card will actually output 5000 points that you gave it, then 5000 points of nothing. So, if you use the Output Wait VI, it actually waits for 10000 points. Therefore, it's probably a good idea to make sure that these two numbers match. -I also had much better timing switching to finite samples on the Output Configure. That said, I really wasn't able to get the duration of the time sample to change during my tests. Try out these suggestions and let us know if this doesn't fully correct it.

QUOTE(Doon @ Mar 14 2007, 07:10 PM) Yes, but writing a generic text-based parser will probably not be very generic. You may want to look into using MSXML -- It's an ActiveX object that you can use in LabVIEW. I've built a set of VIs that use this object to read/write XML files. It takes a while to get up to speed on all the methods/properties of MSXML, but after that, it's super easy to use!

I haven't tried it, but inside the 'Sound Output Set Volume' VI on the Sound Output palette, there's a subVI inside that gets the 'channels' of a sound device and sets the volume of all of them. Does each 'channel' refer to a speaker (ie, left/right). What if you use this VI and modify it to allow for two inputs, one for left speaker volume and one for right speaker volume?

QUOTE(spacetoon34 @ Mar 13 2007, 12:20 AM) Are you trying to embed the subVI's panel into the main VI or are just looking for a pop-up window? If it's the pop-up, size your VI's window to the size you want. If it's embedded, you'll use the entire size of your subpanel, you could change the height and width of your subpanel based on the height and width of the subVI you're opening, and then re-size your main VI's window from that... but it would be much easier to use a pop-up subVI instead of this.

QUOTE(crelf @ Mar 10 2007, 09:52 AM) Yup -- ID3v1 is only 128 bytes at the end of the file, however you're limited to 30 bytes for title, artist, etc. ID3v2 gives much more flexibility by assigning "frames" of information of a given type. These frames can be variable length, so you can store text, images, even other MP3 files inside the tag! These of course of much harder to read directly, since each field isn't in a static position in the file. If you're looking for the exact specs, ID3.org is a good site to visit: http://www.id3.org/Developer_Information''>http://www.id3.org/Developer_Information' target="_blank">http://www.id3.org/Developer_Information

QUOTE(Guia @ Mar 8 2007, 07:38 AM) You could use a polymorphic VI that has different output types, and create one for every type you want to use. You'd also have to manually switch between them, or create a 'type' input terminal that would pick with instance you're using. Not the elegant solution you're looking for, but it's less confusing than XNodes

QUOTE(crelf @ Mar 6 2007, 10:15 AM) I agree -- and especially for those of us with static IPs, I'm not a fan of those boards that broadcast my IP to every member...

QUOTE(lraynal @ Mar 6 2007, 09:57 AM) I agree with TiT, one thing to try is to disable active transfers -- It will probably be less headache in the long run too in case you move to a network which has a firewall and doesn't support active FTP. Other than that, I've also seen huge speed improvements from the 7.1 internet toolkit to the 8.20 version. I'm doing a project now that I'm transfering hundreds of MBs of data from a RT system to a Windows Host, and I'm getting great speeds using 8.20. I was quite scared it having seen the extremely slow transfer rates in 7.1 before. I'm not sure what changed between the versions, but I'm convinced that something happened!

QUOTE(tcplomp @ Mar 2 2007, 04:30 AM) I use the 'Portal' page all the time too -- Luckily I have it bookmarked and it still works... But I was surprised when I went to click it today and it was gone... Can it come back? Thanks Michael! QUOTE(Jeff Plotzke @ Mar 2 2007, 10:18 PM) I use the 'Portal' page all the time too -- Luckily I have it bookmarked and it still works... But I was surprised when I went to click it today and it was gone... Can it come back? Thanks Michael! Oops... Now I notice that you moved it over to the right and didn't take it away... that works for me!

QUOTE(jbrohan @ Mar 1 2007, 02:36 PM) You should submit this to the LAVA Code Repository -- It's there to share LabVIEW code, just like this!

QUOTE(alnaimi @ Mar 1 2007, 01:48 PM) There's (at least) two ways to synchronize DAQ inputs to outputs: -Using a start trigger between both your input and your output and using buffered reads. This way, you can set the exact waveform to output, trigger both the output and the input, and read all your data after you've outputted the entire waveform. However, since you're not using NI equipment, I'm not sure if this will work. This way is shown in the one example we sent you. -A slower way is to do point-by-output output and input, which would work with any DAQ card. Each iteration of your loop you'll output a single value to your analog output. Then, you read your input with an analog input. You can use dataflow to accomplish this by making sure you have at least one wire (most likely your error wire) between your analog output and analog input. It's very important that you ensure that you output before you read your input... If you've never done data acquisition before, you'd really learn from getting a LabVIEW DAQ manual. There's also numerous example on ni.com. I'd recommend playing around with those to learn how they work. That said, feel free to come to LAVA with questions and we'll help you -- the site is here for collaboration, but LAVA members won't write your VIs.

QUOTE(alnaimi @ Mar 1 2007, 08:18 AM) I've never used Keithley DAQ, so I can't help you there. However, the topic can be applied over any type of data acquisition. Without doing synchronization on the DAQ Card level, you need to make sure that you generate one sample from your output and then read one sample from your input after you set your analog output value.

QUOTE(syrus @ Feb 28 2007, 08:27 PM) Absolutely! I agree -- It's much better than 8.0.1

QUOTE(alnaimi @ Feb 28 2007, 01:23 PM) Here's the example VI in LV8 format.

QUOTE(Mike Ashe @ Feb 28 2007, 09:41 AM) Nah... being under 4 inches allows us not to have an office... we just work inside an empty PXI chassis

QUOTE(alnaimi @ Feb 28 2007, 08:39 AM) You'll absolutely need synchronization between your output and your input. Otherwise, you'll have no way to accurately build your XY graph. In the VI you posted yesterday, there wasn't any synchronization -- You output 100 samples of a 10Hz sinewave and read the input each iteration. There's also no guarantee that you'll read your input after you set your output. For this reason, you need to think about these issues in this VI.

QUOTE(alnaimi @ Feb 28 2007, 01:28 AM) Are you getting real values in for your current? Have you probed your analog input to verify? The graph won't show what you're expecting if you don't actually acquire that data.

QUOTE(Joost van Hamond @ Feb 27 2007, 03:55 PM) Joost, Just a thought I had that you'll probably need to watch out for... Depending on how (which browser) you render the webpage in, you'll probably get different results. There's many differences between the way Internet Explorer, Firefox, Opera, etc. renders pages (especially once you get into style sheets and such) that could throw off your application and give you different results. Also, if you're planning to distribute this application, most browsers allow the user to override color settings (like background and text colors) for handicapped users. Just something to think about...

QUOTE(French LVer @ Feb 27 2007, 09:22 AM) Great -- Thanks again for all the suggestions! I think this is how I'm going to implement it. I'll let you know how it turns out!

QUOTE(alnaimi @ Feb 27 2007, 10:04 AM) As tcplomp suggested, can you post a version of your VI? We can't fully help you until we really see what's going wrong.

QUOTE QUOTE It depends if you need a fast response on a 0 - 100% command. P regulation is loose and I regulation is only on fine-tune valve. Thank you both for your help! I do know that the system has a slow response rate; as for stability, I'm not sure. A "fast" response isn't necessary in most cases. So, to make sure I understand completely, I should be able to run control on both valves in parallel, using a P-controller on the coarse valve, and a I-controller (perhaps with a very slight P) on the fine valve. Correct?

QUOTE(crelf @ Feb 26 2007, 09:02 PM) The "slowly adjusting back the fine valve to 50%" part logic frightens me a bit... especially while doing PID control of the system. I agree that in theory your plan should work fine... but theory never likes to play nice with me...

QUOTE(GregSands @ Feb 26 2007, 05:39 PM) That's right, Greg. Shared Variables don't keep their typedef properties. Once you create a Shared Variable from a custom control, the variable takes on that control as 'custom control' without any link to the typedef you created from. This can be a little annoying at times, especially when you drop down a shared variable and create a constant from it -- Watch out -- The constant you create is not connected to your typedef!

QUOTE(crelf @ Feb 26 2007, 07:57 PM) I understand what you're saying -- That's a good idea. I set the fine valve back to 50% so the next time I switch back to fine I have my "full-range" again. My worry was that if I got to a setpoint with a fine valve setting of 10% open or so, then had to jump to my coarse, the next time I jumped back to my fine control, I only had 10% to play with without fully closing the valve and having no where to go. So, while writing this, perhaps it makes since to have it switch when it's a certain delta away from the setpoint. Using an example of the coarse valve supplying a max flow of 100 liters/min and the fine valve supplying 10 liters/min, I want to make sure that I never switch to the fine valve if I'm more than 10 liters/min away from my desired flow. Using a percentage of setpoint may start introducing some problems... Does this make sense?

This isn't exactly LabVIEW, but hopefully someone has done this... I'm trying to do PID control of a system. The input of the system is two proportional valves -- One valve is a large coarse valve, the other is a smaller fine-tune valve. My system must use these two valves in order to achieve a desired flow of the overall system. My thought is this: I monitor the feedback to see if I'm within x% (x to be determined) of my desired setpoint. If I am not, I set my fine valve to 50% open and adjust my coarse valve using PID until I'm within the x%. Once I get within the x% of the setpoint, I switch over to another PID loop, maintaining the current value of the coarse valve, and use the fine-tune valve to home in on my setpoint. However, if I detect that the setpoint drifts out of the x%, I set my fine valve back to 50% and then re-adjust with my coarse. Both PID loops would be running constantly, however my logic would determine if I use the current values or maintain previous values to the system. My worry is the switch points of this logic -- How will the PID react? My hope is that since I'm constantly inputting and running both PID controls, my output won't jump when switching. I understand that I'll definitely need hysteresis so that my system doesn't switch back and forth at the x% point. Has anyone done anything similar that could give me a few tips? Thanks all!