01-12-2012 12:09 PM
Hello
I have a bicycle/DC generator displ;ay setup for the public to view here at the university. I have a vi that will count revolutions, keep time and calculate distance in meters. I used a bike computer. I cutoff the puter, juice up the pick up and when the magnet on the spoke goes by the voltage drops from whatever it is to 0v. I have the vi counting revolutions, calculating distance (known circumference of tire) in meters and a timer set for 5 minutes. It is hard puching against the generator when on the bike so a user will only be on it for a few minutes. I had to add a delay to count just one revolution when the boolean goes from Hi to Lo. Without this delay, the count can run more than one tick.
The generator output is 0-12vdc. A user can pound out more volts, but I am not interested in that. I want to display calorie per watt, volts, distance, power etc....In the image below you can see the display table. The watts are displayed as 50W, 75W, 100W, 125W, 150W and 175W respectively as the volt trip the relays - and the lightbulb goes on. You can also see an op amp circuit. This is to shape the DC generator output from 0-12v to 0-10v for Labview (the generator output is negative from my 2nd stage inverting amp to the DAQ card). My signal conditioning of the DC generator output is perfect. The display table is perfect. As can be 🙂
My problem is when I run the vi, nothing is displayed on the front panel gauge for DC volts out.
I am not very familiar with consumer/prodeucer programmimg. I really need someone to help me develop this. I would like to use what I have, but am not adverse to a complete change.
Anyone?
Thanking you all in advance,
NK
Another thing. I am using a battery supply for rail to rail volts for the op amps (w/virtual ground). See image.
Do I need to ground my DC generator signal in to the card. Chasis gnd? Or none at all? I am not sure about that.
01-12-2012 01:08 PM
Your program is could effectively be refactored as a state machine. It's not a bad overall effort, mind you, but you should do some research on state machines (start by searching this forum).
Some general programming things (this is not everything I see, but I'm a bit pressed for time):
Your FOR loop does nothing. It will either iterate once (in which case you don't need it) or zero times (in which case you REALLY don't need it). And why are you ANDing your "start" button value with a T constant? Just use the boolean value by itself. Same thing.
You can eliminate your local variables and use a shift register instead. (If you don't know about shift registers, that would be another terrific thing for you to learn.) You do some odd things with that "revolutions" value -- why the local write variable? just wire the final value straight to the indicator and get rid of the local write -- and some strange things with your "reset" button value. You're converting the boolean to a number (1 or 0), then comparing it to a value of 1...in other words, you're checking to see if the value is T. The boolean value itself already tells you that. Just use the boolean by itself.
You don't need to invert your "cadence" value before inputting it to the "select" function. Wire the boolean value in, and switch the numeric operations (so that the "+1" is input to the F terminal and the previous value is input to the T terminal). Same thing as what you have, but cleaner.
I don't really understand your "time elapsed" loop within another loop. Exactly what are you trying to accomplish with all that? Is your elapsed time indicator supposed to be somehow related to your DAQ operation? Right now it is not.
Now, your DAQ things:
You are using all of the default values for your physical analog channel, which means that the channel is configured for a range of -5V to 5V (which I'm pretty sure is not what you want) and the wire configuration is set to "default". I don't know what board you're using, so I don't know what the default channel config for that board is, but you do need to make sure it matches your actual wiring. Are you wired as differential? Referenced single-ended? You ask about whether you need to ground. The DAQ board does need some kind of reference in order to measure a voltage.
Have you put a multimeter on your analog input terminals to see if you actually do have a voltage there?
Have you set a probe on the wire to your "generated volts" indicator to see what the DAQ board is measuring on that channel?
You are using "1Channel N Samples" but you don't configure a clock so you won't be grabbing N Samples. Use "1Channel 1Sample" instead.
Currently your "set delay" is set to 15msec. You don't need a loop iteration that fast. Set it to 500msec or thereabouts. You'll grab a DC value and update your front panel every 500msec, which should be more than often enough. You're not measuring a rapidly-varying phenomenon.
Hope some of this points you in a direction. As I said, this is not at all a bad effort. It just needs some cleanup and a better architecture. Everyone starts somewhere and you're doing fine.
01-13-2012 06:36 AM - edited 01-13-2012 06:42 AM
Hey thanks Dianne!
I appreciate the input. I think I will redesign my program. I just started reading the State Machine info on the NI site. I will see what I can get from that and try again.
Thks again 🙂
Ned
I have a question.
If I let the timer dictate the main While loop (so do all this while the time is ticking), will this architecture be able to deal with the revolution sensor AND the volts in (from the generator) in real time at the same time, or do these routines get processed sequentially?
01-13-2012 12:35 PM
Hi Ned,
I'm not 100% sure I understand your question, but I'll try to answer and if my answer doesn't make any sense, let me know and we'll figure it out.
I believe that you are asking whether or not the revolution sensor (your digital input) and the analog input can be read in parallel the way they are now.
Of course they can. Just put both "read" operations in the same state of your state machine. When the set time has elapsed, is your DAQ operation supposed to stop? If so, you will want your timer in that state too. (there are other ways to set things up, but I don't want to toss too many things at you at once...when you're comfortable with your state machine, we can start talking about things like notifiers and queues)
Did I interpret your question correctly?
Keep plugging away at it, and holler if you have more questions! I think you'll like state machines -- they're really flexible and powerful and you can do a lot with them.
d
01-13-2012 12:55 PM
Hey Diane
Yes you did interpret my question correctly!
Thanks for this:
'....Of course they can. Just put both "read" operations in the same state of your state machine. When the set time has elapsed, is your DAQ operation supposed to stop? If so, you will want your timer in that state too. (there are other ways to set things up, but I don't want to toss too many things at you at once...when you're comfortable with your state machine, we can start talking about things like notifiers and queues)...'
I do want to be able to start the timer on a push of a button - so no (timer and revolutions --> and other calculations based on revolutions and subject data) will occur after the subject is on the bike and has pedalled a bit. I do want revolutions and timer action to start and finish at the same time. I want the subject to see the volts gauge needle move in real time as soon as they pedal - so they can get a feel for the resistance level of the DC generator.
Yes I want everything to stop when time is up. Then reset everything to default after data has been viewed on the front panel (for the next subject). Default being volts out on gauge. Timer off. Revolutions off.
I am going to rewrite the program with this in mind. Thanks for your help Diane.
Have a great weekend
NK
Cheers from the Caribbean of Canada
01-14-2012 01:06 PM - edited 01-14-2012 01:07 PM
Hi Ned,
Glad to hear it!
For your state machine, you'll probably want an initialization state where you reset all the indicators and (perhaps) initialize your DAQ tasks. Not start them, mind you -- initialize them. You can pass the DAQ task references to different states by using shift registers.
Then you'll want an idle state, where your program basically does nothing -- it's waiting for a button push.
Then you'll want a run state, which your program enters when someone presses the button. That's where you'll be doing your data acquisition, timer countdown (or up), etc.
You might get really fancy and add an error state (as a professional programmer, this is a must for me -- I think it would be a really good idea for you also), which your program enters if an error occurs.
You'll also want a quit state, where you can reset all the indicators, close the DAQ tasks, etc. before terminating your program.
So there's a basic framework to get you started. Have a look at the event structure too -- it's really awesome for handling things like button presses.
So...shift registers, state machines, event structures, and maybe queues and notifiers (you'll like those too). Got all that?
Have a terrific weekend!